The C++ Object Model: Good? Bad? Ugly?

[tonytech08]

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).

What I don't like about the C++ object model: that most OO features
are not
available for class object design without loss of POD-ness.

So, I'm more than leaning toward "bad" because of the limitations and
that the language doesn't distinguish what is of very key importance.
How do you feel about the object model?

[ebony.soft]

On Nov 1, 6:02*am, tonytech08 <[e-mail]:

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).

What I don't like about the C++ object model: that most OO features
are not
available for class object design without loss of POD-ness.

So, I'm more than leaning toward "bad" because of the limitations and
that the language doesn't distinguish what is of very key importance.
How do you feel about the object model?

Hi
I really don't get completely, what you mean, but for me, the
important things about C++ object model are simplicity, efficiency and
extenability. For example the representation of concrete classes like
Date in memory is exactly like a POD Date struct. The size of object
of a derived class is the size of base class sub-object and its data
members. The size of an object of a class with virtual functions
increases just by the size of virtual v-ptr. The above layout is
extended for classes with static members, multiple inheritance,
virtual base classes and RTTI.
In all, you can see these three items.

I hope it helps you.

Regards,
Saeed Amrollahi

[James Kanze]

On Nov 1, 4:02*am, tonytech08 <[e-mail]:

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.

What I don't like about the C++ object model: that most OO
features are not available for class object design without
loss of POD-ness.

So, I'm more than leaning toward "bad" because of the
limitations and that the language doesn't distinguish what is
of very key importance. How do you feel about the object
model?

The "object model" in the C++ standard is very low-level.
Intentionally. It is designed for you to build on. The object
model of the classes you write is for you to design. It can be
more OO than many other languages (e.g. Java or C#), when that's
appropriate. Just as it can drop the OO model completely when
that's appropriate (e.g value objects). The essential point of
C++ is that it doesn't impose any application level object
model; it lets you use whatever is appropriate.

--
James Kanze (GABI Software) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]

[James Kanze]

On Nov 1, 4:02*am, tonytech08 <[e-mail]:

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.

What I don't like about the C++ object model: that most OO
features are not available for class object design without
loss of POD-ness.

So, I'm more than leaning toward "bad" because of the
limitations and that the language doesn't distinguish what is
of very key importance. How do you feel about the object
model?

The "object model" in the C++ standard is very low-level.
Intentionally. It is designed for you to build on. The object
model of the classes you write is for you to design. It can be
more OO than many other languages (e.g. Java or C#), when that's
appropriate. Just as it can drop the OO model completely when
that's appropriate (e.g value objects). The essential point of
C++ is that it doesn't impose any application level object
model; it lets you use whatever is appropriate.

--
James Kanze (GABI Software) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]

[Salt_Peter]

On Oct 31, 10:02*pm, tonytech08 <[e-mail]:

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).

Definitely not. Data is just data. The true power of the C++ Object
Model is the object's behaviour and extensability.

>
What I don't like about the C++ object model: that most OO features
are not
available for class object design without loss of POD-ness.

So, I'm more than leaning toward "bad" because of the limitations and
that the language doesn't distinguish what is of very key importance.
How do you feel about the object model?

Objects sometimes need to do more than just store data. Behaviour is
nice to have. That inludes 'behaviour' at construction and expected
behaviours through a secure interface. It makes maintaining and
extending code easy, simple.

Write a program that uses some given polymorphic type hierarchy and
have your customer invent / add some new improved class of his own.
The customer's new class works with your original program without
changing a single line of code (except maybe an include).

You can't do that with PODs only. Whats nice is you can bend the
language to choose what path you prefer.

[tonytech08]

On Nov 1, 2:12*am, [e-mail] wrote:

On Nov 1, 6:02*am, tonytech08 <[e-mail]:

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).

What I don't like about the C++ object model: that most OO features
are not
available for class object design without loss of POD-ness.

So, I'm more than leaning toward "bad" because of the limitations and
that the language doesn't distinguish what is of very key importance.
How do you feel about the object model?

Hi
I really don't get completely, what you mean, but for me, the
important things about C++ object model are simplicity, efficiency and
extenability. For example the representation of concrete classes like
Date in memory is exactly like a POD Date struct.

