By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
454,435 Members | 1,414 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 454,435 IT Pros & Developers. It's quick & easy.

A problem with typedef

P: n/a
the code is as follows:
#include <iostream>
using namespace std;

typedef double DOUBLE;

class Screen
{
public:
typedef int DOUBLE;
DOUBLE OK;

};

int main()
{
return 0;
}

the mingw(with the gcc 3.4.2) give an error:
changes meaning of `DOUBLE' from `typedef double
but the vc7 gives OK. so which one is right?

Dec 22 '06 #1
Share this Question
Share on Google+
13 Replies


P: n/a
On 22 Dec 2006 06:13:40 -0800, "mi*********@gmail.com"
<mi*********@gmail.comwrote in comp.lang.c++:
the code is as follows:
#include <iostream>
using namespace std;

typedef double DOUBLE;
Why?
class Screen
{
public:
typedef int DOUBLE;
Why?
DOUBLE OK;

};

int main()
{
return 0;
}

the mingw(with the gcc 3.4.2) give an error:
changes meaning of `DOUBLE' from `typedef double
but the vc7 gives OK. so which one is right?
What do you mean by "give an error"? A compiler is allowed to issue
any sort of messages it wants to, as long as it issues diagnostics
required by the standard. Does it produce an executable? If it does,
it is conforming to the standard in this respect. There is no
requirement that it do so quietly.

--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://c-faq.com/
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++
http://www.contrib.andrew.cmu.edu/~a...FAQ-acllc.html
Dec 22 '06 #2

P: n/a
kk
I think VC compiler should give an error, but it may not. Because you
have typedef DOUBLE in defferent scope, one in global and other one in
class.

mi*********@gmail.com wrote:
the code is as follows:
#include <iostream>
using namespace std;

typedef double DOUBLE;

class Screen
{
public:
typedef int DOUBLE;
DOUBLE OK;

};

int main()
{
return 0;
}

the mingw(with the gcc 3.4.2) give an error:
changes meaning of `DOUBLE' from `typedef double
but the vc7 gives OK. so which one is right?
Dec 22 '06 #3

P: n/a
there is no why. I just read the C++ Primer 4th. In Page 448 ,there
are something about the typedef in global scope and in class scope.I
just have a try about the book's example code in the popular compilers.

BTW: if the typedef in class is written behind the "DOUBLE OK", both
compilers give OK.
there is no compile error.But if the typedef is written before "DOUBLE
OK", the mingw give a compile error.

And whatever behind or before , the Intel CPP compiler , VC7 and Comeau
all give OK!
"Jack Klein д
"
On 22 Dec 2006 06:13:40 -0800, "mi*********@gmail.com"
<mi*********@gmail.comwrote in comp.lang.c++:
the code is as follows:
#include <iostream>
using namespace std;

typedef double DOUBLE;

Why?
>
class Screen
{
public:
typedef int DOUBLE;

Why?
DOUBLE OK;

};

int main()
{
return 0;
}

the mingw(with the gcc 3.4.2) give an error:
changes meaning of `DOUBLE' from `typedef double
but the vc7 gives OK. so which one is right?

What do you mean by "give an error"? A compiler is allowed to issue
any sort of messages it wants to, as long as it issues diagnostics
required by the standard. Does it produce an executable? If it does,
it is conforming to the standard in this respect. There is no
requirement that it do so quietly.

--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://c-faq.com/
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++
http://www.contrib.andrew.cmu.edu/~a...FAQ-acllc.html
Dec 22 '06 #4

P: n/a
mi*********@gmail.com wrote:
the code is as follows:
#include <iostream>
using namespace std;

typedef double DOUBLE;

class Screen
{
public:
typedef int DOUBLE;
DOUBLE OK;

};

int main()
{
return 0;
}

the mingw(with the gcc 3.4.2) give an error:
changes meaning of `DOUBLE' from `typedef double
but the vc7 gives OK. so which one is right?
As far as I can tell, your code is correct, There are two typedefs of
DOUBLE, but that's OK. One is ::DOUBLE, and the other is Screen::DOUBLE.

Now as to why you'd want to call an int a DOUBLE, that's another matter.

For what it's worth, Comeau online likes it.

Dec 22 '06 #5

P: n/a
red floyd wrote:
>
Now as to why you'd want to call an int a DOUBLE, that's another matter.
To experiment with name scoping and typedefs.

--

-- Pete
Roundhouse Consulting, Ltd. (www.versatilecoding.com)
Author of "The Standard C++ Library Extensions: a Tutorial and
Reference." (www.petebecker.com/tr1book)
Dec 22 '06 #6

P: n/a
Pete Becker wrote:
red floyd wrote:
>>
Now as to why you'd want to call an int a DOUBLE, that's another matter.

To experiment with name scoping and typedefs.
I wasn't arguing with the name scoping part. I was commenting on the
naming conventions.

Dec 22 '06 #7

P: n/a
red floyd wrote:
Pete Becker wrote:
>red floyd wrote:
>>>
Now as to why you'd want to call an int a DOUBLE, that's another matter.

To experiment with name scoping and typedefs.

I wasn't arguing with the name scoping part. I was commenting on the
naming conventions.
Naming conventions aren't important when you're doing quick and dirty
experiments.

--

-- Pete
Roundhouse Consulting, Ltd. (www.versatilecoding.com)
Author of "The Standard C++ Library Extensions: a Tutorial and
Reference." (www.petebecker.com/tr1book)
Dec 22 '06 #8

P: n/a
Pete Becker wrote:
red floyd wrote:
>Pete Becker wrote:
>>red floyd wrote:

Now as to why you'd want to call an int a DOUBLE, that's another
matter.
To experiment with name scoping and typedefs.

