Re: [boost] New libraries implementing C++11 features in C++03
On 24 Nov 2011 20:19:17 Joel de Guzman wrote:
The funny thing is that the new feature came from Spirit, not Phoenix. Phoenix API has been stable for many years now. Triple sheesh for ya! :-)
Then why did V3 require a review earlier this year? Phoenix is great if you want things that are easy in a functional programming language to seem easy in C++, but it does have a learning curve. Local requires a little more typing for short snippets, but is probably far less intimidating, and has far fewer potential "gotchas", for the typical user. I don't think the two are competing with each other at all--- Phoenix provides a far richer set of building blocks for those who want them, and Local offers a stable interface, trivial execution model, and straightforward error messages for those who simply want to use a local function here and there. For a non-guru who just wants to reduce code duplication or port something from Delphi, Local is in many cases the more appealing choice.
On 24 Nov 2011 20:19:17 Joel de Guzman wrote:
The funny thing is that the new feature came from Spirit, not Phoenix. Phoenix API has been stable for many years now. Triple sheesh for ya! :-)
Then why did V3 require a review earlier this year?
That's because it has been re-implemented from the grounds up in order to make it compatible and a full replacement for boost::lambda, boost::bind and phoenix::v2. But what's your point anyways? I don't see any relation to the original topic.
Phoenix is great if you want things that are easy in a functional programming language to seem easy in C++, but it does have a learning curve. Local requires a little more typing for short snippets, but is probably far less intimidating, and has far fewer potential "gotchas", for the typical user. I don't think the two are competing with each other at all--- Phoenix provides a far richer set of building blocks for those who want them, and Local offers a stable interface, trivial execution model, and straightforward error messages for those who simply want to use a local function here and there. For a non-guru who just wants to reduce code duplication or port something from Delphi, Local is in many cases the more appealing choice.
All of this might be true. But why does Boost.Local have to be in Boost in order to fulfill these promises? Regards Hartmut --------------- http://boost-spirit.com http://stellar.cct.lsu.edu
On 25 Nov 2011 21:44:41 Dean Michael Berris wrote:
function, it ceases to be a nameless function. The *utility* of having a function defined inside another function is marginal at best because they're absolutely better outside any other functions in all aspects: readability, maintainability, and functionality.
One of the many (often contradictory) heuristics for writing readable, maintainable code is to put declarations near the site of use. If you have a function-like predicate that is only used in one or two places, declaring it right before use makes it more likely that it will be kept in sync with any changes to the calling code. That can also make it easier for someone else (including the future you) to read and fully understand the code later, as less backscrolling/cross-referencing/memorization is required to fully understand what's going on. This is exactly the reason that literate programming tools normally provide (and encourage) a mechanism to interrupt the exposition of the calling function to define a callee, and then return to the parent. Like all other wisdom in this discipline, it's not absolute, but local functions can be a more useful organization tool than defining helper functions at namespace scope.
There's *no* practical reason to put a lambda in a named variable when the point of lambda's are so that you can define them in-line. I would
If they're stored in named variables, you can (more cleanly) switch between two (or more) different predicates based on a runtime condition. You can also put them in an array or container and select based on some key (e.g. for an event handler) or iterate over a subset (e.g. repeating some for_each() loop with several different evaluation metrics.) Furthermore, giving something a name is an opportunity to communicate something about your intent to a future reader--- if "_1 < _2 ? _1 : _2" is named "select_max" then I can suspect a problem; if it's anonymous I might not. These are all the same reasons we put function pointers and function objects in named variables and containers--- sometimes it makes sense to organize the referent functions at namespace scope, and sometimes it doesn't.
participants (2)
-
Brent Spillner -
Hartmut Kaiser