Re: [boost] Assign V2 - first impression

Subject: Re: [boost] Assign V2 - first impression
From: er (er.ci.2020_at_[hidden])
Date: 2011-06-25 03:16:31

>
> 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 imp

Remember that elements are passed through what you call a 'filter' 
(data-generator), even when it is not specified explicitly. Filter's 
result_type is the container's value-type, by default:

// Push at the front of cont, filter( args1… ),..., filter( argsn… )
push_front( cont )( args1... )...( args... );

Assume filter( *begin( range ) ) and filter( range ) are each valid 
expressions. In this case, you have an ambiguity that can only be 
resolved by letting the user specify his intent explicitly, For example:

push_front( cont )( args1 ... ).for_each( range )( argsn... );

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

FYI I made sure that using the existing syntax, the above compiles and 
executes, albeit with char cstr[], not char* cstr[].

>> 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?

It can be accommodated.

>> 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.

Thanks, but I would need a more detailed request.

>
> Regards,
> Luke
> _______________________________________________
> Unsubscribe&  other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
>