"James Kuyper Jr." <kuyper@wizard.net> wrote in message
news:<3C1CC7D5.BE0036F8@wizard.net>...
> Tom wrote:
> >
> > On 12 Dec 2001 11:42:47 -0500, dylan@moldflow.com (Dylan Nicholson)
> > wrote:
>  ...
> >  >Actually I usually add constructors to structs I'm using just as data,
> >  >but only for the purpose for easy initialisation of members.  Why
> >  >shouldn't it be safe to memcpy that around?
> >
> > Define safe. The C++ standard disallows it AFAIK. It is only allowed
> > for POD data, and POD data can't have constructors.  OTOH, I expect it
> > works on all current implementations.
> >
> > I think 3.8 and 3.9 of the standard make this restriction clear(ish).
>
> I think he was aware that the restriction exists; his question was
> "why?".
>
> I believe that the reason was a desire to keep the rules simple. There
> are some classes where memcpy() won't do the right thing with them. The
> prototypical example is std::string, which contains a pointer to a
> string which was allocated by the constructor, and needs to be
> deallocated by the destructor. A memcpy() would create situations where
> two different copies of the string contain pointers to the same memory,
> each of which would attempt to deallocated it when destroyed.
>
> So the question was, how to write the rules governing when memcpy() is
> guaranteed to work? Any class with such complications always needs a
> non-default copy constructor, and usually needs a non-default
> constructor and destructor. It is therefore not a POD type. Therefore,
> to keep the rule simple, it was decided to say that only POD types were
> guaranteed to be safely copyable with memcpy().

But this is absurd, the only reason such a restriction is needed (that
I can see) is for when a compiler generates copying code.

So if I write:

struct color
{
 int red, green, blue;
};

if I write

color c1;
color c2(c1);

the compiler is allowed to generate code that is effectively a memcpy,
but if I add a constructor to color, then the compiler has to generate
code that is effectively memcpy 3 times on each member.  But the
compiler can know for a fact that the "AS IF" result of doing this is
the same as doing a memcpy on the entire struct, so why shouldn't it
do such a thing?
The only thing that should prevent the compiler from doing this is if
a struct has its own copy constructor, or one of its members does
(this applies recursively of course).
So if I write:

struct string
{
string(const string& other) { ... }
};
struct color_value
{
 string name;
 int values[3];
};
struct color
{
color_value red;
color_value green;
color_value blue;
};

...

color c1;
color c2(c1);

then clearly the compiler has to do extra work - calling copy
constructors for the 'name' member of each color_value, but using
memcpy for the 'values' member.
The same sort of deal applies to operator= of course, although quite
independently of whether a copy constructor exists.

In the first case it would seem that what the compiler can do via the
'as if' rule applies just as well to the programmer - the rules for
data layout in a struct are quite clear, the behaviour of memcpy quite
well defined, so there seems to be a conflict if the standard
explicitly forbids performing a memcpy on an otherwise-POD struct just
because it has a constructor.

Dylan

      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]

