On Mon, Aug 15, 2011 at 19:44, Olaf van der Spek <ml@vdspek.org> wrote:
On Thu, Aug 11, 2011 at 10:45 AM, Yakov Galka <ybungalobill@gmail.com> wrote:
class str_ref : public iterator_range<const char*> { ... };
Convertible from both, string literals and std::strings, and provide only one overload that accepts it everywhere.
Doesn't iterator_range treat literals as arrays by default? The str_ref idea is great, but IMO iterator_range isn't suitable for it. Also, doesn't iterator_range require memory allocations itself?
1) It's a proof of concept, not an implementation. iterator_range is just one of the infinity of types which can be mapped to the Range concept and used wherever Ranges expected. 2) Yes, it treats string literals as arrays, so what? It's exactly what we want. If you're talking about including or not the null terminator, then I'm still not sure on this point. We can say that our strings don't contain zeros in the middle (which is acceptable for function expecting const char*), then if end() points to a null terminator we can use it as an optimization when passing to a low-level function accepting a zero-terminated string. If end() doesn't point to zero, then we must do a copy when passing to something like fread(). The alternative is to never include the null terminator when initializing from a string. This solution is also good, since only a small fraction of our functions pass the strings to the system (where a null terminated string is needed), and even then sometimes we *must* do a copy, especially if we want to support Unicode on windows (consider all boost::interprocess which cannot be used now for opening Unicode paths on windows). 3) No, iterator_range just stores a pair of iterators, no memory allocations are done. Also see 1), it's irrelevant to the discussion. -- Yakov