"Pavol Droba" <droba@topmail.sk> wrote in message news:464931589.20050515230222@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