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

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

date_time using CPU performance counter
by Kenneth Porter 18 Nov '11

18 Nov '11

I need high precision under Windows XP but don't need long-term date accuracy. To that end, I think it would be useful to have a microsec_clock implemented in terms of the Windows QueryPerformanceCounter API (which wraps a CPU register query) instead of the GetSystemTimeAsFileTime API (which is only good to 15 msecs and almost guarantees a context switch). Has anyone attempted this? How hard is it to code up a new clock source to fit into the Boost date_time design?

3 3

multi_array and concept check
by Ivan Sorokin 17 Nov '11

17 Nov '11

Hello! Currently it is not possible to pass shape() of one multi_array into constuctor of another: boost::multi_array<float, 2> a; boost::multi_array<float, 2> b(a.shape()); This is because shape() returns size_t const* and multi_array check in constructor that ExtendList satisfy CollectionConcept. size_t const* don't satisfy this concept. I'm going to allow constructor of multi_array to get both size_t const* and size_t const[]. So I'm going to replace extents.begin() with boost::begin(extents). What should I do with concept check?

1 0

Boost.Local Review
by Pierre Morcello 17 Nov '11

17 Nov '11

Hello Boost community, Here is my review of the local function library. - What is your evaluation of the design? The design is clear. Several iterations were done already to come to what it is today. Of course no one is particularly fond of macros, but a huge work was done to reduce the potential problems and on the other hand the library can really help a lot. - What is your evaluation of the implementation? I did not get too much into the current implementation. I dug it almost one year ago, but there were changes since then. The implementation is correct given the features of the library (use of 'this', functor,, name,...). If there were less features, then some optimisations would have been possible (example : not use a virtual function, not use a functor). But the library would in that case have fewer cases of use. I know how the first verion of Lorenzo worked but I did not check the latest. Given the current features, I don't see how to do even better than what Lorenzo did. So I am happy with the implementation. - What is your evaluation of the documentation? I really appreciate the detailled documentation. On a 'merchandising note', the first page is too big. I think this could 'afraid' some new readers. Introduction + an 8-line motivating example should be enough to appeal (or not) the new reader. I am happy to review a submitted library with a complete documentation (that does not always happen). - What is your evaluation of the potential usefulness of the library? This library is filling a few strong needs. Several users including myself needed local function and const block. I am lazy when it comes to functors, I also find this library is pretty nice to make them quick. C++11 will on that last part change it , but const block are a must have in my opinion which are not available in C++11. The local function can greatly reduce the presence of internal functions in ".h", and thus make the interfaces much better in some cases. - Did you try to use the library? With what compiler? Did you have any problems? I use regularly this library on VC9, but mostly for local function. As I don't try to push the limits, I did not come into problems. - How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? I have followed Lorenzo work since his proposition. At the beginning I followed it much more closely, but right now I dont' have the time to redo an in depth study. I use a previous version of Lorenzo library regularly. So for the review, I simply had a glance. But I already read the documentation in detail several month ago. - Are you knowledgeable about the problem domain? I implemented a my own version of local functions for boost almost 2 years ago I think. - 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? I think it's important to check if the author are ok with merging or not. Obviously Lorenzo is very motivated and gives great feedback on his works with boost. Just make sure this won't hurt his motivation ? Because then there are the question of maintening the libraries which is not always the easiest. I am ok if one replace the other. - Do you vote for the library? Yes, I vote for its admission. I also want to add that I am amazed by the overall results in term of quality that Lorenzo was able to get with this library. Lorenzo is constently gathering the users needs and updating his library in that way. Like a marathonian. Very inspiring! Best regards, Pierre Morcello -- View this message in context: http://boost.2283326.n4.nabble.com/Boost-Local-Review-tp4078276p4078276.html Sent from the Boost - Dev mailing list archive at Nabble.com.

4 5

[context] update
by Oliver Kowalke 17 Nov '11

17 Nov '11

Hi, a new updated version is available. src: http://github.com/olk/boost.context docu: http://ok73.ok.funpic.de/boost/libs/context/doc/html/index.html next step mini-review? so long, Oliver

1 0

Boost.Local Review (Nov 10, 2011 to Nov 19, 2011)
by Jeffrey Lee Hellrung, Jr. 17 Nov '11

17 Nov '11

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)

7 21