"Concrete class"? You are using that to mean "struct".

The size of object
of a derived class is the size of base class sub-object and its data
members. The size of an object of a class with virtual functions
increases just by the size of virtual v-ptr.

That's "the problem" I implied: that quickly the object model destroys
the concept of a class looking like the data portion in memory.

[tonytech08]

On Nov 1, 3:32*am, James Kanze <[e-mail]:

On Nov 1, 4:02*am, tonytech08 <[e-mail]:

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

>

What I don't like about the C++ object model: that most OO
features are not available for class object design without
loss of POD-ness.
So, I'm more than leaning toward "bad" because of the
limitations and that the language doesn't distinguish what is
of very key importance. *How do you feel about the object
model?

The "object model" in the C++ standard is very low-level.
Intentionally. *It is designed for you to build on. *The object
model of the classes you write is for you to design. *It can be
more OO than many other languages (e.g. Java or C#), when that's
appropriate. *Just as it can drop the OO model completely when
that's appropriate (e.g value objects). *The essential point of
C++ is that it doesn't impose any application level object
model; it lets you use whatever is appropriate.

It does restrict usage of OO concepts unless one jettisons the "value
object" concept, which is unfortunate (and unnecessary?).

[tonytech08]

On Nov 1, 4:41*am, Salt_Peter <[e-mail]:

On Oct 31, 10:02*pm, tonytech08 <[e-mail]:

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).

Definitely not. Data is just data. The true power of the C++ Object
Model is the object's behaviour and extensability.

Depends on how you want to view it. Sure, class = data+behavior, but I
wasn't talking about fundamental "definitions" but rather usage of
class objects, one aspect of which is manipulating the data directly
for, say for example, in a memory management scenario. That one has to
be severely restricted from using OO concepts without affecting the
representation in memory of the data portion, is unfortunate. I'm not
sure how much could be or could have been done to make the situation
better. For example, was it really necessary to disallow constructors
with initialization lists? I mean, no vptr needed for that!

>

What I don't like about the C++ object model: that most OO features
are not
available for class object design without loss of POD-ness.

So, I'm more than leaning toward "bad" because of the limitations and
that the language doesn't distinguish what is of very key importance.
How do you feel about the object model?

Objects sometimes need to do more than just store data. Behaviour is
nice to have. That inludes 'behaviour' at construction and expected
behaviours through a secure interface. It makes maintaining and
extending code easy, simple.

Write a program that uses some given polymorphic type hierarchy and
have your customer *invent / add some new improved class of his own.
The customer's new class works with your original program without
changing a single line of code (except maybe an include).

You can't do that with PODs only. Whats nice is you can bend the
language to choose what path you prefer.

That's only one usage scenario though. A LOT of usefull stuff can be
built without heavy class objects "weighed down" with vptrs and other
stuff. I of course am referring to that other scenario so talking
about the scenario you mentioned isn't relevant.

[James Kanze]

On Nov 3, 8:44*pm, tonytech08 <[e-mail]:

On Nov 1, 3:32*am, James Kanze <[e-mail]:

On Nov 1, 4:02*am, tonytech08 <[e-mail]:

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, and only because of
constraints of C compatiblity. The data portion of the class
isn't the object in general.

What I don't like about the C++ object model: that most OO
features are not available for class object design without
loss of POD-ness.
So, I'm more than leaning toward "bad" because of the
limitations and that the language doesn't distinguish what
is of very key importance. *How do you feel about the
object model?

The "object model" in the C++ standard is very low-level.
Intentionally. *It is designed for you to build on. *The
object model of the classes you write is for you to design.
*It can be more OO than many other languages (e.g. Java or
C#), when that's appropriate. *Just as it can drop the OO
model completely when that's appropriate (e.g value
objects). *The essential point of C++ is that it doesn't
impose any application level object model; it lets you use
whatever is appropriate.

It does restrict usage of OO concepts unless one jettisons the
"value object" concept, which is unfortunate (and
unnecessary?).

It restricts the use of OO concepts to classes designed to be
used with OO concepts. It supports non OO concepts as well,
which are more appropriate in some cases.

--
James Kanze (GABI Software) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]

