From: Thorsten Ottosen (nesotto_at_[hidden])
Date: 2005-05-15 16:35:56
"Pavol Droba" <droba_at_[hidden]> wrote in message
news:464931589.20050515230222_at_topmail.sk...
| Hi Boosters,
|
| There was a discussion about char[] support in the Boost.Range
| library. The issue seems important and I'd like to express my
| ideas about a possible solution.
|
| First lets sumarize problems and goals.
| The problems:
| char[] and possibly any other type that can be used as a c-string
| (this includes wchar_t, but also int, long and etc when used as a
| unicode code-point) might represent two different things:
| 1.) c-string literal
| 2.) arbitrary c-array
|
| Both views differ in lenght calculation, which is totaly
| incompatible and what's worse, it can lead to casual access
| violation when used improperly.
|
| An example:
| char str[] = "Hello";
| // typeof(str) is char[6], str=={'h','e','l',l','o',0}
|
| In the c-string view, str have 5 letters and ends at the 'o'.
| So the range should be <'H','o')
| In c-array view str is 6 elements long and ends with '\0'
| The range is <'H','\0')
|
| From the user perspective, both views are equaly important,
| however according to the usage scenarion, one might be preferable
| over the other one. Important aspect to keep in mind is this strict
| relativnes. For example for string algorithms c-string literal is
| obvious default, while for a data processing library the second
| choice is better.
|
| Current implementation is not ideal. First of all, there is a
| difference between char,wchar_t[] and the rest of the types.
| This brings some confusion. Secondly, it is not possible to use
| char[] as an ordinary array.
no default can meet all's expectations.
| The goals:
| From the problem analysis above, following goals can be implied
|
| 1. we need to support both views equaly
if you remove "equally" I agree.
| 2. a user must be always able to explicitly specify what type
| of view he requires
| 3. it should be possible for a library writer to select default
| view for his library.
| However point (2) must hold, so the user must be able
| to override this default.
| 4. Support must be present in the Boost.Range library.
| It is not feasible to ask library writer to provide
| specific workarounds/hacks. It would simply break the idea
| of Boost.Range library as a unified interface to range-like
| data structures.
|
| The solution:
|
| I propose to have two free-standing functions
| as_string() and as_array() (naming is not important now).
|
| Both should have the same generic signature:
|
| template<typename RangeT>
| boost::sub_range<RangeT> as_string(RangeT& aRange);
| template<typename RangeT>
| boost::sub_range<RangeT> as_array(RangeT& aRange);
|
+ const overloads
| By default, the functions only copy the input range to the target.
| However for the types like char[], the result will differ.
| For as_string() will create a sub_range delimiting string
| literal (using char_type<char>::length for instance), while as_array()
| will use compile-time boundaries.
sounds fair.
| In addition we might consider to open this interface for
| user-defined type, even if I'm not sure how it can be used.
with ADL. the library says
using boost::as_string;
foo( as_string(bar));
| Please note, that once any of these manipulators is applied to a
| range following application will have no effect.
|
| Lets see how this faicility can be used:
|
| A library writer can set the default by writting algorithm like
| this:
|
| template<typename RangeT>
| ... AnAlgorithm(const RangeT& aRange)
| {
| boost::sub_range<RangeT> StrRange=as_string(aRange);
|
| // Do something with StrRange
| }
|
| If a user calls AnAlgorithm directly:
| char str[]="hello";
| AnAlgorithm(str);
|
| str will be converted to a range, delimiting a string_literal.
| However he can alse use as_array():
|
| char str[]={'h', 'e', 'l', 'l', 'o'};
| AnAlgorithm(as_array(str));
|
| This time no conversion will take place, since as_array() returns
| sub_range.
|
| Note, that for the AnAlgorithm it does not matter what default is
| used in the Range library.
|
| Open questions:
|
| - I have intentionaly not included a proposal for the default view
| that the Range library should provide.
| Goal of this solution is to provide a way, that is not dependant
| on this.
| I'd like to leave it for the discussion. Right now it seems, that
| most of the people that entered discussion prefer c-array view.
| I would prefer c-string view, but I'm probably biased by the fact
| that I'm the author of StringAlgo library.
I prefer the string view too.
That's how boost.tange was designed.
There is one prblem with the default today IMO: char[]
should call char_traits<char>::length();
| - There is a space for possible extentions to the basic proposal.
| For instance, as_string() migh have the second parameter that
| will identify a terminator.
|
| - String literal lenght can be calculated in two ways. Either by
| using strlenght() (or alike), or using compile-time size (N)
| decreased by 1 (N-1).
for const char[], this would be the way to go...and so is it also implemented
by default.
-Thorsten