Re: Structure mapping using reinterpret_cast.
On 22 Jun., 18:48, Olivier <olivier.gr...@gmail.com> wrote:
Hi all,
I would like to check if a certain technique can be used or whether
there is any entry in the standard that prohibits it explicitly. If I
recall correctly, the standard guarantees that two structures
containing the same starting data members can be mapped on one another
and these common members can be access without yielding undefined
behaviour. That is, given :
struct A { int a; int b; };
struct B { int c; };
the following code is guaranteed to work :
A a;
B &b = *reinterpret_cast<B *>(&a);
b.c = 12;
assert(a.a == b.c);
And this assert should never fail.
Yes, this is well-defined because of [class.mem]/16
in the current C++ standard (14882-2003):
"[..] Two POD-structs share a common initial sequence
if corresponding members have layout-compatible types
(and, for bit-fields, the same widths) for a sequence
of one or more initial members."
and both types are POD types (see below).
By extension, if that is true, the following code should be guaranteed
to work :
#include <iostream>
// Base class containing the data.
class A
{
public:
A( int val = 0 ) : val_(val) { }
protected:
int get_value( ) const
{ return val_; }
private:
int val_;
};
// Interface class that uses A's data.
class B : public A
{
public:
int function( ) const
{ return get_value() / 2; }
};
// Another interface class that uses A's data.
class C : public A
{
public:
int function( ) const
{ return get_value() * 2; }
};
int main( )
{
A *a = new A(12);
B *b = reinterpret_cast<B *>(a);
std::cout << b->function() << "\n";
C *c = reinterpret_cast<C *>(a);
std::cout << c->function() << "\n";
delete a;
}
If this isn't the case, could anyone quote the entry in the standard
that states this code yields undefined behavior ?
Based on above quoted *current* standard the behaviour
of the code is *undefined*, because the types are
not POD types. The nearest match here is that you
would try to rely on [class.mem]/14 saying:
"Two POD-struct (clause 9) types are layout-compatible
if they have the same number of nonstatic data members,
and corresponding nonstatic data members (in order) have
layout-compatible types (3.9)."
the problem is that POD-structs are defined to be
/aggregates/ in the current standard [class]/4:
"A POD-struct is an aggregate class[..]"
combined with [dcl.init.aggr]/1:
"An aggregate is an array or a class (clause 9) with no
user-declared constructors (12.1), no private or
protected non-static data members (clause 11), no base
classes (clause 10), and no virtual functions (10.3)."
A has a user-declared constructor and has private
non-static data members and B and C have a base class
A - game over.
Fortunately, C++0x will further relax the conditions
here. In the current working paper N2857 we find
[class.mem]/17:
"[..] Two standard-layout structs share a common
initial sequence if corresponding members have
layout-compatible types and either neither member
is a bit-field or both are bit-fields with the
same width for a sequence of one or more initial
members.
The behaviour of the latter is well-defined, because
is satisfies the new basic requirement, namely that
the corresponding structures are standard-layout types.
The key properties of those are described in [class]/7:
"A standard-layout class is a class that:
? has no non-static data members of type non-standard-layout
class (or array of such types) or reference,
? has no virtual functions (10.3) and no virtual base
classes (10.1),
? has the same access control (Clause 11) for all non-static
data members,
? has no non-standard-layout base classes,
? either has no non-static data members in the most-derived
class and at most one base class with non-static data members,
or has no base classes with non-static data members, and
? has no base classes of the same type as the first non-static
data member."
all these are ok in your example now. Later we find in
[class.mem]/18:
"A pointer to a standard-layout struct object, suitably
converted using a reinterpret_cast, points to its initial
member (or if that member is a bit-field, then to the unit
in which it resides) and vice versa. [ Note: There might
therefore be unnamed padding within a standard-layout
struct object, but not at its beginning, as necessary to
achieve appropriate alignment. ?end note ]"
The classes B and C are /layout-compatible/ as of
[class.mem]/15:
"Two standard-layout struct (Clause 9) types are layout-
compatible if they have the same number of non-static
data members and corresponding non-static data members
(in declaration order) have layout-compatible types (3.9)."
Put all this into one pot and the code will be
well-defined regarding the structure layouts
for C++0x.
HTH & Greetings from Bremen,
Daniel Kr?gler
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]