[tonytech08]

On Nov 3, 4:25*pm, James Kanze <[e-mail]:

On Nov 3, 8:44*pm, tonytech08 <[e-mail]:

On Nov 1, 3:32*am, James Kanze <[e-mail]:

On Nov 1, 4:02*am, tonytech08 <[e-mail]:
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.

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. I'm not willing to go to a paradigm that only allows data
manipulation via class methods. That is way to high level and
constraining for me. A lot of people complain about C and C++ because
of the memory management, but for me, that's one of the things I like
about it! GC breaks MY programming model for example.

>

What I don't like about the C++ object model: that most OO
features are not available for class object design without
loss of POD-ness.
So, I'm more than leaning toward "bad" because of the
limitations and that the language doesn't distinguish what
is of very key importance. *How do you feel about the
object model?
The "object model" in the C++ standard is very low-level.
Intentionally. *It is designed for you to build on. *The
object model of the classes you write is for you to design.
*It can be more OO than many other languages (e.g. Java or
C#), when that's appropriate. *Just as it can drop the OO
model completely when that's appropriate (e.g value
objects). *The essential point of C++ is that it doesn't
impose any application level object model; it lets you use
whatever is appropriate.

It does restrict usage of OO concepts unless one jettisons the
"value object" concept, which is unfortunate (and
unnecessary?).

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?). You seem to be saying that POD classes are not supported or
at least not encouraged. That would be a real downer if true. I'd like
to see more support in the langauge for POD classes. I don't know how
much can be implemented before it becomes impossible. Certainly
initializing constructors can be had? Polymorphism not, but only NOT
because of the way C++ implements it?

It supports non OO concepts as well,
which are more appropriate in some cases.

[Ian Collins]

tonytech08 wrote:

On Nov 3, 4:25 pm, James Kanze <[e-mail]:

>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?).

What's a "heavyweight class"?

You seem to be saying that POD classes are not supported or
at least not encouraged.

Where? They are supported, a C struct is also a C++ struct.

That would be a real downer if true. I'd like
to see more support in the langauge for POD classes. I don't know how
much can be implemented before it becomes impossible. Certainly
initializing constructors can be had? Polymorphism not, but only NOT
because of the way C++ implements it?

An instance of a polymorphic class has to contain information about its
type, so it can't be the same as a POD class. Constructors and
(non-virtual) methods are irrelevant.

--
Ian Collins

[James Kanze]

On Nov 3, 11:55 pm, tonytech08 <[e-mail]:

On Nov 3, 4:25 pm, James Kanze <[e-mail]:

On Nov 3, 8:44 pm, tonytech08 <[e-mail]:

On Nov 1, 3:32 am, James Kanze <[e-mail]:
On Nov 1, 4:02 am, tonytech08 <[e-mail]:
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:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]

[James Kanze]

On Nov 4, 5:51 am, Ian Collins <[e-mail]:

[...]

An instance of a polymorphic class has to contain information
about its type, so it can't be the same as a POD class.
Constructors and (non-virtual) methods are irrelevant.

Just a nit, but it's possible to implement polymorphism with no
additional information in the instance itself; you could, for
example, maintain the information is a separate hashtable which
mapped the address to the type information. What isn't possible
is to establish this mapping without executing some code. I.e. a
constructor.

--
James Kanze (GABI Software) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]

[tonytech08]

On Nov 3, 10:51*pm, Ian Collins <[e-mail]:

tonytech08 wrote:

On Nov 3, 4:25 pm, James Kanze <[e-mail]:

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?).

What's a "heavyweight class"?

A non-POD class.

>

You seem to be saying that POD classes are not supported or
at least not encouraged.

Where? *They are supported, a C struct is also a C++ struct.

"Not supported adequately" is what I meant.

>

That would be a real downer if true. I'd like
to see more support in the langauge for POD classes. I don't know how
much can be implemented before it becomes impossible. Certainly
initializing constructors can be had? Polymorphism not, but only NOT
because of the way C++ implements it?

An instance of a polymorphic class has to contain information about its
type, so it can't be the same as a POD class.

Because of the way C++ implements polymorphism: tacking on a vptr to
the class data.

