Boost logo

Boost :

Subject: Re: [boost] Unicode: what kind of binary compatibility do we want?
From: Cory Nelson (phrosty_at_[hidden])
Date: 2009-06-01 23:19:43


On Mon, Jun 1, 2009 at 8:09 PM, Mathias Gaunard
<mathias.gaunard_at_[hidden]> wrote:
> As I am finishing putting property look-up together for the Unicode library
> GSoC, I am wondering what kind of binary compatibility it should aim for.
>
> The work from Graham Barnett back in 2005 defined an abstract base class
> with virtual functions for every unicode-related feature but I believe
> that's overkill.
>
> Basically, the current property design I have is like this
>
> struct some_property
> {
>    enum type
>    {
>        some_default,
>        some_value1,
>        some_value2,
>        ...
>        _count;
>    }
> };
>
> some_property::type get_some_property(char32 ch);
>
> With get_some_property a simple look-up in the table, but the table layout
> being version dependent it would need to be in the library TUs.
>
> However, a new version of the library may return a value that is not within
> the enum.
>
> Should it then work like this?
>
> some_property::type get_some_property(char32 ch)
> {
>    some_property::type p = get_some_property_impl(ch);
>    if(p >= some_property::_count)
>       return some_property::some_default;
>    return p;
> }
>
> some_property::type get_some_property_impl(char32 ch);
>
> Is that suitable? Or do we want more/less flexibility?
>

I have never had an expectation of binary compatibility with Boost --
as far as I know none of the existing libraries promise it but I could
be wrong. I would prefer not to have it wasting any cycles checking
compatibility, especially with Unicode which often seems to sneak its
way into perf-critical code.

Just my two cents.

-- 
Cory Nelson
http://int64.org

Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk