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 23:38:47

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

Are you saying it's sane engineering practice to avoid local functions?
If so, why don't you avoid C++11 lambdas equally?

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

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

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

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.

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

Could you point me to some links? I am genuinely interested.

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

Regards,
Nate