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

From: Axel Naumann <Axel.Naumann_at_cern.ch>
Date: Thu, 24 Jan 2008 18:19:36 +0100

Hi Jean-Francois,

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.

Even worse: Reflex makes excessive use of inlining, to not penalize runtime too much by the separated API object layer. But that means the code relevant for binary compatibility includes the internal types' functions - and even its data members, where nested inlined accesses to data members occur.

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.

Did I overlook something? Do you have any other ideas?

Cheers, Axel.

On 2008-01-23 18:46, Jean-Francois Bastien wrote:

>> Yes - but not at all costs. It should not increase the 
>> instruction cost (at least not by a lot), and it should not 

>
> It's usually an extra indirection into the implementation pointer, and
> an extra allocation at construction. It's not usually a huge cost.
>

>> obscure interfaces: an std::string is well known; a 
>> Reflex::String is not - and I don't like the idea of wrapping 
>> every single STL class, and re-implementing (and
>> maintaining) their member functions for each supported platform.

>
> You just hit one of the troublesome points: strings aren't a built-in
> type. For an API taking in strings you can dumb down to taking a const
> char *, but for returning a string there's no easy solution but
> returning your own string type (or taking in a buffer+size but that's
> just stupid).
>
> Containers and iterators shouldn't be a problem as long as you use an
> STL-like API.
>

>> So it might boil down to a compromise, but I'd still like to 
>> see your proposal!

>
> This should put you in the right direction:
> http://techbase.kde.org/index.php?title=Policies/Binary_Compatibility_Is
> sues_With_C%2B%2B
>
>
> JF
>
Received on Thu Jan 24 2008 - 18:19:46 CET