Re: [boost] New libraries implementing C++11 features in C++03

Subject: Re: [boost] New libraries implementing C++11 features in C++03
From: Vicente Botet (vicente.botet_at_[hidden])
Date: 2011-11-25 10:37:07

Joel de Guzman-2 wrote
> 
> On 11/25/2011 7:16 PM, Christopher Jefferson wrote:
>> 
>> You seem simply unwilling to accept that there are people who refuse to
>> use Pheonix,
>> and libraries built on it because:
>> 
>> 1) It leads to horribly large compile times.
>> 2) Error messages. I know you hate this, so let me write out my opinion
>> one last time.
>> 
>> Phoenix leads to error messages which:
>> * On the compilers I commonly use - I can't change this, there aren't
>> that many
>>   compilers around.
>> * Are very, very large
>> * and require different skills to read and understand than any other
>> library.
> 
> Ok, let's put that to a test.
> 
> Assumptions:
> 1) You are using a phoenix function
> 2) Your lambda is solely for capturing locals, and should be
>    the basic counterpart of how you do it using Locals (i.e.
>    no fancy phoenix expressions -- we restrict ourself to
>    simple capturing of locals).
> 
> Here's a sample code:
> 
>   http://pastebin.com/t3nW4SFY
> 
> I set it up so you can disable phoenix and test the net time.
> Here's what I get:
> 
> with Phoenix:
>   start time:    19:44:57.73
>   end time:      19:44:59.69
> : 2.0 secs
> 
> without Phoenix:
>   start time:    19:44:29.07
>   end time:      19:44:30.81
> : 1.7 secs
> 
> Now, how about error messages. Here's the lambda part:
> 
>   std::for_each(vec.begin(), vec.end(), plus4(_1, b, l, s));
> 
> You'd have to be absurdly dumb to get that wrong! A more
> realistic scenario is a mistake in the function body itself.
> In which case (try it out), you'll get the same errors as
> plain-'ole C++.
> 
> 1) Leads to horribly large compile times? Not if you keep your
> phoenix expressions simple.
> 2) Error messages? Again, none if you keep your phoenix
> expressions simple.
> 
> And "simple" is the point. Locals does not have complex
> expressions anyway. The complexity is in the function body.
> THAT is the use case of Locals and THAT is one of the cases
> where phoenix really shines.
> 
> 

Hi,

Joel your arguments have convinced me that maybe we don't need Boost.Local. 

Best,
Vicente

--
View this message in context: http://boost.2283326.n4.nabble.com/New-libraries-implementing-C-11-features-in-C-03-tp4096518p4107688.html
Sent from the Boost - Dev mailing list archive at Nabble.com.