*Constructors and
(non-virtual) methods are irrelevant.

Apparently relevant: a POD can't have "non-trivial" constructors, for
one thing.

[tonytech08]

On Nov 4, 3:06*am, James Kanze <[e-mail]:

On Nov 3, 11:55 pm, tonytech08 <[e-mail]:

On Nov 3, 4:25 pm, James Kanze <[e-mail]:

On Nov 3, 8:44 pm, tonytech08 <[e-mail]:
On Nov 1, 3:32 am, James Kanze <[e-mail]:
On Nov 1, 4:02 am, tonytech08 <[e-mail]:
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.

Thanks for reiterating my thought: C++ has more support for OO with
"full OO type objects".

>

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).

Not sure what your point is. I said that I consider the data portion
of an object, "the object". I wasn't trying to be implementation
literal about it. Yes, data+behavior= class, but when the
implementation starts adding things to the data portion, that defines
a different animal than a POD class.

>
* * [...]

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.

"Allows you to choose"? "FORCES you to choose" between lightweight
(POD) class design with more limited OO and and heavyweight (non-POD)
class design with all OO mechanisms allowed but at the expense of
losing POD-ness. It's a compromise. I'm not saying it's a bad
compromise, but I am wondering if so and what the alternative
implementation possibilities are.

>

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.

You seemed to imply that the "supported" ("ecouraged" would probably
be a better word to use) paradigms were: A. data structs with non-
trivial member functions and built-in "behavior" and B. "full OO type
objects".

>

That would be a real downer if true. I'd like to see more
support in the langauge for POD classes.

Such as? *

What I call "initializing constructors" for one thing. (Constructors
that take arguments to initialize a POD class in various ways).

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.

Can't construct conveniently as you can with heavyweight class
objects. Why allowing this would break POD-ness escapes me. Perhaps it
would break C-compatibility? Maybe defining POD-ness as "C
compatibility of structs" is a hindrance, if it is defined something
like that.

>

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.

So it is just the backward compatibility with C that prevents having
those nifty constructors?

>

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 more obvious issue with the polymorphism implementation is the
vptr. But I'm not too worried about not being able to derive from POD-
classes (for now anyway).

>
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.

[tonytech08]

On Nov 4, 3:08*am, James Kanze <[e-mail]:

On Nov 4, 5:51 am, Ian Collins <[e-mail]:

* * [...]

An instance of a polymorphic class has to contain information
about its type, so it can't be the same as a POD class.
Constructors and (non-virtual) methods are irrelevant.

Just a nit, but it's possible to implement polymorphism with no
additional information in the instance itself; you could, for
example, maintain the information is a separate hashtable which
mapped the address to the type information. *What isn't possible
is to establish this mapping without executing some code. I.e. a
constructor.

And how relatively (relative to the current implementation) slow would
that be is the question. I'm pretty much doing that for GUI code
(windowing). I'm not sure that it's appriate at the language
implementation level as a technique though (?).

[tonytech08]

On Nov 3, 10:51*pm, Ian Collins <[e-mail]:

tonytech08 wrote:

On Nov 3, 4:25 pm, James Kanze <[e-mail]:

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?).

What's a "heavyweight class"?

You seem to be saying that POD classes are not supported or
at least not encouraged.

Where? *They are supported, a C struct is also a C++ struct.

"not encouraged" I should have said.

[Ian Collins]

tonytech08 wrote:

On Nov 3, 10:51 pm, Ian Collins <[e-mail]:

>tonytech08 wrote:

>>On Nov 3, 4:25 pm, James Kanze <[e-mail]:
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?).

What's a "heavyweight class"?

>>You seem to be saying that POD classes are not supported or
at least not encouraged.

Where? They are supported, a C struct is also a C++ struct.

"not encouraged" I should have said.

By whom?

--
Ian Collins

[tonytech08]

On Nov 7, 2:02*am, Ian Collins <[e-mail]:

tonytech08 wrote:

On Nov 3, 10:51 pm, Ian Collins <[e-mail]:

tonytech08 wrote:
On Nov 3, 4:25 pm, James Kanze <[e-mail]:
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?).
What's a "heavyweight class"?

