On Mon, Jun 1, 2009 at 8:09 PM, Mathias Gaunard <mathias.gaunard@ens-lyon.org> 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