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-24 22:24:35

On Fri, Nov 25, 2011 at 9:23 AM, Nathan Ridge <zeratul976_at_[hidden]> wrote:
>
>> > 2) As for local functions, namespace, or global structs see N2511. If
>> > you disagree with N2511 arguments, it's truly OK because IMO everyone
>> > is free to use whatever idiom they see fit for themselves and their
>> > problem domain. I am sure the library reviewers had namespaces and
>> > global structs in mind when they assessed the "potential usefulness of
>> > the library" (also because these are mentioned in the library docs).
>> > So also in this case /all/ submitted reviews should allow the review
>> > manager to come to a conclusion on this issue.
>> >
>>
>> Sure, but again I don't see what's in N2511 that's not doable with
>> C++11 lambda's.
>>
>> So in no uncertain terms am I expressing my opinion in the context of
>> this thread that for libraries like Local, *no*, this should not be a
>> library but rather should be a proper language extension for it to
>> provide any real advantage over whatever is already out there and
>> especially what's already in C++11.
>
> You are conflating two different arguments over and over again:
>
> 1. Whether Boost.Local provides any advantage over pure C++03 alternatives
>
> 2. Whether it is appropriate to add something to Boost that improves the
> Â Â  C++03 experience but has been obsoleted by a C++11 feature
>
> Can we please keep these discussions separate and argue them on their own
> merits? It doesn't help when every time someone refutes your position
> about (1) you bring up (2) saying that it makes (1) irrelevant.

I don't know if you actually *read* what I wrote. I said, for
_libraries *like* Local_ they should not even be libraries.

So for the clarity of the situation:

1. Does Boost.Local provide any advantage over pure C++03
alternatives? No. Absolutely no, IMO.

2. Do we want libraries that add something to Boost that improves the
C++03 experience but has been obsoleted by a C++ feature? Answer is:
it depends.

>>
>> The advantages of having a function (a logical piece of code that's
>> meant to be used as a unit *anyway*) at namespace scope or class scope
>> is that re-usability is something you get for free. On the other hand,
>> defining a local function with Boost.Local that I'd want to define as
>> an external function at some point (because oh I don't know I want to
>> use the same function somewhere else all of a sudden) will be too much
>> work with all the macro voodoo that I have to wade through.
>
> I think this is a matter of one's coding style.
>

Huh? This is a matter of the rules of the programming language and
(dare I say) sane engineering practices.

> When I write a function, I think of it as being part of some interface.
> It if it's a public method of a class, it's part of the class's public
> interface. If it's a private method, it's still part of some interface:
> the interface used by the implementations of the public methods. By
> moving a function A from being local to another function B, to being
> in the same scope as B, you are adding function A to the same interface
> that function B is part of. I view this as a design choice: a choice
> I may or may not want to make, and I wouldn't like the langauge to
> stand in my way and force me to make one choice because it doesn't
> support the other.
>

Did you really mean that C++ shouldn't stand in your way when you want
to write Pascal code?

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.

If you really don't want the language to stand in your way and force
you to make one choice because it doesn't support another, use Lisp.

> So, at least in my coding style, I see a use case for local functions
> which does not have a C++03 solution. I think a language, and C++ in
> particular, should be flexible enough to accomodate different coding
> styles. Now given that we don't have language-level support for local
> functions in C++03, the next best thing we can do is emulate it with
> a library.
>

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.

>> Hey I'm not complaining that people are bashing libraries. What I'm
>> complaining about is why people aren't complaining (meta isn't it?)
>> that their compilers suck at displaying better error messages for
>> broken code.
> Â >
>> Again, *THE LIBRARY DOESN'T SPEW ERROR MESSAGES, COMPILERS DO THAT FOR
>> BROKEN CODE*.
> Â >
>> 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.
>
> The problem is that errors point to code that is deep within the library's
> implementation, or worse, the implementations of helper libraries used
> by the library. To understand the error, the user has to look at the
> library's implementation. The user shouldn't have to do that -
> understanding the implementation of a library should not be a
> prerequisite for using it.
>

Okay, again though there's two things working together here: the
compiler pointing you at the wrong place and the library failing
somewhere "deep". There's only so much a library writer can do about
making it not fail somewhere deep but... there's nothing the library
writer can do about the compiler choosing to not pander to humans.

> If you have any specific suggestions about what compilers could do to turn
> these errors from deep within the library implementation, into errors
> that do not require knowing anything about the library implementation,
> I would like to hear it, and I'm sure so would compiler writers.
>

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.

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

Cheers

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