The main disadvantage of C++ Object Model

Hello,

I've been reading the "Inside C++ Object Model" and when reach to the 1.1 section - "The C++ Object Model" I can't understand the content of author. That's as following:

<b>Stroustrup's original (and still prevailing) C++ Object Model is derived from the simple object model by optimizing for space and access time. Nonstatic data members are allocated directly within each class object. Static data members are stored outside the individual class object. Static and nonstatic function members are also hoisted outside the class object. Virtual functions are supported in two steps:

A table of pointers to virtual functions is generated for each class (this is called the virtual table).

A single pointer to the associated virtual table is inserted within each class object (traditionally, this has been called the vptr). The setting, resetting, and not setting of the vptr is handled automatically through code generated within each class constructor, destructor, and copy assignment operator (this is discussed in Chapter 5). The type_info object associated with each class in support of runtime type identification (RTTI) is also addressed within the virtual table, usually within the table's first slot.

Figure 1.3 illustrates the general C++ Object Model for our Point class. 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. (The two table model, for example, offers more flexibility by providing an additional level of indirection. But it does this at the cost of space and runtime efficiency.)</b>

He said the the main drawback is to recompile the unmodified code but I can imagine that situation. Anyone can give me several examples for that?

Thanks,
HTS

Basically it's a complicated way of saying that if you modify a class, you need to recompile all code which uses that class, even if the modification wouldn't affect the operation of said code directly.

May I add two things to this.

1. The disadvantage becomes a big problem if you are writing libraries.

Imagine you are a commercial vendor of a library, thus you provide to your customers header files and the compiled library code. Your customers build your applications based on it. Now you want to fix a bug or optimize something which requires you to change you object members. Even though the change is within the private: section of your class and is perfectly encapsulated, your customers cannot just plugin the new version of your library but have to recompile ALL code that uses the library. Thus you can really only do such changes if you are rolling out a new major release of your library.

2. There is a way to get around this disadvantage (at the cost of space and runtime efficiency), which is the pimpl idiom. Most library vendors use that.

Quote:

---

Originally Posted by hoangtuansu

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.

Anyone can give me several examples for that?

---

Seem quite simple to me: If your class contains a 3rd part class' instance as a data member and the size of that 3rd part class changes, you have to recompile your class.

Code:

---

class MyClass
{
public:
//...

private:
//...

Some3rdPartyClass    myDatamember;
};

---

Pointers work the same as the 'pimpl idiom' in this regard, and can allow you to not include it in your header at all which can be very nice.

Quote:

---

Originally Posted by originalfamousjohnsmith

Pointers work the same as the 'pimpl idiom' in this regard, and can allow you to not include it in your header at all which can be very nice.

---

Well, pimpl means "pointer to implementation", and no, just using a pointer without using the pimpl idiom will not work the same. Sure, a forward declaration in the client code's header would suffice, but when it comes to defining the functions of the client code that actually use objects of the given class, the class definition must be available, and the client code will still need to be re-compiled if "there has been an addition, removal, or modification of the nonstatic class data members" of that class.

In that book, the writter suggested 3 models:

- A Simple Object Model: in which an object contains an array of slots. And every slot is a pointer which point to the available field or method. Apparently, we also need to recompile if there's any modification or addition.

- A Table - Driven Object Model: an object just consists of two pointers, one points to member data table, and one points to funtion member table. And in my opinion, this approach can be solve the problem of the C++ Object Model as I mentioned on the first post.

Anyway, I think that the solution of truess is the same as the approach of creating COM technology which is in the "Essential COM" :-)

Thanks all,
HTS

Sorry, I forgot. The third model is "The C++ Object Model"