Andrei Alexandrescu wrote:
>
> Steve Clamage <stephen.clamage@sun.com> wrote in message
> news:38B72429.DCE42C70@sun.com...
> > More precisely, PODs exclude anything that would break C compatibility.
> > Non-virtual member functions and static data members do not affect
> > class size or layout, and so do not affect C compatibility.
>
> Is an implementation explicitly disallowed to store per-object information
> for nonvirtual member functions? I always thought this would be silly, but
> conforming.

IMHO, it's allowed by the standard, as long as the layout rules for
POD-structs and unions (section 9.2) are respected. It would break C
compatibility for some PODs, however, so an implementor would likely get
complaints from customers.

--
Steve Clamage, stephen.clamage@sun.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              ]

Ron Natalie wrote in message <38B41A37.F497A3B0@sensor.com>...
>Ronny wrote:
>> One of the things a POD struct must not contain are elements
>> which are of type "pointer to member" (unless these elements are
>> static). Does anyone know the rationale for this restriction?

>Pointers to members don't exist in C.

Neither did 'bool', but a POD struct may contain non-static bool members.
AFAICT I can use memcpy to copy an array of three pointers-to-member
(pointer to member is pod), but I can't use it to copy a struct containing
three pointers-to-member.  Likewise

extern int T::*x[1] = { &T::a };                    // Guaranteed (3.6.2/1)
static initialization

extern struct {  int T::*y; } z = { &T::a };    // No such guarantee

I don't understand the rationale behind the different treatments.



---
[ 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 <38B41A37.F497A3B0@sensor.com>, Ron Natalie
<ron@sensor.com> wrote:

>Ronny wrote:
>>
>> One of the things a POD struct must not contain are elements
>> which are of type "pointer to member" (unless these elements
are
>> static). Does anyone know the rationale for this restriction?
>Pointers to members don't exist in C.

Ooops, than I misunderstood the rationale for defining the term
"POD" in the standardsdocument. My interpretation was not, that
it should be for compatibility with C structures; I thought
instead that "POD struct" means that you are allowed to do some
nasty things with it, like using the offsetof macro or the memcpy
function (both of which certainly *would* be possible if member
pointers are allowed).

But if you are right and the sole rationale were only, that you
don't have member pointers because they are not in C, why then
are you allowed to have static members and (non-virtual) member
functions? Those beasts are not in C, and according to the
rationale you gave, they should be forbidden (while under my
assumption, it is clear why they are allowed).

Do you know by chance if there is some official document which
explains, *why* certain parts of the standard are made the way
they were done?

Ronald

Ronald Fischer <ronald_f@myremarq.com>
http://profiles.yahoo.com/ronny_fischer/
http://fusshuhn.ourfamily.com/cppincomp.html

* Sent from RemarQ http://www.remarq.com The Internet's Discussion Network *
The fastest and easiest way to search and participate in Usenet - Free!

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

Ronny wrote:
>
> In article <38B41A37.F497A3B0@sensor.com>, Ron Natalie
> <ron@sensor.com> wrote:
>
> >Ronny wrote:
> >>
> >> One of the things a POD struct must not contain are elements
> >> which are of type "pointer to member" (unless these elements
> are
> >> static). Does anyone know the rationale for this restriction?
> >Pointers to members don't exist in C.
>
> Ooops, than I misunderstood the rationale for defining the term
> "POD" in the standardsdocument. My interpretation was not, that
> it should be for compatibility with C structures; I thought
> instead that "POD struct" means that you are allowed to do some
> nasty things with it, like using the offsetof macro or the memcpy
> function (both of which certainly *would* be possible if member
> pointers are allowed).
>
> But if you are right and the sole rationale were only, that you
> don't have member pointers because they are not in C, why then
> are you allowed to have static members and (non-virtual) member
> functions?

More precisely, PODs exclude anything that would break C compatibility.
Non-virtual member functions and static data members do not affect
class size or layout, and so do not affect C compatibility. The
C version of a POD-struct would simply omit the static members
and member functions.

You cannot write a portable C declaration for a C++ pointer-to-member,
so you can't put one in a POD.

Non-trivial constructors and destructors are excluded because they
change the semantics of copying the object. A POD-struct can
always be copied by copying all the bits, and there are no side
effects in creating temporary POD objects. Not so if a non-
trivial constructor or destructor is involved.

--
Steve Clamage, stephen.clamage@sun.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              ]

