Re: [boost] Assign V2 - first impression

Subject: Re: [boost] Assign V2 - first impression
From: Simonson, Lucanus J (lucanus.j.simonson_at_[hidden])
Date: 2011-06-24 20:11:00

er wrote:
>> Also, it would be nice to have iterator pair and range be acceptable
>> alternatives to the fixed arity and variadic options shown above.  I
>> realize that would require some SFINAE, but I think being able to
>> consistently initialize containers and then mix the forms would be a
>> big plus.    
> 
> Take
> 
> push_back( cont )( range1 )( range2 )( range3 );
> 
> I guess your SFINAE approach would check whether range1 models
> ConceptRange and if so, push back each of its elements at the back of
> cont. Unfortunately, the actual intent might be to treat range1 as an
> element of cont. So I actually prefer the current approach:
> 
> push_back( cont ).for_each( range1 ).for_each( range2 ).for_each(
> range3 ); 
> 
> This puts in cont a total of size( range1 ) + size( range2 ) + size(
> range3 ) elements. Whereas this
> 
> push_back( cont )( range1 )( range2 )( range3 );
> 
> puts 3 elements in cont : range1, range2, and range3.
> 
> What do you think?

I was thinking that we could apply SFINAE on the value type of the container equal to the value type of the iterators/range to know at compile time whether they should be treated as elements or a range/iterator pair.  A vector<vector<int>::iterator> container could then be initialized with a pair of vector<vector<int>::iterator>::iterator representing a range or a pair of vector<int>::iterator representing two elements by identifying at compile time which case we have.  I don't believe it would ever be ambiguous.  SFINAE would also improve the value of your error messages when the interface is used with the wrong type.  The error would be "no function operator() accepts type xyz".  I would agree, however, that the for_each syntax is at least clear and easier to achieve from the library implementation side.  It isn't obvious from a user perspective why they have to use for_each with a range or iterator pair but not for the fixed arity case.  I would say that if the user knows the type of the container and the type of the range he knows what to expect without the use of for_each.

>> 
>> char* cstr[] = "Hello world!";
>> std::vector<char>  chrs;
>> push_back( chrs ,  filter = to_upper )( cstr, cstr+5 )( '\0' );
> 
> push_back(
>      chrs, filter_ = to_upper
> ).for_each( make_iterator_range( cstr, cstr + 5) )( '\0' );

Why do I have to make_iterator_range?  Why can't it be overloaded for both iterators and ranges?

>> 
>> chrs contains a null terminated string "HELLO".
>> 
>> There is then a whole area of treating std::string like a container
>> by specializing some of your library interfaces that would really be
>> handy.  
> 
> Sure, I welcome more examples/problem specifications such as that
> above. Please do send them. Thanks.

I won't ask you to fix everything that is wrong with std string, stream operators and worst of all wide characters.  On the other hand, making std::string behavior more consistent with that of the std containers would be a nice touch and extend the library in a new and useful direction.

Regards,
Luke