Subject: Re: [boost] Heads up - string_ref landing
From: Olaf van der Spek (ml_at_[hidden])
Date: 2012-11-16 05:43:50
On Fri, Nov 16, 2012 at 11:31 AM, Yanchenko Maxim
> Not only subscripted access. Taking a subrange also requires knowing size. Copying from/to (read memcpy) - same.
> Filling (read memset) - same.
> Comparing (read memcmp) - same.
Those are C-style constructs. The C++-style equivalents are iterator-based.
> (char_range is an optimization technique so we aim for maximum speed. If you don't maximize speed you'd be happy with simple and safe std::string copies.)
> end() is needed only in operations at the end of the range or sequential operations on the range as a whole.
>> > OTOH, storing only pointers is conceptually cleaner.
>> You can derive size in bytes and memory range from a ptr pair without
>> type info. That may be handy when debugging and in other situations.
>> You can't do that with (ptr, size) without type info.
> Sorry, I don't understand this, could you elaborate, please?
Suppose you have two pointers, 0xa0 (begin) and 0xb0 (end). The size
in bytes is 0x10.
Suppose you have one pointer (0xa0) and one size (0x10). Does this
point to the same memory? Yes if sizeof(value_type) == 1, no
otherwise. You can't tell to what memory range it points without
>> >> Shouldn't they be implicit?
>> > Not from std::string. Same argument as for not having implicit conversion to char*.
>> What argument would that be?
> You are giving away a reference to string internals that are subject to change/die anytime.
Isn't that by definition for a reference? It applies to const string&
too. I don't think that's a good reason.
> Making it explicit and visible in the caller code ensures that the programmer will take special measures to make sure that the string doesn't change/die while there's a char_range looking into it.
> Consider std::vector<char_range>, for example.
> For the same reason we have explicit char_range::literal and char_range::from_array.
I'd like this to work:
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk