This is wrong, right?

[Steven T. Hatton]

The discussion of the example code, and the example code are mutually
inconsistent in the following are they not?

<quote>
http://publib.boulder.ibm.com/infoc....ibm.xlcpp8a.doc/language/ref/name_hiding.htm
Name hiding (C++ only)

If a class name or enumeration name is in scope and not hidden, it is
visible. A class name or enumeration name can be hidden by an explicit
declaration of that same name -- as an object, function, or enumerator --
in a nested declarative region or derived class. The class name or
enumeration name is hidden wherever the object, function, or enumerator
name is visible. This process is referred to as name hiding.

In a member function definition, the declaration of a local name hides the
declaration of a member of the class with the same name. The declaration of
a member in a derived class hides the declaration of a member of a base
class of the same name.

Suppose a name x is a member of namespace A, and suppose that the members of
namespace A are visible in a namespace B because of a using declaration. A
declaration of an object named x in namespace B will hide A::x. The
following example demonstrates this:

#include <iostream>
#include <typeinfo>
using namespace std;

namespace A {
char x;
};

namespace B {
using namespace A;
int x;
};

int main() {
cout << typeid(B::x).name() << endl;
}

The following is the output of the above example:

int

The declaration of the integer x in namespace B hides the character x
introduced by the using declaration.
</quote>

If anybody knows how to contact the maintainers of the document, you may
want to let them know.

 

[Greg]

The discussion of the example code, and the example code are mutually
inconsistent in the following are they not?

<quote>
http://publib.boulder.ibm.com/infoc....ibm.xlcpp8a.doc/language/ref/name_hiding.htm
Name hiding (C++ only)

If a class name or enumeration name is in scope and not hidden, it is
visible. A class name or enumeration name can be hidden by an explicit
declaration of that same name -- as an object, function, or enumerator --
in a nested declarative region or derived class. The class name or
enumeration name is hidden wherever the object, function, or enumerator
name is visible. This process is referred to as name hiding.

In a member function definition, the declaration of a local name hides the
declaration of a member of the class with the same name. The declaration of
a member in a derived class hides the declaration of a member of a base
class of the same name.

Suppose a name x is a member of namespace A, and suppose that the members of
namespace A are visible in a namespace B because of a using declaration. A
declaration of an object named x in namespace B will hide A::x. The
following example demonstrates this:

#include <iostream>
#include <typeinfo>
using namespace std;

namespace A {
char x;
};

namespace B {
using namespace A;
int x;
};

int main() {
cout << typeid(B::x).name() << endl;
}

The following is the output of the above example:

int

The declaration of the integer x in namespace B hides the character x
introduced by the using declaration.
</quote>

If anybody knows how to contact the maintainers of the document, you may
want to let them know.

So all that needs to be done is to tell the maintainers that you think
there is a mistake in the above text? In particular it's not useful -
for them or for anyone else - to know what you think the mistake is?

Greg

 

[Steven T. Hatton]

So all that needs to be done is to tell the maintainers that you think
there is a mistake in the above text? In particular it's not useful -
for them or for anyone else - to know what you think the mistake is?

Greg

Perhaps I am mistaken. Is there no error?

 

[Kai-Uwe Bux]

http://publib.boulder.ibm.com/infoc....ibm.xlcpp8a.doc/language/ref/name_hiding.htm

Perhaps I am mistaken. Is there no error?

Is this a quiz? What do _you_ think is false. Please, be more specific; then
you might get better answers.


Best

Kai-Uwe Bux

 

[Steven T. Hatton]

http://publib.boulder.ibm.com/infoc....ibm.xlcpp8a.doc/language/ref/name_hiding.htm

Is this a quiz? What do _you_ think is false. Please, be more specific;
then you might get better answers.


Best

Kai-Uwe Bux

I couldn't have hoped for a better response.

 

[Greg]

Perhaps I am mistaken. Is there no error?

The text states that "int x" declaration in B hides the "char x"
declaration in A that is brought into the B namespace with the "using"
declaration. Therefore B::x refers to an int and not to a char
variable.

The output of the program, "int", is implementation-dependent (on gcc,
"i" is the output). But since this text is from the manual for an IBM
compiler, it is reasonable for the text to describe the output of that
compiler.

Greg

 

[Howard]

In what way?

So what's the problem? Just as the text above and below the example states,
the int x hides the char x.

I don't see one. Do you?

I couldn't have hoped for a better response.

Now you sound like you're just trolling. Is there some reason you're unable
or unwilling to articulate what error you're referring to?

