- Boost - lists.boost.org

[Boost.Move] A few notes
by Dan Ivy 13 Jan '12

13 Jan '12

Hi, I was recently trying out Boost.Move and a few issues worth sharing surfaced: 1. It would be helpful to have configuration macros to force emulation mode, even on C++11 compilers, as well as to disable move semantics altogether (that is, the conversion operators to boost::rv& should be disabled, and move/forward should return lvalue-references. BOOST_RV_REF and friends should remain intact, so that overloads remain unique.) In many cases, the higher level semantics of a program are expected to be identical under all three configurations, so having a quick way to switch between them is useful during testing/debugging. 2. Boost.Move is a little bit too opaque, as it stands. What's really missing are Boost.Move-aware type traits. Things like add_rvalue_reference are often necessary to calcuate return types of move-aware generic functions, and so on. Whether this belongs in Boost.TypeTraits or Boost.Move is a separate question. Likewise, there should be type traits to calculate the return types of boost::move and, in particular, boost::forward. On C++11, the return type of forward<T> conincides with add_rvalue_reference<T>, but not so in emulation mode, hence the necessity for this trait. 3. For some reason, the emulated boost::move is written so it doesn't accept temporaries. This doesn't play too nicely with forwarding: Unavoidably on C++03, there has to be made a choice whether forwarding functions use non-const or const-qualified references (bad wording, but you get the point), where the former accepts modifiable lvalues and rejects temporaries, and the latter does the opposite (well, sort of). Boost.Move chooses the latter. This means that while BOOST_FWD_REF parameters accept temporaries, these temporaries are bound as lvalues, which pretty much defeats the purpose of the library (note that these temporaries aren't eligible for copy-elision, since they're bound to a reference.) While there's not much you can do about it on the callee-side, callers could use boost::move on the temporaries to force them into rvalue-refs. Only that they can't. This creates a somewhat confusing situation where forwarding functions are able to take temporaries, but they won't move them, while the only things that can actually be moved are lvalues... Ultimately, this is what I suggest: First of all, have boost::move accept temporaries. Secondly, seriously consider changing the definition of BOOST_FWD_REF(T) from const T& to T&, as this would acheive two desirable, IMO, goals:: a. Forwarding functions would accept modifiable lvalues (and keep them modifiable). b. Forwarding functions would REJECT temporaries, UNLESS they're passed through boost::move, which assures that they're treated as rvalues. A few notes on the implementation: 4. There are many one-liner functions floating around that aren't declared inline. This is a big-deal for less-capable compilers, such as Sun and older versions of GCC. In fact, they simply won't inline boost::move calls without it. 5. boost::rv<T> unconditionally inherits from T, with the assumption that it would never get instanciated for non-class types, since it is only ever used as a reference. This is a false assumption in general. In the context of overload-resolution, the compiler is allowed, though not required, to instanciate the types of function parameters, even if the best overload can be determined without doing this. Consider this move-aware, but not very useful vector class: #include <boost/move/move.hpp> template <typename T> struct vector { void push_back(const T&) {} void push_back(BOOST_RV_REF(T)) {} }; int main() { vector<int> v; v.push_back(123); } The last line of main could potentially instanciate rv<int>, breaking the program. And it does. Sun falls right into this trap. It doesn't take much to make it break on GCC either, for the same reason. Fortunately, the fix is trivial: specialize boost::rv correctly for non-class types. All comments refer to the 1.48 release. I don't know what's going on on trunk. HTH

5 14

Release 1.49
by Barend Gehrels 13 Jan '12

13 Jan '12

Hi, I did not see (m)any recent mail traffic on the list w.r.t. release 1.49. According to the Calendar it was to be merged last Monday (major changes) and next Monday (all changes). Is this planning still up-to-date? Thanks, Barend

2 2

[interprocess] Crash of singleton_module in Windows
by JOAQUIN M. LOPEZ MUÑOZ 13 Jan '12

