In article <398AA5F2.6C93CABB@elektron.its.tudelft.nl>,
Arjen van Rhijn  <arjen@elektron.its.tudelft.nl> wrote:
>If I define a struct or class inside the private part of a class, should
>a derived class be able to use that declaration? For instance, say we've
>got the following code:
>
>class A
>{
>    private:
>        typedef struct {
>            int a;
>            int b;
>        } A_struct;
>
>};
>
>class B : public A
>{
>    A_struct tB;
>};
>
>Should this compile?

No.

>Or should B only be able to 'see' the A_struct
>declaration when it's defined protected or public?

The error is not about "see"ing, but about accessibility,
and no, A_struct (actually A::A_struct) is not accessible in B.

>The above code compiles fine on all compilers I've tried.

Have you tried Comeau C++?  Even if you don't purchase it,
you can try it out at http://www.comeaucomputing.com/tryitout

>So for a derived class the A_struct is visible, but outside
>the class it cannot be accessed, as if
>it were defined protected instead of private.

Right, it's visible but inaccessible.

>What does the standard say about this?

You can't do it.

- Greg
--
Comeau Computing / Comeau C/C++ 4.2.42 (4.2.44 expected soon)
TRY Comeau C++ ONLINE at http://www.comeaucomputing.com/tryitout
Email: comeau@comeaucomputing.com / WEB: http://www.comeaucomputing.com

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

Arjen van Rhijn <arjen@elektron.its.tudelft.nl> writes:

> Are you saying that all compilers other people and myself have tried
> (Borland, microsoft, gcc, edg) are non-conforming? None of these compilers
> reject this code, which almost suggests that there's something more going on
> here.
>
[snip]

See http://gcc.gnu.org/bugs.html#known

gcc does not enforce access control for nested types, and the
  maintainers consider this a bug; it will be fixed in the next major
  release.

I do not know if the makers of any of the other compilers you name
  consider it a bug; I do not use them.

