Re: [boost] [range] strings

Subject: Re: [boost] [range] strings
From: Domagoj Saric (domagoj.saric_at_[hidden])
Date: 2010-03-09 11:26:21

"Mathias Gaunard" <mathias.gaunard_at_[hidden]> wrote in message
news:hn3e4e$nv4$1_at_dough.gmane.org...
> Domagoj Saric wrote:
>
>> But in the mentioned case it is not IMO apriori obvious we are dealing with
>> arrays...
>
> Well, the type of the variable in question was an array. If you don't know the
> types of your variables, you're going to have trouble understanding what
> overload get selected by generic libraries.

I was thinking of "apriori obviousness"/"intuitivness"/readability of code...the
idea of 'self documenting code' or what you think it does before reading the
documentation....and IMO it is more intuitive to expect that the following
assumption holds:

assert( iterator_range<char const *>( "my test string" ) == as_literal( "my test
string" ) );

...but, more importantly, it is also useful...

Likewise, that a function called "as_literal" does _not_ treat its argument as a
(string) literal (but as a plain pointer) is not quite obvious to me...If I'm
not mistaken, section 2.13.4 of the standard pretty clearly says that a string
literal is a null terminatated array of const chars...

>> Consider a use case like this:
>>
>> bool is_a_recognized_string( char const * const string_to_test )
>> {
>>     boost::iterator_range<char const *> const test_string(
>> boost::as_literal( string_to_test );
>
> Now it's a pointer to a const char, a vastly different thing.
> Does that code even compile?

Yes...(the above snippet actually does not because it misses a
parenthesis...just an omission on my part while I was simplifying a real world
piece of code)...

> I would have expected as_literal to not work
> then.

The documentation specifies its return as "[s,s +
std::char_traits<X>::length(s)) if s is a Char* or an array of Char
[boost::begin(x),boost::end(x)) otherwise" so it was obviously designed to work
that way...

>> For example this does not work in Dinkumware STL implementations:
>> std::vector<unsigned char> storage;
>> boost::iterator_range<unsigned char const *> storage_chunk( storage );
>
> It's not supposed to work; if you do that, your code is broken.

Why is it not supposed to work? If the container in question has random access 
iterators and is contiguous in memory (as std::vector is, explicitly, and also 
std::string, implicitly) why would such code be broken?

In any case, what would be your proposal/fix for the following 'solution' 
http://lists.boost.org/Archives/boost/2010/03/162762.php?

IMO the example presented there fits perfectly into the 'story' of Boost.Range 
introduction/motivation..: if all I need as input is a string then a 
boost::iterator_range<tchar const *> would be the perfect abstraction (ABI 
stable and efficient extraction of the strlen information) if it provides 
automatic conversion from a char const *, a string literal, a std::string, a 
std::vector<char>, an MFC CString, an ATL CString or just about any other form 
of a contiguous string of characters in memory...

--
"What Huxley teaches is that in the age of advanced technology, spiritual
devastation is more likely to come from an enemy with a smiling face than from
one whose countenance exudes suspicion and hate."
Neil Postman