A problem with typedef

[miaohua1982]

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?

[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

[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?

[miaohua1982]

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

[red floyd]

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.

[Pete Becker]

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)

[red floyd]

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.

[Pete Becker]

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)

[Jacek Dziedzic]

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.

[red floyd]

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.

[=?ISO-8859-15?Q?Juli=E1n?= Albo]

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

[Greg]

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

[Pete Becker]

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)

[Greg]

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