[ 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://www.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

"James Kuyper Jr." <kuyper@wizard.net> wrote
> Tom wrote:
> >
> > On 12 Dec 2001 11:42:47 -0500, dylan@moldflow.com (Dylan Nicholson)
> > wrote:
>  ...
> >  >Actually I usually add constructors to structs I'm using just as data,
> >  >but only for the purpose for easy initialisation of members.  Why
> >  >shouldn't it be safe to memcpy that around?
> >
> > Define safe. The C++ standard disallows it AFAIK. It is only allowed
> > for POD data, and POD data can't have constructors.  OTOH, I expect it
> > works on all current implementations.
> >
> > I think 3.8 and 3.9 of the standard make this restriction clear(ish).
>
> I think he was aware that the restriction exists; his question was
> "why?".
>
> I believe that the reason was a desire to keep the rules simple. There
> are some classes where memcpy() won't do the right thing with them. The
> prototypical example is std::string, which contains a pointer to a
> string which was allocated by the constructor, and needs to be
> deallocated by the destructor. A memcpy() would create situations where
> two different copies of the string contain pointers to the same memory,
> each of which would attempt to deallocated it when destroyed.

But std::string isn't a POD. Dylan wants to copy POD's with memcpy().

> So the question was, how to write the rules governing when memcpy() is
> guaranteed to work? Any class with such complications always needs a
> non-default copy constructor, and usually needs a non-default
> constructor and destructor. It is therefore not a POD type. Therefore,
> to keep the rule simple, it was decided to say that only POD types were
> guaranteed to be safely copyable with memcpy().

If a structure (POD or not) contains a pointer to "owned" memory, it
might not be safe to copy. On the other hand, C programs that manage
linked lists have dealt with these pointers since before the dawn of
C++, and there are *AT LEAST* half a dozen C programs that don't crash.
(In fact, many C programmers seem feel that linked lists were invented
by Kernigan and Ritchie specifically for use in C, and are shocked to
learn that it ever worked anywhere else!)

Forcing "user" code to handle the pointers, rather than encapsulating
the code in a class, might not be the OOP way, but that doesn't mean
it can't work. Plus, C++-style classes are not the only way to
encapsulate.

My point here is, I can easily construct POD classes that are *not*
safe to copy with memcpy() (even though the standard says it's okay),
and non-POD classes that *are* safe to copy with memcpy() (or would
be, if the standard didn't call it illegal). So if you're right about
the intent of that rule, I'd say it missed the mark.

      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]

[ 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://www.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

In article <3C1DBB18.3CF5E1F4@ihug.co.nz>, Ross Smith
<r-smith@ihug.co.nz> writes
>> Read paragraph 4 of clause 9 of the C++ Standard that defines POD struct
>> and union types. Nowhere does it say anything about constructors,
>
>Not so: a POD struct is an aggregate, and 8.5.1 para 1 forbids
>user-declared constructors for aggregates.

Yes, I had missed that (partly because the backward reference precedes
the sentence it is relevant to. I think we made a real pig's ear of the
wording. Having a dtor and copy assignment for aggregates in general but
not for PODs makes little sense to me. If you need a user defined dtor
then it would be an odd design that did not need a copy ctor and copy
assignment to be written as well.


--
Francis Glassborow
I offer my sympathy and prayers to all those who are suffering
as a result of the events of September 11 2001.

      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]

[ 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://www.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

Francis Glassborow <francis.glassborow@ntlworld.com> writes:

[...]

> The final sentence is:
> Thus, in any elaborated-type specifier, the enum keyword shall be used
> to refer to enumeration (7.2), the union class-key shall be used to
> refer to a union (clause 9), and either the class or struct class-key
> shall be used to refer to a class (clause 9) declared using the class or
> struct class-key.
>
> Now note that it spells out union as one case but does not spell out
> struct and class as separate cases. At the very least that is paragraph
> is ambiguous, perhaps it is even contradictory. I think that a request
> for interpretation would be one route or a defect report (but without
> writing much more it is hard to see how to reword the text.)

I think adding a second "either" between "declared using" and "the
class or struct class-key" would clarify the situation: By repeating
the "either", at least my (admittedly non-native) English
understanding would rule out the possibility of separate association
class-class and struct-struct.

The sentence would then end in: "and either the class or struct
class-key shall be used to refer to a class (clause 9) declared using
either the class or struct class-key."

[...]
---
[ 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://www.research.att.com/~austern/csc/faq.html                ]

Dylan Nicholson wrote:
...
> struct color
> {
>  int red, green, blue;
> };
>
> if I write
>
> color c1;
> color c2(c1);
>
> the compiler is allowed to generate code that is effectively a memcpy,
> but if I add a constructor to color, then the compiler has to generate
> code that is effectively memcpy 3 times on each member.  But the
> compiler can know for a fact that the "AS IF" result of doing this is
> the same as doing a memcpy on the entire struct, so why shouldn't it
> do such a thing?

There's no reason it can't. You're misunderstanding the connection here.
The standard says that the memcpy() is guaranteed to work if the struct
is a POD-struct. It does not say that it won't work if the struct is not
one; it merely allows for that possibility; for an almost-POD struct
like this case, I can't seen any obvious reason why that possibility
would come up. A good optimizing implementation which happens to
implement the struct in such a way that memcpy() would work, is
perfectly free to choose to use memcpy() to implement the copy
construction.

> The only thing that should prevent the compiler from doing this is if
> a struct has its own copy constructor, or one of its members does
> (this applies recursively of course).

I agree, that seems a more reasonable rule; but it's not the one that
was chosen. I think the desire was to define a single distinction: POD
versus non-POD, so that a there are lots of guarantees for C-style
behavior for POD, and all of those guarantees are off for non-PODs. The
alternative would be to define a memcpy-able and non-memcpy-able types,
with different rules than for PODs and non-PODs. You'd have a seperate
category for each of the "C-style" guarantees that are currently tied to
POD types. I counted those guarantees once, there are dozens of them. Do
you think the standard would be well-served by replacing POD/non-POD
with dozens of different more specific categories?

...
> In the first case it would seem that what the compiler can do via the
> 'as if' rule applies just as well to the programmer - the rules for
> data layout in a struct are quite clear, the behaviour of memcpy quite

The rules for data layout are quite clear, but there are only two of
them - they leave a lot of freedom to the implementor.

9.2p12: "Nonstatic data members of a (non-union) class declared without
an intervening _access-specifier_ are allocated so that later members
have higher addresses within a class object. The order of allocation of
non-static data members seperated by an _access-specifier_ is
unspecified".

9.2p17: "A pointer to a POD-struct object, suitably converted using a
reinterpret_cast, points to its initial member (or if that member is a
bit-field, then to the unit in which it resides) and vice versas" Note,
however, that this applies only to POD-structs. Non-POD structs are
allowed to have an arbitrarily large amount of padding before the first
member.

> well defined, so there seems to be a conflict if the standard
> explicitly forbids performing a memcpy on an otherwise-POD struct just
> because it has a constructor.

The standard never forbids anything. It merely tells you that certain
things have undefined behavior; which can include your code doing
precisely what you expect it to do.
---
[ 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://www.research.att.com/~austern/csc/faq.html                ]

On 12 Dec 2001 11:42:47 -0500, dylan@moldflow.com (Dylan Nicholson)
wrote:

 >tom_usenet@hotmail.com (Tom) wrote in message news:<3c06ea42.15047417@news.ntlworld.com>...
 >> On 29 Nov 2001 18:01:22 -0500, Martin Fabian
 >> <fabianNOSPAM@s2.chalmers.se> wrote:
 >>
 >> >Since you (well, me, at least :-) almost always add constructors to the
 >> >c++structs, the c++/c-struct compatibility feature seems to be of
 >> >limited value. I guess it was (is?) most useful during the transition
 >> >from c to c++.
 >>
 >> And for fast, non-portable binary IO which I certainly need a lot
 >> (yes, I did profile before deciding to do this). If you add
 >> constructors you no longer have a POD struct, so you can't just memcpy
 >> it around. Why call memcpy for each member of a class when you can do
 >> the whole lot in one go if you have a POD struct.
 >>
 >
 >Actually I usually add constructors to structs I'm using just as data,
 >but only for the purpose for easy initialisation of members.  Why
 >shouldn't it be safe to memcpy that around?

Define safe. The C++ standard disallows it AFAIK. It is only allowed
for POD data, and POD data can't have constructors.  OTOH, I expect it
works on all current implementations.

I think 3.8 and 3.9 of the standard make this restriction clear(ish).

Tom

      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]

[ 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://www.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

Tom wrote:
>
> On 12 Dec 2001 11:42:47 -0500, dylan@moldflow.com (Dylan Nicholson)
> wrote:
...
>  >Actually I usually add constructors to structs I'm using just as data,
>  >but only for the purpose for easy initialisation of members.  Why
>  >shouldn't it be safe to memcpy that around?
>
> Define safe. The C++ standard disallows it AFAIK. It is only allowed
> for POD data, and POD data can't have constructors.  OTOH, I expect it
> works on all current implementations.
>
> I think 3.8 and 3.9 of the standard make this restriction clear(ish).

I think he was aware that the restriction exists; his question was
"why?".

I believe that the reason was a desire to keep the rules simple. There
are some classes where memcpy() won't do the right thing with them. The
prototypical example is std::string, which contains a pointer to a
string which was allocated by the constructor, and needs to be
deallocated by the destructor. A memcpy() would create situations where
two different copies of the string contain pointers to the same memory,
each of which would attempt to deallocated it when destroyed.

So the question was, how to write the rules governing when memcpy() is
guaranteed to work? Any class with such complications always needs a
non-default copy constructor, and usually needs a non-default
constructor and destructor. It is therefore not a POD type. Therefore,
to keep the rule simple, it was decided to say that only POD types were
guaranteed to be safely copyable with memcpy().
---
[ 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://www.research.att.com/~austern/csc/faq.html                ]

In article <3c1aa1bb.1476763@news.ntlworld.com>, Tom
<tom_usenet@hotmail.com> writes
>Define safe. The C++ standard disallows it AFAIK. It is only allowed
>for POD data, and POD data can't have constructors.  OTOH, I expect it
>works on all current implementations.

Read paragraph 4 of clause 9 of the C++ Standard that defines POD struct
and union types. Nowhere does it say anything about constructors, though
I think it should prohibit user written copy ctors along with copy
assignment. It explicitly prohibits the latter along with user written
dtors.


--
Francis Glassborow
I offer my sympathy and prayers to all those who are suffering
as a result of the events of September 11 2001.

      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]

[ 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://www.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

Francis Glassborow wrote:
>
> In article <3c1aa1bb.1476763@news.ntlworld.com>, Tom
> <tom_usenet@hotmail.com> writes
> >Define safe. The C++ standard disallows it AFAIK. It is only allowed
> >for POD data, and POD data can't have constructors.  OTOH, I expect it
> >works on all current implementations.
>
> Read paragraph 4 of clause 9 of the C++ Standard that defines POD struct
> and union types. Nowhere does it say anything about constructors,

Not so: a POD struct is an aggregate, and 8.5.1 para 1 forbids
user-declared constructors for aggregates.

--
Ross Smith ...................................... Auckland, New Zealand
r-smith@ihug.co.nz ......................... http://storm.net.nz/~ross/
  "We need a new cosmology. New gods. New sacraments. Another drink."
                                                       -- Patti Smith
---
[ 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://www.research.att.com/~austern/csc/faq.html                ]

In article <7f2735a5.0112061412.50fc3d8f@posting.google.com>, Allan W
<allan_w@my-dejanews.com> writes
>Francis Glassborow <francis.glassborow@ntlworld.com> wrote
>> But there is no difference in the language between structs and classes
>> other than their default access specifier.
>
>Are they synonyms, other than this minor difference? Or are they
>just equivalent?
>
>It matters in code like this:
>
>    struct foo { /* ... */ };
>
>    int main() {
>        class foo f;
>    }
>
>The keyword "class" is optional in this context. But is it legal?
>
>IIRC, Microsoft objects, and the error message specifically says that
>foo is a struct instead of a class. Is this complaint justified?

No, it is a result (or so I am told) of the way that MS elected to
mangle names and is non-conforming.


--
Francis Glassborow
I offer my sympathy and prayers to all those who are suffering
as a result of the events of September 11 2001.

      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]

[ 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://www.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

Francis Glassborow <francis.glassborow@ntlworld.com> wrote in message news:<M7m579XIFLE8Ew7Z@robinton.ntlworld.com>...
> In article <7f2735a5.0112061412.50fc3d8f@posting.google.com>, Allan W
> <allan_w@my-dejanews.com> writes
> >    struct foo { /* ... */ };
> >    int main() { class foo f; }
> >the error message specifically says that
> >foo is a struct instead of a class. Is this complaint justified?
> No, it is a result (or so I am told) of the way that MS elected to
> mangle names and is non-conforming.

You know, I know that's what everybody meant to say (if nothing else,
the examples in 3.4.4 are quite clear) but the only normative language
I can find is 7.1.5.3p3:

| The class key or enum keyword present in the elaborated type
specifier
| shall agree in kind with the declaration to which the name in the
| elaborated type specifier refers.

9p3 very strongly implies the difference between `struct` and `class`
is similar in kind to the difference between `union` and `class`:

| A structure is a class defined with the class key `struct`; [...]| A
union is a class defined with the class key `union`; [...]

and I can't find anything else but the rather weak (especially by
contrast to the quoted parallels in 9p3) structural variations in the
text at the end of 7.1.5.3p3.

So it's pedantry time.  Will someone please point me at the normative
language that "shall"s what I know should be?

Jim
---
[ 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://www.research.att.com/~austern/csc/faq.html                ]

Jim Hill wrote:
>
> Francis Glassborow <francis.glassborow@ntlworld.com> wrote in message news:<M7m579XIFLE8Ew7Z@robinton.ntlworld.com>...
> > In article <7f2735a5.0112061412.50fc3d8f@posting.google.com>, Allan W
> > <allan_w@my-dejanews.com> writes
> > >    struct foo { /* ... */ };
> > >    int main() { class foo f; }
> > >the error message specifically says that
> > >foo is a struct instead of a class. Is this complaint justified?
> > No, it is a result (or so I am told) of the way that MS elected to
> > mangle names and is non-conforming.
>
> You know, I know that's what everybody meant to say (if nothing else,
> the examples in 3.4.4 are quite clear) but the only normative language
> I can find is 7.1.5.3p3:
>
> | The class key or enum keyword present in the elaborated type specifier
> | shall agree in kind with the declaration to which the name in the
> | elaborated type specifier refers.
>
> [...]
>
> and I can't find anything else but the rather weak (especially by
> contrast to the quoted parallels in 9p3) structural variations in the
> text at the end of 7.1.5.3p3.
>
> So it's pedantry time.  Will someone please point me at the normative
> language that "shall"s what I know should be?

I think it's the last sentence in 7.1.5.3p3 which you see seem to be calling
"rather weak":

| [...] Thus, in any elaborated-type-specifier, the enum keyword shall be used
to
| refer to an enumeration (7.2), the union class-key shall be used to refer to a
union (clause 9), and either
| the class or struct class-key shall be used to refer to a class (clause 9)
declared using the class or
| struct class-key.

This sentence is explaining what is meant by the "the elaborated type specifier
shall agree in kind" you quoted above.  It's specifically saying that you can
use either 'struct' or 'class' to refer to something that was previously
declared with either 'struct' or 'class'.

---
[ 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://www.research.att.com/~austern/csc/faq.html                ]

In article <a8af2f56.0112092332.46a15312@posting.google.com>, Jim Hill
<jthill_@mac.com> writes
>You know, I know that's what everybody meant to say (if nothing else,
>the examples in 3.4.4 are quite clear) but the only normative language
>I can find is 7.1.5.3p3:
>
>| The class key or enum keyword present in the elaborated type
>specifier
>| shall agree in kind with the declaration to which the name in the
>| elaborated type specifier refers.

However read the whole of that paragraph:

The final sentence is:
Thus, in any elaborated-type specifier, the enum keyword shall be used
to refer to enumeration (7.2), the union class-key shall be used to
refer to a union (clause 9), and either the class or struct class-key
shall be used to refer to a class (clause 9) declared using the class or
struct class-key.

Now note that it spells out union as one case but does not spell out
struct and class as separate cases. At the very least that is paragraph
is ambiguous, perhaps it is even contradictory. I think that a request
for interpretation would be one route or a defect report (but without
writing much more it is hard to see how to reword the text.) I think the
use of 'kind' in the sentence you quote because unions are a different
kind of thing from classes and structs even though they share a number
of common features. The only difference between class and struct is
access which is a pure compile time feature and only effects the way you
write the code not the way it is compiled (a compiler that compiles
struct and class differently would be perverse.)


--
Francis Glassborow
I offer my sympathy and prayers to all those who are suffering
as a result of the events of September 11 2001.

      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]

[ 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://www.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

tom_usenet@hotmail.com (Tom) wrote in message news:<3c06ea42.15047417@news.ntlworld.com>...
> On 29 Nov 2001 18:01:22 -0500, Martin Fabian
> <fabianNOSPAM@s2.chalmers.se> wrote:
>
> >Since you (well, me, at least :-) almost always add constructors to the
> >c++structs, the c++/c-struct compatibility feature seems to be of
> >limited value. I guess it was (is?) most useful during the transition
> >from c to c++.
>
> And for fast, non-portable binary IO which I certainly need a lot
> (yes, I did profile before deciding to do this). If you add
> constructors you no longer have a POD struct, so you can't just memcpy
> it around. Why call memcpy for each member of a class when you can do
> the whole lot in one go if you have a POD struct.
>

Actually I usually add constructors to structs I'm using just as data,
but only for the purpose for easy initialisation of members.  Why
shouldn't it be safe to memcpy that around?

struct color
{
 color() { }
 color(int r, int g, int b) : red(r), green(g), blue(b) { }
 int red, green, blue;
};

Dylan
---
[ 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://www.research.att.com/~austern/csc/faq.html                ]

scott douglass <sdouglass@arm.com> wrote in message news:<9v4o9i$h0g$1@cam-news1.cambridge.arm.com>...
> I think it's the last sentence in 7.1.5.3p3, which you seem to be calling
> "rather weak":
> | [...] Thus [...] either the class or struct class-key shall be
> | used to refer to a class (clause 9) declared using the class or
> | struct class-key.
>
> It's specifically saying that you can use either [...]

I'd agree with you if it weren't for that "thus" up front, which means
to me that the remainder of that sentence is deducible from the rest
of the Standard.  I can't find how. I suspect "thus" was another
~everybody-knows-this~-induced miswording.

Jim

---
[ 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://www.research.att.com/~austern/csc/faq.html                ]

Sungbom Kim wrote:
> "James Kuyper Jr." wrote:
> >
> > Sungbom Kim wrote:
...
> > > Actually not very much is saved by omitting one keyword, and anyway
> > > in most cases 'public' has to be written because the default for
> > > classes (declared 'class') are 'private'.
> >
> > Then declare them as structs.
>
> You wouldn't change 'class' to 'struct' just to get rid of the
> starting "public:" in the above example, would you?

No, because I favor the style that leaves in that "public:" even when
it's redundant. However, you were claiming that you had to write
"public:" if you used the 'class' keyword. I was just echoing the famous
medical advice: "It's hurts when I do this!" "Then don't do that."

> Though classes and structs are technically and essentially the same
> (in most ways, at least), I think they convey different meanings to
> the programmers and readers.

Only to the ones that don't know what they're doing. The difference
between 'struct' and 'class' is entirely about the default access
specifier. Anyone who's attached different connotations to those
keywords has some unlearning to do.
---
[ 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://www.research.att.com/~austern/csc/faq.html                ]

Sungbom Kim wrote:
>
> Sean Kelly wrote:
> >
> > Sungbom Kim <musiphil@bawi.org> wrote in message
> news:<3C051430.3AE0E9C2@bawi.org>...
> > > Wouldn't there be any possibility that the next standard would
> > > declare the omission of the access specifier to be deprecated,
> > > as was the case with implicit int for function return types?
> >
> > Not in this case, because again, the C++ compiler would not be able to
> > compile C code containg struct declarations (as C does not have access
> > specifiers).  Whether C-compatibility is a desirable feature to
> > continue to support, however, is another discussion.
>
> C compatibility is irrelevant here, since as Adam Peterson said,
> if you are inheriting, you're doing C++ anyway.

It's a combination of C compatibility, which requires that the default
for struct members be "public", and C++ consistency, which calls for
base classes to be treated the same way as class members.

In any event, such a change to the standard is extremely unlikely,
because C++ has itself been around for long enough, with the current
rules for base class access, that C++ compatibility becomes the deciding
issue. Those rules could not be changed without breaking a lot of
existing code. This would be a simpler incompatibility than most; it
would be fairly simple to search for and change any single piece of code
that would be affected, but the total amount of code that would have to
be re-written and re-compiled is enormous.
---
[ 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://www.research.att.com/~austern/csc/faq.html                ]

Sungbom Kim <musiphil@bawi.org> wrote in message news:<3C051430.3AE0E9C2@bawi.org>...
> In the absence of an access specifier for a base class,
> - 'public' is assumed when the derived class is declared 'struct', and
> - 'private' is assumed when the derived class is declared 'class'.
>
> I wonder what the rationale is for allowing the omission, and
> for giving such defaults if omission is allowed.

Isnt it historical? The first version of C++ I used (around 86-87 I
believe) didnt have private or protected keywords - structs had public
members, and public inheritance; classes defaulted to private
inheritance, but it could be made public using the public keyword. You
had to put the private members of a class first, and the public ones
last.

Mark Williams
---
[ 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://www.research.att.com/~austern/csc/faq.html                ]

Francis Glassborow <francis.glassborow@ntlworld.com> wrote
> But there is no difference in the language between structs and classes
> other than their default access specifier.

Are they synonyms, other than this minor difference? Or are they
just equivalent?

It matters in code like this:

    struct foo { /* ... */ };

    int main() {
        class foo f;
    }

The keyword "class" is optional in this context. But is it legal?

IIRC, Microsoft objects, and the error message specifically says that
foo is a struct instead of a class. Is this complaint justified?
---
[ 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://www.research.att.com/~austern/csc/faq.html                ]

In article <3C0E2605.CDD50037@wizard.net>, James Kuyper Jr.
<kuyper@wizard.net> writes
>Only to the ones that don't know what they're doing. The difference
>between 'struct' and 'class' is entirely about the default access
>specifier. Anyone who's attached different connotations to those
>keywords has some unlearning to do.

I disagree, those who do not understand current idioms have some
learning to do.  There is more to using any language than just abiding
by the rules, idioms are part of our toolkit for communication.


--
Francis Glassborow
I offer my sympathy and prayers to all those who are suffering
as a result of the events of September 11 2001.

      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]

[ 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://www.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

In article <200112050820.JAA11555@brick.ens.fr>, Valentin Bonnard
<Valentin.Bonnard@free.fr> writes
>> You wouldn't change 'class' to 'struct' just to get rid of the
>> starting "public:" in the above example, would you?
>
>I would.

You surprise me. I am used to the idiomatic use of the struct keyword to
indicate that there will be no private or protected access.


--
Francis Glassborow
I offer my sympathy and prayers to all those who are suffering
as a result of the events of September 11 2001.

---
[ 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://www.research.att.com/~austern/csc/faq.html                ]

Valentin.Bonnard@free.fr (Valentin Bonnard) wrote (abridged):
> > You wouldn't change 'class' to 'struct' just to get rid of the
> > starting "public:" in the above example, would you?
>
> I would.

I have, too. Mainly for in code where the clutter of "public:" seemed
excessive; for example, declaring a local type within a function.

I have also had structs which started out as PODs, and gradually
accumulated constructors and private data.

In my view the word "class" adds nothing to C++ and should never have been
introduced.

  Dave Harris, Nottingham, UK | "Weave a circle round him thrice,
      brangdon@cix.co.uk      |   And close your eyes with holy dread,
                              |  For he on honey dew hath fed
 http://www.bhresearch.co.uk/ |   And drunk the milk of Paradise."

---
[ 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://www.research.att.com/~austern/csc/faq.html                ]

In article <9u7jlu$cnb$1@acs2.byu.edu>, Adam Peterson
<ahp6@email.byu.edu> writes
>Second, even ignoring C, one of the (IMHO) greatest acknowledged strengths
>of C++ is that it has broad and extensive support for multi-paradigm
>programming.  Structs are a valuable tool for procedural programming, and if
>someone decides to code part of a project in a procedural paradigm (perhaps
>to make it easier/possible to link to C modules, perhaps because they feel
>that the problem is most eloquently solved in procedural notation), structs
>and straight POD types should be at their disposal in C++.  (They are
>available now.  Compilers support them.  Why take it away?)

But there is no difference in the language between structs and classes
other than their default access specifier. I am not arguing for their
removal just pointing out that from the compiler's perspective struct
adds nothing to the language. However from the human perspective they
do, they allow me to document that I intend there to be public access to
the data of instances of this type. What I would argue for (if it were
not for legacy code) is the removal of access specifiers for structs.
Good programmers already avoid putting protected and private in a
struct, but the language allows it. I think that is a pity.


--
Francis Glassborow
I offer my sympathy and prayers to all those who are suffering
as a result of the events of September 11 2001.

      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]

[ 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://www.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

"James Kuyper Jr." wrote:
>
> Sungbom Kim wrote:
> >
> > In the absence of an access specifier for a base class,
> > - 'public' is assumed when the derived class is declared 'struct', and
> > - 'private' is assumed when the derived class is declared 'class'.
> >
> > I wonder what the rationale is for allowing the omission, and
> > for giving such defaults if omission is allowed.
>
> I'd guess that the main reason was to maintain a parallel between the
> way the base classes are handled, and the way members are handled. A
> base class is, in many ways, just a special kind of member.
>
> That in turn leads to the question of why members are handled that way.
> The use of a default access specification for 'struct', and the fact
> that the default was chosen to be 'public', were choices that guaranteed
> that a C-style struct declaration would be interpreted in a way that was
> compatible with C, simplifying code conversion. However, most members
> should be 'private' in proper C++ code, and that is encouraged by making
> 'private' the default for classes declared with the 'class' keyword.

However I have also seen a lot of materials that recommend writing
the interface of a class first, in which case (and in my most cases)
I start by saying "public:".

The most common form is, I think:

class Derived : public Base
{
public:
    // interface for "the general public"
protected:
    // interface for derived classes (if any)
private:
    // implementation detail
};

> > Actually not very much is saved by omitting one keyword, and anyway
> > in most cases 'public' has to be written because the default for
> > classes (declared 'class') are 'private'.
>
> Then declare them as structs.

You wouldn't change 'class' to 'struct' just to get rid of the
starting "public:" in the above example, would you?
Though classes and structs are technically and essentially the same
(in most ways, at least), I think they convey different meanings to
the programmers and readers.

--
Sungbom Kim <musiphil@bawi.org>



      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]

[ 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://www.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

Sean Kelly wrote:
>
> Sungbom Kim <musiphil@bawi.org> wrote in message
news:<3C051430.3AE0E9C2@bawi.org>...
> > Wouldn't there be any possibility that the next standard would
> > declare the omission of the access specifier to be deprecated,
> > as was the case with implicit int for function return types?
>
> Not in this case, because again, the C++ compiler would not be able to
> compile C code containg struct declarations (as C does not have access
> specifiers).  Whether C-compatibility is a desirable feature to
> continue to support, however, is another discussion.

C compatibility is irrelevant here, since as Adam Peterson said,
if you are inheriting, you're doing C++ anyway.

--
Sungbom Kim <musiphil@bawi.org>



      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]

[ 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://www.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

Adam Peterson wrote:
>
> I think that disallowing (or deprecating) omission of an access specifier
> for classes makes sense.  The first line of my class definition is 95% of
> the time "public:" because I declare my interface first.  When it's not
> "public:", it's "private:" because I feel that specifying it is clearer than
> leaving it out.  (I only do this to declare a private copy constructor and
> assignment operator when I choose to disallow copying of my class.)
> Likewise, for private inheritance I always put the keyword in for
> readability.
>
> However, in the case of structs, I still feel that we should not only keep
> them in the language, but also we should allow the omission of a specifier
> to imply public access.
>
> [...]
>
> In the case of classes, I agree that requiring access specifiers (or
> deprecating their omission) would be a valuable language feature.  Certainly
> in the case of the inheritance specifier.  (I have been bitten by
> accidentally inheriting privately.)  But as far as structs go, I would say
> that for the most part they should be left as they are.

Agreed.
Now I have come to think that it would be better to require access
specifiers for both inheritance and members with classes and to leave
the rules untouched as they are for structs. This makes clear the
intention of the programmer for new real OO codes, while preserving
the compatibility for codes that require POD structs (C codes, etc.).

--
Sungbom Kim <musiphil@bawi.org>
---
[ 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://www.research.att.com/~austern/csc/faq.html                ]

Sungbom Kim  wrote:

> The most common form is, I think:
>
> class Derived : public Base
> {
> public:
>     // interface for "the general public"
> protected:
>     // interface for derived classes (if any)
> private:
>     // implementation detail
> };
>
>> > Actually not very much is saved by omitting one keyword, and anyway
>> > in most cases 'public' has to be written because the default for
>> > classes (declared 'class') are 'private'.
>>
>> Then declare them as structs.
>
> You wouldn't change 'class' to 'struct' just to get rid of the
> starting "public:" in the above example, would you?

I would.

   --   VB

---
[ 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://www.research.att.com/~austern/csc/faq.html                ]

Sungbom Kim wrote:
>
> In the absence of an access specifier for a base class,
> - 'public' is assumed when the derived class is declared 'struct', and
> - 'private' is assumed when the derived class is declared 'class'.
>
In general it holds that
In the absence of an access specifier
- 'public' is assumed when the class is declared 'struct', and
- 'private' is assumed when the class is declared 'class'.

This makes (some) sense for members and specifically allows c++structs
to be compatible with c-structs.

<snip>

> In particular I supposed that it would have been better to give a
> default of 'public' in either case, since public inheritance is much
> more common and represents the IS-A relationship that the most typical
> kind of inheritance expresses.
>
I think its a good thing that special rules do not apply for
inheritance, in this case. If you leave out the specifier, you know what
gives. Now, whether we should allow leaving out that specifier...

<snip>

> Wouldn't there be any possibility that the next standard would
> declare the omission of the access specifier to be deprecated,
> as was the case with implicit int for function return types?
>
Agreed (I think).
Since you (well, me, at least :-) almost always add constructors to the
c++structs, the c++/c-struct compatibility feature seems to be of
limited value. I guess it was (is?) most useful during the transition
from c to c++.

Note also that disallowing omission of the access specifier really
implies that struct should be removed altogether (doesn't it?).
--
Martin Fabian                         http://www.s2.chalmers.se/~fabian/
                                                                      --
   Ask enough experts. Eventually you'll get the answer you want.

        /* Remove NOSPAM from reply-to address to mail me */
---
[ 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://www.research.att.com/~austern/csc/faq.html                ]

Sungbom Kim wrote:
>
> In the absence of an access specifier for a base class,
> - 'public' is assumed when the derived class is declared 'struct', and
> - 'private' is assumed when the derived class is declared 'class'.
>
> I wonder what the rationale is for allowing the omission, and
> for giving such defaults if omission is allowed.

I'd guess that the main reason was to maintain a parallel between the
way the base classes are handled, and the way members are handled. A
base class is, in many ways, just a special kind of member.

That in turn leads to the question of why members are handled that way.
The use of a default access specification for 'struct', and the fact
that the default was chosen to be 'public', were choices that guaranteed
that a C-style struct declaration would be interpreted in a way that was
compatible with C, simplifying code conversion. However, most members
should be 'private' in proper C++ code, and that is encouraged by making
'private' the default for classes declared with the 'class' keyword.

...
> And I also supposed that it would have been better not to allow
> omission of the access specifier altogether, so that the intent
> of the programmer could always be explicitly expressed.

That's a controversial issue of language design. Personally, I like well
chosen defaults. They simplify ordinary code, while allowing for more
complicated cases. Also, if well-chosen, they provide the programmer
with guidance - whenever in doubt, use the default first, and correct it
later if you learn that the default was a bad choice in this case.

> Actually not very much is saved by omitting one keyword, and anyway
> in most cases 'public' has to be written because the default for
> classes (declared 'class') are 'private'.

Then declare them as structs.

> Wouldn't there be any possibility that the next standard would
> declare the omission of the access specifier to be deprecated,
> as was the case with implicit int for function return types?

Sure, there's a possibility, but I don't think it's likely. There's far
less of a consensus that this particular style of coding is a bad idea.
---
[ 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://www.research.att.com/~austern/csc/faq.html                ]

Sungbom Kim <musiphil@bawi.org> writes:

> In the absence of an access specifier for a base class,
> - 'public' is assumed when the derived class is declared 'struct', and
> - 'private' is assumed when the derived class is declared 'class'.
>
> I wonder what the rationale is for allowing the omission, and
> for giving such defaults if omission is allowed.

The defaults follow the ones inside the class. If a class is declared
with "class", the members are all private until the first access
specifier is seen. If it is declared using "struct", all members are
public by default. The base class is just some special kind of member,
so it gets the same treatment.

> Wouldn't there be any possibility that the next standard would
> declare the omission of the access specifier to be deprecated,
> as was the case with implicit int for function return types?

I guess there would, but I think it is unlikely to change. The reason
for deprecating the implicit int is that it is a frequent source of
confusion, as translations such as

(*x);

suddenly become well-formed. With the access specifiers for base
classes, I see no such problem: if a programmer is confused about it,
the compiler will usually report an error, instead of silently
mis-interpreting the program.

Regards,
Martin
---
[ 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://www.research.att.com/~austern/csc/faq.html                ]

Sungbom Kim <musiphil@bawi.org> wrote in message news:<3C051430.3AE0E9C2@bawi.org>...
> In the absence of an access specifier for a base class,
> - 'public' is assumed when the derived class is declared 'struct', and
> - 'private' is assumed when the derived class is declared 'class'.
>
> I wonder what the rationale is for allowing the omission, and
> for giving such defaults if omission is allowed.
>
> In particular I supposed that it would have been better to give a
> default of 'public' in either case, since public inheritance is much
> more common and represents the IS-A relationship that the most typical
> kind of inheritance expresses.

You're confusing inheritance with access.  The rule states that
members of a struct are public unless declared otherwise and members
of a class are private unless declared otherwise.  The reason for
struct members defaulting to public is simple -- it was neccessary for
backwards-compatibility with C code.  The reason for class members
being private is equally straightforward -- the idea was to promote
encapsulation.  What has always bugged me was that in C++ we end up
having two specifiers for the exact same thing.  I grant that the each
label is appropriate for the access rules, but inheritance heirarchies
incorporation both seems messy to me.  I'd rather just use class or
struct everywhere and get rid of the other label entirely.

> Wouldn't there be any possibility that the next standard would
> declare the omission of the access specifier to be deprecated,
> as was the case with implicit int for function return types?

Not in this case, because again, the C++ compiler would not be able to
compile C code containg struct declarations (as C does not have access
specifiers).  Whether C-compatibility is a desirable feature to
continue to support, however, is another discussion.
---
[ 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://www.research.att.com/~austern/csc/faq.html                ]

On 29 Nov 2001 18:01:22 -0500, Martin Fabian
<fabianNOSPAM@s2.chalmers.se> wrote:

>Since you (well, me, at least :-) almost always add constructors to the
>c++structs, the c++/c-struct compatibility feature seems to be of
>limited value. I guess it was (is?) most useful during the transition
>from c to c++.

And for fast, non-portable binary IO which I certainly need a lot
(yes, I did profile before deciding to do this). If you add
constructors you no longer have a POD struct, so you can't just memcpy
it around. Why call memcpy for each member of a class when you can do
the whole lot in one go if you have a POD struct.

Tom

      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]

[ 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://www.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

"Sean Kelly" <kensai@pacbell.net> wrote in message
news:721ff0b.0111291627.59b46888@posting.google.com...
> Sungbom Kim <musiphil@bawi.org> wrote in message
news:<3C051430.3AE0E9C2@bawi.org>...
> > In the absence of an access specifier for a base class,
> > - 'public' is assumed when the derived class is declared 'struct', and
> > - 'private' is assumed when the derived class is declared 'class'.
> >
> > I wonder what the rationale is for allowing the omission, and
> > for giving such defaults if omission is allowed.
> >
> > In particular I supposed that it would have been better to give a
> > default of 'public' in either case, since public inheritance is much
> > more common and represents the IS-A relationship that the most typical
> > kind of inheritance expresses.
>
> You're confusing inheritance with access.

No, I don't think he does that. He mentions access speciciers for the
inheritance, and public inheritance means is-a, while e.g. private
inheritance does not.

So it's relevant.


Regards,

Terje Slettebo


      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]

[ 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://www.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

<snip>
> > Wouldn't there be any possibility that the next standard would
> > declare the omission of the access specifier to be deprecated,
> > as was the case with implicit int for function return types?
> >
> Agreed (I think).
> Since you (well, me, at least :-) almost always add constructors to the
> c++structs, the c++/c-struct compatibility feature seems to be of
> limited value. I guess it was (is?) most useful during the transition
> from c to c++.
>
> Note also that disallowing omission of the access specifier really
> implies that struct should be removed altogether (doesn't it?).

I think that disallowing (or deprecating) omission of an access specifier
for classes makes sense.  The first line of my class definition is 95% of
the time "public:" because I declare my interface first.  When it's not
"public:", it's "private:" because I feel that specifying it is clearer than
leaving it out.  (I only do this to declare a private copy constructor and
assignment operator when I choose to disallow copying of my class.)
Likewise, for private inheritance I always put the keyword in for
readability.

However, in the case of structs, I still feel that we should not only keep
them in the language, but also we should allow the omission of a specifier
to imply public access.

I have two reasons for this:

First, maintaining (reasonable) compatibility with C is a valuable thing,
even a veritable must.  I believe that C has as much life left in it as C++,
and there are valid technical and anthropological reasons to choose C over
C++, and while I am glad that for the most part they don't apply to my
situation, I acknowledge their validity.  When you throw in all the specious
reasons to choose C over C++ on top of the valid ones, you have to
acknowledge that C will be with us for a while, and the easier we make it to
port C code to C++, the larger C++ code base and developer base we are
likely to attract.  Disallowing structs, or even requiring the access
specifier, will break C code when there's no need to.  (This might not
necessarily apply to inheritance access specifiers, since if you are
inheriting, you're doing C++ anyway.)

Second, even ignoring C, one of the (IMHO) greatest acknowledged strengths
of C++ is that it has broad and extensive support for multi-paradigm
programming.  Structs are a valuable tool for procedural programming, and if
someone decides to code part of a project in a procedural paradigm (perhaps
to make it easier/possible to link to C modules, perhaps because they feel
that the problem is most eloquently solved in procedural notation), structs
and straight POD types should be at their disposal in C++.  (They are
available now.  Compilers support them.  Why take it away?)

In the case of classes, I agree that requiring access specifiers (or
deprecating their omission) would be a valuable language feature.  Certainly
in the case of the inheritance specifier.  (I have been bitten by
accidentally inheriting privately.)  But as far as structs go, I would say
that for the most part they should be left as they are.



      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]

[ 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://www.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

In the absence of an access specifier for a base class,
- 'public' is assumed when the derived class is declared 'struct', and
- 'private' is assumed when the derived class is declared 'class'.

I wonder what the rationale is for allowing the omission, and
for giving such defaults if omission is allowed.

In particular I supposed that it would have been better to give a
default of 'public' in either case, since public inheritance is much
more common and represents the IS-A relationship that the most typical
kind of inheritance expresses.

And I also supposed that it would have been better not to allow
omission of the access specifier altogether, so that the intent
of the programmer could always be explicitly expressed.
Actually not very much is saved by omitting one keyword, and anyway
in most cases 'public' has to be written because the default for
classes (declared 'class') are 'private'.

Wouldn't there be any possibility that the next standard would
declare the omission of the access specifier to be deprecated,
as was the case with implicit int for function return types?

--
Sungbom Kim <musiphil@bawi.org>


      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]

[ 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://www.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]