-Howard

 

[Steven T. Hatton]

In what way?


So what's the problem? Just as the text above and below the example
states, the int x hides the char x.


I don't see one. Do you?


Now you sound like you're just trolling. Is there some reason you're
unable or unwilling to articulate what error you're referring to?

Yes.

 

[Noah Roberts]

Howard wrote:

Yes.

They say that when you find yourself at the bottom of a hole stop
digging.

 

[Steven T. Hatton]

They say that when you find yourself at the bottom of a hole stop
digging.

I'm not the one doing the digging.

 

[Steven T. Hatton]

Greg wrote:

The text states that "int x" declaration in B hides the "char x"
declaration in A that is brought into the B namespace with the "using"
declaration. Therefore B::x refers to an int and not to a char
variable.

The output of the program, "int", is implementation-dependent (on gcc,
"i" is the output). But since this text is from the manual for an IBM
compiler, it is reasonable for the text to describe the output of that
compiler.

Greg

There is no using declaration in the example.

See ISO/IEC 14882:2003(E) §7.3.3 and §7.3.4

This is an older version, but the essence is the same:
http://www.kuzbass.ru:8086/docs/isocpp/dcl.html#namespace.udecl

And yes, this is more than mere pedantry on my part. It really does matter.

 

[Howard]

Greg wrote:




There is no using declaration in the example.

See ISO/IEC 14882:2003(E) '7.3.3 and '7.3.4

This is an older version, but the essence is the same:
http://www.kuzbass.ru:8086/docs/isocpp/dcl.html#namespace.udecl

And yes, this is more than mere pedantry on my part. It really does
matter.

Ok, so he said "using declaration" when he should have said "using
directive". Why not just say that up front? Quit acting like a troll and
get to your point, or you'll find it very lonely here.

-Howard

 

[Steven T. Hatton]

Ok, so he said "using declaration" when he should have said "using
directive". Why not just say that up front? Quit acting like a troll and
get to your point, or you'll find it very lonely here.

The official IBM AIX C++ language reference has it wrong. Trying to spell
out the point I am making would be moot. Either you get it our you don't.

Here's one minor point to consider: Being an obnoxious arrogant twit who
knows what he is talking about is far superior to being an obnoxious
arrogant twit who doesn't know what he is talking about.

 

[Noah Roberts]

The official IBM AIX C++ language reference has it wrong.

Where? In what way?

Of course, several people have already asked you these questions.

Trying to spell
out the point I am making would be moot. Either you get it our you don't.

Apparently nobody does so you must be speaking for only your own
benefit...seing as you do not wish others to understand you.

 

[Kai-Uwe Bux]

The official IBM AIX C++ language reference has it wrong. Trying to spell
out the point I am making would be moot. Either you get it our you don't.

Here's one minor point to consider: Being an obnoxious arrogant twit who
knows what he is talking about is far superior to being an obnoxious
arrogant twit who doesn't know what he is talking about.

Maybe, but as long as you keep dancing around the issue, we have no way of
determining which of the two applies.


Best

Kai-Uwe Bux

 

[Howard]

Here's one minor point to consider: Being an obnoxious arrogant twit

You can stop there. Now I understand perfectly.

 

[Steven T. Hatton]

Where? In what way?

Of course, several people have already asked you these questions.

Restored for context:

Congratulations Noah! You are the first person in my 15 years on USENET to
get an official, fully pronounced, RTFM from me. Not only did I explain
what is wrong with the example. I also provided specific references to the
Standard and easy access to a copy of the same so that the reader might
verify it for him or herself.

Apparently nobody does so you must be speaking for only your own
benefit...seing as you do not wish others to understand you.

The silence of certain knowledgeable others regarding this thread is
sufficient to convince me that some do get it.

 

[Steven T. Hatton]

Maybe, but as long as you keep dancing around the issue, we have no way of
determining which of the two applies.

This response intentionally left blank.

 

[Evan]

Here's one minor point to consider: Being an obnoxious arrogant twit who
knows what he is talking about is far superior to being an obnoxious
arrogant twit who doesn't know what he is talking about.

But it still leaves you an obnoxious arrogant twit. *Unhelpful*
obnoxious arrogant twit you might add.

 

[Jack Klein]

Here's one minor point to consider: Being an obnoxious arrogant twit who
knows what he is talking about is far superior to being an obnoxious
arrogant twit who doesn't know what he is talking about.

Can't remember why I removed you from my kill file once. Guarantee it
won't happen again.

*plonk*