Re: empty base optimization of a multiple common base
On May 25, 7:33 pm, Nikolay Ivchenkov <ts...@mail.ru> wrote:
On 23 May, 22:47, itaj sherman <itajsher...@gmail.com> wrote:
Let me get this straight, you're saying that c++98 was not clear about
this, and it has been decided to fix for c++03 that pointers to two
such subobjects may compare equal.
No, I didn't say that.
Which means I cannot compare such pointers to an empty class, and know
whether they are the same subobject or not.
The current standard does not explicitly require two objects of the
same type to have distinct addresses.
And it seems that c++0X does generally, but not in my original case of
two empty subobject base objects of the same most derived object (nor
bit field case). right?
If so, I need to make sure: What if the class is not empty, but the
compiler can prove that the 2 subobjects always have the same state,
is it then allowed to optimize and have them at the same address?
for example:
I would like to consider a more simple case:
#include <cassert>
int main()
{
signed char const x[2] = {};
unsigned char const y[2] = {};
assert((void *)&x[0] != &y[0]); // may fail
assert((void *)&x[0] != &y[1]); // may fail
assert((void *)&x[1] != &y[0]); // may fail
}
I think, here x and y may overlap in any way (this is not explicitly
prohibited by the C++03 rules).
And did you mean before that it is required by c++0X resolution for DR
734?
On 23 May, 22:43, "Bo Persson" <b...@gmb.dk> wrote:
If two pointers of the same type
compares equal, they either point to the same object, or no objects at
all (like the position after the end of an array).
ISO/IEC 14882:2003 - 5.10 does not require that. ISO/IEC 14882:1998 is
obsolete - see C++03 - Foreword:
"This second edition cancels and replaces the first edition (ISO/IEC
14882:1998), which has been technically revised."
On 24 May, 19:47, itaj sherman <itajsher...@gmail.com> wrote:
5 [Note: A base class subobject might have a layout (3.7) different
from the layout of a most derived object of
the same type. A base class subobject might have a polymorphic
behavior (12.7) different from the polymorphic
behavior of a most derived object of the same type. A base class
subobject may be of zero size
(clause 9); however, two subobjects that have the same class type and
that belong to the same most derived
object must not be allocated at the same address (5.10). ]
That means that in my original example the two base subobjects of type
A must have different addresses, because they have the same mode
derived type D.
Notes are not normative and they can be completely ignored by
implementors.
Do compilers actually comply with this?
If you mean all existing C++ compilers, you can't get a reliable
affirmative answer for that question.
I meant standard complying ones... lol.
I probabely meant the popular ones.
As in, I need to know how safe it is to assume this rule into my code,
and how badly I need to document that if I do. I could also think of
adding some assetions maybe so that if the code is ever compiled on a
different compiler it will verify this (for the used classes).
Nikolay's example is different. It's a subobject of base class and a
data member. They are of the same type, but not of the same most
derived object.
Do you want to say that here
#include <iostream>
struct B
{
B() { std::cout << this << std::endl; }
};
struct D : B
{
B b;
};
int main()
{
D d;
}
b is not a subobject of d? The note refers to "two subobjects", not to
"two base subobjects" only, so member subobjects are also considered.
- 5 ... however, two subobjects that have the same class type and that
belong to the same most derived object must not be allocated at the
same address (5.10). ]
Ok, now that's a really unclear wording of the standard (IMO).
I'll try be clear:
There's the defined instance D d; I'll call the b data member object
x. The base object of type B I'll call y.
Both x and y are of type B.
The most derived object of x is itself, that is x, which is the b data
member.
The most derived object of y is d.
The conclusion must be that the most derived object of x and the most
derived object of y are not the same object.
Now comes the question whether that note should apply to x and y or
not:
They both have type B.
But what does the rest mean?
I really thought this what "belong" means here, that is: belong to the
same most derived object == they have the same most derived object.
And their most derived objects are not the same one (as I cleared
above), which is why I said that doesn't apply to them.
Now that you inquired, I'm not sure, does b being a data member of d
means that it "belongs" to it in the way this note refers to?
itaj
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]