On Tue, 26 Sep 2006 14:40:10 GMT, petebecker@acm.org (Pete Becker)
wrote:

>Alberto Ganesh Barbati wrote:
>>
>> It's always been like this and everybody is happy with that. However, I
>> find the use of the term non-POD-struct unfortunate. What is a
>> non-POD-struct? Is it any-type-that-is-not-a-POD-struct? Or is it
>> any-struct-that-is-not-a-POD-struct? In other words, is "non-POD-struct"
>> equivalent to "non-(POD-struct)" or "(non-POD)-struct"?
>>
>
>Someone put in too many hyphens. The correct term is "non-POD struct."
>I've made a note to fix that.

Then why not "non-POD class" :-) You might also want to look at this
post, specifically the part beginning with "The terminology, also,
seems to be...":


<http://google.com/groups?selm=1ogfnuon5k5vnpgnd707umv1okjk0r9fbr@4ax.com>

--
Gennaro Prota

---
[ 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.comeaucomputing.com/csc/faq.html                      ]

Alberto Ganesh Barbati wrote:
> Greg Herlihy ha scritto:
>> Alberto Ganesh Barbati wrote:
>>
>> Significant revisions to the Standard's POD terminology are currently
>> under review. For example, the proposed revised text of the above
>> definition reads:
>>
>> "A POD class is an aggregate class that has no non-static data members
>> of non-POD type (or array of such a type) or reference, and has no
>> user-declared copy assignment operator and no user-declared destructor.
>> A POD-struct is a POD class defined with the class-key struct or the
>> class-key class. A POD-union is a POD class defined with the class-key
>> union."
>>
>> http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#538
>
> Thanks for the reference. I somehow missed that. It's a pity that paper
> N2062 which is going to be discussed in Portland doesn't mention issue
> #538 and proposes a text which still include the dubious
> "non-POD-struct" term.

There will be a revision of N2062 that should reach the committee before
the Portland meeting, with proposed text relative to the proposed text
in 538.

Thanks for pointing this out.

--Beman Dawes

---
[ 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.comeaucomputing.com/csc/faq.html                      ]

Hi Everybody,

The definition of POD-struct in =A79/4 is "A POD-struct is an aggregate=20
class that has no non-static data members of type non-POD-struct,=20
non-POD-union (or array of such types) or reference, and has no=20
user-defined copy assignment operator and no user-defined destructor."

It's always been like this and everybody is happy with that. However, I=20
find the use of the term non-POD-struct unfortunate. What is a=20
non-POD-struct? Is it any-type-that-is-not-a-POD-struct? Or is it=20
any-struct-that-is-not-a-POD-struct? In other words, is "non-POD-struct"=20
equivalent to "non-(POD-struct)" or "(non-POD)-struct"?

The latter seems more reasonable, but the ambiguity is legitimate, IMHO.=20
If we accept the former, we get into troubles... Consider this struct:

struct pod_wannabe
{
   int member;
};

is it a POD-struct? Well, yes, we all know that. Sure? The only member=20
is an int, which is not a POD-struct (it's not an aggregate class), so=20
if we can say that it is a non-POD-struct, that would make pod_wannabe a=20
non-POD-struct as well.

The recent paper N2062 which aims at a redefinition of the POD and=20
POD-related concepts still proposes a wording that is prone to this=20
interpretation.

I am wondering why isn't the definition of POD-struct: 1) put in a=20
positive form, instead of a negative form that relies on a double=20
negation, 2) put more simply in terms of POD types. For example:

"A POD-struct is an aggregate class whose non-static members (if any)=20
are of POD type and has no user-defined copy assignment operator and no=20
user-defined destructor."

(the definition in N2062 also mentions access control and base classes,=20
which I have omitted here, I just hope you get the idea)

No need to mention array or references, because of the definition of POD=20
in 3.9/10 makes it redundant. In what would this definition be=20
different? Am I missing something?

Regards,

Ganesh

---
[ 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.comeaucomputing.com/csc/faq.html                      ]