I wasn't arguing with the name scoping part. I was commenting on the
naming conventions.

Naming conventions aren't important when you're doing quick and dirty
experiments.
Well, if we are in picky mode, then let me point out that
perhaps that's why red floyd wrote "that's another matter".

- J.
Dec 22 '06 #9

P: n/a
Jacek Dziedzic wrote:
Pete Becker wrote:
>red floyd wrote:
>>Pete Becker wrote:
red floyd wrote:
>
Now as to why you'd want to call an int a DOUBLE, that's another
matter.
>

To experiment with name scoping and typedefs.
I wasn't arguing with the name scoping part. I was commenting on the
naming conventions.

Naming conventions aren't important when you're doing quick and dirty
experiments.

Well, if we are in picky mode, then let me point out that
perhaps that's why red floyd wrote "that's another matter".
Thanks, Jacek. I guess I'll have to put smileys in next time.
Dec 22 '06 #10

P: n/a
Pete Becker wrote:
>I wasn't arguing with the name scoping part. I was commenting on the
naming conventions.
Naming conventions aren't important when you're doing quick and dirty
experiments.
They are important when doing experiments in public forums, to avoid this
messages.

--
Salu2
Dec 22 '06 #11

P: n/a
mi*********@gmail.com wrote:
the code is as follows:
#include <iostream>
using namespace std;

typedef double DOUBLE;

class Screen
{
public:
typedef int DOUBLE;
DOUBLE OK;

};

int main()
{
return 0;
}

the mingw(with the gcc 3.4.2) give an error:
changes meaning of `DOUBLE' from `typedef double
but the vc7 gives OK. so which one is right?
Neither compiler is behaving incorrectly according to the C++ Standard.

Since the name DOUBLE evaluates first as a typedef for double in the
context of its declaration but evaluates as a typedef for int when
evaluated in the context of the completed Screen class - the program is
ill-formed. However - even though the program is ill-formed, the
Standard states that a diagnostic is not required for this type of
error. So whether the compiler informs you that the program is wrong,
is a decision left up to whoever wrote the compiler.

Greg

Dec 23 '06 #12

P: n/a
Greg wrote:
mi*********@gmail.com wrote:
>the code is as follows:
#include <iostream>
using namespace std;

typedef double DOUBLE;

class Screen
{
public:
typedef int DOUBLE;
DOUBLE OK;

};

int main()
{
return 0;
}

the mingw(with the gcc 3.4.2) give an error:
changes meaning of `DOUBLE' from `typedef double
but the vc7 gives OK. so which one is right?

Neither compiler is behaving incorrectly according to the C++ Standard.

Since the name DOUBLE evaluates first as a typedef for double in the
context of its declaration but evaluates as a typedef for int when
evaluated in the context of the completed Screen class - the program is
ill-formed. However - even though the program is ill-formed, the
Standard states that a diagnostic is not required for this type of
error. So whether the compiler informs you that the program is wrong,
is a decision left up to whoever wrote the compiler.
That doesn't sound right, but I haven't looked it up. My recollection is
that this pass-and-a-half rule was intended to invalidate changing the
type after it was used. So if the typedef for DOUBLE inside Screen
occurred after the definition of OK it would violate the rule, but not
before. I think the confusion comes from "the context of the completed
Screen class". That's not the context where the class is defined (where
DOUBLE is a synonym for double), but the context at the end of the
definition of Screen (where DOUBLE is a synonym for int). Since all the
uses of DOUBLE inside Screen saw it as int, it's okay.

--

-- Pete
Roundhouse Consulting, Ltd. (www.versatilecoding.com)
Author of "The Standard C++ Library Extensions: a Tutorial and
Reference." (www.petebecker.com/tr1book)
Dec 23 '06 #13

P: n/a
Pete Becker wrote:
Greg wrote:
mi*********@gmail.com wrote:
the code is as follows:
#include <iostream>
using namespace std;

typedef double DOUBLE;

class Screen
{
public:
typedef int DOUBLE;
DOUBLE OK;

};

int main()
{
return 0;
}

the mingw(with the gcc 3.4.2) give an error:
changes meaning of `DOUBLE' from `typedef double
but the vc7 gives OK. so which one is right?
Neither compiler is behaving incorrectly according to the C++ Standard.

Since the name DOUBLE evaluates first as a typedef for double in the
context of its declaration but evaluates as a typedef for int when
evaluated in the context of the completed Screen class - the program is
ill-formed. However - even though the program is ill-formed, the
Standard states that a diagnostic is not required for this type of
error. So whether the compiler informs you that the program is wrong,
is a decision left up to whoever wrote the compiler.

That doesn't sound right, but I haven't looked it up. My recollection is
that this pass-and-a-half rule was intended to invalidate changing the
type after it was used. So if the typedef for DOUBLE inside Screen
occurred after the definition of OK it would violate the rule, but not
before. I think the confusion comes from "the context of the completed
Screen class". That's not the context where the class is defined (where
DOUBLE is a synonym for double), but the context at the end of the
definition of Screen (where DOUBLE is a synonym for int). Since all the
uses of DOUBLE inside Screen saw it as int, it's okay.
Yes, I was thinking of a "typedef DOUBLE DOUBLE;" kind of declaration
inside the class - which while it looks harmless, is in fact an error.
The actual program in this case, while questionable in style, does
seems to be legal.

As an editorial aside, I do find the C++ language, especially its name
lookup rules (and rules for template type deduction) somewhat
complicated. At some point, one has to wonder whether compilers will be
the only ones left who can completely understand the C++ language. What
is needed I believe is a C++ compiler that can post answers to C++
questions on USENET forums, when it's not busy compiling source files,
that is.

Greg

Dec 23 '06 #14

This discussion thread is closed

Replies have been disabled for this discussion.