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