>You seem to be saying that POD classes are not supported or
at least not encouraged.
Where? *They are supported, a C struct is also a C++ struct.

"not encouraged" I should have said.

By whom?

Whoever decided to focus on heavyweight objects for OO, "only" in
designing/evolving/implementing C++.

[James Kanze]

On Nov 8, 1:08*pm, tonytech08 <[e-mail]:

On Nov 8, 3:12*am, James Kanze <[e-mail]:

On Nov 7, 10:20*pm, tonytech08 <[e-mail]:

On Nov 7, 4:40*am, James Kanze <[e-mail]:
On Nov 6, 11:29 pm, tonytech08 <[e-mail]:

* * [...]

Thanks for reiterating my thought: C++ has more support
for OO with "full OO type objects".
More support than what. *
More support for OO with "heavyweight" classes than for
POD classes.

You're not making sense. *How does C++ have more support for
OO than for other idioms?

Why are you asking that when I said nothing of the sort? I
said that once you put a vptr into the data portion of an
object (for example), it's a different animal than a class
without a vptr (for example!). I distinguished these
fundamentally different animals by calling them "heavyweight"
and "lightweight" classes/object (and apparently wrongly
POD-classes wrongly).

Well, OO is often used to signify the presence of polymorphism,
and the only time you'll get a vptr is if the class is
polymorphic.

Moreso, I was concerned that other things one can do with a
class, such as defining overloaded constructors, may make code
fragile against some future or other current implementation of
the language. Who's to say (not me) that someone won't make a
compiler that tacks on or into a class object some other
"hidden" ptr or something to implement "overloaded
constructors"? I don't care if code is generated but I do care
if the compiler starts aberrating the data portion.

Well, that's C++. And C. And Fortran, and just about every
other language I'm aware of. The only language I know which
specifies the exact format of any types is Java, and it only
does so for the built-in types.

So what's your point. Data layout is implementation defined,
period. That was the case in C, and C++ didn't introduce any
additional restrictions.

C++ has support for "full OO type objects", if that's what
you need. *Most of my objects aren't "full OO type objects",
in the sense that they don't support polymorphism. *C++
supports them just as well.
I think I may be OK without polymorphism in "lightweight"
classes, but overloaded constructors sure would be nice. And
conversion operators. *Can a POD class derive from a pure
abstract base class? That would be nice also if not.

And C++ supports all of that. *

But am I guaranteed that my a class will stay lightweight if I
do that or is it implementation defined?

Everything is implementation defined. C++ inherits this from C,
and it was pretty much standard practice at the time C was
invented.

[...]

It's just an abstract way of looking at it. It's hardly a
stretch either, since the C++ object model or at least
most implementations use that as the foundation upon which
to implement polymorphism: tacking a vptr onto "the thing
part" (noun) of "the object".

C++ supports dynamic typing, if that's what you mean. *In
other words, the type of an object vary at runtime. *But I
don't see your point. *It is the designer of the class who
decides whether to use dynamic typing or not. *The language
doesn't impose it.

It imposes "a penalty" the second you introduce the vptr. The
class becomes fundamentally and categorically different in a
major way. (Read: turns a lightweight class into a
heavyweight one).

You're throwing around meaningless adjectives again. The
compiler has to implement dynamic typing somehow. You don't pay
for it unless you use it, and using a vptr is about the cheapest
implementation known.

[...]

I agree that there are other hindrances to having an elegant
programming model. Sigh. That's not to say that one can't get
around them to a large degree. (Not the least of which is:
define your platform as narrowly as possible).

That's a route C and C++ intentionally don't take. If there
exists a platform on which the language is not implementable,
it's pretty much considered a defect in the language.

I wasn't trying to be implementation literal about it.
Yes, data+behavior= class, but when the implementation
starts adding things to the data portion, that defines a
different animal than a POD class.
But the implementation *always* adds things to the data
portion, or controls how the data portion is interpreted.
*It defines a sign bit in an int, for example (but not in an
unsigned int). *If you want to support signed arithmetic,
then you need some way of representing the sign. *If you
want to support polymorphism, then you need some way of
representing the type. *I don't see your point. *(The point
of POD, in the standard, is C compatibility; anything in a
POD will be interpretable by a C compiler, and will be
interpreted in the same way as in C++.)
Well maybe I'm breaking new ground then in suggesting that
there should be a duality in the definition of what a class
object is. There are "heavyweight" classes and "lightweight"
ones.

There's no strict binary division. *

A class with a vptr is fundamentally different than one
without, for example.

And a class with private data members is fundamentally different
from one with public data members. And a class with user
defined constructors is fundamentally different from one
without.

There are a number of different classifications possible

The only ones I'm considering in this thread's topic though is
the lightweight/heavyweight ones.

Without defining it or showing its relevance to anything at all.

I use C++ with that paradigm today, but it could be more
effective if there was more support for "object-ness" with
"lightweight" classes.

Again: what support do you want? *You've yet to point out
anything that isn't supported in C++.

(Deriving from interface classes and maintaining the size of
the implementation (derived) class would be nice (but maybe
impossible?)).

Not necessarily impossible, but it would make the cost of
resolving a virtual function call significantly higher. And
what does it buy you? You say it would be "nice", but you don't
explain why; I don't see any real advantage.

I am just trying to understand where the line of demarcation
is between lightweight and heavyweight classes is and how that
can potentially change in the future and hence break code.

There is no line of demarcation because there isn't really such
a distinction. It's whatever you want it to mean, which puts it
where ever you want.

The limitation appears to be backward compatibity with C.
If so, maybe there should be structs, lightweight classes,
heavyweight classes.

And maybe there should be value types and entity types. *Or
maybe some other classification is relevant to your
application. The particularity of C++ is that it lets you
choose. *The designer is free to develop the categories he
wants. *(If I'm not mistaken, in some circles, these type of
categories are called stereotypes.)

I'm only talking about the two categories based upon the C++
mechanisms that change the data portion of the object.

Which in turn depends on the implementation, just as it did in
C.

Why do you care about the layout of the data anyway? There's
nothing you can really do with it.

Deriving a simple struct from a pure abstract base class will
get you a beast that is the size of the struct plus the size
of a vptr. IOW: an aberrated struct or heavyweight object.
Call it what you want, it's still fundamentally different.

A C style struct is different from a polymorphic class, yes.
Otherwise, there wouldn't be any point in having polymorphic
classes. The difference isn't any more fundamental than making
the data members private would be, however, or providing a user
defined constructor; in fact, I'd say that both of those were
even more fundamental differences.

* * [...]
The change occurs when you do something to a POD
("lightweight") class that turns the data portion of the
class into something else than just a data struct, as when
a vptr is added. Hence then, you have 2 distinct types of
class objects that are dictated by the implementation of
the C++ object model.

