Review: Inside the C++ Object Model

by Stanley Lippman.

Not 100% satisfied: mitigated interest, many repetitions, some errors, some controversies (e.g. with Scott Meyers on the Named Return Value optimization -- NRV). A few useful insights, though, and some useful information. May be too cfront related...

Quotes and comments

1.3 An Object Distinction
p 20

The definition and use of thing2 [...] is a well-behaved instance of the OO paradigm. The definition and use of thing1 [...] reflects a well-behaved instance of the ADT paradigm. Whether the behavior of thing1 is good or bad depends on what the programmer intended.
[This brings Kierkegaard to mind, doesn't it?]

2.1 Default Constructor Construction
p 34, Member Class Object with Default Constructor

If a class without any constructors contains a member object of a class with a default constructor, the implicit default constructor of the class is nontrivial [...]
[Er... only if the member's default constructor itself is nontrivial!?]

p 38, Class with a Virtual Function

    flip( b ); // should be b.flip()
    flip( w ); //           w.flip()

3.1 The Binding of a Data Member
p 75

    typedef int length;

    class Point3d
    {
    public:
       // oops: length resolves to global
       mumble( length val ) { _val = val; } // should have been Point3d
       // ...
    private:
       // ...
       typedef float length;
       // ...
    };

This aspect of the language still requires the general defensive programming style of always placing nested type declarations at the beginning of the class.
[HP aCC spots this as an error. Indeed, HP CC doesn't.]

3.4 Inheritance and the Data Member
p 91, Multiple Inheritance

Figure 3.3: Data Layout: Single Inheritance with Virtual Inheritance
[should have been: "with Non-Virtual Inheritance" or "with Virtual Pointer"]

4.2 Virtual Member Function
p 139, Virtual Functions under Virtual Inheritance

My recommendation is not to declare nonstatic data members within a virtual base class.

7.1 Templates
p 248-249, Name Resolution within a Template

[...] which instance of foo() is invoked [?...] the instance chosen is the nonintuitive one.
[...] The program site of the resolution of a nonmember name within a template is determined by whether the use of the name is dependent on the parameter types used to instantiate the template. If the use is not dependent, then the scope of the template declaration determines the resolution of the name. If the use is dependent, the the scope of the instantiation determines the resolution of the name.
[Would be a good example of a complex and nonintuitive rule, if it really is so. At least HP aCC doesn't behave as predicted here! Thread in comp.std.c++]

7.2 Exception Handling
p 258, A Quick Review of Exception Handling

If however, the exception were thrown within the Point constructor following allocation from the heap, any constructed composite or subobject within Point (that is, a member class or base class object) would automatically be destructed and then the heap memory freed.
[I either don't understand or disagree, and anyway miss the place where the topic should have been revisited at the end of the session]

7.4 Efficient, but Inflexible?
Shared Memory

[Good summary of the problem]