I'm really only familiar with the oiiotool part of the codebase, but I noticed there are a few places that pass const char* instead of std::string because the latter can't represent NULL. Does string_ref allow the null string?
Is this the same thing? http://www.boost.org/doc/libs/1_55_0/libs/utility/doc/html/string_ref.html cheers On Dec 26, 2013, at 1:10 PM, Larry Gritz <[email protected]> wrote: > Just floating the idea to see what people think. > > Many packages have some version of a "string reference" class that is a > non-owning (and non-allocating) reference to character data that > auto-converts to char* or std::string when assigned. C++14 is drafting it > into its standard library. > > I've been toying with the idea of doing an implementation of this in OIIO, > and changing many of the utility and other functions that take strings -- > which are currently a bit of a mish-mash of std::string, char*, and ustring > -- to accepting a string_ref, then internally it can do what it wishes. For > many uses that just need to look at the characters, this can eliminate many > transitory std::string allocations and copies. Since we can't count on C++14 > (hah, we can't even count on C++11), I'd have to write my own (it's very > simple) and so it could also be aware of ustring. > > Does anybody have strong opinions? Including: > > 1. Don't change anything ever, we hate string_ref. > > 2. A nice idea to use it when it's available from C++14, but wait until then. > > 3. Yes, do it and convert anyplace where it's appropriate. Making it > ustring-aware is great, even if it means deviating from what C++14 will > eventually offer as std::string_ref. > > 4. Do it, but only if it's exactly like what C++14 std::string_ref will end > up being. > > 5. Something else. > > If you don't care one way or the other, as long as it won't really affect > what the source code looks like on the app side, you don't need to chime in, > that's the default answer. > > Similarly, there are a lot of places where we pass arrays as just a T*. It > sometimes bugs me how unsafe this is, there are always assumptions about how > many T's it points to. We could make an array_ref<T> template, which is just > a bundling of the pointer and a length, and use that in many places instead > of raw pointers. There's no allocation issue here, but forcing the callers to > pass an explicit length (and have the called function given an explicit > length) could be useful in improving code safety. > > -- > Larry Gritz > [email protected] > > > > _______________________________________________ > 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