The concept of a POD was introduced mainly for reasons of
interfacing with C. *Forget it for the moment. *You have as
many types of class objects as the designer wishes. *If you
want just a data struct, fine; I use them from time to time
(and they aren't necessarily POD's---it's not rare for my
data struct's to contain an std::string). *If you want
polymorphism, that's fine too. *If you want something in
between, say a value type with deep copy semantics, no
problem.

There is NO restriction in C++ with regards to what you can
do.

Yes there is if you don't want the size of your struct to be
it's size plus the size of a vptr. If maintaining that size is
what you want, then you can't have polymophism. Hence,
restriction.

What on earth are you talking about. C++ doesn't guarantee the
size of anything. (Nor does any other language.) If you need
added behavior which requires additional memory, then you need
added behavior which requires additional memory. That's not C++
talking; that's just physical reality.

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.
You seemed to imply that the "supported" ("ecouraged" would
probably be a better word to use) paradigms were: A. data
structs with non- trivial member functions and built-in
"behavior" and B. "full OO type objects".
Not at all. *You define what you need. *
There are the limitations though: you can't have overloaded
constructors, for example, without losing POD-ness.

Obviously, given the particular role of PODs. *So? *What's your
point? *

My point is that I'm worried about defining some overloaded
constructors and then finding (now or in the future) that my
class object is not "struct-like" anymore (read, has some
bizarre representation in memory).

I'm not sure what you mean by "struct-like" or "some bizarre
representation in memory". The representation is whatever the
implementation decides it to be. Both in C and in C++. I've
had the representation of a long change when upgrading a C
compiler. On the platforms I generally work on, the
representation of a pointer depends on compiler options. And on
*ALL* of the platforms I'm familiar with, the layout of a struct
depends on compiler options, both in C and in C++.

The whole point of using a high level language, like C++ (or C,
or even Fortran) is that you're isolated from this
representation.

Or derivation from "interfaces" (?).

How is a C program going to deal with derivation? *For that
matter, an interface supposes virtual functions and dynamic
typing; it's conceptually impossible to create a dynamically
typed object without executing some code.

Code generation/execution is not what I'm worried about.

There's not much point in defining something that can't be
implemented.

[...]

I'm not sure what you mean by "the data portion to remain
intact". *

Derive a class and you have compiler baggage attached to the
data portion.

Or you don't. Even without derivation, you've got "compiler
baggage" attached to the data portion. Both in C and in C++.

If I ever instantiate a class object that has overloaded
constructors and find that the size of the object is different
from the expected size of all the data members (please don't
bring up padding and alignment etc), I'm going to be unhappy.

Be unhappy. First, there is no "expected" size. The size of an
object varies from implementation to implementation, and depends
on compiler version and options within an implementation. And
second, I've yet to find anything to be gained by changing this.

Taken literally, the data portion had better remain intact
for all types of objects. *If you mean contiguous, that's a
different issue: not even POD's are guaranteed to have
contiguous data (since C doesn't guarantee it)---on many
machines (e.g. Sparcs, IBM mainframes...) that would
introduce totally unacceptable performance costs.

If a platform is so brain-damaged that I can't do things to
have a high degree of confidence that the size of a struct is
what I expect it to be, then I won't be targeting that
platform. Other people can program "the exotics".

So what do you expect it to be? You can't expect anything,
reasonable.

If anything, C++ specifies the structure of the data too
much. A compiler is not allowed to reorder data if there is
no intervening change of access, for example. *If a
programmer writes:

* * struct S
* * {
* * * * char c1 ;
* * * * int *i1 ;
* * * * char c2 ;
* * * * int *i2 ;
* * } ;

for example, the compiler is not allowed to place the i1 and
i2 elements in front of c1 and c2, despite the fact that
this would improve memory use and optimization.

And I think I have control over most of those things on a
given platform. Which is all fine with me, as long as I HAVE
that control (via compiler pragmas or switches or careful
coding or whatever).

And compilers have alway been free (and always will be free) to
provide such controls. I've never found the slightest use for
them, but they're there. The standard intentionally doesn't
specify how to invoke the compiler, or what pragmas are
available, to achieve this, since there's nothing you can really
say which would make sense for all possible platforms.

Anything else would be a contradiction: are you saying you
want to provide a constructor for a class, but that it won't
be called? *
Of course I want it to be called. By "POD-ness" I just meant I
want a struct-like consistency of the object data (with no
addition such as a vptr, for example).

I don't understand all this business of vptr. *Do you want
polymorphism, or not. *

Yes, but without the vptr please (coffee without cream
please).

You mean café au lait without any milk. If you have
polymorphism, it has to be implemented.

If you want polymorphism, the compiler must memorize the
type of the object (each object) somewhere, when the object
is created; C++ doesn't require it to be in the object
itself, but in practice, this is by far the most effective
solution.

But what if just pure ABC derived classes were handled
differently? Then maybe the situation would be less bad.

Propose a solution. If you want polymorphism, the compiler must
maintain information about the dynamic type somehow. Whether
the base class is abstract or not doesn't change anything; an
object must somehow contain additional information. Additional
information means additional bits, which have to be stored
somewhere. The only alternative to storing them in the object
itself is somehow being able to recover them from the address of
the object. A solution which would seem off hand considerably
more expensive in terms of run-time. For practically no
advantage in return.

* * [...]

Well there's another example then of heavyweightness: sprinkle
in "public" and "private" in the wrong places and the compiler
may reorder data members. (I had a feeling there was more than
the vptr example).

Yes, because C compatibility is no longer involved. It is
fairly clear that C actually went too far in this regard, and
imposed an unnecessary constraint which had negative effects for
optimization. Since most people would prefer faster programs
with smaller data, C++ did what it could to loosen this
constraint.

Can you give an example of reasonable code where this makes a
difference?

*That, and the fact that a class cannot have a size of 0, are
about the only restraints. *C (and C++ for PODs) also have a
constraint that the first data element must be at the start
of the object; the compiler may not introduce padding before
the first element.

So you are saying that a non-POD does not have to have the
first data element at the start of the object.

Obviously. Where do you think that most compilers put the vptr?

Example number 3 of heavyweightness. (NOW we're getting
somewhere!). So "losing POD-ness" IS still "bad" and my
assumed implication of that and use of "POD-ness" seems to
have been correct.

OK. I'll give you example number 4: the size of a long
typically depends on compiler options (and the default varies),
so putting a long in a class makes it heavyweight. And is "bad"
according to your definitions.

I think you're being emminately silly.

If I'm not mistaken, the next version of the standard
extends this constraint to "standard-layout classes"; i.e.
to classes that have no virtual functions and no virtual
bases, no changes in access control, and a few other minor
restrictions (but which may have non-trivial constructors).
*This new rule, however, does nothing but describe current
practice.

So in the future I will be able to have overloaded
constructors (I'm not sure what exactly a "trivial"
constructor is, but I assumed that an overloaded one is not
trivial) and still have lightweight classes, good. That threat
of a compiler not putting data at the front of non-PODs is a
real killer.

I have no idea. I've not bothered really studying this in the
standard, because I don't see any real use for it. (I suspect,
in fact, that it is being introduced more as a means of wording
other requirements more clearly than for any direct advantages
that it may have.)

--
James Kanze (GABI Software) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]

