November 2011 - Boost - lists.preview.boost.org

Proposed Boost.Algorithms Review Ends
by Dave Abrahams 28 Nov '11

28 Nov '11

The review of Marshall Clow's proposed Boost.Algorithms submission officially ended yesterday, but if you get your review in before the end of the weekend, as review manager I'll probably consider it. So far we've had five votes, which is reasonable for something of this scale. Thanks everybody for your time and interest. I'll be posting the review results next week. Regards, Dave -- Dave Abrahams BoostPro Computing http://www.boostpro.com

2 3

[msm] guard behavior if guard guards the transition MSM threats event as handled is that correct?
by Michael.Herchel＠rohde-schwarz.com 28 Nov '11

28 Nov '11

Hi Christophe, Regarding our compile-time problem in the past and therefore, the changes Richard made: Would it be also feasible to develop an additional backend that is derived from the MSM one, but only implements the process_event() method for each event and not in a generic template-based way? With this approach we could still use MSM out-of-box and not having the need for internal transition tables or having references from inner to outer state machines etc but still gain small compiler units. I understand that we will loose flexibility and creating new state machines becomes more work, but I think we could live with that. What is your opinion? Am I thinking too short? Thanks, Michael

2 1

Fwd: [msm] guard behavior if guard guards the transition MSM threats event as handled is that correct ?
by Richard Szabo 28 Nov '11

28 Nov '11

Hi Christophe the attached example I think shows 2 problems. 1st is that the deferral of event3 is not happening. 2nd is that the no_transition function is never called. the output of the run is : MS1 Entering State: Idle by: event1 MS1 Leaving State: Idle by: event1 MS1 Entering State: SubRunning by: event1 FwdGuard: returns:1, event: event2 Processing BaseEvent Instance(event2) Setting guard false FwdGuard: returns:0, event: event3 FwdGuard: returns:0, event: event4 FwdGuard: returns:0, event: event5 MS1 Leaving State: SubRunning by: event5 MS1 Entering State: AfterSub by: event5 I think it shall be : MS1 Entering State: Idle by: event1 MS1 Leaving State: Idle by: event1 MS1 Entering State: SubRunning by: event1 FwdGuard: returns:1, event: event2 Processing BaseEvent Instance(event2) Setting guard false FwdGuard: returns:0, event: event3 FwdGuard: returns:0, event: event4 MS1 no_transition event (event4) MS1 Leaving State: SubRunning by: event5 MS1 Entering State: AfterSub by: event5 MS1 no_transition event (event3) So in this example event3 and event4 are never triggered a transition ... the Row < SubRunning , baseEvent , none , ProcessBaseEvent , FwdGuard > was guarded by the FwdGuard for these events. Is my expected behavior wrong ? If guard is executed but the transition actually is triggered because it is guarded out why this event treated as handled event ?. This 2 problems breaks my current nested state machine implementation because I'm using no_transition to forward the event to the outer state machine. I'm confused :(. Cheers Richie

2 6

[spirit] missing boost/endian/integers.hpp
by Jürgen Hunold 28 Nov '11

28 Nov '11

Hi, after the version number bump to 1.49.0 my builds fail with src/devel/boost/boost/spirit/home/support/detail/endian.hpp:24:37: fatal error: boost/endian/integers.hpp: No such file or directory It seems that spirit want to use Boost.Endian from 1.49 which is not merged to trunk yet. Patch attached, ok to commit? Yours, Jürgen -- Dipl.-Math. Jürgen Hunold | IVE mbH Software-Entwickler | Lützerodestraße 10 Tel: +49 511 897668 33 | 30161 Hannover, Germany Fax: +49 511 897668 29 | http://www.ivembh.de juergen.hunold(a)ivembh.de | | Geschäftsführer: Sitz des Unternehmens: Hannover | Univ.-Prof. Dr.-Ing. Thomas Siefer Amtsgericht Hannover, HRB 56965 | PD Dr.-Ing. Alfons Radtke

2 1

[preprocessor] Get last token
by Roman Perepelitsa 28 Nov '11

28 Nov '11

Is it possible to extract the last token from a list of space separated tokens? LAST_TOKEN(a b) // expands to b LAST_TOKEN(blah blah b) // expands to b LAST_TOKEN(* & b) // expands to b Roman Perepelitsa.

2 4

Re: [boost] [Boost-commit] svn:boost r75690 - trunk/tools/build/v2/tools
by Steven Watanabe 27 Nov '11

27 Nov '11

AMDG On 11/27/2011 04:50 AM, bdawes(a)acm.org wrote: > Author: bemandawes > Date: 2011-11-27 07:50:00 EST (Sun, 27 Nov 2011) > New Revision: 75690 > URL: http://svn.boost.org/trac/boost/changeset/75690 > > Log: > Change deprecated /Op option to its replacement, /fp:precise. This quiets a warning from the Intel compiler, which uses the msvc toolset. > Did you miss my reply on boost-build? Please revert this. It's wrong. > On 11/26/2011 06:03 AM, Beman Dawes wrote: >> > The patch below clears a warning from Intel 12.1, and works fine for >> > MSVC 8, 9, and 10. >> > >> > Unless someone objects, I'll apply it tomorrow. I'm posting advance >> > notice in case any of the math folks want to give it a try beforehand. >> > > I object. This branch is for msvc 6 and 7, which > only have /Op. /fp:precise is for msvc 8 and > up. The real problem is that intel-win is assuming > vc7.1 compatibility. > > Text files modified: > trunk/tools/build/v2/tools/msvc.jam | 2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) > > Modified: trunk/tools/build/v2/tools/msvc.jam > ============================================================================== > --- trunk/tools/build/v2/tools/msvc.jam (original) > +++ trunk/tools/build/v2/tools/msvc.jam 2011-11-27 07:50:00 EST (Sun, 27 Nov 2011) > @@ -240,7 +240,7 @@ > > # Improve floating-point accuracy. Otherwise, some of C++ Boost's "math" > # tests will fail. > - toolset.flags $(toolset).compile CFLAGS $(conditions) : /Op ; > + toolset.flags $(toolset).compile CFLAGS $(conditions) : /fp:precise ; > > # 7.1 and below have single-threaded static RTL. > toolset.flags $(toolset).compile CFLAGS $(conditions)/<runtime-debugging>off/<runtime-link>static/<threading>single : /ML ; > _______________________________________________ > Boost-commit mailing list > Boost-commit(a)lists.boost.org > http://lists.boost.org/mailman/listinfo.cgi/boost-commit >

2 1

[local] Any "active Boost library author" in favor of Boost.Local?
by Lorenzo Caminiti 26 Nov '11

26 Nov '11

Hello all, I will be honest: The fact that some of the people arguing for not including Boost.Local are "active Boost library authors" (Thomas, Joel, and Hartmut) seems to make their opinion weight more than the opinion of others that have also submitted a review for the library. Two questions: 1) Should reviews from "active Boost library authors" carry more weight? (This is /not/ a rhetoric question.) 2) Is there any "active Boost library author" out there that is in favor of including Boost.Local? (If so, please say so by replying to this thread.) Thanks a lot :) --Lorenzo

8 18

Re: [boost] New libraries implementing C++11 features in C++03
by Brent Spillner 25 Nov '11

25 Nov '11

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.

2 2

Re: [boost] [local] Any "active Boost library author" in favor of Boost.Local?
by Andrzej Krzemienski 25 Nov '11

25 Nov '11

> Hello all, > I will be honest: The fact that some of the people arguing for not > including Boost.Local are "active Boost library authors" (Thomas, > Joel, and Hartmut) seems to make their opinion weight more than the > opinion of others that have also submitted a review for the library. > Two questions: > 1) Should reviews from "active Boost library authors" carry more > weight? (This is /not/ a rhetoric question.) Hi Lorenzo. I am /not/ an active Boost library author or maintainer. I will only address the first question. I was asking myself the same question recently, and my answer to it is that their opinions should weigh more than others'. Well, "others" is an ambiguous term; I meant someone like me, who is just a Boost user, and says "I want to have this, and this, and that one". My argument is that Boost as an organization has its goals or status, or spirit (no pun intended). I tried to look for something like "what is our goal" on the Boost site, but I did not find a satisfactory answer. The only thing that I found useful is a section in Scott Meyers's "Effective STL". I am not sure if Boost developers will agree, but he says that Boost was founded in part by people who submitted proposals for Standard Library to the C++ committee that were rejected. Boost was supposed to be the place where these libraries were still to be developed, maintained and widely used, which would give them the grater chance to succeed in the next round of standardization. On the other hand, some existing Boost libraries do not appear (at least in my limited view) to meet this criterion (as well as other criteria mentioned recently). I am thinking about the unit testing framework. Do not get me wrong I am not trying to imply that it shouldn't be there, and in fact this is my preferred unit testing framework for many valid reasons. But I was trying to apply the recently risen acceptance criteria to all Boost libraries that I know, and this example appeared the most interesting. Even though it provides a non-macro alternative it encourages using macros for nearly everything in the "automated version": tests, checks, suites, modules. Even thought there are other free libraries for C++ that are known to provide almost the same functionality without a single macro: http://tut-framework.sourceforge.net/. It does not look like a potential candidate for the inclusion into the standard; there are many unit-testing frameworks out there that do not appear to be any worse. It does not appear to encourage some good coding style (apart from the fact that having good unit tests is a good development style).... Given this lack of clear criteria, active Boost library authors and maintainers should be in the better position to assess if the tacit criteria for library admission are met. Some of them have been with boost since its inception (almost 15 years now). If we think otherwise, we are risking the situation where Boost users that just want some library "in the Boost package" will outnumber the few library developers that have a broader goal in mind, and may not even have time to submit a review because they are busy maintaining their libraries or submitting proposals to ISO Committee. I guess that in case of Boost.Local review, this argument would be stronger if the "active Boost library author" reviewers were not the authors of libraries that /somehow/ overlap with Boost.Local. Thus I believe you are bringing the valid point in trying to engage other Boost library authors, and it would be beneficial, also to the entire Boost community, if someone responded to your question. Regards, &rzej

