Re: Feedback on string-convert branch

On 01/05/2017 12:12 AM, Tim Mayberry wrote:
> On Thu, Jan 5, 2017 at 7:14 AM, Paul Davis <[email protected]>
> wrote:
> 
>>
>>
>> On Wed, Jan 4, 2017 at 12:52 PM, Tim Mayberry <[email protected]> wrote:
>>
>>> I've pushed a branch called string-convert to the main repository that
>>> I'd like
>>> some feedback on from the other developers when they get a chance. It
>>> represents a fair bit of work over the last year or so and is attempt to
>>> make
>>> improvements to the de/serialization code in Ardour.
>>>
>>
>> I still don't understand how this is supposed to work with plugin data. If
>> you leave the global locale setting untouched, how do we know what to do
>> when reloading plugin data across two systems where the global locale may
>> be different?
>>
>>
> 
> Of the 100 or so LocaleGuard's in master, the 10 or so that remain are in
> the Plugin get/set_state methods, which is why I mentioned removing
> LocaleGuard's that guard internal string conversion.

Since changing the locale is expensive, so we should also retain a
single LocaleGuard in save_state() rather than switch forth/back in
every Plugin get/set state.

With some luck, plugins don't change the locale and every save only
needs to change the locale once.


> That some plugins depend on a specific global locale for correct operation
> or worse modify the global locale is dissappointing but seems to be a
> reality and it is accounted for in the branch.

..and it's worse. Some plugins expect to also *run* in the "C" or en_US
locale. e.g. NI Kontakt fails in numeric-locales that use a comma, and
NI isn't alone.


If we add a custom system, I think it's better to

 - don't change the locale at all, keep using the default "C" locale for
C++/std::locale

 - keep relying on standard functions for string-conversion

and instead

 - come up with a custom message-translation system that does not depend
on the std::locale at the time the message is formatted.

2c,
robin