Re: Concerning n2157 and is_empty specification
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 ]