Re: [Boost-users] [review][assign] Formal review of Assign v2 ongoing

Subject: Re: [Boost-users] [review][assign] Formal review of Assign v2 ongoing
From: er (er.ci.2020_at_[hidden])
Date: 2011-06-23 13:33:36

On 6/21/11 7:08 PM, er wrote:
>
>> If it is true that you cannot use an initializer list with an explicit
>> constructor in the new standard I think it will make explict
>> constructors very painful. I may not have reasoned it through fully,
>> but I see no reason not to allow initializer lists to use explict
>> constructors. It doesn't seem to create safety concerns or ambiguity.
>> Does someone know the rationale for that? It seems to be a mistake to me.
>
> I'm only reporting what I observe, and I'm unable to make a judgment.
> Hopefully someone with a later version of gcc can confirm or infirm.
>
> In any case, it still leaves containers that have not been augmented
> with initializer list constructors, such as queue, for which Assign is
> helpful under C++0x, for the task of initializing a container.
>
> Thanks for sharing your thoughts.
>
>>
>> Regards,
>> Luke

Did you get a chance to think it through? It would be nice to clarify 
this issue before the review closes, tomorrow.

PS: This thread stopped but still continues in lib.boost.devel. Here's a 
copy of my last post hoping it makes the purpose of v2 more clear.

 > I think your library needs to do better than coming up with a slightly
 > different syntax than V1, otherwise I don't see the point of having it.

Indeed, but I claim more than a slightly different syntax. The 
fixed-arity stuff is quite a different syntax. The other stated goals of 
the design, in the change-log, are, amongst other things, to bring these 
improvements:

1- Code reuse because deque and put share the same crtp
2- Code decoupling (modularity)
3- Open for extension (albeit not enough, see my response to)

Do I have to argue that these objectives worthwhile?! No, so I please 
ask whether they are were met, and if not, what is lacking. PS: maybe I 
did not state 3-.

Let's assume I get paid for writing a TPS report, every day, involving 
100 unit-tests such as the one below.

STL approach:

std::deque<int> cont;
const int n = 2;
int x = log10( 1 );
for(int i = 0; i < n; i++)
{
     cont.push_front( x );
}
x = log10( 10 );
for(int i = 0; i < n; i++)
{
     cont.push_front( x );
}
x = log10( 100 );
for(int i = 0; i < n; i++)
{
     cont.push_front( x );
}
x = log10( 1000 );
for(int i = 0; i < n; i++)
{
    cont.push_front( x );
}

assert(
     boost::range::equal(
         cont,
         csv_deque( 3, 3, 2, 2, 1, 1, 0, 0 )
     )
);

PS: No need to argue that a nested loop would made the job easier. Your 
boss can make it as arcane as he likes and he might have as well 
re-arranged 1, 10, 100, 1000 in a different order.

Assign 2.0:

BOOST_AUTO( _r, ( _repeat = 2 ) );
typedef function<int(int)> f_;
BOOST_AUTO( _d, ( _data = f_( log10 ) ) );

assert(
     boost::range::equal(
         csv(
             deque<int, push_front_>( _nil) % _d % _r,
             1, 10, 100, 1000
         ),
         csv_deque( 3, 3, 2, 2, 1, 1, 0, 0 )
     )
);

Does Assign (1.0-2.0) begins to add positively to your well being?

Assume, further, that you have to do the same thing all over again, but 
you have to drop the function altogether, and replace push_front by 
push_back. Is it better to write a function or use Assign?

As for 2.0, specifically, do we agree about *decoupling* of features 
(_r,_d and push_front_)?

The same code above requires very minor modification if used with put() 
rather than deque(), are we on the same page about *code reuse*?

Finally, let's say you want something other than repeat, that does not 
already exits. You can write write a small class, that conforms to a 
concept (ConceptModifier), and invoke two mere macros, and the job is 
done. Do you agree about *open for extension*?

https://svn.boost.org/svn/boost/sandbox/assign_v2/boost/assign/v2/option/modifier/repeat.hpp

Please have a bit mercy and give me your updated impressions based on 
these clarifications.