<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Thu, Jan 5, 2017 at 7:14 AM, Paul Davis <span dir="ltr"><<a href="mailto:paul@linuxaudiosystems.com" target="_blank">paul@linuxaudiosystems.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><br></div><div class="gmail_extra"><br><div class="gmail_quote"><span class="gmail-">On Wed, Jan 4, 2017 at 12:52 PM, Tim Mayberry <span dir="ltr"><<a href="mailto:mojofunk@gmail.com" target="_blank">mojofunk@gmail.com</a>></span> wrote:<br><blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="gmail_quote"><div dir="ltr"><div>I've pushed a branch called string-convert to the main repository that I'd like </div><div>some feedback on from the other developers when they get a chance. It </div><div>represents a fair bit of work over the last year or so and is attempt to make </div><div>improvements to the de/serialization code in Ardour.</div></div></blockquote></span><div><br>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?<br> </div></div></div></div></blockquote><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>There will be some further small changes necessary to account for the recent LocaleMode changes to work correctly if the global C++ locale is used for localization of numeric data via string_compose/iostream/stringstring. In master AFAICT the LocaleMode setting won't currently work correctly for C++ level numeric conversion because as I mentioned, the PBD::LocaleGuard constructor sets the global C++ locale to "C" and then only the global C locale is reset in the LocaleGuard destructor, which means that the global C++ locale is always "C" for the purposes of numeric conversion and there are a fair few places in master (that don't use a LocaleGuard) that make this assumption or at least rely on it for correct behaviour.</div><div><br></div><div>Tim</div></div><br></div></div>