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

Subject: Re: [boost] New libraries implementing C++11 features in C++03
From: Nathan Ridge (zeratul976_at_[hidden])
Date: 2011-11-24 17:23:06

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

We already know your position about (2): that now C++11 is here, we should
be moving on and stop giving attention to C++03 problems which are solved
by C++11. I, on the other hand, think the reality is that C++03 will be
around for a while longer, and it's worth caring about the C++03 experience
evem if there are C++11 solutions. Obviously our positions are derived
from different experiences working with C++, and I don't think there's much
point arguing about this, other than asking others to weigh in and share
their positions based on their experiences.

> 3. I cannot, no matter how I look at your examples and the "logic"
> behind the concept of local functions, comprehend why this is a good
> way to organize code. Aren't we all past the phase yet of functions
> that have more than 10 lines of code?
 >
> 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.

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.

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.

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

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.

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.

Regards,
Nate