Steve Clamage <stephen.clamage@sun.com> wrote in message
news:38B72429.DCE42C70@sun.com...
> More precisely, PODs exclude anything that would break C compatibility.
> Non-virtual member functions and static data members do not affect
> class size or layout, and so do not affect C compatibility.

Is an implementation explicitly disallowed to store per-object information
for nonvirtual member functions? I always thought this would be silly, but
conforming.


Andrei


---
[ 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 <38B72429.DCE42C70@sun.com>, Steve Clamage
<stephen.clamage@sun.com> wrote:
>Non-trivial constructors and destructors are excluded because
they
>change the semantics of copying the object. A POD-struct can
>always be copied by copying all the bits, and there are no side
>effects in creating temporary POD objects. Not so if a non-
>trivial constructor or destructor is involved.

I understand your point. Could you please point out which chapter
in the standard forbids non-trivial constructors for a POD? I
found the description in the intro to chapter 9, paragraph 4, in
the DWP (I don't have the final standard at hand), and it says
nothing about constructors.

Ronald

Ronald Fischer <ronald_f@myremarq.com>
http://profiles.yahoo.com/ronny_fischer/
http://fusshuhn.ourfamily.com/cppincomp.html

* Sent from RemarQ http://www.remarq.com The Internet's Discussion Network *
The fastest and easiest way to search and participate in Usenet - Free!

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

Ronny wrote:
>

> I understand your point. Could you please point out which chapter
> in the standard forbids non-trivial constructors for a POD? I
> found the description in the intro to chapter 9, paragraph 4, in
> the DWP (I don't have the final standard at hand), and it says
> nothing about constructors.
>

Chapter 9 para 4 defines POD... "A POD-struct is an aggregate class which
has ..."

8.5.1 defines Aggregate as having no user defined constructors., ...

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

Ronny wrote in message <08df872c.933ccfcc@usw-ex0101-006.remarq.com>...

>Could you please point out which chapter
>in the standard forbids non-trivial constructors for a POD? I
>found the description in the intro to chapter 9, paragraph 4, in
>the DWP (I don't have the final standard at hand), and it says
>nothing about constructors.

9p4 says a POD struct is an aggregate with certain additional restrictions.

8.5.1p1 says that an aggregate has no user-declared constructor.

HTH



---
[ 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 Tue, 29 Feb 2000 04:56:28 CST, Ronny <ronald_f@myremarq.com>
wrote:

>In article <38B72429.DCE42C70@sun.com>, Steve Clamage
><stephen.clamage@sun.com> wrote:
>>Non-trivial constructors and destructors are excluded because
>they
>>change the semantics of copying the object. A POD-struct can
>>always be copied by copying all the bits, and there are no side
>>effects in creating temporary POD objects. Not so if a non-
>>trivial constructor or destructor is involved.
>
>I understand your point. Could you please point out which chapter
>in the standard forbids non-trivial constructors for a POD? I
>found the description in the intro to chapter 9, paragraph 4, in
>the DWP (I don't have the final standard at hand), and it says
>nothing about constructors.

Chapter 9 says that a POD is an aggregate class and 8.5.1 says an
aggregate class may not have a user-declared constructor.

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

One of the things a POD struct must not contain are elements
which are of type "pointer to member" (unless these elements are
static). Does anyone know the rationale for this restriction?

Ronald

Ronald Fischer <ronald_f@myremarq.com>
http://profiles.yahoo.com/ronny_fischer/
http://fusshuhn.ourfamily.com/cppincomp.html

* Sent from RemarQ http://www.remarq.com The Internet's Discussion Network *
The fastest and easiest way to search and participate in Usenet - Free!

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

Ronny wrote:
>
> One of the things a POD struct must not contain are elements
> which are of type "pointer to member" (unless these elements are
> static). Does anyone know the rationale for this restriction?
>

Pointers to members don't exist in C.

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

Is there a definition of POD?


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

Ronny wrote:
>
> One of the things a POD struct must not contain are elements
> which are of type "pointer to member" (unless these elements are
> static). Does anyone know the rationale for this restriction?

The POD concept exists to specify C compatibility. A POD struct
can contain only those things that can be used in C. There is
no way to write a (portable) C declaration of a pointer-to-member,
so you can't put one in a POD.

--
Steve Clamage, stephen.clamage@sun.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              ]