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:
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-... Sent from the Boost - Dev mailing list archive at Nabble.com.