Topic: Quick questions (but no longer so quic
Author: abell@mindspring.com (Andrew Bell)
Date: 1996/04/22 Raw View
clamage@Eng.Sun.COM (Steve Clamage) wrote:
>That [name mangling] isn't a given, it is a lamentable state of affairs which
>many vendors are laboring to fix.
But not, unless I've been hearing/reading falsehoods, the C++
standards committee...
>By definition, if you have a platform ABI, object code (including name
>mangling) is consistent across implementations and languages.
As long as you're modifying the ABI to define name-mangling, you
*could* modify it to allow wrapper classes that are aligned as per
their base...
>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.
Actually, if we add a wrapper definition as per another message of
mine, a restriction that wrappers could only be derived from
structs/classes would be perfectly acceptable; the whole alignment
issue was something of a tangent.
[ comp.std.c++ is moderated. To submit articles: try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ FAQ: http://reality.sgi.com/employees/austern_mti/std-c++/faq.html ]
[ Policy: http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu ]
Author: clamage@Eng.Sun.COM (Steve Clamage)
Date: 1996/04/22 Raw View
abell@mindspring.com (Andrew Bell) writes:
>clamage@Eng.Sun.COM (Steve Clamage) wrote:
>>That [name mangling] isn't a given, it is a lamentable state of affairs which
>>many vendors are laboring to fix.
>But not, unless I've been hearing/reading falsehoods, the C++
>standards committee...
I don't understand that comment. Name mangling is not mentioned
in the standard, and there has never been any requirement that
names be mangled. And as I keep saying, name mangling is a trivial
detail that has no effect on portability of code. If the only
difference between two object code formats is the name mangling,
you can use a map (which with many linkers comes for free) to
resolve the name differences. Differences in name mangling normally
serve as a visible signal that object code formats are in fact NOT
compatible. Wouldn't you rather find that out at link time instead
of having code that links but runs incorrectly?
>>By definition, if you have a platform ABI, object code (including name
>>mangling) is consistent across implementations and languages.
>As long as you're modifying the ABI to define name-mangling, you
>*could* modify it to allow wrapper classes that are aligned as per
>their base...
Of course. An ABI can make any guarantees it likes. It can specify
any sort of object layout that makes sense for the platform. It
could specify that every object has the same alignment and that
no padding and no extra data space is ever used in any struct or
class. That set of rules isn't practical on every platform, so the
C++ standard does not make such requirements. The C++ standard
specifies what *every* C++ implementation on *every* platform must
provide -- supercomputers, personal computers, and microwave ovens.
--
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
]
Author: clamage@Eng.Sun.COM (Steve Clamage)
Date: 1996/04/01 Raw View
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
]