Alternative implementation for BOOST_PP_VARIADIC_SIZE
by Gennadiy Rozental 17 Nov '11

17 Nov '11

Hi, Current implementation of subject macro have a very serious shortcoming - it does not work for empty __VA_ARGS__. After googling around a bit for some ideas I came up with the following alternative: #include <boost/preprocessor/arithmetic/mul.hpp> #include <boost/preprocessor/arithmetic/sub.hpp> #include <boost/preprocessor/punctuation/comma.hpp> #define MY_VA_ARG_N( \ _1, _2, _3, _4, _5, _6, _7, _8, _9,_10, \ _11,_12,_13,_14,_15,_16,_17,_18,_19,_20, \ _21,_22,_23,_24,_25,_26,_27,_28,_29,_30, \ _31,_32,_33,_34,_35,_36,_37,_38,_39,_40, \ _41,_42,_43,_44,_45,_46,_47,_48,_49,_50, \ _51,_52,_53,_54,_55,_56,_57,_58,_59,_60, \ _61,_62,_63, N, ...) N #define MY_VA_RSEQ_N() \ 63,62,61,60, \ 59,58,57,56,55,54,53,52,51,50, \ 49,48,47,46,45,44,43,42,41,40, \ 39,38,37,36,35,34,33,32,31,30, \ 29,28,27,26,25,24,23,22,21,20, \ 19,18,17,16,15,14,13,12,11,10, \ 9, 8, 7, 6, 5, 4, 3, 2, 1, 0 #define MY_DO_VA_NARG2(...) MY_VA_ARG_N __VA_ARGS__ #define MY_DO_VA_NARG(...) MY_DO_VA_NARG2(( __VA_ARGS__ )) // this version produces incorrect value (1) for empty __VA_ARGS__ #define MY_VA_NARG_(...) MY_DO_VA_NARG(__VA_ARGS__, MY_VA_RSEQ_N()) // this version fixes it #define MY_VA_NARG(...) BOOST_PP_SUB( BOOST_PP_MUL( MY_VA_NARG_( __VA_ARGS__ ), 2 ), MY_VA_NARG_( BOOST_PP_COMMA __VA_ARGS__ () ) ) This version work for zero sized __VA_ARGS__ and also works for MSVC-9,10 , gcc-4.1 gcc 3.2 (did not test with other compilers). Does it make sense to improve trunk version? Regards, Gennadiy

7 39

[1.48.0] Can't build any PDF docs
by John Maddock 16 Nov '11

16 Nov '11

I'm trying to build the PDF docs for 1.48 but all attempts to build PDF's on both Trunk and release branches fails with errors such as: bjam pdf M:/data/boost/trunk/tools/build/v2/tools\boostbook.jam:649: in object(boostbook-generator)(a)49.run from module object(boostbook-generator)@49 error: Cannot build documentation type 'pdf' M:/data/boost/trunk/tools/build/v2/build\generators.jam:1004: in try-one-generator-really from module generators M:/data/boost/trunk/tools/build/v2/build\generators.jam:1066: in try-one-generator from module generators M:/data/boost/trunk/tools/build/v2/build\generators.jam:1282: in construct-really from module generators M:/data/boost/trunk/tools/build/v2/build\generators.jam:1366: in generators.construct from module generators M:/data/boost/trunk/tools/build/v2/build\targets.jam:1495: in construct from module object(typed-target)@776 M:/data/boost/trunk/tools/build/v2/build\targets.jam:1297: in object(typed-target)(a)776.generate from module object(typed-target)@776 M:/data/boost/trunk/tools/build/v2/build\targets.jam:732: in generate-really from module object(main-target)@782 M:/data/boost/trunk/tools/build/v2/build\targets.jam:704: in object(main-target)(a)782.generate from module object(main-target)@782 M:/data/boost/trunk/tools/build/v2/build\targets.jam:258: in object(project-target)(a)772.generate from module object(project-target)@772 M:/data/boost/trunk/tools/build/v2\build-system.jam:736: in load from module build-system M:\data\boost\trunk\tools\build\v2/kernel\modules.jam:283: in import from module modules M:\data\boost\trunk\tools\build\v2\kernel\bootstrap.jam:142: in boost-build from module M:\data\boost\trunk\boost-build.jam:17: in module scope from module Nothing has changed in my user-config.jam, and I've updated to the latest bjam executable. Any ideas on what broke? Thanks, John.

2 3