James Kanze
11/4/2008 9:06:00 AM
On Nov 3, 11:55 pm, tonytech08 <tonytec...@gmail.com> wrote:
> On Nov 3, 4:25 pm, James Kanze <james.ka...@gmail.com> wrote:
> > On Nov 3, 8:44 pm, tonytech08 <tonytec...@gmail.com> wrote:
> > > On Nov 1, 3:32 am, James Kanze <james.ka...@gmail.com> wrote:
> > > > On Nov 1, 4:02 am, tonytech08 <tonytec...@gmail.com> wrote:
> > > > > What I like about the C++ object model: that the data
> > > > > portion of the class IS the object (dereferencing an
> > > > > object gets you the data of a POD object).
> > > > No it doesn't.
> > > class SomePODClass
> > > {
> > > public:
> > > int first_int;
> > > int second_int;
> > > void Func1(){}
> > > };
> > > SomePODClass X;
> > > int first_int_in_obj = *(int*)&X; // this is not pretty, but true
> > But it's only true for POD types,
> Well that's why I added the parenthetical part in my original
> post: to make clear I was referring to what I like about the
> C++ model and wish it wouldn't get abberated so quickly by
> changing the memory representation of the data portion. 'POD'
> was very key for my thought, though could have been worded
> better to show that I guess.
Well, PODs make up part of the C++ object model; one important
aspect of it is that PODs do behave differently from objects
which have non-trivial constructors or destructors. The main
reasons for this are probably linked with C compatibility, but
it was always intended in C++ that you could create simple
structures which were no more than a collection of data (with or
without member functions), as well as full OO type objects. The
object model of C++ is designed to support both.
> > and only because of constraints of C compatiblity. The data
> > portion of the class isn't the object in general.
> I tend to think of the data portion (noun, vs. behavior=verb)
> as "the thing" because that's what get's operated on and maybe
> even directly manipulated.
In C++ (and even in C, for that matter), an object has a type
and an address; the type determines its size, and the set of
legal operations on it. Since an object is a thing, in some
way, I guess it is a noun, but even a POD struct has behavior:
you can assign it, for example, or access members. Compared to
C, C++ adds the ability for the user to define additional
operations (member functions), and to define non-trivial
initialization and destruction (which forces significant changes
in the object model). Beyond that, C++ adds support for dynamic
typing (which is what one usually understands with OO).
[...]
> > It restricts the use of OO concepts to classes designed to
> > be used with OO concepts.
> Not really, since one can have POD classes with methods, just
> not CERTAIN methods (you are suggesting that "classes designed
> to be used with OO concepts" are those heavyweight classes
> that break PODness, right?).
No. I'm really not suggesting much of anything. However you
define the concept of OO, the concept only applies to classes
which were designed with it in mind. C++ doesn't force any
particular OO model, but allows you to chose. And to have
classes which aren't conform to this model.
> You seem to be saying that POD classes are not supported or at
> least not encouraged.
Where do I say that? POD classes are definitely supported, and
are very useful in certain contexts. They aren't appropriate
for what most people would understand by OO, but so what. Not
everything has to be rigorously OO.
> That would be a real downer if true. I'd like to see more
> support in the langauge for POD classes.
Such as? Part of the motivation for defining POD as a special
category is C compatibility; a POD should be usable in C.
Beyond that, there is a wide range of things you can do.
> I don't know how much can be implemented before it becomes
> impossible. Certainly initializing constructors can be had?
A non-trivial constructor causes changes in the way object
lifetime is defined. So the results aren't (and can't be) a
POD. The justification is simple: you can't define an object
with a non-trivial constructor in C.
> Polymorphism not, but only NOT because of the way C++
> implements it?
Polymorphism implies a non-trivial constructor. Regardless of
how it is implemented, something must occur (some code must
execute) for the raw memory to assume its type.
The next version of the standard adds some additional
definitions; in addition to PODs and agglomerates, it has
something called standard-layout structs and unions, and support
for managing alignment. But even without that, I've found
plenty of support for everything I've had to do, at all levels.
--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34