🚀 go-pugleaf

In article 916@mule2.mindspring.com, abell@mindspring.com (Andrew Bell) writes:
>clamage@Eng.Sun.COM (Steve Clamage) wrote:
>>C++ implementations don't exist in a vacuum. They
>>have to coexist with platform ABIs (Application Binary Interface, the
>>bit-level description of data and function calls). It is common for an ABI
>>to specify rules for structured types that are different from the rules
>>for simple types, no matter what the contents of the structure. 

>But where would our example [ class Short { int short; }; ] ever need
>to appear as anything other than a short, save within the C++ program
>itself?  

>>Either the generated code is incompatible with system and 3rd-party
>>libraries, or the compiler violates the C++ standard.

>Given that name-mangling isn't standard or consistent from compiler to
>compiler, unless you have a library created by that same compiler
>(that would thus realize the alignment would be as per short), when
>would this matter? 

That isn't a given, it is a lamentable state of affairs which many vendors
are laboring to fix. Because C++ implementations are usually mutually
incompatible even on the same platform, implementors are careful to use
different name mangling to reduce the chance of linking together code
which won't run properly together. In other words, object code is not
incompatible because of differences in name mangling; rather, name
mangling schemes are different because object code is incompatible anyway.

By definition, if you have a platform ABI, object code (including name
mangling) is consistent across implementations and languages. The
whole point of an ABI is that you can write code in one language
compiled with one compiler, and link it with code from another language
and/or compiler.

If ABIs that include C++ are to become a reality, and they must for C++
to be successful, the standard must not constrain implementations to
the point where they cannot conform to platform ABIs.

You are asking in this thread to be able to extend a class and keep
guarantees about its layout and structure, and keep a simple class like
Short bit-compatible with type short.

Suppose a C programmer writes
	struct Short { short s; };
and your C++ program must link to that code and use struct Short. Further
suppose the ABI for the platform (which has been around for years)
specifies that all structs are aligned on 4-byte boundaries and padded
to 4-byte multiples. (I'm not making up that requirement; it is common.)
In addition, the ABI says that integer types are passed in registers by
value, but all struct types are passed via a pointer and copied by the
called function (also a common requirement).

Now suppose the C++ standard says that Short must be treated exactly the
same as short. Boom! It is now impossible to have a C++ compiler that both
complies with the C++ standard and the ABI for that (common) platform. In
my view that is far too high a price to pay for the benefits you want.

Nothing prevents an implementation from doing what you want if it is
feasible on the platform. You just can't depend on it in portable code.
---
Steve Clamage, stephen.clamage@eng.sun.com
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your 
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu 
]