---
[ 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 <398EFD39.F16365@elektron.its.tudelft.nl>,
  Arjen van Rhijn <arjen@elektron.its.tudelft.nl> wrote:
> Are you saying that all compilers other people and myself have tried
> (Borland, microsoft, gcc, edg) are non-conforming? None of these
compilers
> reject this code, which almost suggests that there's something more
going on
> here.

Actually, the EDG compiler (2.43) does reject the code:

        line 13: error: type "A::A_struct" is inaccessible
              A_struct tB;
              ^

For some reason, compiler writers have seemed to put a low
priority on implementing access checking for types.
Eventually, presumably, they will all catch up.

--
William M. Miller, wmm@fastdial.net
Vignette Corporation (www.vignette.com)


Sent via Deja.com http://www.deja.com/
Before you buy.

---
[ 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 <398EFD39.F16365@elektron.its.tudelft.nl>,
Arjen van Rhijn  <arjen@elektron.its.tudelft.nl> wrote:
>wmm@fastdial.net wrote:
>> The Standard says that access control applies to all names
>> declared in a class and that derived classes have no access
>> to private names in their base classes.  This code is ill-
>> formed, and compilers that do not issue a diagnostic about
>> it are non-conforming.
>
>Are you saying that all compilers other people and myself have tried
>(Borland, microsoft, gcc, edg) are non-conforming?

No, you're saying that :)

>None of these compilers reject this code, which almost suggests
>that there's something more going on here.

I bet you are not running any of them in strict mode.
(I say this way too often in all the NGs, and yet time after
time folks don't want to believe the reality of it.)

- Greg
--
Comeau Computing / Comeau C/C++ 4.2.42 (4.2.44 expected soon)
TRY Comeau C++ ONLINE at http://www.comeaucomputing.com/tryitout
Email: comeau@comeaucomputing.com / WEB: http://www.comeaucomputing.com

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

The amazing thing with regard to Borland is that the earlier version, BC++ 5.02
and BCB3 do report this as an error while the latest versions BCB4 and BCB5 do
not. Evidently something in the C++ standard seems to have changed the mind of
the people there into believing that the code is now compilable without an
error, or else they just got sloppy. I also would think that the code is in
error.

Arjen van Rhijn wrote:

> Are you saying that all compilers other people and myself have tried
> (Borland, microsoft, gcc, edg) are non-conforming? None of these compilers
> reject this code, which almost suggests that there's something more going on
> here.
>
> Arjen
>
> wmm@fastdial.net wrote:
>
> > The Standard says that access control applies to all names
> > declared in a class and that derived classes have no access
> > to private names in their base classes.  This code is ill-
> > formed, and compilers that do not issue a diagnostic about
> > it are non-conforming.

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

Greg Comeau wrote:

> I bet you are not running any of them in strict mode.
> (I say this way too often in all the NGs, and yet time after
> time folks don't want to believe the reality of it.)

Compiling the code with either C++ Builder 5 from Borland  ir VC++6 from
Microsoft,  in strict Ansi mode, which disables all other language
extensions, incorrectly does not catch the error in the code. Amazingly
enough while C++ Builder 4 and C++ Builder 5 do not catch the error,
Borland's C++ 5.02 and C++ Builder 3, the previous 2 versions of their C++
compiler, correctly do catch the error in the code. All were compiled in
strict Ansi mode.

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

I asked this question before on comp.lang.c++, but no one seemed to be
able to answer it, so I thought I'd try here.

If I define a struct or class inside the private part of a class, should

a derived class be able to use that declaration? For instance, say we've

got the following code:

class A
{
    private:
        typedef struct {
            int a;
            int b;
        } A_struct;

};

class B : public A
{
    A_struct tB;
};

Should this compile? Or should B only be able to 'see' the A_struct
declaration when it's defined protected or public? The above code
compiles fine on all compilers I've tried. So for a derived class the
A_struct is visible, but outside the class it cannot be accessed, as if
it were defined protected instead of private.
What does the standard say about this?

Arjen



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

Arjen van Rhijn wrote:

> class A
> {
>     private:
>         typedef struct {
>             int a;
>             int b;
>         } A_struct;
>
> };
>
> class B : public A
> {
>     A_struct tB;
> };
>
> Should this compile?

No it should not, because A_struct isn't accessible in B. Access
checking apply to all names (variables, functions, types, templates)
the same way. I don't know when compile will implement this old and
simple rule.

--

Valentin Bonnard

---
[ 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 <398AA5F2.6C93CABB@elektron.its.tudelft.nl>,
  Arjen van Rhijn <arjen@elektron.its.tudelft.nl> wrote:
> Hi,
>
> I asked this question before on comp.lang.c++, but no one seemed to be
> able to answer it, so I thought I'd try here.
>
> If I define a struct or class inside the private part of a class,
should
>
> a derived class be able to use that declaration? For instance, say
we've
>
> got the following code:
>
> class A
> {
>     private:
>         typedef struct {
>             int a;
>             int b;
>         } A_struct;
>
> };
>
> class B : public A
> {
>     A_struct tB;
> };
>
> Should this compile? Or should B only be able to 'see' the A_struct
> declaration when it's defined protected or public? The above code
> compiles fine on all compilers I've tried. So for a derived class the
> A_struct is visible, but outside the class it cannot be accessed, as
if
> it were defined protected instead of private.
> What does the standard say about this?

The Standard says that access control applies to all names
declared in a class and that derived classes have no access
to private names in their base classes.  This code is ill-
formed, and compilers that do not issue a diagnostic about
it are non-conforming.

--
William M. Miller, wmm@fastdial.net
Vignette Corporation (www.vignette.com)


Sent via Deja.com http://www.deja.com/
Before you buy.

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

Are you saying that all compilers other people and myself have tried
(Borland, microsoft, gcc, edg) are non-conforming? None of these compilers
reject this code, which almost suggests that there's something more going on
here.

Arjen

wmm@fastdial.net wrote:

> The Standard says that access control applies to all names
> declared in a class and that derived classes have no access
> to private names in their base classes.  This code is ill-
> formed, and compilers that do not issue a diagnostic about
> it are non-conforming.
>
> --
> William M. Miller, wmm@fastdial.net
> Vignette Corporation (www.vignette.com)
>
> Sent via Deja.com http://www.deja.com/
> Before you buy.
>
> ---
> [ 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              ]

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

"Arjen van Rhijn" <arjen@elektron.its.tudelft.nl>:
| Are you saying that all compilers other people and myself have tried
| (Borland, microsoft, gcc, edg) are non-conforming?

Yes, that's what he is saying. You might want to file a bug report to the
respective vendors.

|None of these compilers reject this code, which almost suggests that
| there's something more going on here.

Yes, uncareful implementation of the C++ Standard in each of the compilers named
above.

--
Sebastian Moleski
SurakWare Corp.
www.surakware.com (IE5 required)


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