ok, first of all, i'll give the stl idea a try. osg's .obj importer uses sscanf to read in data. what would you suggest as an stl alternative now? (i have to admit that i barely ever used stl):
Code: Select all
sscanf(line+2,"%f %f %f %f", &x, &y, &z, &w);
If you want to make the osg stuff locale safe you would have to change a lot of places in the osg code. And you would have to redo it every time a new osg version is released. You're sure this is the way you want to go?
I think there might be a third option, if you're only interested in getting string translations according to the user locale. You could proceed as follows:
1) Allocate a wxLocale object and keep a pointer to it where you can access it globally,
2 Set the locale you need, i.e. german locale, using the Init method of your wxLocale object,
2) Load the needed message catalog file(s)
3) Restore the C locale (allocate a wxLocale object, call Init with wxLANGUAGE_ENGLISH)
4) Write a replacement for wxGetTranslation so that it refers to your locale for which you loaded the message catalogs, and redefine the macro _() to use your replacement function.
5) When exiting your application delete the locale created in 3) and thereafter the locale created in 1)
This should give you translated message without the need to modify the osg code.
I wouldn't recommend to temporarily change the locale while loading files due to the possible unwanted side effects.
.. for example?
At least in a multithreaded environment you might get errors when converting doubles to strings or vice versa since the decimal separator might be different unexpectedly.