Re: [boost] Unicode: what kind of binary compatibility do we want?

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