RE: [Reflex] Binary compatibility, was: Re: [Reflex] Thread safety

From: Jean-Francois Bastien <jfbastien_at_cae.com>
Date: Thu, 24 Jan 2008 12:42:01 -0500


> if you are referring to d-pointers: that's not going to work
> :-/ The Reflex API objects are specifically designed such
> that they do not cost much overhead compared to a pointer
> allocation ("TypeBase* tb" or "Type t" have almost the same
> number of instructions). There is no way we can allocate
> objects in Type's constructor, and free them in its destructor.

Yes, I was refering to d-pointers and other tricks that allow binary compatibility. I understand your point, but I get the impression that it is premature optimisation without any benchmarks to justify it. I agree that certain classes can't have a d-pointer for performance reasons, but I think these classes should be determined with some real numbers to back up the choice.

In any case, if you fully control a class' layout (i.e. if it has no members from the STL and if its size and layout don't depend on preprocessor macros being defind or not) then you're much safer. Type is currently "safe" in that TypeBase (which has an std::string) is held as a pointer.

My obsession on binary compatibility is twofold:

The first point is very important, the second less so. If you watch out when you fix code then the second point is fulfilled even if your API isn't fully designed for binary compatibility.

> So all I can promise is to keep the API as fixed as possible
> (_after_ the changes I'm currently working on) - which will
> still not guarantee binary compatibility. I'm afraid you
> would have to keep your own branched version of Reflex if you
> absolutely need that... I wouldn't mind sacrificing some of
> our requirements to find a compromise - but d-pointers are
> too much of an overhead, and so is outlining of all functions.

Let me know when your changes are done.

JF Received on Thu Jan 24 2008 - 18:43:19 CET

This archive was generated by hypermail 2.2.0 : Thu Jan 24 2008 - 23:50:01 CET