Howard Hinnant wrote:
>
> Perhaps the best thing to do would be to go back to the old definition
> for is_empty, but insist that it be defined somewhere in the language
> spec.  And then is_empty can refer to that spec.  That makes it somebody
> else's problem. :-)  Although, that definition may not be compatible
> with our intent for is_empty...
>

Depending, of course, on what "our intent" is. My intent in voting for
this was for is_empty, like all the rest of the characterization traits,
to reflect the meaning given in the core language (which is why the
requirements for those traits simply refer to the appropriate section,
rather than more or less duplicating what the core portion already
says). There is a core problem that "empty class" is used in several
places but not defined.

--

 -- Pete
Roundhouse Consulting, Ltd. (www.versatilecoding.com)
Author of "The Standard C++ Library Extensions: a Tutorial and
Reference." (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                      ]

On 3/13/07 1:19 PM, in article 55o7vqF261fmfU1@mid.individual.net, "Alf P.
Steinbach" <alfps@start.no> wrote:

> * Greg Herlihy:
>>
>> The NonEmpty example is in fact doubly misleading. Because (somewhat
>> paradoxically) a NonEmpty base class is still eligible for the empty
>> base class optimzation - and may in fact contribute zero bytes to the
>> size of subclass object (thereby affirming for a second time that
>> NonEmpty is an empty class). The only stipulation is that the size of
>> the derived class on its own (that is, without the NonEmpty base
>> class) would be at least equal to the size of a NonEmpty object.
>>
>> So whether defined by its zero bits of information or by the zero
>> bytes of incremental storage - it's clear that the "oversight" and
>> (unsuccessful) attempt to define an "empty" class is found in the "C++
>> Templates" book and not in the proposed wording for is_empty<> type
>> trait - which is accurate in its current wording.
>
> Uh, well.  Albert, some words?  (Albert kicks in) "All is relative!"
>
> With a class such as NonEmpty it seems to me it depends on the derived
> class (specifically, its size) whether the empty base class optimization
> can be applied or not.

In order for the Empty Base Class Optimization to be applied to a base class
- the base class must (naturally enough) be "empty". And the std::is_empty<>
type trait (in the wording originally proposed) performs precisely that test
for emptiness. Granted, there are other factors that determine whether an
empty base class may be optimized in a given situation (for example, the
compiler might not support the optimization) - but in the abstract case, the
distinction between empty and non-empty classes is not relative - but
absolute: an empty class is one whose size (as a subobject) may be optimized
to zero bytes (under the right circumstances). A non-empty class is one
whose size (as a sub- or as a complete object) may never be optimized to
zero bytes - under any circumstances.

So the reason why NonEmpty is an empty class, is because there are
circumstances under which a NonEmpty base class contributes nothing to the
size of the complete object.

> If is_empty<> is meant to say whether EBCO can be applied, it seems to
> me it needs the size information about the derived class, or must simply
> not apply to this case (compile time error?), and if it's not meant to
> say whether EBCO can be applied, what is it for?

The std::is_empty<> type trait is supposed to be ideally-suited for testing
whether a base class is ever eligible for the EBC optimization. Where the
"C++ Templates" book went astray was assuming that the the target of the
empty base class optimization (and of the is_empty type trait as well) was
the complete class object itself. Granted, the complete type benefits from
the EBCO, but as its very name suggests, the optimization is applied to the
empty base class. So is_empty<NonEmpty> is really testing whether a class
that adds NonEmpty as a base class is certain to become larger by doing so,
or whether there is a possibility (but by no means a guarantee) that its
size would remain unchanged.

Unfortunately, if std::is_empty<> template type trait is hacked in order to
force is_empty<NonEmpty>::value to evaluate to false, then the is_empty<>
template would no longer be able to test whether a class's base class was
empty and - by extension - to test whether the complete class type may
benefit from the EBCO. In fact, by returning inaccurate results is_empty<>
would no longer have any discernable, useful purpose (that I can discern) -
and would in fact have the less-than-useful effect of propagating the same
errors, illogic and confusion evident in the C++ Templates book's discussion
of empty class types into the C++ Standard itself.

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                      ]

* Greg Herlihy:
>
> Unfortunately, if std::is_empty<> template type trait is hacked in order to
> force is_empty<NonEmpty>::value to evaluate to false, then the is_empty<>
> template would no longer be able to test whether a class's base class was
> empty and - by extension - to test whether the complete class type may
> benefit from the EBCO. In fact, by returning inaccurate results is_empty<>
> would no longer have any discernable, useful purpose (that I can discern) -
> and would in fact have the less-than-useful effect of propagating the same
> errors, illogic and confusion evident in the C++ Templates book's discussion
> of empty class types into the C++ Standard itself.

Now, now.  Why not is_empty<NonEmpty, 0> yielding false, and
is_empty<NonEmpty, 2> yielding true, where the number is the size of the
derived class sans NonEmpty base?  That said, being very much less than
a luminary in the forefront of C++ technology I'm not fully grokking the
purpose of is_empty: is it for compiler writers?

--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

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

In article <55tff8F26esmvU1@mid.individual.net>,
 "Alf P. Steinbach" <alfps@start.no> wrote:

> That said, being very much less than
> a luminary in the forefront of C++ technology I'm not fully grokking the
> purpose of is_empty: is it for compiler writers?

For me at least, it is for compressed_pair:

http://www.boost.org/libs/utility/compressed_pair.htm

We want compressed_pair<T1, T2> to derive from its template parameters
if they are empty classes.

Perhaps compressed_pair should just derive from the parameter if it is a
class. <shrug> I have an irrational distrust of multiple inheritance. ;-)

compressed_pair is subsequently handy for optimizing away the space
overhead for allocators and comparators in containers, and deleters in
smart pointers.

-Howard

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

Just recently I stumbled once again since a longer
time across chapter 16.2.1 of the first edition of
"C++ Templates" from Vandevoorde/Josuttis, which
explains the Empty Base Class Optimization (EBCO)
principle as well as its limits.
One interesting example is given, which must necessarily
forbid EBCO:

class Empty {
};

class EmptyToo : public Empty {
};

class NonEmpty : public Empty, public EmptyToo {
};

The reasoning is that NonEmpty cannot be an empty
class, because this would have the effect that two
subobjects of the same type would end up at the same
offset, which is not permitted by C++ object layout
rules.

The revised wording in n2157, found at

http://www2.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2157.html

does *not* exclude the above NonEmpty class from
is_empty categorization, because it says:

"    template <class T> struct is_empty : public
integral_constant<bool, b> {};

If is_class<T>::value is false then b is false. Otherwise T is
considered empty if and only if:

    * T has no non-static data members, or all non-static data
members, if any, are bit-fields of length 0, and
    * T has no virtual members, and
    * T has no virtual base classes, and
    * T has no base classes B for which is_empty<B>::value is false.

Requires: T shall be a complete type, an array type of unknown bounds,
or is a void type."

Now I wonder whether this is (a) an oversight in the is_empty
specification or (b) a deliberate design decision?

Greetings from Bremen,

Daniel Kr   gler


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

In article <1173648852.230192.11800@p10g2000cwp.googlegroups.com>,
 "Daniel Kr=FCgler" <daniel.kruegler@googlemail.com> wrote:

> Just recently I stumbled once again since a longer
> time across chapter 16.2.1 of the first edition of
> "C++ Templates" from Vandevoorde/Josuttis, which
> explains the Empty Base Class Optimization (EBCO)
> principle as well as its limits.
> One interesting example is given, which must necessarily
> forbid EBCO:
>=20
> class Empty {
> };
>=20
> class EmptyToo : public Empty {
> };
>=20
> class NonEmpty : public Empty, public EmptyToo {
> };
>=20
> The reasoning is that NonEmpty cannot be an empty
> class, because this would have the effect that two
> subobjects of the same type would end up at the same
> offset, which is not permitted by C++ object layout
> rules.
>=20
> The revised wording in n2157, found at
>=20
> http://www2.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2157.html
>=20
> does *not* exclude the above NonEmpty class from
> is_empty categorization, because it says:
>=20
> "    template <class T> struct is_empty : public
> integral_constant<bool, b> {};
>=20
> If is_class<T>::value is false then b is false. Otherwise T is
> considered empty if and only if:
>=20
>     * T has no non-static data members, or all non-static data
> members, if any, are bit-fields of length 0, and
>     * T has no virtual members, and
>     * T has no virtual base classes, and
>     * T has no base classes B for which is_empty<B>::value is false.
>=20
> Requires: T shall be a complete type, an array type of unknown bounds,
> or is a void type."
>=20
> Now I wonder whether this is (a) an oversight in the is_empty
> specification or (b) a deliberate design decision?

