Boost logo

Boost Users :

Subject: Re: [Boost-users] [review][assign] Formal review of Assign v2 ongoing
From: er ([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

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 );

         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 ) ) );

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

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

Boost-users list run by williamkempf at, kalb at, bjorn.karlsson at, gregod at, wekempf at