1 0

Formal Review Schedule Queue
by Ben Robinson 25 Nov '11

25 Nov '11

Currently, there are eight library submissions in the queue, none of which have a review manager or a scheduled review period. What is the process to assign review managers? I realize that the Boost.Local review is still in progress (and quite a lively discussion). :) Ben Robinson, Ph.D.

2 1

[Boost.Local] Review
by Hartmut Kaiser 25 Nov '11

25 Nov '11

This is not a full review, mainly because I have not had the time to devote more than a quick glance over the documentation (which is a good read, btw). Upfront my vote: no, please do not include this library into Boost. My reasons are: a) Boost is a library which has quite some visibility not only for library writers but also for application developers. IMHO, Boost not only has the task of finding new ways for using C++, but it plays the role of evangelizing good programming style, great API design, and thoughtful functionality. Using macros as the sole API of a library to be mainly used by application writers (not library authors) is not a good idea because of all those well know problems related to macros: difficult to debug, error messages are even more difficult to interpret than those generated by TMP, macros are type agnostic and have absolutely no knowledge of C++, etc. b) The proposed library does not add any functionality which couldn't be _easily_ replaced by using existing C++ language features or libraries. This is especially true if we talk about C++11 (which we should, IHMO). c) A very personal reason: code written based on the proposed library for me tends to be an unreadable mess. I have problems to remember, what arguments to the macros means what, when to use additional parenthesis and when not, etc. This is especially true when it comes to using 'default' and 'bind' in the argument list. This just does not 'look right' to me. Regards Hartmut --------------- http://boost-spirit.com http://stellar.cct.lsu.edu

7 20

Re: [boost] [local] Any "active Boost library author" in favor of Boost.Local
by Brian Wood 25 Nov '11

25 Nov '11

Lorenzo Caminiti: > Hello all, > > I will be honest: The fact that some of the people arguing for not > including Boost.Local are "active Boost library authors" (Thomas, > Joel, and Hartmut) seems to make their opinion weight more than the > opinion of others that have also submitted a review for the library. > > Two questions: > 1) Should reviews from "active Boost library authors" carry more > weight? (This is /not/ a rhetoric question.) > 2) Is there any "active Boost library author" out there that is in > favor of including Boost.Local? (If so, please say so by replying to > this thread.) I'm in favor of accepting it. Not because I plan to use it, but think Boost could use the help and you have been learning the ropes. Regardless of the outcome of the review, I like the tenacity you've shown. I'm not a Boost library author. -- Brian Wood Ebenezer Enterprises http://webEbenezer.net <http://webebenezer.net/>

1 0

Error in the getting started guide?
by Philip Bennefall 24 Nov '11

24 Nov '11

I was just looking at the getting started guide on Windows for version 1.48.0 and saw this paragraph: The easiest way to get a copy of Boost is to use an installer. The Boost website version of this Getting Started guide will have undated information on installers as they become available, ..." I'm guessing it should be "updated"? It might confuse new users slightly so I thought I'd mention it. If the list is not the right place for this note, then I apologize. Kind regards, Philip Bennefall

2 1

[lexical_cast] Error casting void* to std::string
by GMan 24 Nov '11

24 Nov '11

I did a search on the mailing list and found nothing, but apologies if I missed it. This bug seems to be new to 1.48. Compiling the following code in MSVC2010: #include <boost/lexical_cast.hpp> #include <string> int main() { void* ptr = 0; boost::lexical_cast<std::string>(ptr); } Results in an error, pointing to line 1738 in boost\lexical_cast.hpp, stating: 'removed_ptr_t': illegal sizeof operand. ('removed_ptr_t' is, however, defined a few lines above.) I see nothing wrong with the code from a C++ point-of-view, so I'm guessing this is another MSVC bug. Is this known? I don't see an immediate permanent workaround. A client-side workaround exists by introducing this small class: struct print_ptr { explicit print_ptr(void* ptr) : mPtr(ptr) {} friend std::ostream& operator<<(std::ostream& sink, print_ptr printPtr) { return sink << printPtr.mPtr; } private: void* mPtr; }; And using: boost::lexical_cast<std::string>(print_ptr(ptr)); -- GMan, Nick Gorski

3 3

Re: [boost] What is boost:
by Brian Wood 24 Nov '11

24 Nov '11

From: Gregory Crosswhite > Perhaps, but could you give us some examples of what you mean to provide a better sense of what you are thinking? Thanks! :-) If a library hasn't had a maintainer for a certain period then it gets removed. If I'm using a library that is close to being removed I'd either have to do something to help maintain it or decide to use another library. I'm OK with it becoming easier to add libraries if it also becomes easier to remove them. -- Brian Wood Ebenezer Enterprises http://webEbenezer.net <http://webebenezer.net/>

3 2

Policy when duplicate code detected
by Ioannis Papadopoulos 24 Nov '11

24 Nov '11

Hi, I was wondering what is the policy when someone finds code that is clearly duplicated or implements the same thing with just different interface? What is the best way to report it? Thanks

2 1

Re: [boost] What is boost:
by Brian Wood 24 Nov '11

24 Nov '11

Lorenzo Caminiti: >On Wed, Nov 23, 2011 at 2:09 PM, Robert Ramey <ramey(a)rrsd.com> wrote: >> >> So I'm more of the view that we let stuff into boost as long at it meets >> quality standards. ?Then let users decide. > > +1 I guess, but is there any way to remove libraries from Boost? I think it almost needs pruning more than it needs more libs. -- Brian Wood Ebenezer Enterprises http://webEbenezer.net

2 1

Re: [boost] [Boost.Local] Review
by Brent Spillner 24 Nov '11

24 Nov '11

On 23 Nov 2011 10:24:53 Leo Goodstadt wrote: >For "acknowledgment" / "acknowledgement": both spellings started out in the >16th c. but the first form historically was found more in the US. Citations >from the 19th and 20th c show that both variants are found on both sides >of the Atlantic (e.g. the short form in the UK in Dickens, Bronte, Macaulay) >though the long form seems to predominate in the 20c only in U.K. >newspapers. I too appreciate the clarification--- guess I didn't understand this quite as well as I thought. In the US, "acknowledgement" does seem to correlate frequently with a casual attitude toward spelling, but it looks like I need to broaden my horizons a bit.

1 0

Re: [boost] [local] Review (and resignation from review assistant)
by Andrzej Krzemienski 23 Nov '11

23 Nov '11

> > Ok, I am not sure if there are no better ways to write it in each variant, > > and I may be biased. I also didn't try to compile the examples. But it > > should give the potential users an overview of options they have. > > Yep. This highlights the verbosity well: > for_each( vec.begin(), vec.end(), if_(empty(_1)) [_1 = "n/a"] ); > vs: > BOOST_CLOSURE_PARAMS( std::string & n ) { > if( n.empty() ) n = "n/a"; > }BOOST_CLOSURE_NAME(replace_empties); > for_each( vec.begin(), vec.end(), replace_empties ); Honestly, my goal was to show an example where Phoenix has limitations and Local could be considered an attractive alternative. Obviously my example failed to do that. I wanted to see how you can call member functions. I can see Phoenix has nice support for container-like operations. But how about changing the rules a bit, and calling an arbitrary member function? for_each( vec.begin(), vec.end(), if_(bind(&SuperLib::SuperString::IsVulgar, arg1)) [arg1 = "unknown" ] ); vs. BOOST_CLOSURE_PARAMS( SuperLib::SuperString & n ) { if( n.isVulgar() ) n = "unknown"; }BOOST_CLOSURE_NAME(replace_vulgar); for_each( vec.begin(), vec.end(), replace_vulgar ); I realize that one can tweak examples to show whatever one wants. But member access does not appear too unusual. This really happened to me that I used a very complicated bind statement where I had to bind some variables and leave some free, pass some by reference, some by value. I thought "it was the right way because this is Boost way", until I realized no-one else in the team knows what that is suppose to mean. Regards, &rzej

2 1

[parameter] increase BOOST_PARAMETER_MAX_ARITY
by Tim Blechmann 23 Nov '11

23 Nov '11

hi, i've been using boost.parameter extensively with boost.heap and now came to a point, that i need to raise BOOST_PARAMETER_MAX_ARITY to at least 7 in order to be able to compile it. i am planning to merge boost.heap into trunk in the next few days, so i wonder, would it be reasonable to increase the default of this value to e.g. 8 (patch attached)? currently, boost.heap defines BOOST_PARAMETER_MAX_ARITY before including boost/parameter.hpp, but this will break, if boost/parameter.hpp is included before the boost.heap headers. it would be great, if the default would be high enough to compile all boost libraries, or could this cause any issues? thanks, tim

1 0

[local] not just "better" error messages (was: Re: New libraries implementing C++11 features in C++03)
by Lorenzo Caminiti 23 Nov '11

23 Nov '11

