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 01:23:33

On Fri, Nov 25, 2011 at 3:38 PM, Nathan Ridge <zeratul976_at_[hidden]> wrote:

>> Stuff I (mikhailberis_at_[hidden]) said...
>>
>> Huh? This is a matter of the rules of the programming language and
>> (dare I say) sane engineering practices.
>
> Are you saying it's sane engineering practice to avoid local functions?
> If so, why don't you avoid C++11 lambdas equally?
>

Because C++11 lambdas are function objects I can define in-line where
I need function objects -- which is what modern C++ prefers over
function pointers. The STL and every other sanely engineered C++
library that requires function object callbacks will support function
objects whether they're defined in-line with C++11 lambdas or as
hand-rolled function objects using operator() overloading.

Also, I personally do not see a need for a construct like this:

  auto f = []() { /* do something here */ }

I say this because there's absolutely 0 point in doing this if I can
drop the lambda in where I need f *anyway*.

>>
>> Did you really mean that C++ shouldn't stand in your way when you want
>> to write Pascal code?
>
> I don't know Pascal so I can't comment on that. I am saying that C++
> shouldn't stand in my way when I want to make design choices like making
> one function local to another versus making them "equals" by putting them
> in the same scope.
>

What's the problem with making them equals? They're just functions.

>> I'm sorry but this logic is just broken. You're saying "I want local
>> functions in C++ but I don't want it as a language extension". This
>> makes no sense at all.
>
> I do want it as a language extension. We have it as a language extension,
> it's called C++11 lambdas. But let's let the poor guys who can't use C++11
> yet have an approximation of it, too!
>

Then propose/implement it as a language extension, or keep the current
implementation and use it -- nobody's stopping you or anybody from
doing that. Putting it in Boost is what I object to "just because".

>>
>> But there are C++03 solutions, it involves functions in
>> namespaces/class scope and binders. If you really want in-lined
>> functions defined then you use an approximation of lambda's like
>> Phoenix/Bind/Lambda in C++03.
>
> The key word here being "approximation". Boost.Local is an approximation,
> too, just in a different way. Boost.Local gives you something Phoenix etc.
> do not (C++ statement syntax), and Phoenix etc. give you something
> Boost.Local does not (in-line definition in an expression context).
> Both approximations are useful, and some may prefer one over the other.
>

I know what gives me C++ statement syntax: C++ functions. I still
don't get why local functions are so worth the trouble of muddying up
a function's implementation when functions can stand alone anyway and
be just as good.

>>
>> Oh believe me they've heard it from me (or at least I've made some
>> noise about it already). I can make more noise and maybe send in
>> patches but there's other things in this world that concern me (and
>> others) to actually do anything substantial in other fronts.
>
> Could you point me to some links? I am genuinely interested.
>

Just this one: http://cplusplus-soup.com/2010/11/21/c-hating/ and look
at the comments too if you have enough time. :)

>> > Otherwise, you have to accept that library writers face a trade-off
>> > between the user-friendliness of error messages, and the expressiveness,
>> > terseness, and power obtained by extensive use of advanced techniques
>> > such as template metaprogramming. There is no one right answer to
>> > this tradeoff, and it is good for users to have different alternatives
>> > available to them.
>>
>> Sure. So what's the point again? I don't see how this paragraph is
>> relevant to the discussion.
>
> You asked:
>
>> So again, how does broken code using any library become a basis for
>> whether the library is a good library for inclusion in Boost? It just
>> seems silly to me.
>
> Since dealing frequently with errors is a reality of programming, and we
> cannot rely on compilers to substantially improve the readability of TMP
> error messages in the short term, a library that solves a similar problem
> to an existing library, but using different techniques that give rise to
> more user-friendly error messages, adds value, and therefore can reasonably
> be considered for inclusion in Boost.
>

No, sorry -- just having "prettier error messages" isn't a good
measure for inclusion in Boost. You're going to have to try harder
than that to make a case for a library.

Cheers

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