- Boost - lists.boost.org

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

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

19 Nov '11

> > 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 guarantee is strong if the placement delete/new are marked > noexcept, isn't it? What I meant by "a >>pseudo destructor call<< followed by a call to placement new." is a call to destructor w/o releasing the memory and then a call to constructor w/o allocating memory: ob.~T(); new (&ob) T( std::forward<Args>(args)... ); This trick will provide a strong guarantee if destructor and the constructor are nothrow. While destructors usually are non-throwing, it is rather unlikely that constructors would not throw: it is the constructors that we often expect to throw in case of initialization failure. Regards, &rzej

1 0

[inteprocess] Using named_mutex on Windows 7
by Edward Diener 19 Nov '11

19 Nov '11

I wrote a program more than 3 years ago where I used boost::interprocess_named_mutex to protect more than one instance of the same process from running the same sequence of code at the same time. The program appears to run fine under Windows XP and Windows Vista but occasionally locks up waiting for the locked mutex to unlock on Windows 7. The code looks like this: ------------------------------------------------------------------- boost::interprocess::named_mutex cmutex(boost::interprocess::open_or_create_t(),"MyMutexName"); { boost::interprocess::scoped_lock<boost::interprocess::named_mutex> cscoped(cmutex); // Code here which must be run one at a time. } ------------------------------------------------------------------- Under Windows 7 the code occasionally hangs on the scoped_lock instantiation, which of course I can not have. I notice there is a file in the temporary directory ( TMP or TEMP environment variable ) which is being used by interprocess, and after that file is manually deleted, the program no longer hangs on the scoped_lock instantiation. Is there a reason for this problem on Windows 7 ? I know that Windows 7 has global and local named mutexes and only by prefacing a named mutex name with global\ is the mutex truly global. I do not know if this is causing the problem on Windows 7. It does seem as if something in the file in the temporary directory is telling inteprocess that "MyMutexName" is still locked when the hangup occurs, but I would have expected that when acoped_lock goes out of scope, it handles resetting that file to the correct state. I wonder if this has something to do with UAC/file permissions in Windows 7, where the process somehow can no longer write to the file in the temporary directory afte creating it. Is this a known interprocess problem, perhaps fixed in a later release ? I wrote my code before Windows 7 even came out, recompiled it for Windows 7, but did not update the version of Boost I was using for the program ( Boost 1.35 ). Maybe I need to do that ? I would certainly be willing to do that if I knew that this was a problem with interprocess in Boost 1.35 that has subsequently been fixed in a later version of Boost.

1 0

[signals] Compiler error
by "Claas H. Köhler" 18 Nov '11

18 Nov '11

Hi everybody! When compiling boost 1.48.0 using gcc-4.6 and the "--std=c+0x" option, I get the following error message: libs/signals/src/named_slot_map.cpp: In member function ‘void boost::signals::detail::named_slot_map::disconnect(const boost::signals::detail::stored_group&)’: libs/signals/src/named_slot_map.cpp:99:48: error: conversion from ‘std::list<boost::signals::detail::connection_slot_pair>::const_iterator {aka std::_List_const_iterator<boost::signals::detail::connection_slot_pair>}’ to non-scalar type ‘boost::signals::detail::slot_pair_iterator {aka std::_List_iterator<boost::signals::detail::connection_slot_pair>}’ requested The reason seems to be that std::map's erase function expects a std::map::iterator in the old standard (according to cplusplus.com) while c++11 seemingly requires a std::map::const_iterator as argument (see section 23.4.4.1). Thus replacing line 105 OLD groups.erase(group); NEW groups.erase( static_cast<const_group_iterator>(group) ); and line 128 OLD if (empty(g)) groups.erase(g++); NEW if (empty(g)) groups.erase( static_cast<const_group_iterator>(g++); solves the problem for me. Is it intended to have all boost libraries conforming with C++11? Regards Claas

1 0