Re: A question about a section in "Inside the C++ Object Model"
I can't understand why I haven't seen any replies to this yet, it's a
great question.
This is my third attempt at a reply. My first was rejected due to
insufficient quotation. My second was rejected due to excessive
quotation.
To me it seems that every sentence in the original question works
together in an integrated way, and I am finding it difficult to
excerpt from it without butchering. Perhaps this will be found
acceptable. Here goes:
On Mar 26, 2:40 pm, goodbye...@gmail.com wrote:
Following is quoted from "Inside the C++ Object Model" section 1.2:
If a programmer absolutely needs a data portion of an arbitrarily
complex C+
+ class to have the look and feel of an equivalent C declaration, that
porti
on is best factored out into an independent struct declaration.
[...]
This idiom is no longer recommended, however, because of changes to
the clas
s inheritance layout in some compilers [...]. Composition, rather than inheritance, is the only portable
method
[...]
I don't really understand why composition makes a difference from
inheritance in this case. Yes, if the derived class Point has a
virtual function then an object of class Point may have a vptr at the
beginning of the object, located before the data members of the base
struct C_point subobject [...] Microsoft VC++ [...] When the Point object is to be
converted to a C_point object when calling the "C" linkage function
draw_rect(), the default copy constructor of C_point will be invoked.
Can anyone point out what I am missing here?
Possibly just that platform APIs for that implementation of C++ are
known for discarding type information even at the C language level.
For example, it would not be surprising to find an API which can
manipulate a C_Point to be declared as taking a void* (you might
supply an enum to indicate it was supposed to be a C_Point). In that
case, "&mypoint" compiles fine, but no copy ctor or pointer adjustment
would be performed.
So my understanding is that, as long as the base C_point struct
contains no virtual member function, inheritance has the same effect
as composition, with regard to keeping C layout compatibility.
Let's say way back in 1990 someone put something in a header file that
looked kinda like this:
#if CPLUSPLUS
extern "C" {
#endif
/* A struct POINT */
typedef struct POINT_tag {
int x;
int y;
} POINT, *PPOINT;
/* Code using POINT */
void GetCoordinates(POINT *);
#if CPLUSPLUS
}
#endif
Imagine that the implementation of 'GetCoordinates' gets installed
onto something like one billion hard drives around the world.
Now imagine that many thousands of C++ developers get that header
file, and write software for it:
class CMyPoint : public POINT
{
CMyPoint();
virtual ~CMyPoint();
// ... and so on ...
};
int main()
{
CMyPoint point;
GetCoordinates(&point); // <-- derived* converts implicitly to
base*
// Virtual destructor called via overwritten vptr
return point.x + point.x=y;
}
I promise you that no mainstream compiler is going to turn that
particluar piece of formerly working code into a nasty crash bug, even
if some standards groups decided not to prohibit them from doing so.
- Marsh
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]