It is an oversight.  This was an attempt to give meaning to "empty=20
class".  Note the (marked out) definition it is replacing. =20
Unfortunately "empty class" isn't defined elsewhere in the standard,=20
though the phrase is occasionally used.

Perhaps the best thing to do would be to go back to the old definition=20
for is_empty, but insist that it be defined somewhere in the language=20
spec.  And then is_empty can refer to that spec.  That makes it somebody=20
else's problem. :-)  Although, that definition may not be compatible=20
with our intent for is_empty...

Suggestions for better wording welcome.

-Howard

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

Howard Hinnant schrieb:

> In article <1173648852.230192.11800@p10g2000cwp.googlegroups.com>,
>  "Daniel Kr   gler" <daniel.kruegler@googlemail.com> wrote:
>
> > The revised wording in n2157, found at
> >
> > http://www2.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2157.html
> >
> > does *not* exclude the above NonEmpty class from
> > is_empty categorization, because it says:
> >
> > "    template <class T> struct is_empty : public
> > integral_constant<bool, b> {};
> >
> > If is_class<T>::value is false then b is false. Otherwise T is
> > considered empty if and only if:
> >
> >     * T has no non-static data members, or all non-static data
> > members, if any, are bit-fields of length 0, and
> >     * T has no virtual members, and
> >     * T has no virtual base classes, and
> >     * T has no base classes B for which is_empty<B>::value is false.
> >
> > Requires: T shall be a complete type, an array type of unknown bounds,
> > or is a void type."
> >
> > Now I wonder whether this is (a) an oversight in the is_empty
> > specification or (b) a deliberate design decision?
>
> It is an oversight.  This was an attempt to give meaning to "empty
> class".  Note the (marked out) definition it is replacing.
> Unfortunately "empty class" isn't defined elsewhere in the standard,
> though the phrase is occasionally used.
>
> Perhaps the best thing to do would be to go back to the old definition
> for is_empty, but insist that it be defined somewhere in the language
> spec.  And then is_empty can refer to that spec.  That makes it somebody
> else's problem. :-)  Although, that definition may not be compatible
> with our intent for is_empty...
>
> Suggestions for better wording welcome.

>From the current proposal I could not clearly deduce,
which use cases is_empty is *really* supposed to support
(Besides N2157 I studied N2028- N1424 therefore, but could
not find anything - am I blind?).
And independent of the actual outcome to that question I
recommend to add a footnote or note that clarifies this intend
for future implementors.

1) is_empty is meant to allow EBCO to work. If so, the wording
needs an adaption, v.i.
2) is_empty is meant to support use-cases like compressed_pair.
Note that (1) also implies (2), but not necessarily vice versa.
Although NonEmpty is not completely empty in the sense of EBCO,
such a class is at least a class which can be used as the second
half of an inheritance chain and can be used as a base class
 for further chaining (OK, its a little bit lame reasoning ;-).

Now some wording. OK. Let's try and get be inspired by someone
else:

http://www.cantrip.org/emptyopt.html

I find (at the very end of this article) a sentence like

"[..] as long as they don't have any bases in common with one another
or with the containing class"

Couldn't we just add the following bullet after the last one of the
current is_empty requirements written similar to the wording of
10/7 from N2134:

"* T does not have two base class subobjects that have the same
class type."

?

Another interesting point is, that aforementioned DDJ article from
Myers also extends the meaning of EB(C)O to "empty subobject
optimizations":

"A whole family of related "empty subobject" optimizations are
possible,
subject to the ABI specifications a compiler must observe. (Jason
Merrill
pointed some of these out to me, years back.) For example, consider
three struct members of (empty) types A, B, and C, and a fourth non-
empty.
They may, conformingly, all occupy the same address, as long as they
don't have any bases in common with one another or with the
containing
class. A common gotcha in practice is to have the first (or only)
member
of a class derived from the same empty base as the class. The
compiler
has to insert padding so that they two subobjects have different
addresses."

