Re: empty base optimization of a multiple common base
On 21/05/10 04:33, Nikolay Ivchenkov wrote:
On 20 May, 02:25, Maxim Yegorushkin<maxim.yegorush...@gmail.com>
wrote:
On 19/05/10 03:04, Nikolay Ivchenkov wrote:
On 19 May, 01:51, Maxim Yegorushkin<maxim.yegorush...@gmail.com>
wrote:
The standard requires that base class subobjects of the same type have distinct addresses.
Where exactly the definitive text of the current standard contains
such a requirement?
I have no idea, try using a pdf reader with a search function.
That was a rhetorical question, because I believe that C++03 does not
require what you said above.
According to C++98 - 5.10/1,
"Two pointers of the same type compare equal if and only if they are
both null, both point to the same object or function, or both point
one past the end of the same array."
In C++03 this wording was changed to
"Two pointers of the same type compare equal if and only if they are
both null, both point to the same function, or both represent the same
address (3.9.2)."
Basically, they are preparing to say that empty base class subobjects
can be optimized away.
See defect report #73 for details:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3084.html#73
Lets consider C++98/C++03 - 10/5 now:
"[Note: [...] 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). ]"
This non-normative wording refers to 5.10. Though it was relevant to C+
+98 - 5.10, this note isn't correct in C++03 since the wording of 5.10
was changed as shown above.
However, you can derive it from common sense.
The identity of an object in C++ is its address, that is, every unique
object has a unique address. This is a fundamental rule.
First, it is not stated in C++03. The resolution for DR 734 fixes this
hole:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3084.html#734
Second, it's very funny that the committee makes the same ridiculous
mistake as you do: no exception is made for objects and their
subobjects. Lets consider the following:
int arr[1];
Here arr and its element arr[0] are two distinct objects: the former
one has the type "array of 1 int", the latter one has the type "int".
According to N3092 - 1.8/6, these objects shall have distinct
addresses:
Not sure who is making what mistake, probably the wording is just less
than perfect.
"Unless an object is a bit-field or a base class subobject of zero
size, the address of that object is the address of the first byte it
occupies. Two distinct objects that are neither bit-fields nor base
class subobjects of zero size shall have distinct addresses."
Looks like they now explicitly allow optimizing away empty base classes
of the same type in C++03. Please note that the above does not require
two empty base subobjects of the same type to have the same address.
There is an important footnote in the link you provided:
[Footnote: Under the ???as-if??? rule an implementation is allowed to store
two objects at the same machine address or not store an object at all if
the program cannot observe the difference (1.9 [intro.execution]). ???end
footnote].
Note the "if the program cannot observe the difference". Don't know if
this footnote made it into the standard.
If a derived class contains several subobjects of the same base class
these subobjects are distinct from each other and, therefore, they need
to have distinct addresses, even if their class is empty, otherwise the
fundamental identity rule would be violated.
This isn't stated in C++03/C++0x, and this doesn't work in practice:
My practise is different.
#include<iostream>
struct B
{
B() { std::cout<< this<< std::endl; }
};
struct D : B
{
B b;
};
int main()
{
D d;
}
VC++ 9.0 and Intel C++ 11.0.061 for Windows place two D's subobjects
of type B at the same address.
$ g++ --version
g++ (GCC) 4.4.1 20090725 (Red Hat 4.4.1-2)
Copyright (C) 2009 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
$ g++ -O3 -Wall -o test test.cc
$ ./test
0x7fffc2d173f0
0x7fffc2d173f1
--
Max
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]