13 Jan '12

Steps to reproduce the problem: * Create singleton_dll.dll. * Create singleton_exe.exe, which uses singleton_dll.dll. * Run. On exit, an access violation happens. Seemingly, the problem happens when two different singletons are created, one in the main executable and the other in a DLL. If both singletons are created in the same module everything's OK, though. Best regards, Joaquín M López Muñoz Telefónica Digital ________________________________ Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nuestra política de envío y recepción de correo electrónico en el enlace situado más abajo. This message is intended exclusively for its addressee. We only send and receive email on the basis of the terms set out at. http://www.tid.es/ES/PAGINAS/disclaimer.aspx

4 7

[bjam] if MSVC 7.1 or 8.0 compile-fail
by lcaminiti 13 Jan '12

13 Jan '12

Hello all, If there a way to program the following within a Jamfile? import testing ; if(MSVC 7.1 or MSVC 8.0) { # How do I program this? [ compile-fail native_tu_test.cpp native_tu1.cpp native_tu2.cpp : : : <define>BOOST_TYPEOF_NATIVE ] } else { [ run native_tu_test.cpp native_tu1.cpp native_tu2.cpp : : : <define>BOOST_TYPEOF_NATIVE ] } Thanks a lot. --Lorenzo -- View this message in context: http://boost.2283326.n4.nabble.com/boost-bjam-if-MSVC-7-1-or-8-0-compile-fa… Sent from the Boost - Dev mailing list archive at Nabble.com.

2 1

[Boost.Variant] Parameterized Visitors
by Andy Jost 13 Jan '12

13 Jan '12

New poster. When I'm using Boost.Variant, I often want to pass additional parameters to a visitor. A common case is when the variant is a class member and I want to have access to other members (or even "this") in the visitor. I muddled through for a long time writing visitors with explicit constructors and data members to take whichever parameters I needed, but I finally got around to making this generic with Boost.Fusion and I love it. I'm wondering whether I should submit this for consideration as an addition to the Boost.Variant library and how. First a few questions: 1. Is there already an equivalent solution that I should be aware of? 2. Should this be considered for an addition to Boost? 3. If so, how do I begin the review process? 4. This is a small change (400 or so lines of code). Is there anyone willing to help with the logistics, testing, and/or documentation (perhaps in exchange for a credit in the docs)? Here's an example, which should be fairly self-explanatory: struct A {}; struct B {}; struct C {}; struct my_visitor1 : param_visitor<my_visitor1, bool> { result_type operator()(int, float, char, A) const {...} result_type operator()(int, float, char, B) const {...} result_type operator()(int, float, char, C) const {...} }; struct my_visitor2 : fused_param_visitor<my_visitor2, bool> { template<typename Sequence> result_type operator()(Sequence const &, A) const {...} ... }; int main() { boost::variant<A,B,C> abc; boost::apply_visitor(my_visitor1().tie(1, 3.14, 'k'), abc); boost::apply_visitor(my_visitor2().tie(1, 3.14, 'k'), abc); return 0; } In terms of technical detail, there's not much to it. The base classes provide tie() and load() methods to take arguments by reference or value, respectively. A call to one of those returns a helper object that contains a copy of the derived visitor and a fusion::vector of arguments. Visiting that causes the user-defined visitor to be called with all of the arguments. For parameter forwarding, I use an implementation of perfect forwarding based on boost/flyweight/detail/dyn_perfect_fwd.hpp (I used a default limit of 4 parameters). Thanks, Andy

2 2

tuple and virtual functions
by Mark Snelling 12 Jan '12

12 Jan '12

I'm having a problem with Boost.Tuple virtual functions. Consider the code below, I would have expected the output to be "B::foo()" but instead get "A::foo()". Am I missing something here? #include <boost/tuple/tuple.hpp> #include <iostream> class A { public: virtual void foo() { std::cout << "A::foo()" << std::endl; } }; class B :public A { public: void foo() { std::cout << "B::foo()" << std::endl; } }; boost::tuple< A > make( const A& a ) { return boost::make_tuple( a ); } int main( int argc, char* argv[] ) { B b; make( b ).get< 0 >().foo(); return 0; }

3 2

abi-compliance-checker
by Neal Becker 12 Jan '12

12 Jan '12

Sounds useful: http://forge.ispras.ru/projects/abi-compliance-checker

1 0

[context] mini-review period ended
by Giovanni Piero Deretta 12 Jan '12

12 Jan '12

Hi all, The boost.context mini-review period ended sometime betweend yesterday and today depending on your timezone. We didn't get many reviews, but we had some interesting discussions and I should be able to reach a conclusion. If anybody is still completing a review, please let me know me ASAP, otherwise I should be able to wrap everything up by this weekend and announce the results next week. Thanks for everybody that partecipated in the review and thanks to Oliver for submitting his library. -- gpd

1 0

Re: [boost] Condition Variables, POSIX signals and system time changes
by Johan Borkhuis 12 Jan '12

12 Jan '12

Vicente, > I'm reworking the timed wait interface using Boost.Chrono. In this case > you could use a steady clock to mean a MONOTONIC clock. Unfortunately my > refactoring did use pthread_condattr_setclock to force a monotonic clock > while waiting on the condition. Even if this should not be the source of > the problem as it works when you don't generate the signals, I think > that this will be better when available. I will need some time to make > this working but I hope I could release it for boost 1.50 :( Looking forward to that. For the moment we have a workaround, but I will keep an eye on changes in this area, so we can move back when this becomes available. >> The demo application shows where things go right and wrong, so hopefully >> you should be able to reproduce the issue. > > I have not understood the example completely. How do you change the time > forward or backward? Could you point me where or how do you do? by hand? Sorry, should have mentioned that. I change the time externally by hand, using the date command. When I change the time backwards (so an earlier time) the problem occurs. When I change the time forward again to a time equal to or before the time I changed the time the application continues. >> >> Again, thank you for your quick response. >> >> > Thanks for reporting this and for the application example. > Vicente Thank you for your work on this. Kind regards, Johan Borkhuis

1 0

problem in trunk with file system library
by Robert Ramey 12 Jan '12

12 Jan '12

I'm seeing this message on bunch of tests "/sierra/Sntools/extras/compilers/gcc-4.3.4/bin/g++" -ftemplate-depth-128 -O0 -fno-inline -Wall -pedantic -g -fPIC -Wno-long-long -ftemplate-depth-255 -DBOOST_ALL_NO_LIB=1 -DBOOST_ARCHIVE_TEST=binary_archive.hpp -DBOOST_FILESYSTEM_DYN_LINK=1 -DBOOST_LIB_DIAGNOSTIC=1 -DBOOST_SYSTEM_DYN_LINK=1 -I".." -c -o "/scratch/kbelco/boost/results/boost/bin.v2/libs/serialization/test/test_array_binary_archive.test/gcc-4.3.4/debug/test_array.o" "../libs/serialization/test/test_array.cpp" In file included from ../boost/filesystem.hpp:36, from ../libs/serialization/test/test_tools.hpp:5, from ../libs/serialization/test/test_array.cpp:22: ../boost/filesystem/v3/operations.hpp:139: error: extra ???;??? ../boost/system/error_code.hpp:214: warning: ???boost::system::posix_category??? defined but not used ../boost/system/error_code.hpp:215: warning: ???boost::system::errno_ecat??? defined but not used ../boost/system/error_code.hpp:216: warning: ???boost::system::native_ecat??? defined but not used This is provoked by the following code:symlink_perms = 0x4000 // on POSIX, don't resolve symlinks; implied on Windows};BOOST_BITMASK(perms); // line 139//--------------------------------------------------------------------------------------//Would it be possible to get this fixed. I don't what the exact fix is. Robert Ramey

2 1