On 04/08/2013 06:39 PM, Larry Gritz wrote:
Would it help if, for a future release, we tried to replicate all of
the API entry points that take std::string& to have another version
that takes const char*, so that apps can use either one (in
particular, so that platform/app combinations that find std::string
dangerous, which obviously doesn't include the ones I use, can use the
char* ones?
As far as we're concerned, yes, that would help.
We have our own internal string container, we don't use std::string
anywhere, so using 'const char*' is the best solution for us.
On 04/08/2013 06:39 PM, Larry Gritz wrote:
I try very hard to minimize the number of places in the public APIs
where we use anything other than POD or simple types that we define.
(Example: we use boost quite a bit internally, but no boost types or
other references exist in the public APIs at all.)
I would like to think that std::string (and maybe std::vector) would
be safe after so many years in the C++ standard, but apparently in
some cases (is it only Windows?) it is not. Grrr.... this does not
bode well for hopes of having any C++-11 idioms anywhere in the APIs
any time in the foreseeable future.
I'm not surprised that it strikes only/mainly windows. Putting aside the
std::string class itself, we could have other issues using non basic
types as parameters, given the way the libraries are organised: we
cannot link OIIO without explicitely telling the linker to ignore some
system libraries. (we get symbols arleady defined otherwise). I always
feel like playing russian roulette when i choose the lib i'm going to
ignore...
_______________________________________________
Oiio-dev mailing list
[email protected]
http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
