RE: [Reflex] Thread safety

> 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 Wed Jan 23 2008 - 18:48:07 CET