I never realized that non-inheritance-based space optimizations are
possible, until I read this part!

Greetings from Bremen,

Daniel


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

Howard Hinnant schrieb:

> In article <1173648852.230192.11800@p10g2000cwp.googlegroups.com>,
>  "Daniel Kr   gler" <daniel.kruegler@googlemail.com> wrote:
>
> > The revised wording in n2157, found at
> >
> > http://www2.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2157.html
> >
> > does *not* exclude the above NonEmpty class from
> > is_empty categorization, because it says:
> >
> > "    template <class T> struct is_empty : public
> > integral_constant<bool, b> {};
> >
> > If is_class<T>::value is false then b is false. Otherwise T is
> > considered empty if and only if:
> >
> >     * T has no non-static data members, or all non-static data
> > members, if any, are bit-fields of length 0, and
> >     * T has no virtual members, and
> >     * T has no virtual base classes, and
> >     * T has no base classes B for which is_empty<B>::value is false.
> >
> > Requires: T shall be a complete type, an array type of unknown bounds,
> > or is a void type."
> >
> > Now I wonder whether this is (a) an oversight in the is_empty
> > specification or (b) a deliberate design decision?
>
> It is an oversight.  This was an attempt to give meaning to "empty
> class".  Note the (marked out) definition it is replacing.
> Unfortunately "empty class" isn't defined elsewhere in the standard,
> though the phrase is occasionally used.
>
> Perhaps the best thing to do would be to go back to the old definition
> for is_empty, but insist that it be defined somewhere in the language
> spec.  And then is_empty can refer to that spec.  That makes it somebody
> else's problem. :-)  Although, that definition may not be compatible
> with our intent for is_empty...
>
> Suggestions for better wording welcome.

>From the current proposal I could not clearly deduce,
which use cases is_empty is *really* supposed to support
(Besides N2157 I studied N2028- N1424 therefore, but could
not find anything - am I blind?).
And independent of the actual outcome to that question I
recommend to add a footnote or note that clarifies this intend
for future implementors.

1) is_empty is meant to allow EBCO to work. If so, the wording
needs an adaption, v.i.
2) is_empty is meant to support use-cases like compressed_pair.
Note that (1) also implies (2), but not necessarily vice versa.
Although NonEmpty is not completely empty in the sense of EBCO,
such a class is at least a class which can be used as the second
half of an inheritance chain and can be used as a base class
 for further chaining (OK, its a little bit lame reasoning ;-).

Now some wording. OK. Let's try and get be inspired by someone
else:

http://www.cantrip.org/emptyopt.html

I find (at the very end of this article) a sentence like

"[..] as long as they don't have any bases in common with one another
or with the containing class"

Couldn't we just add the following bullet after the last one of the
current is_empty requirements written similar to the wording of
10/7 from N2134:

"* T does not have two base class subobjects that have the same
class type."

?

Another interesting point is, that aforementioned DDJ article from
Myers also extends the meaning of EB(C)O to "empty subobject
optimizations":

"A whole family of related "empty subobject" optimizations are
possible,
subject to the ABI specifications a compiler must observe. (Jason
Merrill
pointed some of these out to me, years back.) For example, consider
three struct members of (empty) types A, B, and C, and a fourth non-
empty.
They may, conformingly, all occupy the same address, as long as they
don't have any bases in common with one another or with the
containing
class. A common gotcha in practice is to have the first (or only)
member
of a class derived from the same empty base as the class. The
compiler
has to insert padding so that they two subobjects have different
addresses."

I never realized that non-inheritance-based space optimizations are
possible, until I read this part!

Greetings from Bremen,

Daniel


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

In article <1173738558.576141.72190@q40g2000cwq.googlegroups.com>,
 "Daniel Kr=FCgler" <daniel.kruegler@googlemail.com> wrote:

> "* T does not have two base class subobjects that have the same
> class type."

That works for me.  Thanks Daniel (and Nathan)!

-Howard

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

On Mar 12, 12:21 pm, howard.hinn...@gmail.com (Howard Hinnant) wrote:
> In article <1173648852.230192.11...@p10g2000cwp.googlegroups.com>,
>  "Daniel Kr   gler" <daniel.krueg...@googlemail.com> wrote:

