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
> Domagoj Saric wrote:
>> But in the mentioned case it is not IMO apriori obvious we are dealing with
> 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
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
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
>> 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'
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