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.
> 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.
Boost list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk