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. On Mon, Apr 8, 2013 at 9:39 AM, Larry Gritz <[email protected]> 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?). > > > > On Mon, Apr 8, 2013 at 9:14 AM, Brecht Van Lommel < > [email protected]> wrote: > >> Hi Michel, >> >> We've had similar issues with Blender, and I don't have a good >> solution for it either. There's a lot of confusing information about >> this online, my understanding is that to avoid issues you must: >> >> * Ensure all the compiler flags match for the application and all >> libraries. >> * Build with /MD instead of /MT when using a DLL. Otherwise the DLL >> and main application will not use the same heap. /MT does work ok with >> a static OIIO library. >> >> It would be nice if the OIIO (and OSL) API would not use these STL >> data structures, but this of course involves major API compatibility >> breakage. So I'm not sure how practical this is. >> >> Brecht. >> >> On Mon, Apr 8, 2013 at 4:51 PM, Michel Lerenard >> <[email protected]> wrote: >> > Hi everybody, >> > >> > we've been struggling for a few days hunting a weird bug in >> > ImageInput::create, and the search raised one major concern about the >> use of >> > std::string in the API. >> > I don't know if the issue has been discussed before (in a sense, I hope >> > not). >> > >> > We've had a crash when trying to open a specific JPEG file. To >> understand >> > its cause we built OIIO in debug, to find that the crash occured in the >> > geterror() function. Apparently it crashed in the destruction of the >> > std::string that is used in ImageInput::create because it's been >> > overwritten. >> > Recompiling with more debug flags we found that strangely the string is >> > already in a bad state before opening the file: we crashed in the boost >> > function that extracts the extension of the file. (called from the line >> > "std::string format = Filesystem::extension (filename)" in >> > ImageInput::create). >> > Which is quite weird because it does not relate very well with the >> crash we >> > had at the beginning, which was linked to the data in the file. And it >> now >> > crashes on every single file we try to open. >> > >> > Trying to dig deeper we hit a bunch of issues, mainly related to >> std::string >> > and the way it's implemented. >> > >> > Is there a reason for using "std::string" instead of a simple "char*" >> (even >> > const) in all interface functions ? As far as we're concerned, it's >> heavy >> > and raises many compatibility issues especially under windows ( >> libraries >> > versions, debug/non debug MT option, etc...). So far we have failed to >> build >> > a full debug version of an application using OIIO that does not crash at >> > startup. Either we can't debug because libraries are in release, either >> we >> > crash in mainCRTStartup. >> > >> > Our debug session uses the trunk of OIIO and boost 1.44 version. >> > >> > We used boost 1.44 because of this bug >> > https://svn.boost.org/trac/boost/ticket/6320, which seems to have >> appeared >> > in 1.48 and was fixed only on boost trunk at this time. At first we >> used the >> > 1.49 version then tried the 1.53 and finally the 1.44. Going back to the >> > 1.44 did change things a bit: with OIIO in release with debug info, no >> > crash. But OIIO won't load any image. >> > >> > ------------------------------ >> > Michel >> > Isotropix SAS >> > >> > _______________________________________________ >> > Oiio-dev mailing list >> > [email protected] >> > http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org >> _______________________________________________ >> Oiio-dev mailing list >> [email protected] >> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org >> > > > > -- > Larry Gritz > [email protected] > -- Larry Gritz [email protected]
_______________________________________________ Oiio-dev mailing list [email protected] http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
