[Box Backup-dev] COMMIT r348 - in box/chris/bb-save-state: . bin/bbackupd lib/common lib/server

[Martin Ebourne]

On Mon, 2006-01-30 at 12:02 -0800, Gary wrote:
> Well, the whole purpose of the Archive class with operator overloading and multiple type-dependent
> store/retrieve calls was to simplify the main body of code (functionality implementation) as much
> as possible. Once those are gone, the whole Archive class should go as well, as there is no reason
> for it to exist anymore.

In its new incarnation it is still simplifying the implementation in
that it provides the overloaded type specific Read and Write methods.
Without this the rest of the code would be much more complicated and
error prone.

As it is now it also adds very little in terms of code complexity and
overhead, so I think the right balance has been struck.

> From my experience, a vtable (polymorphic) call is always guaranteed, unless the compiler can
> figure out that it is not possible for an object can be polymorphic (no derivations exist, or a
> local stack variable, or RTTI disabled in complier settings, etc.), in which case it can inline to
> speed up processing. I think it works correctly under any compiler I have encountered, but I
> certainly understand that it's best to be on the safe side, when it comes to such a cross-platform
> project.

Yes, the conditions you list are where the compiler can inline. But for
a polymorphic class it is extremely rare that those can be satisfied so
it will almost always use the vtable, thus none of the intended
performance benefit of inline is realised.

Now the problem the compiler faces is where to make the vtable and
method implementations. IIRC GCC will place them in the same file as the
first non-inline virtual method. But a problem is posed where the class
is fully inline (as I think this one was). Now the compiler has nowhere
to put them, so it ends up generating vtable and method code in every
file where the class is used, relying on the linker to sort the mess
out. This is obviously very inefficient in object size and compile time.

Cheers,

Martin.