Re: Feedback on string-convert branch

On 01/05/2017 03:36 PM, Robin Gareus wrote:
> 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.
> 

PS. The recent code to only set LC_MESSAGES is step in that direction.

For now the intention is to investigate and to collect feedback from
various affected systems + plugins.


@Tim: can that code that you wrote also work in the other direction?
Can we use it to format floats with some preferred user's locale (comma,
dot) for display only?