In article <35f79542.50922532@nntp.ix.netcom.com>, Michael Rubenstein
<miker3@ix.netcom.com> writes
>I favor the second interpretation and would call this a VC++ bug.  My
>reasons are:
>
>       1.  I can't see any reason for the passage cited other than
>           compatibility with C.  It certainly complicates things.
>           Your example would clearly be legal in C.
>
>       2.  If an object with the same name is declared in the same
>           scope as the declaraton the class, the name normally
>           refers to the object, except where an elaborated type
>           specifier (i.e., one using the keyword struct or class) is
>
>           used.  I can't see any reason the same resolution cannot
>           be used within the class definition.  If there is a reason
>
>           for treating this case differently, I have missed it.

Name look-up has never been simple and the special rules to support C's
tag namespace are an added complication that in an ideal world we could
do without.

In addition we have the problems of constructors.  I believe that a
warped view of a constructor is that it is a nameless function that
returns a class type.  I also have some vague recillection that there is
special wording to cover constructor names.  Perhaps that adequately
covers:

struct B  {
        int B;
};

vector<B> someBs;

I know the code is stupid:) But I am trying to illustrate that even if
we never provide one explicitly, we can still find ourselves invoking
constructors whose apparent name is the class name.

--
Francis Glassborow


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Francis Glassborow wrote:

> struct B  {
>         int B;
> };
>
> vector<B> someBs;
>
> I know the code is stupid:) But I am trying to illustrate that even if
> we never provide one explicitly, we can still find ourselves invoking
> constructors whose apparent name is the class name.

The code is also ill-formed.  See Clause 9.2

-13- If T is the name of a class, then each of the following shall have
a name different from T:

     every data member of class T;

     every member of class T that is itself a type;

     every enumerator of every member of class T that is an enumerated
type; and

     every member of every anonymous union that is a member of class T.

-Mike Ball-


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <35F347B6.E6CC9431@eng.sun.com>, Michael Ball
<michael.ball@sun.com> writes
>The code is also ill-formed.  See Clause 9.2
>
>-13- If T is the name of a class, then each of the following shall have
>a name different from T:
>
>     every data member of class T;
>
>     every member of class T that is itself a type;
>
>     every enumerator of every member of class T that is an enumerated
>type; and
>
>     every member of every anonymous union that is a member of class T.
>
>-Mike Ball-

Thanks.  I knew we must have done the sane thing.  That answers the
original question VC++ 5 is not only doing something sensible but
something right and apparently gcc 2.whatever was not.

--
Francis Glassborow


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In message <35F347B6.E6CC9431@eng.sun.com>, <michael.ball@sun.com>
Michael Ball wrote:
[Francis Glassborow example elided]
>
>The code is also ill-formed.  See Clause 9.2
>
>-13- If T is the name of a class, then each of the following shall
>have a name different from T:
>

 Yes. This looks like the answer to my original query...
 which was basically is this code legal?
----------------------------
struct ip_opts
{
 struct in_addr ip_dst;
 char ip_opts[40];
};
----------------------------

 I only have access to the CD2 which says:
---
9.2 Class members
13 If T is the name of a class, then each of the following shall
have a name different from T:
 every data member of class T;
 every member of class T that is itself a type;
 every enumerator of every member of class T that is an enumerated type; and
 every member of every anonymous union that is a member of class T.
---

 Is this wording the same in the FDIS?
 Do you agree that this rule applies to the ip_opts example?

<curious>
-het


   "People who are hungry and out of a job are the stuff
                of which dictatorships are made." -FDR




[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Hi Folks,
 I have run into a funny compile time error, and I am not
 sure who to blame.
 The struct below compiles fine under GCC 2.7.2.
 It does not compile under VC5.0.

----------------------------
struct ip_opts
{
 struct in_addr ip_dst;
 char ip_opts[40];
};
----------------------------

 The difficulty is that VC5.0 seems to think the ip_opts
 character field is a constructor.

 So here is the question:
 Is it ISO C++ legal for a struct to have a non-constructor member
 with the same name as the struct?

<curious>
-het



   "People who are hungry and out of a job are the stuff
                of which dictatorships are made." -FDR
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

On 06 Sep 98 07:42:30 GMT, het@despam.pangea.ca (Harvey Taylor) wrote:

> I have run into a funny compile time error, and I am not
> sure who to blame.
> The struct below compiles fine under GCC 2.7.2.
> It does not compile under VC5.0.
>
>----------------------------
>struct ip_opts
>{
> struct in_addr ip_dst;
> char ip_opts[40];
>};
>----------------------------
>
> The difficulty is that VC5.0 seems to think the ip_opts
> character field is a constructor.
>
> So here is the question:
> Is it ISO C++ legal for a struct to have a non-constructor member
> with the same name as the struct?

As I read the draft, this is a bit unclear.  From 3.3.7,

 A class name or enumeration name can be hidden by the name of
 an object, function, or enumerator declared in the same scope.

The question is what it means by "the same scope."  Is it the scope in
which the class name is declared or any scope in which the declaration
is active?

In your example you are declaring ip_opts in an inner scope, rather
than the scope in which struct ip_opts is defined so under the latter
interpretation your code is correct.  Under the former, this wouldn't
apply and I cannot find anything else that would apply.

I favor the second interpretation and would call this a VC++ bug.  My
reasons are:

 1.  I can't see any reason for the passage cited other than
     compatibility with C.  It certainly complicates things.
     Your example would clearly be legal in C.

 2.  If an object with the same name is declared in the same
     scope as the declaraton the class, the name normally
     refers to the object, except where an elaborated type
     specifier (i.e., one using the keyword struct or class) is

     used.  I can't see any reason the same resolution cannot
     be used within the class definition.  If there is a reason

     for treating this case differently, I have missed it.

Note that VC++ 6.0 behaves the same way.
--
Michael M Rubenstein


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]