Boost logo

Boost :

Subject: Re: [boost] New libraries implementing C++11 features in C++03
From: Joel de Guzman (joel_at_[hidden])
Date: 2011-11-25 07:24:23

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.

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.

So, gentlemen, please, let's keep the FUD to a minimum.


Joel de Guzman

Boost list run by bdawes at, gregod at, cpdaniel at, john at