Note: I've changed the title of the email because this part of the discussion is not related to Boost for C++11 or C++03. On Wed, Nov 23, 2011 at 6:21 AM, Joel de Guzman <joel(a)boost-consulting.com> wrote: > On 11/23/2011 5:53 PM, Lorenzo Caminiti wrote: >>> we should do is push the C++ compiler writers to give us library writers >>> > more power to address the problems such as the often cited deluge of >>> > undecipherable error messages. TMP libraries are ubiquitous in modern C++. >>> > Avoiding them because of the problem of error messages is backwards thinking. >>> > What we should do instead is to find better solutions, not hide the problems. >>> > >>> > This is Boost! > >> How is a library like Boost.Algorithm pushing the limit? It's a very > > How did you arrive at that? I said: > > "what we should do is push the C++ compiler writers to give us library > writers more power to address the problems such as the often cited > deluge of undecipherable error messages." > > Please read that again. You've mixed that with what I said earlier: > > "Keep in mind that Boost has been at the forefront of C++ library > development. It is because of these libraries that push the limits > of C++ that we see the advancement in C++ that we enjoy now in C++11." > > I never said that all libraries in Boost push the limits of C++. I see, yes that is what you wrote for example here "what we should do is push the C++ compiler writers to give us library writers more power to address the problems such as the often cited deluge of undecipherable error messages". I miss read your email, I didn't understand that it was pushing the limits of compilers to give library programmers more control over error detection/reporting. Thanks for the clarification. > All the rest of your reply is irrelevant. Well, no. The following part of my reply is now even more relevant because it repeats that Local is not just about (2) better error messages (your point above about pushing the limit) but also about (1) usual statement syntax for the function body (which every programmer in your team will understand at once). >> the syntax presented there. Proponents of locals have cited error-messages >> generated by the compiler as a justification for Locals. Locals is probably >> a good workaround. But hear me out... > > Nope, not just a good workaround for error-messages. Proponents of > Locals mentioned two (2) main things as advantages. Please let's cite > both of them correctly: > 1) Use statement syntax for function definition. > 2) Compiler error retain their usual meaning for the function definition. > While these two things are related from an library implementation > prospective, they are two different advantages for the library > end-user. > > The politically correct sentence fro the docs: "[Local functions] can > be defined using C++ statement syntax plus eventual compiler errors > follow the usual format of C++ statement errors". > https://svn.boost.org/svn/boost/sandbox/local/libs/local/doc/html/boost_loc… --Lorenzo

1 0

Re: [boost] [Boost.Local] Review
by Leo Goodstadt 23 Nov '11

23 Nov '11

> John Bytheway <jbytheway+boost <at> gmail.com> writes: > > > > On 19/11/11 20:39, Brent Spillner wrote: > > > On Fri, 18 Nov 2011 20:59:26 lorcaminiti wrote: > > >>> The title is spelt wrong (should be Acknowledgements) > > > Actually, "Acknowledgments" is the traditionally correct spelling. > > > There are some dictionaries that accept "Acknowledgement," but this > > > reads as faddish and less literate. A similar word is "judgment"--- > > > both are frequently misspelled even by native speakers. > > BTW, I grew up spelling both as "acknowledgement" and "judgement". Online > sources seem to indicate that in Britain those spellings are the norm while in > the US the 'e' after 'g' is usually dropped. But I was born and raised here in > the US so what gives? Given that my first name is "Geoff" (English spelling) and > not "Jeff" (American spelling) the confusion is readily apparent? This is where the Oxford English Dictionary with all its historical citations comes in handy. For "acknowledgment" / "acknowledgement": both spellings started out in the 16th c. but the first form historically was found more in the US. Citations from the 19th and 20th c show that both variants are found on both sides of the Atlantic (e.g. the short form in the UK in Dickens, Bronte, Macaulay) though the long form seems to predominate in the 20c only in U.K. newspapers. For "judgement" / "judgment": judgement seems slightly more consistent etymologically (with the Old French/Norman "iugement"?). This may be why it seems to be preferred by the OED. However, both forms are equally old, and >80% of the modern citations have the *short* form not the long form, on both sides of the Atlantic. Conclusion: Spell these words however you want! Hope that clears thing up. Leo

3 2

[local] Review
by John Bytheway 23 Nov '11

23 Nov '11

To begin with, my overall opinion: I say yes, Boost.Local should be accepted. > - What is your evaluation of the design? The design is clearly well thought-out. I admire Lorenzo's dedication to discussing his design decisions as thoroughly as possible on the mailing list. I've watched the development of the library with interest, and have been glad of the opportunity to comment along the way. On one specific pleasant surprise: thank you for providing the inline feature to offer your users the chance to choose their optimization trade-offs for themselves, and I'm glad you found a faster alternative to the virtual function trick. However, I still have a few concerns: I question the choice to bind const variables by const value by default, with (as far as I can see) no means to bind them by non-const value. This runs contrary to my instincts in regard to functions in C++ more generally (although I see C++11 lambdas have similar behaviour...). It's not a serious problem, but I would have chosen differently. On binding this: I vote that this_ is a better name than _this. The name is not a placeholder in the sense the term is used in libraries using the leading underscore convention for placeholders. Also, how do your various choices of syntax behave in the context of nested local functions? Consider: void BOOST_LOCAL_FUNCTION_PARAMS(bind this) { void BOOST_LOCAL_FUNCTION_PARAMS(bind this_) { this_->f(); } BOOST_LOCAL_FUNCTION_NAME(g) } BOOST_LOCAL_FUNCTION_NAME(h) If you change the syntax (as I think you were proposing) so that "this_" appears in the first line here in place of "this", then how would the second line behave? I would want it to bind the this pointer for the outer object, not the inner instance of the class that Boost.Local defines for me. You discuss exception specifications for the various objects that can be defined. If this includes noexcept in C++11 (which I imagine it does) then you should mention that. The ability to write noexcept local blocks (which can easily be made to work in C++03 too) might be another motivating feature for local blocks. Furthermore, you should seriously consider whether BOOST_LOCAL_EXIT's function should be declared noexcept by default where possible, since it is in many ways like a destructor. How feasible would it be to allow overload to be used without declaring all the function types. So, your example: boost::local::function::overload< void (const std::string&) , void (const double&) // Overload 1st param type. , void (const double&, const char*) // Overload giving default param. , int (int, int) // Overload giving 2 params (from function pointer). > print(print_string, print_double, print_double, print_add); might be written instead: auto print = make_overload(print_string, print_double, print_double, print_add); (with suitable use of BOOST_AUTO for C++03). I guess this only works if all the functors passed are monomorphic and expose (or could be made to expose) their argument types, but that covers function pointers, boost::function objects, and Boost.Local functions, which is a fairly wide applicability. Writing the above inspires me to ask: Do Boost.Local functions expose their argument types and return types at compile time? If there is a widely accepted way for monomorphic functors to do so, then they should. If there is no such widely accepted way, then one should be created, but that's probably not a job for you right now :). In a similar vein, as I was pondering potential uses of the overload feature, I wondered whether it could be used to write a visitor for Boost.Variant. I suspect that it could not, because such a visitor must declare its return type in a manner tat the overload object will not. It would be nice if that could be made to work. Can you think of a good way? > - What is your evaluation of the implementation? I have not looked at the implementation, but I have followed the discussions and examined some earlier versions of it. Any problems I noted before have, I think, as far as reasonable, been resolved. However, I would like to ask: on the overloading features: It looks like boost::local::function::overload could be written with variadic templates where available and thereby avoid the maximum arities in the configuration macros (and be much simpler and faster to compile). Have you done so? > - What is your evaluation of the documentation? The documentation is very good. Allow me to praise in particular the detailed rationales. A few niggles: * General You have various examples which write to stdout. I realise it's fairly clear, but it might be nice to drive the point home by explicitly showing what the expected output of these programs is. Alternatively, use asserts instead of writing to stdout. * Introduction "the object this can be bound (eventually by constant value" - I don't understand "eventually". * Tutorial The code "if (size && nums) delete[] nums;" perpetuates the myth that one should not delete NULL pointers. Please don't do that. Go ahead and delete[] nums even if it's NULL. "The maximum number of parameters that can be passed to a local function (excluding eventual bound variables)" - I don't understand "eventual". You have the "Important" warning about registering types with Boost.Typeof. I presume this applies only to compilers without typeof support. If so you should probably make this a little more clear. * Advanced Topics Does the existence of the recursive "keyword" mean that a local function cannot be named recursive? If so, you should mention that in passing. "Compilers have not been observed to be able to inline recursive local function calls (not even when the recursive local function is also declared inlined)." - do you mean "not only when"? "C++03 local classes cannot be templates." - this is also true in C++11, right? * Macro BOOST_LOCAL_FUNCTION_NAME "The local function name can be prefixed by the "keyword" inline to declare the local function inlined or by the "keyword" recursive to declare the local function recursive" - can both "keywords" be used? This wording suggests to me that they cannot. If they can, then I suggest changing "or" to "and/or". If not, this should be made clearer. * Macro BOOST_IDENTITY_TYPE I don't understand the "Warning" at the bottom; can you expand? * Macro BOOST_IDENTITY_VALUE The implementation provided on this page doesn't look like it could possibly work. Surely the type T cannot be deduced in a call to identity_value without template arguments? * Examples Should a chunk of the variadic macro version of the Emulating D's Scope Guards" example be commented out? Surely not... * Appendix: Alternatives In the benchmarking note, you say "For all tested compilers, this function pointer prevents the compiler optimization algorithms from inlining the local function calls.". You might want to mention that it is in theory possible for the compiler to inline it, and some other compilers or future versions may do so. (Or you may not, if you think it sounds too weasely or hypothetical) I don't see any of the benchmarking images. Should I? I'm experiencing some very odd symptoms from my graphics card since I first tried to view them, so it may well be a problem at my end. * Release Notes Why is there a "TODO" at the bottom? * Acknowledgments The title is spelt wrong (should be Acknowledgements) Thanks for the thanks :). > - What is your evaluation of the potential usefulness of the > library? Personally, my C++ development has mostly moved to C++11, and I do not expect to have reason to want this functionality, settling for lambdas instead. However, I might yet be in a situation where I am forced to use C++03, and I'm sure many others will be in just that situation for a while yet. In that context, I think this library has significant potential usefulness. Certainly there have been times when I have wanted something like it. Much as I admire Phoenix, I think there will always be circumstances where Boost.Local will be an easier, more useful and more readable alternative. As part of your struggle to motivate the utility of const binding in local blocks, you might want to mention in the documentation the possibility of using it to assure the behaviour of code received in macro parameters as (I imagine) you are doing in Boost.Contract. > - Did you try to use the library? With what compiler? Did you have > any problems? I did not try to use this version, but I have experimented briefly with previous versions, with gcc, clang, and icc (IIRC). I had no problems serious enough that I recall them. > - How much effort did you put into your evaluation? A glance? A > quick reading? In-depth study? I read the documentation with moderate care. Also, I have been following the development on the list over recent months. > - Are you knowledgeable about the problem domain? I have faced problems that this library would have solved neatly, and I discussed some implementation details with Lorenzo at times. > Please also consider the following issues and proposals specific to > Boost.Local. Your opinion is welcome on any or all of these. > > - Boost.Local's local exits provide the same functionality (and then > some) as Boost.ScopeExit. Does this duplication of functionality > need to be dealt with, and if so, how? Since I think the Boost.Local version is strictly superior to the Boost.ScopeExit version, I would suggest that the ScopeExit version be deprecated (but not removed, unless it is proving a significant maintenance burden). On the other hand, ScopeExit is a good name for that functionality, and so it is well worth seriously considering upgrading that library and not including the functionality in this new place. Should that be possible to achieve smoothly, it might be a better choice. > - Lorenzo is proposing to add boost::local::function::overload to > Boost.Function as boost::function::overload. Indeed it sounds reasonable to put it there. If so, it should be implemented with due regard for the possibilities of C++11 features (variadic macros, perfect forwarding) as mentioned above. > - Lorenzo is proposing to add BOOST_IDENTITY_TYPE to boost/utility. This seems reasonable. > - Likewise, Lorenzo is proposing to add BOOST_IDENTITY_VALUE to > boost/utility. I am struggling to see any situation where BOOST_IDENTITY_VALUE is necessary. Can you provide one? When will simply wrapping the expression in parentheses not suffice? Is it because you might be in a preprocessing context that requires an alphanumeric initial character? That's all for my review. Thanks to Lorenzo, Jeffrey, Gregory, and good luck! John Bytheway

