In article 17aq@mule1.mindspring.com, abell@mindspring.com (Andrew Bell)
writes:
>clamage@Eng.sun.com (Steve Clamage) wrote [but much edited by me]:
>
>>I assume you mean a class like
>> class Short { short val; };
>>with non-virtual member functions added. You can't assume the size and
>>alignment of the class will be the same as its only data member, and no,
>>the standard provides no special support for this special case.
>
>Seems like if you only have one data member and no virtual functions,
>there's no reason to arbitrarily restrict it to a greater alignment
>level, save maybe to make compiler programmer's lives (and maybe
>debugger programmer's lives) trivially easier.

That isn't the reason. 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. That is,
all structured types are treated by one set of rules.

If a platform ABI required that all structs be at least 4-byte aligned and
padded to 4-byte boundaries, but C++ required that struct alignment and
padding be no stricter than that of the strictest member, you place the C++
implementor in an impossible position. Either the generated code is
incompatible with system and 3rd-party libraries, or the compiler violates
the C++ standard.

Nothing prevents an implementation from implementing class Short above in
the same way as type short if the ABI allows it, but the point is that you
can't depend on type Short being either the same as or different from
type short.

>>The typeids of two types compare equal if and only if they are
>>the same type. Base and derived classes are not ever the same type.
>
>Fair enough, although in this case RTTI forces the creation of an
>additional vtable that wouldn't normally be necessary.  Since the
>general criterion for RTTI support in a class in the first place is
>the existence of any virtual functions (and thus a vtable), it doesn't
>seem like it would be too unreasonable to make classes with identical
>vtables evaluate to the same thing.  Adding an operator to a class
>(externally) doesn't change its identity; should a non-virtual member
>function do so?

That's a philosophical question about what is a type. C++ follows the
common convention that different types are different types. The One-
Definition Rule says that there is only one definition of a type in
a program. In addition, the type must be defined in a single declaration,
not spread out. Some consequences of this consistent set of rules are that
a derived type is always a different type from the base, and namespace-scope
functions are not part of any class's type.

Certainly different rules are possible, and other languages have other
rules. The C++ rules are easy to understand and the consequences are
easy to predict. Not so if type equivalence depends on subtle distinctions.

---
Steve Clamage, stephen.clamage@eng.sun.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                             ]

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                             ]