Re: Feedback on string-convert branch

On Fri, Jan 6, 2017 at 7:20 PM, Paul Davis <[email protected]>
wrote:

> I've read through Tim's email descrption of string-convert and taken a
> quick look at the code.
>
> There's a lot of good work here that I think has many net benefits.
>
> My concern is that the changes are not enough to ensure that locale issues
> are fully addressed without using locale (either because of 3rd party code
> or local coding changes).
>

I'm sorry, I just don't understand what you mean by this sentence, can you
please explain in a bit more detail.

Do you have concerns with pbd/string_convert.h API and whether or not it is
independent of the global locale/s and or thread safe etc? or do you mean
something else?


> If they don't ensure this, then it just comes down to whether there are
> any direct costs to switching to the string-convert approach AND whether it
> is an improvement to have *two* systems of ensuring locale-independent
> serialization, one explicit and one implicit.
>
>
What sort of direct costs are you referring to?

When you refer to having *two* systems do you mean mixing use of the new
API's and the existing system of using LocaleGuards and then performing
explicit numeric conversion with a mix of the existing API's we use?

I can't see how that would be an improvement, that would mean using at
least 4 different API's and you would not get much benefit AFAICT and it
may be worse. I'm suggesting only using a single API(mostly) for
serialization and the others for localization (which seems pretty common
and normal to me).


> I am not totally clear on the answers to these two questions.
>
>
Sorry, perhaps I'm just tired as it is late here but I'm not clear on what
the questions were?

Tim


> --p
>
>
> On Thu, Jan 5, 2017 at 5:16 PM, Robin Gareus <[email protected]> wrote:
>
>> On 01/05/2017 04:55 PM, John Emmas wrote:
>> > On 05/01/2017 14:24, Robin Gareus wrote:
>> >> Since I don't know the MSVC build-environment and build-dependencies
>> >> used there a quick-solution would be an #ifndef COMPILER_MSVC
>> >>
>> > Yeah, I guess that should help - but does this effectively mean that
>> > translations / internationalization etc won't work any more for an MSVC
>> > build?
>> >
>>
>> Depends on the preference setting.  There is a new mode to only set
>> LC_MESSAGES and leave the rest of the locale alone (to investigate
>> issues with plugins, see the other branch in this email thread)
>>
>> It needs to be explicitly enabled in Preferences > Global > Translations
>> The default hasn't changed and Ardour still sets LC_ALL. So there should
>> be no change WRT to translations compared to prior MSVC builds.
>>
>>
>> Since gettext() chooses the translation based on LC_MESSAGES [1], I'm
>> curious how this works with MSVC builds if there's no LC_MESSAGES.
>>
>> ciao,
>> robin
>>
>> [1]
>> https://www.gnu.org/software/libc/manual/html_node/Using-get
>> textized-software.html
>> _______________________________________________
>> ardour-dev mailing list
>> [email protected]
>> http://lists.ardour.org/listinfo.cgi/ardour-dev-ardour.org
>>
>
>
> _______________________________________________
> ardour-dev mailing list
> [email protected]
> http://lists.ardour.org/listinfo.cgi/ardour-dev-ardour.org
>
>

_______________________________________________
ardour-dev mailing list
[email protected]
http://lists.ardour.org/listinfo.cgi/ardour-dev-ardour.org