> > Just recently I stumbled once again since a longer
> > time across chapter 16.2.1 of the first edition of
> > "C++ Templates" from Vandevoorde/Josuttis, which
> > explains the Empty Base Class Optimization (EBCO)
> > principle as well as its limits.
> > One interesting example is given, which must necessarily
> > forbid EBCO:
>
> > class Empty {
> > };
>
> > class EmptyToo : public Empty {
> > };
>
> > class NonEmpty : public Empty, public EmptyToo {
> > };
> > > The revised wording in n2157, found at
>
> >http://www2.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2157.html
>
> > does *not* exclude the above NonEmpty class from
> > is_empty categorization, because it says:
>
> > "    template <class T> struct is_empty : public
> > integral_constant<bool, b> {};
>
> > If is_class<T>::value is false then b is false. Otherwise T is
> > considered empty if and only if:
>
> >     * T has no non-static data members, or all non-static data
> > members, if any, are bit-fields of length 0, and
> >     * T has no virtual members, and
> >     * T has no virtual base classes, and
> >     * T has no base classes B for which is_empty<B>::value is false.
>
> > Requires: T shall be a complete type, an array type of unknown bounds,
> > or is a void type."
>
> > Now I wonder whether this is (a) an oversight in the is_empty
> > specification or (b) a deliberate design decision?
>
> It is an oversight.  This was an attempt to give meaning to "empty
> class".  Note the (marked out) definition it is replacing.
> Unfortunately "empty class" isn't defined elsewhere in the standard,
> though the phrase is occasionally used.

According to the Vandevoorde/Josuttis book, an empty class object is
one "[whose] internal representation does not require any bits of
memory at run time." So by the book's own definition of "empty",
"NonEmpty" is an empty class - which it obviously is. After all,
NonEmpty has the same zero bits of runtime information content as each
of its two base classes either singly or combined.

Logically there is no connection between the Empty Base Class
Optimization and the "emptiness" of the complete class whose
subobjects to which it is applied. The EBC optimization applies to any
class (empty or non-empty) that has an empty base class. So the
conclusion that NonEmpty is not an empty class is a complete non-
sequitur. It seems that authors lost sight of the fact that the very
compact name, "NonEmpty", describes a "Non-(Empty-base-class-
optimized)" class object and not a "Non-Empty" class object - a
description which its name more closely resembles.

The NonEmpty example is in fact doubly misleading. Because (somewhat
paradoxically) a NonEmpty base class is still eligible for the empty
base class optimzation - and may in fact contribute zero bytes to the
size of subclass object (thereby affirming for a second time that
NonEmpty is an empty class). The only stipulation is that the size of
the derived class on its own (that is, without the NonEmpty base
class) would be at least equal to the size of a NonEmpty object.

So whether defined by its zero bits of information or by the zero
bytes of incremental storage - it's clear that the "oversight" and
(unsuccessful) attempt to define an "empty" class is found in the "C++
Templates" book and not in the proposed wording for is_empty<> type
trait - which is accurate in its current wording.

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                      ]

* Greg Herlihy:
>
> The NonEmpty example is in fact doubly misleading. Because (somewhat
> paradoxically) a NonEmpty base class is still eligible for the empty
> base class optimzation - and may in fact contribute zero bytes to the
> size of subclass object (thereby affirming for a second time that
> NonEmpty is an empty class). The only stipulation is that the size of
> the derived class on its own (that is, without the NonEmpty base
> class) would be at least equal to the size of a NonEmpty object.
>
> So whether defined by its zero bits of information or by the zero
> bytes of incremental storage - it's clear that the "oversight" and
> (unsuccessful) attempt to define an "empty" class is found in the "C++
> Templates" book and not in the proposed wording for is_empty<> type
> trait - which is accurate in its current wording.

Uh, well.  Albert, some words?  (Albert kicks in) "All is relative!"

With a class such as NonEmpty it seems to me it depends on the derived
class (specifically, its size) whether the empty base class optimization
can be applied or not.

If is_empty<> is meant to say whether EBCO can be applied, it seems to
me it needs the size information about the derived class, or must simply
not apply to this case (compile time error?), and if it's not meant to
say whether EBCO can be applied, what is it for?

Cheers,

- Alf

--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

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