Here's the C++ draft document: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3442.html It's being considered for C++14.
Boost 1.55 has an implementation, but not everybody (including my employers) is on such a recent boost, so I don't think we can depend on that. It's a simple class, I don't mind rolling our own, and in fact if we do we can also make it a bit more optimized in dealing with ustring. The basic gist is that, say you have a library function foo(x), where x is a character sequence. What type should x be? Let's assume that foo needs to read the characters but doesn't wish to assume ownership or modify them in place. And also let's assume that the library function may be used by apps that like char*, and other apps that like std::string. If x is const char*, then (a) it's technically unsafe because no length is passed, so it assumes that the characters are valid and are 0-terminated, and also (b) an app that is dealing with std::string needs to call it as foo(s.c_str()), which is a little clunky and may rub some people wrong. On the other hand, if x is a std::string&, that works really nicely for an app already using std::string, but if the caller just has a char array, it'll end up converting to a std::string to pass (which involves allocating memory, copying the chars, then deallocating after the call, very wasteful). So the idea is that you'd declare a non-owning (char* + length) object and pass that around with implied conversions. You can just pass either a char* or a std::string, works fine both ways, and in neither case will it allocate, copy, or deallocate. For the char* case, if the app knows the length of the string already, it further provides safety by passing the length without having to scan the string. Also, there are examples of functions that currently return a string where the string will necessarily be a contiguous subregion of another existing string that was passed as an argument (example: substr). Instead of allocating std::strings, it can return string_ref's. The allocation, if ever needed, is done on the assignment after return, if you know what I mean. To answer your question, you can have an empty string_ref, yes. On Dec 26, 2013, at 3:02 PM, Mark Visser <[email protected]> wrote: > 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 -- Larry Gritz [email protected]
_______________________________________________ Oiio-dev mailing list [email protected] http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
