«

From 'Inside the C++ Object Model' by 'Stanley B. Lippman'

'The primary strength of the C++ Object Model is its space and runtime
efficiency. Its primary drawback is the need to recompile unmodified
code that makes use of an object of a class for which there has been
an addition, removal, or modification of the nonstatic class data
members.'

Here I can understand the strength of C++ object model but can anybody
elaborate the primary drawback of it.

sumsin <> writes:

> From 'Inside the C++ Object Model' by 'Stanley B. Lippman'
>
> 'The primary strength of the C++ Object Model is its space and runtime
> efficiency. Its primary drawback is the need to recompile unmodified
> code that makes use of an object of a class for which there has been
> an addition, removal, or modification of the nonstatic class data
> members.'
>
> Here I can understand the strength of C++ object model but can anybody
> elaborate the primary drawback of it.

Imagine you have:

class Widget ublic Object {
private:
Rect bounds;
public:
virutal Rect& getBounds(void);
};

and a thousand of subclasses of Widget.


And suddenly, the user requets that the widgets may be oriented by
some angle on the screen. So you add a field:

class Widget ublic Object {
private:
Rect bounds;
float angle;
public:
virutal Rect getBounds(void);
virutal float getAngle(void);
};

and lo, you have to recompile all the thousand of subclasses, because
now the field layout has changed, for all these classes.


Contrast that with CLOS:

> (defclass widget () ((bounds :initarg :bounds :accessor bounds)))
#1=#<STANDARD-CLASS WIDGET>
> (defclass button (widget) ((title :initarg :title :accessor title)))
#1=#<STANDARD-CLASS BUTTON>
> (defvar *button-1* (make-instance 'button :bounds #(10 20 110 40) :title "Test"))
*BUTTON-1*
> (inspect *button-1*)
#<COMMON-LISP-USER::BUTTON #x000334202008>: standard object
type: COMMON-LISP-USER::BUTTON
0 [BOUNDS]: #<ARRAY T (4) #x000334201F10>
1 [TITLE]: "Test"
INSPECT-- type :h for help; :q to return to the REPL ---> :q

We created the superclass and a subclass, and made an instance of the subclass.


Suddenly, we modify the superclass:

> (defclass widget () ((bounds :initarg :bounds :accessor bounds) (angle :initarg :angle :accessor angle :initform 0.0)))
WARNING: DEFCLASS: Class BUTTON (or one of its ancestors) is being redefined, instances are obsolete
#1=#<STANDARD-CLASS WIDGET :VERSION 1>

Of course new instances of the subclasses will take into account the
changes (nothing has to be done about the subclasses themselves):

> (defvar *button-2* (make-instance 'button :bounds #(10 20 110 40) :angle (/ pi 3) :title "At an angle"))
*BUTTON-2*
> (inspect *button-2*)
#<COMMON-LISP-USER::BUTTON #x00033426C9A0>: standard object
type: COMMON-LISP-USER::BUTTON
0 [BOUNDS]: #<ARRAY T (4) #x00033426C878>
1 [ANGLE]: 1.0471975511965977461L0
2 [TITLE]: "At an angle"
INSPECT-- type :h for help; :q to return to the REPL ---> :q


But what's more, the old instances of the subclasses have been updated too:

> (inspect *button-1*)
#<COMMON-LISP-USER::BUTTON #x000334202008>: standard object
type: COMMON-LISP-USER::BUTTON
0 [BOUNDS]: #<ARRAY T (4) #x000334201F10>
1 [ANGLE]: 0.0
2 [TITLE]: "Test"
INSPECT-- type :h for help; :q to return to the REPL ---> :q

>


In CLOS, it's even possible to define (and compile) subclasses before having defined the superclass:

> (defclass window (view) ())
#1=#<STANDARD-CLASS WINDOW :INCOMPLETE>
> (defclass view (widget) ())
#1=#<STANDARD-CLASS VIEW>
> (make-instance 'window :bounds #(0 0 512 342))
#<WINDOW #x0003342E24C0>
> (inspect *)
#<COMMON-LISP-USER::WINDOW #x0003342E24C0>: standard object
type: COMMON-LISP-USER::WINDOW
0 [BOUNDS]: #<ARRAY T (4) #x0003342E2400>
1 [ANGLE]: 0.0
INSPECT-- type :h for help; :q to return to the REPL ---> :q

>

--
__Pascal Bourguignon__

sumsin a écrit :
> From 'Inside the C++ Object Model' by 'Stanley B. Lippman'
>
> 'The primary strength of the C++ Object Model is its space and runtime
> efficiency. Its primary drawback is the need to recompile unmodified
> code that makes use of an object of a class for which there has been
> an addition, removal, or modification of the nonstatic class data
> members.'
>
> Here I can understand the strength of C++ object model but can anybody
> elaborate the primary drawback of it.

The drawback is in terms of impact upon change: if you change the
definition of a class (its members) ,you have to recompile every piece
of code that uses this class even if it has not been modified.

A solution to this drawback is the pimpl idiom.

--
Michael

Pascal J. Bourguignon wrote:

> In CLOS, [...]

That's comparing apples and oranges. C++ is basically a macro assembler,
just like C. It only has more features than C but the basic mode of
operation is the same. Once the code is compiled, the language is gone.
However, it works pretty well in that role (imho). You can't compare
that to a dynamic language (lisp, smalltalk?, obj-C) and complain how
inflexible that model is. One of the stated goals of C++ is to remain
compatible with C's language model as a portable assembler -- not to
introduce any (substantial) language middle layer between the program
and the hardware. For that, it works quite ok but of course this brings
some limitations (aswell as advantages).

On Jun 11, 4:56 pm, Michael DOUBEZ <michael.dou...@free.fr> wrote:
> sumsin a écrit :
>
> > From 'Inside the C++ Object Model' by 'Stanley B. Lippman'
>
> > 'The primary strength of the C++ Object Model is its space and runtime
> > efficiency. Its primary drawback is the need to recompile unmodified
> > code that makes use of an object of a class for which there has been
> > an addition, removal, or modification of the nonstatic class data
> > members.'
>
> > Here I can understand the strength of C++ object model but can anybody
> > elaborate the primary drawback of it.
>
> The drawback is in terms of impact upon change: if you change the
> definition of a class (its members) ,you have to recompile every piece
> of code that uses this class even if it has not been modified.
>
> A solution to this drawback is the pimpl idiom.
>
> --
> Michael

You mean if I add any:
- static data member and/or
- non-static member function and/or
- static member function and/or
- virtual member function, even then also the unmodified code will
recompile!!

But that is not the meant of statement I think.

On Jun 11, 4:54 pm, p...@informatimago.com (Pascal J. Bourguignon)
wrote:
> sumsin <sumsin...@gmail.com> writes:
> > From 'Inside the C++ Object Model' by 'Stanley B. Lippman'
>
> > 'The primary strength of the C++ Object Model is its space and runtime
> > efficiency. Its primary drawback is the need to recompile unmodified
> > code that makes use of an object of a class for which there has been
> > an addition, removal, or modification of the nonstatic class data
> > members.'
>
> > Here I can understand the strength of C++ object model but can anybody
> > elaborate the primary drawback of it.
>
> Imagine you have:
>
> class Widget ublic Object {
> private:
> Rect bounds;
> public:
> virutal Rect& getBounds(void);
>
> };
>
> and a thousand of subclasses of Widget.
>
> And suddenly, the user requets that the widgets may be oriented by
> some angle on the screen. So you add a field:
>
> class Widget ublic Object {
> private:
> Rect bounds;
> float angle;
> public:
> virutal Rect getBounds(void);
> virutal float getAngle(void);
>
> };
>

but suppose if user request only for some member functions not for
data members, in that case what will happen? Do we still need to
recompile thousand of the subclasses?

> and lo, you have to recompile all the thousand of subclasses, because
> now the field layout has changed, for all these classes.
>

sumsin a écrit :
> On Jun 11, 4:56 pm, Michael DOUBEZ <michael.dou...@free.fr> wrote:
>> The drawback is in terms of impact upon change: if you change the
>> definition of a class (its members) ,you have to recompile every piece
>> of code that uses this class even if it has not been modified
>
> You mean if I add any:
> - static data member and/or
> - non-static member function and/or
> - static member function and/or
> - virtual member function, even then also the unmodified code will
> recompile!!

Yes. If you add or remove something you must recompile every compilation
unit that uses this class (in practice that include the header file).

For static data, you can get away with it somewhat (when the value of
the static is defined outside the definition of the class).

This is usually handled by the dependency system (Makefile, ...).

> But that is not the meant of statement I think.

IMO, that is what he says:
<< Its primary drawback is the need to recompile unmodified code that
makes use of an object of a class for which there has been an addition,
removal, or modification of the nonstatic class data members.>>

Typically, you may want to change the internal representation of a class
(let say a float into a double). Even if a code doesn't explicitly uses
the member (by example if it is part of the private part of the class),
it must be recompiled.

--
Michael

sumsin <> writes:
> but suppose if user request only for some member functions not for
> data members, in that case what will happen? Do we still need to
> recompile thousand of the subclasses?

If it's not a virtual member, then it should be more or less ok not to
recompile, but if it's a virtual member you will have to recompile
because it changes the layout of the vtable, and the numbering of all
the other virtual members following in that class, and in the
subclasses.

--
__Pascal Bourguignon__

On Jun 11, 7:04 pm, p...@informatimago.com (Pascal J. Bourguignon)
wrote:
> sumsin <sumsin...@gmail.com> writes:
> > but suppose if user request only for some member functions not for
> > data members, in that case what will happen? Do we still need to
> > recompile thousand of the subclasses?
>
> If it's not a virtual member, then it should be more or less ok not to
> recompile, but if it's a virtual member you will have to recompile
> because it changes the layout of the vtable, and the numbering of all
> the other virtual members following in that class, and in the
> subclasses.
>
> --
> __Pascal Bourguignon__

Ok, apart from the sub-classing concept, let we talk in some other
way.
Supose we have two classes say 'foo' and 'bar'.
And class bar uses some instance of class foo then what will happen?

I mean in what condition the class bar will recompile?

sumsin <> writes:

> On Jun 11, 7:04 pm, p...@informatimago.com (Pascal J. Bourguignon)
> wrote:
>> sumsin <sumsin...@gmail.com> writes:
>> > but suppose if user request only for some member functions not for
>> > data members, in that case what will happen? Do we still need to
>> > recompile thousand of the subclasses?
>>
>> If it's not a virtual member, then it should be more or less ok not to
>> recompile, but if it's a virtual member you will have to recompile
>> because it changes the layout of the vtable, and the numbering of all
>> the other virtual members following in that class, and in the
>> subclasses.
>>
>> --
>> __Pascal Bourguignon__
>
> Ok, apart from the sub-classing concept, let we talk in some other
> way.
> Supose we have two classes say 'foo' and 'bar'.
> And class bar uses some instance of class foo then what will happen?
>
> I mean in what condition the class bar will recompile?

It's the same, since the selection of the method to be called is done
at the call site, with a virtual method index, and that's this virtual
method index that needs to be globally computed.

Basically, o->m() is implemented as o->vtable[ vindex of method m in class o ]();
and the vindexes are computed so that whatever the subclass the same
index is used for the same virtual method.

The vindex is a literal that is hard coded in all call sites.

--
__Pascal Bourguignon__