🚀 go-pugleaf

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?  The only case I can think of is for SOM or some
other system-level object modelling proposal.

Is what I want to do (add member funcs to an already-defined class),
and have some way to define conversion operators from the old class to
the new such a rare concept?  Seems like I read a lot about the
conflict between adding lots of functions to a class and keeping it
simple and usable, and having support for wrappers would be a possible
way to deal with this.

Say:

wrapper new_class : <public,protected,private> base_class
{
	...
};

Wrappers could not have new member variables, virtual functions of any
kind, or more than one base class.  Conversion from a wrapper to the
base would be automatic.  It would need some way to define conversions
the other way (the new_class member funcs might not apply to all
base_class objs, just some of them).

Andrew Bell
abell@mindspring.com
---
[ 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                             ]