"Mathias Gaunard" <mathias.gaunard@ens-lyon.org> wrote in message news:hn3e4e$nv4$1@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