[rio]

"James Kanze" <ja*********@gmail.comha scritto nel messaggio
news:01e16d1a-8911-450f-88df-

>Why do you care about the layout of the data anyway? There's
nothing you can really do with it.

if i know how data is written i know how modify it
the same all other languages

if i have
32bits:8bits:64bits
i can write well on each of that

[=?UTF-8?B?RXJpayBXaWtzdHLDtm0=?=]

On 2008-11-10 12:40, rio wrote:

"James Kanze" <ja*********@gmail.comha scritto nel messaggio
news:01e16d1a-8911-450f-88df-

>>Why do you care about the layout of the data anyway? There's
nothing you can really do with it.

if i know how data is written i know how modify it
the same all other languages

if i have
32bits:8bits:64bits
i can write well on each of that

But since neither C, C++, Fortran, or just about any other language
guarantees a particular layout of a struct (or equivalent) you would
still need to use compiler specific methods to ensure that layout, both
in C, C++, Fortran, and just about any other language.

If you want full control of the placement of the bits (without using
platform dependent means) you should allocate a char array and perform
manipulations on that:

unsigned char data[13];

unsigned int* i = &data[0];
unsigned char* c = &data[4];
unsigned long* l = &data[5];

Assuming int, char, and long are 32, 8, and 64 bits respectively, and
that your platform does not require aligned accesses (in which case you
need additional work).

--
Erik Wikström

[James Kanze]

On Nov 10, 12:40*pm, "rio" <[e-mail]:

"James Kanze" <[e-mail] scritto nel messaggio
news:01e16d1a-8911-450f-88df-

Why do you care about the layout of the data anyway? *There's
nothing you can really do with it.

if i know how data is written i know how modify it the same
all other languages

The language provides the means to modify it. And as far as I
know, no language except Java specifies the actual data format,
and Java only does it for the basic types (and then, only
because there's no way a Java program can verify that the VM
actually follows in internally---the JVM for Windows doesn't,
for example).

if i have
32bits:8bits:64bits
i can write well on each of that

Sorry, I can't parse that sentence. Maybe if you'd give an
example of what you're trying to do?

--
James Kanze (GABI Software) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]

[tonytech08]

On Nov 11, 5:01*pm, tonytech08 <[e-mail]:

Maybe though the pure ABC (interfaces) concept
should not be implemented with the same machinery as non-pure ABCs
(interfaces).

I meant to write: Maybe though, the pure ABC (interfaces) concept
should not be implemented with the same machinery as non-interface
classes.

Maybe there should be an interface keyword.