Alberto Ganesh Barbati wrote:
> Hi Everybody,
>
> The definition of POD-struct in    9/4 is "A POD-struct is an aggregate
> class that has no non-static data members of type non-POD-struct,
> non-POD-union (or array of such types) or reference, and has no
> user-defined copy assignment operator and no user-defined destructor."
>
> It's always been like this and everybody is happy with that. However, I
> find the use of the term non-POD-struct unfortunate. What is a
> non-POD-struct? Is it any-type-that-is-not-a-POD-struct? Or is it
> any-struct-that-is-not-a-POD-struct? In other words, is "non-POD-struct"
> equivalent to "non-(POD-struct)" or "(non-POD)-struct"?

Significant revisions to the Standard's POD terminology are currently
under review. For example, the proposed revised text of the above
definition reads:

"A POD class is an aggregate class that has no non-static data members
of non-POD type (or array of such a type) or reference, and has no
user-declared copy assignment operator and no user-declared destructor.
A POD-struct is a POD class defined with the class-key struct or the
class-key class. A POD-union is a POD class defined with the class-key
union."

http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#538

Defining a POD class in negative terms is appropriate because it
emphasizes that a POD class is not a POD class by virtue of any overt,
defining quality. On the contrary, a class that declares nothing is a
POD class. So the quality of "POD-ness" ("PODitude"?) is not something
earned, but something that can be lost. A POD class loses its POD-ness
by including a non-POD type as a member.

So when it comes to writing a POD-class, there is nothing that the
programmer has to do to ensure the class's PODness - there is only one
thing that the programmer must be sure not to do - in order to keep the
class's PODness intact - assuming of course that the programmer even
gives a, um, better make that, has an opinion on the matter in the
first place.

Greg


---
[ 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.comeaucomputing.com/csc/faq.html                      ]

Alberto Ganesh Barbati wrote:
>
> It's always been like this and everybody is happy with that. However, I
> find the use of the term non-POD-struct unfortunate. What is a
> non-POD-struct? Is it any-type-that-is-not-a-POD-struct? Or is it
> any-struct-that-is-not-a-POD-struct? In other words, is "non-POD-struct"
> equivalent to "non-(POD-struct)" or "(non-POD)-struct"?
>

Someone put in too many hyphens. The correct term is "non-POD struct."
I've made a note to fix that.

--

 -- Pete

Author of "The Standard C++ Library Extensions: a Tutorial and
Reference." For more information about this book, see
www.petebecker.com/tr1book.

---
[ 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.comeaucomputing.com/csc/faq.html                      ]

Greg Herlihy ha scritto:
> Alberto Ganesh Barbati wrote:
>
> Significant revisions to the Standard's POD terminology are currently
> under review. For example, the proposed revised text of the above
> definition reads:
>
> "A POD class is an aggregate class that has no non-static data members
> of non-POD type (or array of such a type) or reference, and has no
> user-declared copy assignment operator and no user-declared destructor.
> A POD-struct is a POD class defined with the class-key struct or the
> class-key class. A POD-union is a POD class defined with the class-key
> union."
>
> http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#538

Thanks for the reference. I somehow missed that. It's a pity that paper
N2062 which is going to be discussed in Portland doesn't mention issue
#538 and proposes a text which still include the dubious
"non-POD-struct" term.

> Defining a POD class in negative terms is appropriate because it
> emphasizes that a POD class is not a POD class by virtue of any overt,
> defining quality. On the contrary, a class that declares nothing is a
> POD class. So the quality of "POD-ness" ("PODitude"?) is not something
> earned, but something that can be lost. A POD class loses its POD-ness
> by including a non-POD type as a member.

Well, that's a matter of opinions. I don't see in this particular case
the need to stress such intent. Here we just have two different
sentences with the same logical value and the positive form is IMHO
clearer and more understandable because it avoids a double negation. So
between "has no non-POD member" and "every member (if any) is a POD" I
prefer the latter. The situation is worsened by the presence of the
adjective "non-static" which introduces another (unrelated) negation.

The second part of the statement "has no user-declared copy assignment
operator..." does not include a double negation, so there's no gain in
turning it into positive form (which actually sounds worse). I also
don't see anything wrong in having part of sentence in the positive and
part in the negative.

I would also remove the "(or array of such a type) or reference" which
is a redundant concept, IMHO, as it's already included in the definition
of POD-type.

Just my 2 eurocent.

Ganesh

---
[ 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.comeaucomputing.com/csc/faq.html                      ]