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

Subject: Re: [boost] New libraries implementing C++11 features in C++03
From: Dean Michael Berris (mikhailberis_at_[hidden])
Date: 2011-11-25 06:38:22

On Fri, Nov 25, 2011 at 10:16 PM, Christopher Jefferson
<chris_at_[hidden]> wrote:
>
> On 25 Nov 2011, at 11:01, Dean Michael Berris wrote:
>>
>>
>> If the rejection of N2511 in favor of the current lambda is any
>> indication, even the committee finds that local functions an
>> unnecessary complication. What makes you think that bringing N2511
>> back into C++03 would even make sense especially since there are
>> already approximations to C++11 lambda's?
>>
>> It's logic really:
>>
>> Â 1) C++11 lambda > N2511
>> Â 2) Since Phoenix ~ (C++11 lambda + more) and Local ~ N2511
>> Â 3) Therefore, Phoenix > N2511
>> Â 4) QED
>>
>> No?
>
> No.
>

Of course, my bad. I don't have my compiler handy, what was I thinking?!

  1) C++11 lambda > N2511
  2) Since Phoenix ~ (C++11 lambda + more) and Local ~ N2511
  3) Therefore Phoenix > Local
  4) QED

> You seem simply unwilling to accept that there are people who refuse to use Pheonix, and libraries built on it because:

Wait, did I reject that people refuse to use Phoenix? Are you putting
words in my mouth?

Nobody -- I repeat hoping that it sinks in somehow -- as in ABSOLUTELY
NOBODY is forcing anybody to use Phoenix. If you don't want in-lined
lambdas defined using C++03 syntax that approximates C++11 lambda's,
then don't use it. It's that simple.

>
> 1) It leads to horribly large compile times.

Compilers suck at compiling TMP. Compilers need to get better at it.

> 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.
>

Wait, doesn't Phoenix have tests that compile? I hope you're not
saying Phoenix is broken that people who use it automatically
encounter these horrible error messages with their favorite compiler
even if their code is correct. Or do the error messages only ever show
up when you use Phoenix incorrectly?

So you're saying it takes different skills to read other than the same
skills you use to read? I absolutely don't get this.

> And therefore, I choose not to use it, as developing code using these libraries is much more difficult than the alternatives, even after I spend time trying to understand their idiosyncrasies.
>

Everyone is entitled to their own opinion. I'm not forcing you or
anybody to use Phoenix, I'm saying that Boost.Local provides marginal
benefit at best. There's nobody stopping you from using Boost.Local
either but I don't necessarily think it has to be in Boost for it to
be used by people who want to use it.

> You seem to think that anyone who doesn't agree with you on this point is stupid, or just "doesn't get it".

What makes you think that? Have I called anybody stupid?

What's happening is that people are just disagreeing but don't give
clarity to their positions with *logic*.

> I have written several large parsers using boost::spirit. They had great performance, and once the code was written they looked very nice to read. However, I have still removed those parsers, and will not write any more (after I have re-evaluated the current root of spirit/phoenix, to see if error messages have improved in the last 6 months or so).
>

I don't see why this is relevant to the discussion. This is your
personal preference and unfortunately logic doesn't care what you like
or don't like.

> I have spent a lot of time reading C++ error messages, and writing large C++ libraries. I have contributed quite a few patches to boost.
>

Good for you then.

> Personally, having now taken the time to full evaluate local (which I wouldn't have done without this discussion), I believe it is a valuable C++ library, which I will make use of during the C++03 -> C++11 migration period (which I expect to take several years, given clang still doesn't support lambdas today).
>

Good for you. I still don't think it should be in Boost though for
reasons I've already mentioned several times.

Have a good day.

Cheers

-- 
Dean Michael Berris
http://goo.gl/CKCJX