2 2

[local] implementation using C++11 lambdas
by Lorenzo Caminiti 22 Nov '11

22 Nov '11

On Tue, Nov 22, 2011 at 3:32 PM, Jeffrey Lee Hellrung, Jr. <jeffrey.hellrung(a)gmail.com> wrote: > On Tue, Nov 22, 2011 at 11:39 AM, Vicente J. Botet Escriba < >> I think that there is a difference between Boost.Local and Boost.Move. >> Boost.Move provides an emulation of a C++11 feature on compilers that don't >> provides this feature. >> >> Boost.Local provides an emulation of a feature that has not been accepted >> to c++11. >> Note that I'm not saying that Boost.Local should not be accepted, but I'm >> sure that things will be different if Boost.Local provided an emulation for >> c++11 lambdas, that is, if in c++11 compilers the macros could be able to >> generate C++11 lambdas. >> > > Well, named lambdas are basically the same as local functions, no? What I > really mean is, Local provides an imperfect emulation of C++11 lambdas, but > by the same token, Boost.Move provides an imperfect emulation of rvalue > references. > > The question I have for the Boosters that don't like the local function >> approach is if they will accept as a good approximation of the following >> use of a lambda expression >> >> std::sort(x, x + N, [](float a, float b) {return std::abs(a) < >> std::abs(b); }); >> >> the storage on a temporary as in >> >> auto cmp = [](float a, float b) {return std::abs(a) < std::abs(b); }; >> std::sort(x, x + N, cmp); >> >> If Lorenzo would be able to define a macro that could be used to replace >> the named lambda as in >> >> BOOST_AUTO_LAMBDA(cmp, float a, float b, bool, ({return std::abs(a) < >> std::abs(b); })); Yes, this should be trivial but what would be its value? Note that on C++11 compilers the existing Boost.Local local function implementation has compile and run time performance comparable to the ones of C++11 lambdas: https://svn.boost.org/svn/boost/sandbox/local/libs/local/doc/html/boost_loc… Therefore, why would you care if the local function is internally implemented using a C++11 lambda (macro above) or a local struct (macro below) given that there's no significant performance impact? bool BOOST_LOCAL_FUNCTION(float a, float b) { return std::abs(a) < std::abs(b); } BOOST_LOCAL_FUNCTIONS_END(cmp) (Also this has better error messages because the body is out of the macros so the compiler line numbers retain their usual meaning.) In summary, the current Boost.Local implementation already performs as well as C++11 lambdas on C++11 compilers and it also works on C++03 compilers. Therefore the current Boost.Local implementation already allows you to portably program named lambdas (but not lambdas because local functions cannot be defined within expressions) at no performance cost with respect to C++11 lambdas. >> std::sort(x, x + N, cmp); >> >> could you consider that this is promoting good usage of C++11 features on >> compilers that don't provide them and be a good candidate for a Boost >> library? >> > > This is drifting away from my intended thread topic a little bit. But, > nonetheless... Isn't this latter syntax trivial to implement with the > present macros provided by Local? And, as an aside, the significant Yes, it should be trivial. > disadvantage to the above versus splitting the declaration over 2 macro > instantiations is that compiler error messages from the body of the > function would be less informative (essentially missing line numbers). Oh, Yes, all compiler errors would have the same line number (significantly) reducing their informative value. > and I don't know if you can reliably do your BOOST_AUTO_LAMBDA syntax > without variadic macros. That said...it may be convenient to provide > something like that the BOOST_AUTO_LAMBDA macro for simple and small named > lambdas with no unparenthesized commas. HTH, --Lorenzo

1 0

Boost libraries for 'TR2'
by Vicente J. Botet Escriba 22 Nov '11

22 Nov '11

Hi, just out of curiosity, which Boost libraries could we expect to be proposed for the TR2 (or whatever the new C++ run for new libraries will be called)? Who is working on a concrete proposal? Which libraries would you like to be proposed? I would like myself to see between others: Accumulators, Any, Asio, DynamicBitset, Filesystem, Format, Fusion, Interprocess, Intrusive, Mpl, Optional, PointerContainer, ProgramOptions, Proto, Range, Signals, Thread (shared locks), Units and Variant. Best, Vicente

7 11

Re: [boost] [Boost.Local] Review
by Brent Spillner 22 Nov '11

22 Nov '11

On Fri, 18 Nov 2011 20:59:26 lorcaminiti wrote: >> "the object this can be bound (eventually by constant value" - I don't >> understand "eventually". > > It means that you can either "bind this" or "const bind this" (the > second binds the object as constant within the local functions even if > the object is non-const in the enclosing member function). I will make > this text more clear. The issue (both places) is the word "eventually." This is a false cognate with Spanish, Dutch, and probably other languages; in English, "eventually" means only "shall happen at some time in the future." In the rewrite, you probably want to use "optionally" or "possibly" instead. >> * Acknowledgments >> >> The title is spelt wrong (should be Acknowledgements) > > OK. Actually, "Acknowledgments" is the traditionally correct spelling. There are some dictionaries that accept "Acknowledgement," but this reads as faddish and less literate. A similar word is "judgment"--- both are frequently misspelled even by native speakers. Isn't English fun?

5 4

Ok to add new folder?
by Antony Polukhin 22 Nov '11

22 Nov '11

There is already a folder trunk/libs/conversion where lies Boost.Lexical_cast tests. I`d love to split lexical_cast.hpp onto multiple files (old deprecated version, modern version, common headers for two versions...) and put those files into trunk/boost/conversion. Ok to add folder trunk/boost/conversion ? Best regards, Antony Polukhin

2 1

[functional] [variant] Hash patch for variant
by Antony Polukhin 22 Nov '11

22 Nov '11

Header and tests in attachments. Passes tests on GCC-4.4 and VC10. OK to commit to trunk and include header file from boost/functional/hash/extensions.hpp ? Best regards, Antony Polukhin

2 3

Re: [boost] [optional] std::tr2::optional
by Andrzej Krzemienski 22 Nov '11

22 Nov '11

> boost::optional can be used for many purposes. One of these (and I had to > use optional like that) is to make classes that provide RAII-like interface > (noncopyable, nonmoveable) usable in contexts where I need to use two-phase > initialization or to release the resource before the end of the scope > (subject to some runtime condition) -- all that in order to have a resource > acquired for as short span of time as possible. > I would be forced to do that for std::lock_guard if the library did not > provide a second template std::unique_lock. But not every library provides > two interfaces for almost the same thing, and this is arguably an > unnecessary redundancy for an interface. optional<RAII> as described above > is a generic tool for transforming types that implement 'scoped ownership' > into types that implement 'unique ownership' of a resource. I think I went too far with this story. Although you can implement a two-phase initialization and cleanup, you cannot provide a full 'unique ownership' semantics with boost::optional for 'scoped' types, because there is no way to implement a move constructor for types that do not support either a move constructor or swap. Regards, &rzej

1 0

[local] Review
by Thomas Heller 22 Nov '11

22 Nov '11

Hi all, Following is my Review of the upcoming Boost.Local library. I will as others split my review into the three parts that make up this library: local functions, local blocks, scoped exit. Let me first start with some general comments. I personally find the decision to support two syntaxes not a good path to follow. While I understand the rationale behind it, and the desire to have the variadic macro version, having both might become a maintenance nightmare. Also, reading through the documentation, most of the time is spent on explaining, the difference between the two syntaxes. Why not just stick with one and concentrate on the functionality? Additionally, despite the introductory motivating statement ("Local functions are a form of information hiding and are useful for dividing procedural tasks into subtasks which are only meaningful locally, avoiding cluttering other parts of the program with functions, variables, etc unrelated to those parts.") I can not see that this library solves this appropriately. I personally think that exposing macros as the interface to program with the library does not lead to a nice and clean design of ones code. Boost.Local is very different from other heavily macro based libraries like Boost.Parameter. It is different, because I would consider Boost.Local not as a infrastructure library but as a library for end users. This being said, i would not like to see application code cluttered with overly verbose calls to macros. As boost is trying to not only push the boundaries of C++ it should also try to set examples of best C++ practice. I would not consider Macro calls to interface with a library not good practice. Local Functions: From the tutorial section on Local Functions: "Local functions are defined using the following macros (see the Reference section) from within a declarative context (this is a limitation with respect to C++11 lambda functions which can instead be declared within expressions):" Right, to have the lambdas in a "declarative context" use auto f = [...](...){...} The default parameter syntax is confusing, it looks like it is a completely new parameter, and not belonging to the previous argument. This gets confusing once you have more than one parameter with a default parameter. The WITH_DEFAULT macro should be the default, as it clearly states the relationship of the default value to the parameter. I would consider binding variables from the enclosing scope one of the major weak points of Boost.Local. The need to binding those variables is obvious. However, how it is done clutters the arguments list of the BOOST_LOCAL_FUNCTION_PARAMS to an extend that it is not immediately clear what the arity of the local function is. It would make things clearer to have something like: BOOST_LOCAL_FUNCTION_PARAMS(...) BOOST_LOCAL_FUNCTION_CAPTURE(...) Additionally as binding is probably the right term to use here, it might confuse people with the already existing solutions of the various bind implementations. WRT to your note in the documentation that C++11 can not bind const reference. I suggest the following workaround: int i = 0; auto f = [&](){ auto const & icr = i; ... }; I agree that this and _this should be used always, instead of having both _this and this. On other notes, Lorenzo already clarified the defect in the library that it can't really be used as a closure. This would have been my next point. All in all the documentation is very accurate and in good shape. Additionally i played around with this specific part of the library a little bit in order to see how i can break it. TBH, I didn't (and still don't) trust the macros to do the right thing always, my knowledge of the PP isn't good enough to judge that particular part of the implementation. However, by deliberately trying to break the breaks (putting typos in the variables, omitting commas etc.) the error messages are of course very arcane, and you have to know exactly where and what part of the macros involved failed and why. Of course, these error message can be deciphered very easily once you have enough experience with that library. But i would argue that this is the case for any other (TMP based) library. Which brings me to my next point. I think that Boost.Local does not fulfill its own purpose. While it is of course true that errors in the function bodies are written in "usual C++" the surrounding macros are, IMHO, just cluttering the code. The points Lorenzo makes in the motivational section are not met. I would argue that most of the times, namespaces and classes are good enough, and such a macro syntax should be avoided. For everything else, there already exist a couple of solutions (Boost.Bind, Boost.Lambda and Boost.Phoenix). I would like to see improvements in ease of use in these libraries instead of advertising a completely macro based solutions. Local Blocks: I can't see the value in that one. The example in the documentation doesn't help either, as those things are easily detected by any modern compiler, with the appropriate warning levels (ok, not in the assert case, but for other boolean contexts at least gcc does). Local Exit: Why do we need two libraries doing the exact same thing with neither of the adding any functionality. I suggest to improve ScopedExit instead. In the alternatives section, which version of Phoenix do you use? Now to the usual questions: > - What is your evaluation of the design? I think the design is not what can be considered Modern C++. However, in the context of what the author tried to achieve, he did a good job. > - What is your evaluation of the implementation? The implementation looks solid! > - What is your evaluation of the documentation? The documentation is very good! > - What is your evaluation of the potential usefulness of the library? The potential usefulness of the library is out of question, that is why C++11 now has lambdas, and libraries like Bind, Lambda and Phoenix exist. However, I do not believe that Local adds any value to the existing solution of the described problems. > - Did you try to use the library? With what compiler? Did you have > any problems? Yes. gcc 4.6.2. no problems. > - How much effort did you put into your evaluation? A glance? A > quick reading? In-depth study? Reading of the documentation. Looking briefly at the implementation. > - Are you knowledgeable about the problem domain? Yes. I am the author of Phoenix V3. I vote to not include the library into boost. Regards, Thomas

8 42

Re: [boost] BGL CSR Format (logarithmic edge search)
by Ryan Lichtenwalter 21 Nov '11

21 Nov '11

> Hello, > > According to: > > http://www.boost.org/doc/libs/1_48_0/libs/graph/doc/compressed_sparse_row.h… > > [Edge search] requires linear time in the number of edges outgoing from u. > > The purpose of the CSR format is to support highly efficient computation > with minimal memory requirements at the cost of mutability and additional > time in construction. Is there a reason, then, that the adjacencies are > stored unsorted within their vertex ranges? With minimal additional time > during construction, edge access could be reduced to logarithmic time in > the number of edges outgoing from u without sacrificing any functionality > elsewhere that I can determine. > > Can somebody explain this design decision to me? If there is no > explanation, does anybody have plans to adjust the representation? I would > probably be willing to contribute an adjusted representation if nobody else > has plans to do so. The edges from each vertex used to be sorted, but that was changed when linear-time graph construction was introduced. One problem is that the standard sorting routines cannot sort corresponding ranges of elements (such as edge targets and properties); also, sorting edges increases the time complexity of the graph construction algorithm. Note that the CSR constructors that do sorting, except for the in-place versions, apply stable sorts to the edges you input, so you could give it a sorted list of edges and then write a logarithmic-time search routine using out_edges(). -- Jeremiah Willcock Hi, Thanks for your response. I'm sorry to hear about the move away from sorted adjacencies. I'm not sure if this is open for discussion, but I'd like to offer my two cents. The construction cost (of sorting) is minimal, especially in sparse networks for which the compressed sparse row format is specifically targeted where it is essentially asymptotically constant-time unless the degree distribution is highly skewed. On the other hand, certain aspects of link prediction, subgraph counting, and any algorithm that requires neighbor set intersections will benefit greatly from the ordering. I actually rolled exactly the solution you suggested for my own needs. Thank you so much. Ryan Lichtenwalter

1 0

Re: [boost] [optional] std::tr2::optional
by Andrzej Krzemienski 21 Nov '11

21 Nov '11

> > Interesting. It looks like optional can be seen as a special container with > > the maximum size of 1, and then functions like clear() or empty() come as > > natural. On the other hand it can be seen as a pointer-like entity with > > value semantics, and then functions like reset() and literal nullptr come > > as natural. > > Ok, I have no strong preference between reset() or clear() for making the > optional empty. However, a explicit empty() member would be useful anyway. > class MyClass > { > optional< int > m_x; > public: > bool has_x() const { return !m_x.empty(); } > }; > With the current interface I should have written has_x() in a more obscure > way, like !!m_x or m_x.get_ptr() != NULL. > > I withdraw my suggestion to use nullptr. Function reset() would be a better > > choice. I also find reset() preferable to clear() because reset can be > > extended to accept parameters and the name does not become confusing; > > similarly to unique_ptr::reset(). > I think, providing the reset() member with construction semantic is not a good > idea because it would make imposible in-place default construction. There > should be another method that would handle construction. In another post I > suggested assign() but I'm happy if someone comes up with a better name. I managed to come up with the following interface for initializing and un-initializing. My goal was also to not introduce in-place factories. template< typename... Args > optional( tr2::in_place_t, Args &&... args ) noexcept( noexcept(T{std::forward<Args>(args)...}) ) the first parameter is a /tag/, much like std::piecewise_construct for pairs. We use it like this: tr2::optional<W> { tr2::in_place, i, str, 1, &g }; The tag indicates that we request an 'in place' initialization of W with remaining arguments.Next functions are more natural: template< typename... Args > void initialize( Args &&... args ) noexcept( noexcept(T{std::forward<Args>(args)...}) ) // for deferred initialization. void uninitialize() noexcept // so that it spells similar to 'initialize' bool is_initialized() const noexcept // as in boost Regards, &rzej

3 2

BGL CSR Format (logarithmic edge search)
by Ryan Lichtenwalter 21 Nov '11

21 Nov '11

Hello, According to: http://www.boost.org/doc/libs/1_48_0/libs/graph/doc/compressed_sparse_row.h… [Edge search] requires linear time in the number of edges outgoing from u. The purpose of the CSR format is to support highly efficient computation with minimal memory requirements at the cost of mutability and additional time in construction. Is there a reason, then, that the adjacencies are stored unsorted within their vertex ranges? With minimal additional time during construction, edge access could be reduced to logarithmic time in the number of edges outgoing from u without sacrificing any functionality elsewhere that I can determine. Can somebody explain this design decision to me? If there is no explanation, does anybody have plans to adjust the representation? I would probably be willing to contribute an adjusted representation if nobody else has plans to do so. Thanks! Ryan Lichtenwalter

2 1

Re: [boost] [optional] std::tr2::optional
by Andrzej Krzemienski 21 Nov '11

21 Nov '11

> > Also, if someone likes the assignment-of-"none" syntax, in C++11 there will > > be a similar syntax available: > > std::tr2::optional<T> op = {}; > > op = {}; > Wouldn't that be confusing with creating a filled optional with the value > constructed with empty initialization list? If there is assignment-of-none > syntax, it should probably be more explicit, pretty much like the current > "none" keyword. I see your point. But note that this confusing syntax will still be available (and is available today on compilers that support the new initialization syntax) even if we have "none" keyword. This is just the new way of requesting value-initialization (default constructor). Personally, I have doubts about introducing entity "none". There would be too many ways of indicating the null-state for different types. You could look at nullptr as a special pointer with special value; but you could also think of it as a keyword for indicating null-state: a stet of not having any meaningful value. Pointers represent addresses: they can either represent a valid address or not-an-address. Now for optionals we will have none for not-a-value, even though it is almost the same concept. I was thinking also about null_value or nullval. But they appear even more confusing than an already familiar "none". I am not English speaker, so I cannot be positive about it, but does "none" fit logically into the context? Is "nothing" or "naught" more suitable, gramatically? Regards, &rzej

1 0

Re: [boost] [local] Review (and resignation from review assistant)
by Andrzej Krzemienski 21 Nov '11

21 Nov '11

> > - What is your evaluation of the design? > The library is very well designed. The function declaration syntax looks a little foreign at first, but it is very easy to get used to. Furthermore, error messages are usually able to point you to what you did wrong. The fact that you can write the body of the function in plain C++ code is a major advantage of this library. Some have referred to Boost.Bind, Boost.Lambda and Boost.Phoenix as essentially being equivalent to this library, but in none of those libraries can you express the body of your function in plain C++; one advantage of this is that errors in your code result in normal C++ error messages rather than cryptic error messages. Lorenzo, given this comment by Greg, I do have one more suggestion for documentation (or did someone already say it?). Given the heated discussion of whether Boost.Bind, Boost.Lambda and Boost.Phoenix are sufficient to render Boost.Local unnecessary, perhaps it would be worth to provide a comparison of how my code (not too trivial, and not too complex) would look in either case. For instance: With C++11 lambdas: for_each( vec.begin(), vec.end(), []( std::string & n ){ if(n.empty()) n = "n/a";} ); With Boost.Lambda + Boost.Bind: for_each( vec.begin(), vec.end(), if_then(boost::bind(&std::string::empty, _1), _1 = "n/a") ); With Phoenix: using boost::phoenix::arg_names::arg1; using boost::phoenix::if_; using boost::phoenix::bind; // right? for_each( vec.begin(), vec.end(), if_(bind(&std::string::empty, arg1)) [ arg1 = "n/a" ] ); With Boost.Local (Boost.Closure): BOOST_CLOSURE_PARAMS( std::string & n ) { if( n.empty() ) n = "n/a"; }BOOST_CLOSURE_NAME(replace_empties); for_each( vec.begin(), vec.end(), replace_empties ); Ok, I am not sure if there are no better ways to write it in each variant, and I may be biased. I also didn't try to compile the examples. But it should give the potential users an overview of options they have. Regards, &rzej

4 4

Boost CRC maintainer (Daryle Walker) missing in action?
by Olaf van der Spek 21 Nov '11

21 Nov '11

Hi, It looks like the Boost CRC maintainer (Daryle Walker) is missing in action? No response to tickets from the past 3 years. What's the procedure in this case? https://svn.boost.org/trac/boost/ticket/2492 https://svn.boost.org/trac/boost/query?component=crc&col=id&col=summary&col… Greetings, -- Olaf

1 3

Re: [boost] Boost.Local Review (Nov 10, 2011 to Nov 19, 2011)
by Andrzej Krzemienski 21 Nov '11

21 Nov '11

> Do you have any preference? > FUNCTION or CLOSURE? > And also a), b1), b2), c) or d)? > (Or something else...) Hi Lorenzo, Now that I have better understood your library, my personal preference goes towards "closure". The reason for that is: 1. "Closure" better reflects the nature of your library: you provide a tool for defining closures: something more than functions, and something less than lambda expressions. 2. This may make the learning of the library easier. If I know I am dealing with closures I already expect binding functionality; there will be less questions like "what is this 'bind' and what does it actually do?" 3. It may be a marketing bonus "closure" sounds (IMO) more attractive than "function". How about Boost.Closure library? "Local" may not even be necessary, because "closure" somehow implies locality. (you do not need a global closure, because global function will do). Regards, &rzej

3 6

Fw: [asio] multicast.
by John Maddock 21 Nov '11

21 Nov '11

Message forwarded from original sender: ~~~~~ Hi I am trying to join multicast group via _VPN_, this means that I cannot see listen-address in ipconfig actually Could I please me explain how should I connect in this case? I am using multicast-reciever sample. http://www.boost.org/doc/libs/1_41_0/doc/html/boost_asio/example/multicast/… with port 9023, listen 172.20.200.42, multicast 239.192.112.3 #include <iostream> #include <string> #include <boost/asio.hpp> #include "boost/bind.hpp" const short multicast_port = 9023; class receiver { public: receiver(boost::asio::io_service& io_service, const boost::asio::ip::address& listen_address, const boost::asio::ip::address& multicast_address) : socket_(io_service) { try{ // Create the socket so that multiple may be bound to the same address. boost::asio::ip::udp::endpoint listen_endpoint( boost::asio::ip::address::from_string("0.0.0.0"), multicast_port); //boost::asio::ip::udp::endpoint listen_endpoint( // listen_address, multicast_port);//if I use listen_address instead of 0.0.0.0, there is an error in socket_.bind(listen_endpoint); socket_.open(listen_endpoint.protocol()); socket_.set_option(boost::asio::ip::udp::socket::reuse_address(true)); socket_.bind(listen_endpoint); // Join the multicast group. socket_.set_option( boost::asio::ip::multicast::join_group(multicast_address)); socket_.async_receive_from( boost::asio::buffer(data_, max_length), sender_endpoint_, boost::bind(&receiver::handle_receive_from, this, boost::asio::placeholders::error, boost::asio::placeholders::bytes_transferred)); } catch (std::exception& e) { std::cerr << "Exception: " << e.what() << "\n"; } } void handle_receive_from(const boost::system::error_code& error, size_t bytes_recvd) { if (!error) { std::cout.write(data_, bytes_recvd); std::cout << std::endl; socket_.async_receive_from( boost::asio::buffer(data_, max_length), sender_endpoint_, boost::bind(&receiver::handle_receive_from, this, boost::asio::placeholders::error, boost::asio::placeholders::bytes_transferred)); } } private: boost::asio::ip::udp::socket socket_; boost::asio::ip::udp::endpoint sender_endpoint_; enum { max_length = 1024 }; char data_[max_length]; }; int main(int argc, char* argv[]) { try { std::string list = "172.20.200.42"; std::string mt = "239.192.112.3"; boost::asio::io_service io_service; receiver r(io_service, boost::asio::ip::address::from_string(list), boost::asio::ip::address::from_string(mt)); io_service.run(); } catch (std::exception& e) { std::cerr << "Exception: " << e.what() << "\n"; } return 0; } //===================================== But with native c++ I can obtain data: #include <winsock2.h> #include <Ws2tcpip.h> #include <mswsock.h> #include <stdio.h> #include <stdlib.h> #include <iostream> using namespace std; #pragma comment(lib, "Ws2_32.lib") int main(){ WSAData data; WSAStartup( MAKEWORD( 2, 2 ), &data ); int sd = socket(AF_INET,SOCK_DGRAM,IPPROTO_UDP); sockaddr_in Sender; int SenderAddrSize = sizeof( Sender ); struct sockaddr_in binda; char *arg1 = new char[100]; char *arg2 = new char[100]; char *arg3 = new char[100]; arg1 = "239.192.112.3"; arg2 = "172.20.200.42"; arg3 = "9023"; binda.sin_family = AF_INET; binda.sin_port = htons( atoi(arg3)); binda.sin_addr.s_addr = htonl(INADDR_ANY); bind(sd,(struct sockaddr*)&binda, sizeof(binda)); struct ip_mreq_source imr; imr.imr_multiaddr.s_addr = inet_addr(arg1); imr.imr_sourceaddr.s_addr = inet_addr(arg2); imr.imr_interface.s_addr = INADDR_ANY; setsockopt(sd, IPPROTO_IP, IP_ADD_SOURCE_MEMBERSHIP, (char *) &imr, sizeof(imr)); char buf[65536]; while(1) { int res=recvfrom(sd,(char*)buf,sizeof(buf),0, (SOCKADDR *)& Sender, &SenderAddrSize); printf(buf); } //WORKS } //===================================== I cannot realize what is the difference in these two samples, Could you please tell me in which way should I use boost library to obtain data in this case? Thanks in advance, -- С уважением, Василий.

1 0

[local] Review (and resignation from review assistant)
by Gregory Crosswhite 21 Nov '11

21 Nov '11

Hey everyone, The discussion on the mailing list has caused me to realize that I have sufficient passion for the Local library that it is difficult for me to stay neutral, so I will be recusing myself from my position as Review Assistant for this library. (I have learned that should I decide to help out again in the future in this role for another review, I will make sure that it is for a library that I don't feel strongly about either way!) On the other hand, this means that there is no longer any reason not to post a review of this library. I have been a fan of this library for a long time because for me it solved the problem of having a nice way to write (pseudo-)closures in C++03 without having to write and maintain a lot of pointless boilerplate code, and without having to use a completely foreign syntax that I could never seem to get to work. Here is my review of it. > - What is your evaluation of the design? The library is very well designed. The function declaration syntax looks a little foreign at first, but it is very easy to get used to. Furthermore, error messages are usually able to point you to what you did wrong. The fact that you can write the body of the function in plain C++ code is a major advantage of this library. Some have referred to Boost.Bind, Boost.Lambda and Boost.Phoenix as essentially being equivalent to this library, but in none of those libraries can you express the body of your function in plain C++; one advantage of this is that errors in your code result in normal C++ error messages rather than cryptic error messages. It is also clear reading through the documentation that Lorenzo has put a great deal of thought into possible use cases of his library; there are a great number of features which most users might never need to use but which are available for those times when they are completely necessary --- such as explicitly providing types of bound parameters, and marking functions inline --- and they are provided in such a way that when they aren't needed they introduce no additional overhead to the syntax. > - What is your evaluation of the implementation? I am not familiar enough with preprocessor programming to be able to make a fully qualified statement on this. However, it looks reasonable based on the Implementation appendix. The virtual function call is a shame as, if I recall correctly, it can make Boost.Local slower than Boost.Phoenix when the compiler is not smart enough to optimize it into a direct call, but Lorenzo has put so much time and expertise into the design of this library that I doubt it is possible to improve on this while maintaining compatibility with C++03. For me this part of the overhead is not a big deal because I primarily have been using Boost.Local in test suites where the difference in performance does not matter. > - What is your evaluation of the documentation? The documentation is some of the best well written I have seen for a Boost library. It does a good job both explaining how the library works, providing a reference for remembering how the syntax works, and explaining why the library was designed the way that it does. As I have told Lorenzo in a separate e-mail, I do have a minor criticism of the Tutorial section: the ordering of the first four sections is probably not what typical user reading it the first time would want because it puts the most important and essential feature, variable binding, after two features, default and empty argument features, which are nice to have but are not likely to be needed in typical usage, especially considering that a first-time user is most likely just looking for a convenient way to create a simple (pseudo-)closure in C++03. Thus, I suggest the following ordering: "Local Functions" "Variable Binding" "Default Parameters" "Empty Parameters" This way a typical user, who will only care about writing a function that binds a few local variables, will be able to get started immediately after reading the second section rather than first having to wade through two sections describing features that they are unlikely to care about right away. The rationale for putting "Default Parameters" before "Empty Parameters" is that a typical user is very unlikely to need to know how to call the macro with no arguments because there are few use cases where a typical user won't want to bind *anything* from the local environment (since most of the time this means that they won't be thinking in terms of local functions in the first place), so they are less likely to care about how to do this than they are about how to specify default parameters. > - What is your evaluation of the potential usefulness of the library? This library is very useful for people who want to use much of the functionality of C++11 lambdas on C++03 compilers, as I can say from personal experience in using it. As I have said before, the existence of Boost.Bind, Boost.Lambda and Boost.Phoenix do not reduce the utility of this library. They do have a large advantage over Boost.Local of being succinct, which is why I often prefer them over Boost.Local when it is easy to do so. However, because they require to you learn completely new syntax for *all* of the code in the function body, and because they make use of heavy metatemplate programming that results in absolutely horrendous error message that do not give you a clue where they are wrong, for anything non-trivial Boost.Local is hands-down *far* easier to use because you can use plain C++ statement syntax which results in plain C++ error message when you get something wrong. Put another way, Boost.Bind, Boost.Lambda and Boost.Phoenix are complementary to rather than competitors of Boost.Local. > - Did you try to use the library? With what compiler? Did you have any > problems? I have used the library extensively in my own codes, though most often in test suites. I have used them on OSX with GCC 4.2, and on Linux with (if I recall correctly) GCC 4.3 and 4.4. > - How much effort did you put into your evaluation? A glance? A quick > reading? In-depth study? I have become accustomed to using the library on a regular basis and hence my evaluation is written based on my personal experience with it. > Please state clearly whether you think this library should be accepted as a Boost library. Definite yes. Cheers, Greg

2 1

[interprocess] Named types ( mutexes, semaphores etc.) and Windows 7
by Edward Diener 20 Nov '11

20 Nov '11

Under Windows 7 fior named types to be global, the name of the type needs to be prefixed by the string "Global\" Is this being done in the interprocess library for Windows 7 ?

2 1

[fusion] view gcc 4.6
by Karsten Ahnert 20 Nov '11

20 Nov '11

Hi, the following code does not compile with gcc 4.6.1: #include <boost/fusion/view.hpp> int main( int argc , char ** argv ) { return 0; } It produces errors like this: $> g++-4.6 -I$BOOST_ROOT test_fusion_view.cpp ... ... In file included from /home/karsten/boost/boost_1_47_0/boost/preprocessor/iteration/detail/iter/forward1.hpp:92:0, from /home/karsten/boost/boost_1_47_0/boost/fusion/view/nview/detail/nview_impl.hpp:40, from /home/karsten/boost/boost_1_47_0/boost/fusion/view/nview/nview.hpp:105, from /home/karsten/boost/boost_1_47_0/boost/fusion/view/nview.hpp:12, from /home/karsten/boost/boost_1_47_0/boost/fusion/view.hpp:13, from test_fusion_view.cpp:1: /home/karsten/boost/boost_1_47_0/boost/fusion/view/nview/detail/nview_impl.hpp:55:57: warning: overflow in implicit constant conversion [-Woverflow] /home/karsten/boost/boost_1_47_0/boost/fusion/view/nview/detail/nview_impl.hpp:55:57: error: overflow in constant expression [-fpermissive] /home/karsten/boost/boost_1_47_0/boost/fusion/view/nview/detail/nview_impl.hpp:55:57: note: in template argument for type ‘int’ Any Ideas? I think the code should compile sincde fusion/view.hpp is a forwarding for the views...

4 6

Reminder! Boost.Local Review officially ends Saturday, Nov 19, 2011
by Jeffrey Lee Hellrung, Jr. 20 Nov '11

20 Nov '11

Just a friendly reminder that the ongoing Boost.Local review is officially set to end tomorrow (Saturday), Nov 19, 2011. Please let me know if you plan on reviewing the library but need more time, possibly into early next week, and I'll either formally extend the review period (subject to the Review Wizards' approval) or simply informally allow late submissions. Copied below is the original review announcement: ---------------- Hi all, It is time! The review of Lorenzo Caminiti's proposed Boost.Local library begins tomorrow, ***November 10, 2011***, and ends on ***November 19, 2011***. Boost.Local implements local functions, local blocks, and local exits for the C++ programming language. It allows one to define a function at any declarative scope, including function scope; bind variables from the enclosing scope; and pass this function to templated STL-style algorithms. Please see the Introduction of the documentation for a longer but still brief overview. -------- The code and documentation are available from the Boost sandbox ( https://svn.boost.org/svn/boost/sandbox/) https://svn.boost.org/svn/boost/sandbox/local/ [everything] https://svn.boost.org/svn/boost/sandbox/local/boost/ [code] https://svn.boost.org/svn/boost/sandbox/local/libs/local/doc/html/index.htm… -------- Please state clearly whether you think this library should be accepted as a Boost library. Other questions you may want to consider: - What is your evaluation of the design? - What is your evaluation of the implementation? - What is your evaluation of the documentation? - What is your evaluation of the potential usefulness of the library? - Did you try to use the library? With what compiler? Did you have any problems? - How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? - Are you knowledgeable about the problem domain? Please also consider the following issues and proposals specific to Boost.Local. Your opinion is welcome on any or all of these. - Boost.Local's local exits provide the same functionality (and then some) as Boost.ScopeExit. Does this duplication of functionality need to be dealt with, and if so, how? - Lorenzo is proposing to add boost::local::function:: overload to Boost.Function as boost::function::overload. See https://svn.boost.org/svn/boost/sandbox/local/libs/local/doc/html/boost/loc… - Lorenzo is proposing to add BOOST_IDENTITY_TYPE to boost/utility. See https://svn.boost.org/svn/boost/sandbox/local/libs/local/doc/html/BOOST_IDE… - Likewise, Lorenzo is proposing to add BOOST_IDENTITY_VALUE to boost/utility. See https://svn.boost.org/svn/boost/sandbox/local/libs/local/doc/html/BOOST_IDE… -------- Lastly, please note that Boost.Local has included a copy of the Variadic Macro Data (VMD) library in boost/detail/preprocessor/variadic_macro_data. Since then, VMD has been modified and integrated into Boost.Preprocessor. After the review has concluded, Lorenzo will remove this local copy of the VMD library and replace its usage within Boost.Local with the Boost.Preprocessor variadic extensions. -------- Thanks in advance to all who participate in the review discussion; I'm looking forward to it! - Jeffrey Hellrung (Review Manager) - Gregory Crosswhite (Review Assistant)

3 2

Review of Local Exits
by Alexander Nasonov 20 Nov '11

20 Nov '11

This is not a full review of the proposed Boost.Local library, I've reviewed only Local Exits and a potential merge with Boost.ScopeExit. I vote NOT to merge Local Exits with Boost.ScopeExit for the following reasons: - Local Exits feature gives two different interfaces ("variadic" and "sequencing"). In my opinion, it should only document C++0X interface and have a section called something like "What if I don't have a C++0X compliant compiler?" where it will explain an alternative interface for a transitional period. Some compilers already support enough C++0X features to let you develop a "perfect" interface. - Binding of variables should be modeled after lambda captures. This means no this_ and no void. I really like void and I'd added it if Lorenzo came up with the idea at the time when Boost.ScopeExit was still in development. - For the same reason, const bind& and bind& should be removed from the interface. Regards, Alex

3 4

Re: [boost] [optional] std::tr2::optional
by Andrzej Krzemienski 20 Nov '11

20 Nov '11

> > * Use nullptr instead of boost::none? - this will make some uses of > > optional pointers harder, but will make usage more clear in other cases. > > I don't think nullptr is a good choice here because of the complications you > mentioned. Actually, I would prefer traditional clear() and empty() methods > for clearing and testing for value presence. The operator safe_bool() and > operator!() may also be present in the interface for brevity in conditional > expressions. Interesting. It looks like optional can be seen as a special container with the maximum size of 1, and then functions like clear() or empty() come as natural. On the other hand it can be seen as a pointer-like entity with value semantics, and then functions like reset() and literal nullptr come as natural. I withdraw my suggestion to use nullptr. Function reset() would be a better choice. I also find reset() preferable to clear() because reset can be extended to accept parameters and the name does not become confusing; similarly to unique_ptr::reset(). Also, if someone likes the assignment-of-"none" syntax, in C++11 there will be a similar syntax available: std::tr2::optional<T> op = {}; op = {}; Interestingly, boost::optional did have a reset function (now deprecated) which was replaced with boost::none assignment. I wonder what was the reason for this replacement. Regards, &rzej

2 2

Re: [boost] [optional] std::tr2::optional
by Andrzej Krzemienski 20 Nov '11

20 Nov '11

> > * Conversion explicit conversion to bool should be declared as explicit. > > Doesn't an explicit conversion disallows to use it in a conditional > expression as in > if(opt) {} I believe that the primary motivation for the explicit conversion operators was to provide a simpler alternative for safe-bool idiom, and address cases like this one. http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2437.pdf > > * Should exception safety guarantees for assignment operations be enforced? > > In boost::optional they only provide a basic guarantee. > > One option is to provide strong guarantee for types T which implement > > operator= with strong guarantee, and give basic guarantee for other cases > > Other option (not sure if it is possible) is to provide strong guarantee > > for all cases at the cost of run-time performance (heap allocation). > Provide the same exception guaranties as the T assignment seems the more > reasonable. My apologies, I wrote this in a hurry an didn't make myself clear. There are three cases to consider (leaving move assignment and no-throw copyable types aside): 1. Our stored type T provides a strong assignment - the choice is obvious: optional<T>'s assignment is also strong 2. T has "basic" assignment - the natural choice is to provide also a basic guarantee for optional<T>'s assignment. 3. T is neither copyable nor moveable -- it is like a scope guard, or boost::scoped_ptr. In this case optional<T> still provides assignment by making a "pseudo destructor call" followed by a call to placement new. -- but this gives only basic guarantee. The question is if for this third variant we should be happy with only basic guarantee or to use a trick boost::variant is using with auxiliary heap-allocated object? (I do not even know if this is applicable though). > > template< typename ... Args> > > optional( Args&& ...args ); > I like them. > > The constructor will clash with another optional constructor: > > optional<T>::optional( bool cond, const T& val ); > > I don't understand why. Currently boost::optional provides this constructor: optional<T>::optional( bool cond, const T& val ); If cond is true the optional is initialized with object val, otherwise it is uninitialized. Now suppose I have a following type: struct MyType { bool on; int m1; int m2; MyType( bool on, MyType const& rhs ) :on{on}, m1{rhs.m1}, m2{rhs.m2} {} }; MyType mt { true, 1, 2 }; boost::optional<MyType> o1{ true, mt }; // optional initialized with mt (copy ctor used) boost::optional<MyType> o2{ boost::in_place(true, mt) }; // uses 2-arg ctor But if std::tr2::optional has "variadic" constructor: std::tr2::optional<MyType> mt{ true, mt }; // uses 2-arg ctor Regards, &rzej

4 5

Boost 1.48.0 Release Notice
by Beman Dawes 19 Nov '11

19 Nov '11

Release 1.48.0 of the Boost C++ Libraries is now available. These open-source libraries work well with the C++ Standard Library, and are usable across a broad spectrum of applications. The Boost license encourages both commercial and non-commercial use. This release contains new libraries: Container, Locale, Move. Updated libraries include: Asio, Chrono, Config, Fusion, Geometry, Graph, Interprocess, Intrusive, Lexical cast, Math, MSM, Numeric Conversion, Proto, Regex, Spirit, TypeTraits, Unordered, Wave, and more. For details, including download links, see http://www.boost.org/users/news/version_1_48_0 You can also download directly from SourceForge: http://sourceforge.net/projects/boost/files/boost/1.48.0/ To install this release on your system, see http://www.boost.org/doc/libs/release/more/getting_started/index.html Thanks, --The Boost release team Beman Dawes Daniel James Eric Niebler Rene Rivera Vladimir Prus

5 5

[ScopeExit] C++0X support
by Alexander Nasonov 19 Nov '11

19 Nov '11

I committed lambda-based implementation of ScopeExit to trunk today. It should be backward compatible with the previous implementation. In addition, if you've fully switched to C++0x, you can use = and & from C++0x and use ; instead of BOOST_SCOPE_EXIT_END. For instance: BOOST_SCOPE_EXIT((&)) {}; Alex

1 0

Re: [boost] [optional] std::tr2::optional
by Andrzej Krzemienski 19 Nov '11

19 Nov '11

> Do we even want the third variant? That is, do we want to support tr2::optional of something that is neither copyable nor movable? > My gut instinct says no, that's unintuitive. boost::optional can be used for many purposes. One of these (and I had to use optional like that) is to make classes that provide RAII-like interface (noncopyable, nonmoveable) usable in contexts where I need to use two-phase initialization or to release the resource before the end of the scope (subject to some runtime condition) -- all that in order to have a resource acquired for as short span of time as possible. I would be forced to do that for std::lock_guard if the library did not provide a second template std::unique_lock. But not every library provides two interfaces for almost the same thing, and this is arguably an unnecessary redundancy for an interface. optional<RAII> as described above is a generic tool for transforming types that implement 'scoped ownership' into types that implement 'unique ownership' of a resource. Given this optional<RAII> pattern I can already re-set my object to a different resource: template< typename ...Args > void reset( boost::optional<RAII> & o, Args &&... args ) { o = boost::none; o = in_place( std::forward<Args>(args)... ); } Or perhaps boost::optional already implements this 'strange' assignment. I didn't have a need to reset a handle to a different resource. But you can see how (arguably) natural it becomes for optional<RAII>. Regards, &rzej

1 0

Re: [boost] [optional] std::tr2::optional
by Andrzej Krzemienski 19 Nov '11

19 Nov '11

> Do we even want the third variant? That is, do we want to support tr2::optional of something that is neither copyable nor movable? > My gut instinct says no, that's unintuitive. boost::optional can be used for many purposes. One of these (and I had to use optional like that) is to make classes that provide RAII-like interface (noncopyable, nonmoveable) usable in contexts where I need to use two-phase initialization or to release the resource before the end of the scope (subject to some runtime condition) -- all that in order to have a resource acquired for as short span of time as possible. I would be forced to do that for std::lock_guard if the library did not provide a second template std::unique_lock. But not every library provides two interfaces for almost the same thing, and this is arguably an unnecessary redundancy for an interface. optional<RAII> as described above is a generic tool for transforming types that implement 'scoped ownership' into types that implement 'unique ownership' of a resource. Given this optional<RAII> pattern I can already re-set my object to a different resource: template< typename ...Args > void reset( boost::optional<RAII> & o, Args &&... args ) { o = boost::none; o = in_place( std::forward<Args>(args)... ); } Or perhaps boost::optional already implements this 'strange' assignment. I didn't have a need to reset a handle to a different resource. But you can see how (arguably) natural it becomes for optional<RAII>. Regards, &rzej

1 0

Re: [boost] [optional] std::tr2::optional
by Andrzej Krzemienski 19 Nov '11

19 Nov '11

> This is more of an addition to your list, but I think adding > the | operator for getting the optional value or a default value would be nice. > For example: > optional<double> safe_sqrt(double x) > { > if (x < 0) return none; > else return sqrt(x); > } > double x = safe_sqrt(4) | 0; //x = 4 > double y = safe_sqrt(-1) | 0; //y = 0 > I dont know if this is possible for tr2, but would be really nice > addition in the future. Especially, since a lot of times i just > want a default value if the optional value doesn't exist. Note, that boost::optional already provides a functionality for that, although with a slightly more verbose syntax: double x = safe_sqrt(4).get_value_or(0); std::tr2::optional would also provide this functionality. If this is only about shorthand notation, this item would be controversial. bitwise-or is a better choice that logical-or but it might turn out too confusing and disturbing for programmers that do not want to learn what overloaded operators mean for every type they use. What I mean to say is that liberal use of overloaded operators is a general controversy. Regards, &rzej

1 0