- Boost - lists.preview.boost.org

[Test] Darwin Intel 11.1
by Belcourt, K. Noel 09 Nov '11

09 Nov '11

Hi, I've attached a patch that appears to fix problems with about 20 Boost libraries on trunk that depend on Boost.Test. This patch simply removes an argument to format_report(). The trunk tests (http://www.boost.org/development/tests/trunk/developer/summary.html ) currently reflect this patch. I've added this patch to the nightly trunk testing patch script until such time as we get this committed to trunk. -- Noel

1 0

Fw: [atomic] review results
by Peter Dimov 08 Nov '11

08 Nov '11

-----Original Message----- From: Peter Dimov Sent: Monday, November 07, 2011 22:38 To: Helge Bahmann Subject: Re: [boost] [atomic] review results Helge Bahmann wrote: > yes makes sense -- there was a concern raised by Andrey Semashev that the > spinlock pool as implemented and used by shared_ptr presently may fail on > Windows due to the pool being non-unique (not had a chance to test this > yet), > and I have found a way to produce a similar failure using dlopen, atomics > private to shared libraries and RTLD_LOCAL -- currently I am therefore > leaning on creating a shared library just for the spinlock pool, but since > you wrote the initial implementation maybe you could comment as well? This is a problem in principle, but requiring all users of shared_ptr to link to a shared library is a non-starter. I wouldn't use such a shared_ptr, and I doubt many others will. And I wouldn't be surprised if this sentiment applies to Boost.Atomic as well.

5 35

[parameter] type requirement compiler error
by lcaminiti 08 Nov '11

08 Nov '11

Hello all, The following parameter type requirement: (required (graph, *) ) (optional (root_vertex, (typename boost::graph_traits<graph_type>::vertex_descriptor), *boost::vertices(graph).first) ) Generates a GCC error: dfs.05.cpp:40: error: ‘graph_type’ was not declared in this scope Detailed code and error below. In fact, if I look at the code after pp, I can see that graph_type is define only after the type requirement is checked... why? What am I doing wrong? Thanks a lot! --Lorenzo #include <boost/graph/adjacency_list.hpp> #include <boost/graph/depth_first_search.hpp> #include <boost/range/irange.hpp> #include <boost/pending/indirect_cmp.hpp> #include <boost/parameter.hpp> #include <iostream> namespace graphs { BOOST_PARAMETER_NAME(graph) BOOST_PARAMETER_NAME(visitor) BOOST_PARAMETER_NAME(root_vertex) BOOST_PARAMETER_NAME(index_map) BOOST_PARAMETER_NAME(color_map) template< typename Size, typename IndexMap > boost::iterator_property_map<boost::default_color_type*, IndexMap, boost::default_color_type, boost::default_color_type&> default_color_map ( Size const& num_vertices, IndexMap const& index_map ) { std::vector<boost::default_color_type> colors(num_vertices); return &colors[0]; } BOOST_PARAMETER_FUNCTION( (void), depth_first_search, tag, (required (graph, *)) (optional (visitor, *, boost::dfs_visitor<>()) (root_vertex, (typename boost::graph_traits<graph_type>::vertex_descriptor), *boost::vertices(graph).first) (index_map, *, boost::get(boost::vertex_index, graph)) (in_out(color_map), *, default_color_map(boost::num_vertices(graph), index_map)) ) ) { std::cout << "here\n"; boost::depth_first_search(graph, boost::visitor(visitor). color_map(color_map).root_vertex(root_vertex). vertex_index_map(index_map)); } } // namespace graphs template< typename TimeMap > class dfs_time_visitor : public boost::default_dfs_visitor { typedef typename boost::property_traits< TimeMap >::value_type T; public: dfs_time_visitor(TimeMap dmap, TimeMap fmap, T& t) : dmap_(dmap), fmap_(fmap), time_(t) {} template< typename V, typename G > void discover_vertex ( V u, G const& g ) const { put(dmap_, u, time_++); } template< typename V, typename G > void finish_vertex ( V u, G const& g ) const { put(fmap_, u, time_++); } TimeMap dmap_; TimeMap fmap_; T& time_; }; using namespace boost; int main ( ) { typedef boost::adjacency_list<boost::vecS, boost::vecS, boost::directedS> G; typedef boost::graph_traits<G>::vertices_size_type size_type; enum {u, v, w, x, y, z, N}; char names[] = {'u', 'v', 'w', 'x', 'y', 'z'}; typedef std::pair<int, int> E; E edges[] = {E(u, v), E(u, x), E(x, v), E(y, x), E(v, y), E(w, y), E(w, z), E(z, z)}; G g(edges, edges + sizeof(edges) / sizeof(E), N); std::vector<size_type> dtime(boost::num_vertices(g)); std::vector<size_type> ftime(boost::num_vertices(g)); size_type t = 0; dfs_time_visitor<size_type*> vis(&dtime[0], &ftime[0], t); graphs::depth_first_search(g, vis); std::vector<size_type> dorder(N); boost::integer_range<size_type> r(0, N); std::copy(r.begin(), r.end(), dorder.begin()); std::sort(dorder.begin(), dorder.end(), boost::indirect_cmp<size_type*, std::less<size_type> >(&dtime[0])); std::cout << "order of discovery: "; for(int i = 0; i < N; ++i) std::cout << names[dorder[i]] << " "; std::cout << std::endl; std::vector<size_type> forder(N); std::copy(r.begin(), r.end(), forder.begin()); std::sort(forder.begin(), forder.end(), boost::indirect_cmp<size_type*, std::less<size_type> >(&ftime[0])); std::cout << "order of finish: "; for(int i = 0; i < N; ++i) std::cout << names[forder[i]] << " "; std::cout << std::endl; return 0; } $ g++ -Wall -I../../../../../boost-trunk.cygwin dfs.05.cpp dfs.05.cpp:40: error: ‘graph_type’ was not declared in this scope dfs.05.cpp:40: error: template argument 1 is invalid dfs.05.cpp:40: error: expected `::' before ‘,’ token dfs.05.cpp:40: error: expected identifier before ‘,’ token dfs.05.cpp:40: error: template argument 3 is invalid dfs.05.cpp:40: error: expected `::' before ‘{’ token dfs.05.cpp:40: error: expected class-name before ‘{’ token ../../../../../boost-trunk.cygwin/boost/parameter/preprocessor.hpp: In instantiation of ‘boost::parameter::aux::argument_pack<graphs::boost_param_params_40depth_first_search<int>, const boost::adjacency_list<boost::vecS, boost::vecS, boost::directedS, boost::no_property, boost::no_property, boost::no_property, boost::listS>, const dfs_time_visitor<main::size_type*>, boost::parameter::void_, boost::parameter::void_, boost::parameter::void_>’: dfs.05.cpp:88: instantiated from here ../../../../../boost-trunk.cygwin/boost/parameter/preprocessor.hpp:157: error: no type named ‘parameter_spec0’ in ‘struct graphs::boost_param_params_40depth_first_search<int>’ ../../../../../boost-trunk.cygwin/boost/parameter/preprocessor.hpp:158: error: no type named ‘parameter_spec0’ in ‘struct graphs::boost_param_params_40depth_first_search<int>’ ../../../../../boost-trunk.cygwin/boost/parameter/preprocessor.hpp: In instantiation of ‘boost::parameter::aux::argument_pack<graphs::boost_param_params_40depth_first_search<int>, const boost::adjacency_list<boost::vecS, boost::vecS, boost::directedS, boost::no_property, boost::no_property, boost::no_property, boost::listS>, boost::parameter::void_, boost::parameter::void_, boost::parameter::void_, boost::parameter::void_>’: dfs.05.cpp:88: instantiated from here ../../../../../boost-trunk.cygwin/boost/parameter/preprocessor.hpp:157: error: no type named ‘parameter_spec0’ in ‘struct graphs::boost_param_params_40depth_first_search<int>’ ../../../../../boost-trunk.cygwin/boost/parameter/preprocessor.hpp:158: error: no type named ‘parameter_spec0’ in ‘struct graphs::boost_param_params_40depth_first_search<int>’ dfs.05.cpp: In function ‘int main()’: dfs.05.cpp:88: error: no matching function for call to ‘depth_first_search(main()::G&, dfs_time_visitor<size_type*>&)’ -- View this message in context: http://boost.2283326.n4.nabble.com/boost-parameter-type-requirement-compile… Sent from the Boost - Dev mailing list archive at Nabble.com.

6 14

[1.48 lexical_cast] Illegal Derefence
by Olaf van der Spek 08 Nov '11

08 Nov '11

Hi, This does an illegal dereference in boost\lexical_cast.hpp(1357): if ( Traits::eq(minus,*start) ) #include <boost/lexical_cast.hpp> #include <boost/range/iterator_range.hpp> int main() { boost::iterator_range<const char*> v; boost::lexical_cast<int>(v); } -- Olaf

3 10

Boost interprocess: Segmentation fault
by thuannv 08 Nov '11

08 Nov '11

Hi everybody, I am beginner to develop with boost library. I am working with shared memory (boost.interprocess). So, I got error in executing and could anyone help me solve this problem? My problem is: - I wrote 2 process named SHMWriter and SHMReader. + SHMWwriter: write a map (int, int) into the SHM. + SHMReader: read the map value from SHM. - I executed the SHMWriter then SHMReader. - SHMWriter successfully executed. But, SHMWriter always executed failed (error: Segmentation fault). - The sources code are listed below: //SHMWriter: -------------------------------------------- typedef std::pair<int, int> MapValue; typedef allocator<MapValue, managed_shared_memory::segment_manager> MapAllocator; typedef map<int, int, std::less&lt;int>, MapAllocator> IntegerMap; const char* segName = "MAPSEGMENT"; const char* mapName = "MAPNAME"; int main() { shared_memory_object::remove(segName); managed_shared_memory segment(create_only, segName, 1000); MapAllocator allocator(segment.get_segment_manager()); IntegerMap* pOffsetMap = segment.construct<IntegerMap>(mapName)(std::less<int>(), allocator ); int key = 1; int ivalue = 10; MapValue value(key, ivalue); pOffsetMap->insert(value); return 0; } //SHMReader ----------------------------- typedef std::pair<int, int> MapValue; typedef allocator<MapValue, managed_shared_memory::segment_manager> MapAllocator; typedef map<int, int, std::less&lt;int>, MapAllocator> IntegerMap; const char* segName = "MAPSEGMENT"; const char* mapName = "MAPNAME"; int main() { try { managed_shared_memory segment(open_only, "MAPSEGMENT"); IntegerMap* pMap = segment.find_no_lock<IntegerMap>(mapName).first; int key = 1; int value = pMap->at(key); std::cout << value << std::endl; } catch(interprocess_exception& ie) { std::cout << ie.what() << std::endl; } catch(std::exception& stde) { std::cout << stde.what() << std::endl; } return 0; } -- View this message in context: http://boost.2283326.n4.nabble.com/Boost-interprocess-Segmentation-fault-tp… Sent from the Boost - Dev mailing list archive at Nabble.com.

1 0

[Range] Confusing result of iterator_range::size()
by Sergey Voropaev 08 Nov '11

08 Nov '11

Hi, I try use boost::iterator_range as replacement for some standard container in my code. The function iterator_range::size() has non standart declaration: difference_type size() const; but not: size_type size() const When I compile code in VC++ 2010 I have a some warning and error. For example: #include <boost/range.hpp> #include <vector> #include <algorithm> int main() { int aaa[10] ={1,2,3,4,5,6,7,8,9,10}; std::vector<int> bbb(20); boost::iterator_range<int*> arr(aaa); if(bbb.size() > arr.size()) //warning C4018: '>' : signed/unsigned mismatch { } const size_t lng = std::min(bbb.size(), arr.size()); //error C2780: 'const _Ty &std::min(const _Ty &,const _Ty &,_Pr)' : expects 3 arguments - 2 provided //error C2782: 'const _Ty &std::min(const _Ty &,const _Ty &)' : template parameter '_Ty' is ambiguous // const size_t lng = std::min(bbb.size(), (size_t)arr.size()); //OK for(size_t i = 0; i < lng; ++i) { bbb[i] = arr[i]; } return 0; } I think declaration of boost::iterator_range must be fixed. Or there was some reason for this non standard declaration?

8 29

Boost.Build is broken?
by Gennadiy Rozental 08 Nov '11

08 Nov '11

Hi, Frankly I do not know who supports Boost.Build, but how long it'll stay broken? I can't say when it started, but ever since I started working on Boost.Test changes I experience constant problems. I can't believe I am the only one. 1. When you take boost trunk and go into Boost.Test build or test directory and try building using any toolset it immediately fails with: ..\..\..\libs\test\build\Jamfile.v2:110: in modules.load rule boost-install unknown in module Jamfile</.../trunk/libs/test/build>. .../trunk/tools/build/v2/build\project.jam:314: in load-jamfile .../trunk/tools/build/v2/build\project.jam:62: in project.load .../trunk/tools/build/v2/build\project.jam:766: in project.use .../trunk/tools/build/v2/build\project.jam:89: in load-used-projects .../trunk/tools/build/v2/build\project.jam:73: in load .../trunk/tools/build/v2/build\project.jam:115: in load-parent .../trunk/tools/build/v2/build\project.jam:464: in initialize .../trunk/tools/build/v2/build\project.jam:309: in load-jamfile .../trunk/tools/build/v2/build\project.jam:62: in load .../trunk/tools/build/v2/build\project.jam:115: in load-parent .../trunk/tools/build/v2/build\project.jam:464: in initialize .../trunk/tools/build/v2/build\project.jam:309: in load-jamfile .../trunk/tools/build/v2/build\project.jam:62: in load .../trunk/tools/build/v2/build\project.jam:168: in project.find .../trunk/tools/build/v2\build-system.jam:570: in load .../trunk\tools\build\v2/kernel\modules.jam:283: in import .../trunk\tools\build\v2\kernel\bootstrap.jam:142: in boost-build .../trunk\boost-build.jam:17: in module scope 2. Once I remove boost-install from Boost.Test Jamfile, I get bun of errors like this: ..\..\..\libs\test\src\compiler_log_formatter.cpp(16) : fatal error C1083: Cannot open include file: 'boost/test/impl/compiler_log_formatter.ipp': No such file or directory Essentially boost home directory is missing from include path. How come? 3. Once I add "<include>../../.." into requirements section I can build with msvc toolsets. Now I am trying to use gcc toolset on Windows. I have latest cygwin installation and I am getting these errors (lots of them): gcc.compile.c++ ..\..\..\libs\test\build\bin\gcc\debug\link-static\compiler_log_formatter.o "g++" ... # compilation line here Access is denied. Apparently g++ is not an executable anymore with cygwin. I am able to workaround this by adding using gcc : 4.5.3 : g++-4.exe ; into user-config.jam, but why Boost.Build can't figure this out and do I need to support this file now myself? 4. After the fix I am able to build dll based tests, but when I attempt to use static library version of Boost.Test I am getting: gcc.archive ..\..\..\libs\test\build\bin\gcc-4.5.3\ debug\link-static\libboost_unit_test_framework.a "/usr/i686-pc-cygwin/bin/ar.exe" rc .... # list of object files here "/usr/i686-pc-cygwin/bin/ranlib.exe" ... # lib here The system cannot find the path specified. The system cannot find the path specified. This one I do not know how to fix. So the situation is that I cannot test any static library based unit tests (as a side note, this inability was the cause of crashes which interrupted trunk testing month ago). I addition whenever I want to check in my local changes to Jamfile (excluding hacks which I actually do not want to check in) it is rather annoying process. Any help would be appreciated, Gennadiy

3 4

[atomic] review results
by Tim Blechmann 07 Nov '11

07 Nov '11

hi all, unfortunately only few reviews of boost.atomic arrived in time, however i count 3 YES and no NO, so i am happy to say: Helge Bahmann's boost.atomic library is ACCEPTED. since the library is an implementation of a c++11 feature for c++03, design, API and semantics are mostly fixed. many comments are going into details of the implementation, so i won't sum them all up ... iac, helge already said he wants to address the raised issues, the main points are summarized below. full implementation of the c++11 interface: the library currently only implements a subset of the c++11 library. it lacks the functional interface for integral atomic types and the ATOMIC_VAR_INIT / ATOMIC_FLAG_INIT macro. quickly consulting the latest draft that i currently have at hand the following two functions are missing as well: template <class T> T kill_dependency(T y); void atomic_signal_fence(memory_order); i encourage helge to provide a full implementation of the interface. documentation: the documentation is currently lacking a good API reference. i would therefore encourage helge to provide a doxygen-generated reference section. there were some concerns that it assumes that readers will have to be familiar with concurrency. maybe it is a good idea to point to some literature/tutorials about concurrent programming and/or to c++11 atomics. the section of real-world examples could probably include a link to shavit/herlihy's book `the art of multiprocessor programming'. it would also be helpful to have a detailed specification, if a platform/compiler combination supports a specific type natively (with run-time dispatching or specific compiler flags) ... maybe in form of a table. shared memory support/multi-module support: in multi-module applications and when using shared memory, the blocking emulation of atomics can cause troubles. for multi-module applications this can be resolved by placing the spinlock pool inside a shared library. shared- memory support could be realized by associating a (spin)lock with each blocking atomic<> instead of using a pool of spinlocks. boost should definitely provide atomics which support shared memory, either by default or by an additional implementation which is placed in the boost::interprocess namespace. i would like to thank helge for implementing boost.atomic and submitting it to boost and everyone who participated in the review. cheers, tim review manager

4 4

[smart_ptr] Please merge 5327
by Steve M. Robbins 07 Nov '11

07 Nov '11

Peter Dimov, When you have a moment, could you merge the patch in ticket https://svn.boost.org/trac/boost/ticket/5327 It should be safe enough; Debian has been using this since August 2009. Thanks, -Steve

2 1

[parameter] named template parameters
by Lorenzo Caminiti 07 Nov '11

07 Nov '11

Hello all (and especially Boost.Parameter's authors), The Boost.Parameter docs suggest to implement parameter-enabled class templates using a series of typedes for the argument pack and the actual argument types. I think it is best to define extra template parameters with default values to old the argument pack Args and named template parameters ClassType, etc as shown below. This allows to use the named template parameters within the class declaration for example in a base class (boost::python::class_<ClassType, ...>) instead that just in the class definition. Do you see any problem in using extra template parameter to define the argument pack and named template parameters? #include <boost/parameter.hpp>#include <boost/python/class.hpp>#include <boost/type_traits/is_class.hpp>#include <boost/type_traits/is_base_and_derived.hpp>#include <boost/mpl/is_sequence.hpp>#include <boost/mpl/placeholders.hpp>#include <boost/mpl/not.hpp>#include <boost/mpl/and.hpp>#include <boost/noncopyable.hpp>#include <boost/shared_ptr.hpp> namespace py { namespace detail { struct bases_tag {}; } template< class B0 = void, class B1 = void, class B2 = void >struct bases : detail::bases_tag {}; BOOST_PARAMETER_TEMPLATE_KEYWORD(ClassType) BOOST_PARAMETER_TEMPLATE_KEYWORD(BaseList)BOOST_PARAMETER_TEMPLATE_KEYWORD(HeldType)BOOST_PARAMETER_TEMPLATE_KEYWORD(Copyable) template< typename Arg123X0 , typename Arg123X1 = boost::parameter::void_ , typename Arg123X2 = boost::parameter::void_ , typename Arg123X3 = boost::parameter::void_ , typename Args123 = typename boost::parameter::parameters< // IF(IS_EMPTY(DEFAULT(p)), required, optional) boost::parameter::required< tag::ClassType , boost::is_class<boost::mpl::_> > , boost::parameter::optional< // IF(IS_DEDUCED(p), deduced<tag::NAME(p)>, tag::NAME(p)) boost::parameter::deduced<tag::BaseList> // COMMA_IF(COMPL(IS_EMPTY(REQUIRES(p)))) REQUIRES(p) , boost::is_base_and_derived<detail::bases_tag, boost::mpl::_> > , boost::parameter::optional< boost::parameter::deduced<tag::HeldType> , boost::mpl::not_< boost::mpl::or_< boost::is_base_and_derived<detail::bases_tag, boost::mpl::_> , boost::is_same<boost::noncopyable, boost::mpl::_> > > > , boost::parameter::optional< boost::parameter::deduced<tag::Copyable> , boost::is_same<boost::noncopyable, boost::mpl::_> > >::bind<Arg123X0, Arg123X1, Arg123X2, Arg123X3>::type , typename ClassType = typename boost::parameter::value_type< Args123, tag::ClassType >::type , typename BaseList = typename boost::parameter::value_type< // ... COMMA_IF(COMPL(IS_EMPTY(DEFAULT(p)))) DEFAULT(p) >::type Args123, tag::BaseList, bases<> >::type , typename HeldType = typename boost::parameter::value_type< Args123, tag::HeldType, ClassType >::type , typename Copyable = typename boost::parameter::value_type< Args123, tag::Copyable, void >::type>struct class_ : boost::python::class_<ClassType, BaseList, HeldType, Copyable>{ typedef ClassType class_type; typedef BaseList base_list; typedef HeldType held_type; typedef Copyable copyable;}; } // namespace py struct b { virtual ~b() = 0; }; struct d : b { ~d() {} }; // Named parameters.typedef py::class_< py::ClassType<b>, py::Copyable<boost::noncopyable> > x1;typedef py::class_< d, py::HeldType< boost::shared_ptr<d> >, py::BaseList< py::bases<b> > > x2;// Deduced parameters.typedef py::class_< b, boost::noncopyable > y1;typedef py::class_< d, boost::shared_ptr<d>, py::bases<b> > y2; A couple more things: 1) I thing that BOOST_PARAMETER_TEMPLATE_KEYWORD(ClassType) macro should define a symbol _ClassType to be used for the named parameter so to be consistent with the BOOST_PARAMETER_NAME(x) which defined _x to be used for the named function parameter. However, ClassType is defined without the leading _. What is the reason for this asymmetry? 2) I'd expect a macro that allows to specify tag and passing argument name for template parameters BOOST_PARAMETER_TEMPLATE_KEYWORD((PassClassType, mytag) ClassType) as for BOOST_PARAMETER_NAME((pass_x, mytag) x) does for function parameters. Why is such a usage of BOOST_PARAMETER_TEMPLATE_KEYWORD not supported? Thanks a lot. --Lorenzo

4 10

[smart_ptr] scoped_array / shared_array (size_t) constructor
by Olaf van der Spek 07 Nov '11

07 Nov '11

Hi, Currently, one has to manually allocate the array and pass the ptr to the constructor of scoped_array / shared_array. boost::scoped_array<unsigned char> A(new unsigned char[100]); boost::shared_array<unsigned char> B(new unsigned char[100]); This requires one to repeat the type and shared_array requires two allocations (one extra for the control block). std::vector has a constructor from size_t and one can write: std::vector<unsigned char> V(100); This avoids the type duplication and it'd allow shared_array to do only a single allocation. A few choices have to be made: 1. Should "new T[sz]" or "new T[sz]()" be used? 2. What should happen when size = 0? Should it call new T[0] or should it just use NULL? https://svn.boost.org/trac/boost/ticket/4637 -- Olaf

10 46

[python] Please apply and merge 2208
by Steve M. Robbins 07 Nov '11

07 Nov '11

Hi, The patch has been used in Debian since August 2008 so it should be safe to apply. Thanks, -Steve

1 0

[units] spatial coordinates, vectors, x, y, z, something like that
by Janek Kozicki 06 Nov '11

06 Nov '11

Hi, I want to use boost::units to calculate diffraction & interference patterns and wave propagation in 3D. I need some way to represent points in spatial 3D space with 'length' dimension. What do you guys use for that? I need them to work with 'frequency' & 'speed' dimensions also. Don't tell me that I need to write my own 'vector' class ? best regards -- Janek Kozicki http://janek.kozicki.pl/ |

2 2

Interest in bounded (Top-Bounded) Range adaptor.
by Fernando Pelliccioni 06 Nov '11

06 Nov '11

Is there interest in adding a Top-Bounded adaptor into Boost.Range ? Example: using namespace boost::adaptors; using namespace boost::assign; std::vector<int> input; input += 1,2,3,4,5,6,7,8,9; boost::copy( input | bounded(0), std::ostream_iterator<int>(std::cout, ",")); // prints nothing boost::copy( input | bounded(1), std::ostream_iterator<int>(std::cout, ",")); // prints 1, boost::copy( input | bounded(2), std::ostream_iterator<int>(std::cout, ",")); // prints 1,2, boost::copy( input | bounded(8), std::ostream_iterator<int>(std::cout, ",")); // prints 1,2,3,4,5,7,8, The above example is similar in behavior to ... boost::copy_n( input, 0, std::ostream_iterator<int>(std::cout, ",")); boost::copy_n( input, 1, std::ostream_iterator<int>(std::cout, ",")); boost::copy_n( input, 2, std::ostream_iterator<int>(std::cout, ",")); boost::copy_n( input, 8, std::ostream_iterator<int>(std::cout, ",")); The difference is that *copy_n* algorithm doesn't check for begin(range) != end(range) In the following line, an error occurs at runtime... boost::copy_n( input, 9, std::ostream_iterator<int>(std::cout, ",")); Unlike the following that runs ok... boost::copy( input | bounded(9), std::ostream_iterator<int>(std::cout, ",")); // prints 1,2,3,4,5,7,8,9, This behavior could be equated using *sliced(0, X)*, but sliced requires *RandomAccessRange*, unlike bounded that requires *SinglePassRange*. *bounded* code is based on *indexed* adaptor code, I think it is more efficient than *sliced* ( that uses *make_iterator_range* --> std::advance ). I don't know if this behavior can be achieved using other adapters, if so, please let me know. Is there interest in this for Boost? Regards, Fernando.

5 12

[parameter] aux_/void.hpp: potential undefined behavior
by Krzysztof Czainski 05 Nov '11

05 Nov '11

Hello, Here's boost/aux_/void.hpp contents, without include quards and license note, where I marked a line with a comment to refer to it below. [code] namespace boost { namespace parameter { // A placemarker for "no argument passed." // MAINTAINER NOTE: Do not make this into a metafunction struct void_ {}; namespace aux { inline void_& void_reference() { static void_ instance; // (1) return instance; } } // namespace aux }} // namespace boost::parameter [/code] My question is: is it allowed to use an instance of an uninitialized empty struct? The struct void_ is empty. On line (1) a static uninitialized instance of struct void_ is defined, and it is then returned. Does the standard allow this? I can't imagine any real problems with this, but I'm curious if this has defined behavior according to the standard. A natural and simple solution to my concern is of course to change the line (1) to: static void_ instance = {}; I'd be happy to create a ticket with a patch, if my concern is valid. Regards, Kris

3 5

[lockfree] review
by Gordon Woodhull 05 Nov '11

05 Nov '11

Hi Tim, Hopefully I'll have at least a partial review. I only know enough about the subject to be a little dangerous. (One course in concurrent data structures, one successfully implemented lockfree hash table - except for the memory reclamation. Unspecified barriers and ABA problems. :p ) Considering the difficulty of the subject, you seem to have carefully chosen a small set of algorithms where at least there is consensus that the sources you are using have solved the problem correctly. I apologize if this has already been covered, but I don't see anything in the documentation about which platforms and compilers this has been tested on. These algorithms are extremely susceptible to compiler and processor optimizations. Anyway, I thought I would try to run the tests, and maybe try changing the testing methodology a little, but I got a few compiler errors, below. Defining uint fixed most of these, but bench_1.cpp also appears to be out of date? Of course I also have my lack of understanding of boost build library linking to contend with. Hope to try again later. Cheers, Gordon ~/lib/boost_lockfree/libs/lockfree/test ~/src/boost-trunk grodo-mcwoohu:test gordon$ bjam ...found 141 targets... ...updating 21 targets... darwin.compile.c++ ../../../bin.v2/libs/lockfree/test/bench_1.test/darwin-4.5.3/debug/threading-multi/bench_1.o g++: unrecognized option '-no-cpp-precomp' bench_1.cpp: In function 'void test_fifo_pop()': bench_1.cpp:67:23: error: no matching function for call to 'boost::lockfree::fifo<long int>::dequeue(long int*)' ../../../boost/lockfree/fifo.hpp:214:10: note: candidate is: bool boost::lockfree::detail::fifo<T, freelist_t, Alloc>::dequeue(T&) [with T = long int, freelist_t = boost::lockfree::caching_freelist_t, Alloc = std::allocator<long int>] bench_1.cpp: In function 'void test_fifo_pop_unsafe()': bench_1.cpp:77:30: error: no matching function for call to 'boost::lockfree::fifo<long int>::dequeue_unsafe(long int*)' ../../../boost/lockfree/fifo.hpp:255:10: note: candidate is: bool boost::lockfree::detail::fifo<T, freelist_t, Alloc>::dequeue_unsafe(T&) [with T = long int, freelist_t = boost::lockfree::caching_freelist_t, Alloc = std::allocator<long int>] bench_1.cpp: In function 'void test_stack_pop()': bench_1.cpp:87:19: error: no matching function for call to 'boost::lockfree::stack<long int>::pop(long int*)' ../../../boost/lockfree/stack.hpp:179:10: note: candidate is: bool boost::lockfree::stack<T, freelist_t, Alloc>::pop(T&) [with T = long int, freelist_t = boost::lockfree::caching_freelist_t, Alloc = std::allocator<long int>] bench_1.cpp: In function 'void test_stack_pop_unsafe()': bench_1.cpp:97:26: error: no matching function for call to 'boost::lockfree::stack<long int>::pop_unsafe(long int*)' ../../../boost/lockfree/stack.hpp:207:10: note: candidate is: bool boost::lockfree::stack<T, freelist_t, Alloc>::pop_unsafe(T&) [with T = long int, freelist_t = boost::lockfree::caching_freelist_t, Alloc = std::allocator<long int>] "g++" -ftemplate-depth-128 -O0 -fno-inline -Wall -g -dynamic -no-cpp-precomp -gdwarf-2 -fexceptions -fPIC -I"../../.." -c -o "../../../bin.v2/libs/lockfree/test/bench_1.test/darwin-4.5.3/debug/threading-multi/bench_1.o" "bench_1.cpp" ...failed darwin.compile.c++ ../../../bin.v2/libs/lockfree/test/bench_1.test/darwin-4.5.3/debug/threading-multi/bench_1.o... ...skipped <p../../../bin.v2/libs/lockfree/test/bench_1.test/darwin-4.5.3/debug/threading-multi>bench_1 for lack of <p../../../bin.v2/libs/lockfree/test/bench_1.test/darwin-4.5.3/debug/threading-multi>bench_1.o... ...skipped <p../../../bin.v2/libs/lockfree/test/bench_1.test/darwin-4.5.3/debug/threading-multi>bench_1.run for lack of <p../../../bin.v2/libs/lockfree/test/bench_1.test/darwin-4.5.3/debug/threading-multi>bench_1... darwin.compile.c++ ../../../bin.v2/libs/lockfree/test/fifo_test.test/darwin-4.5.3/debug/threading-multi/fifo_test.o g++: unrecognized option '-no-cpp-precomp' fifo_test.cpp:103:18: error: 'uint' does not name a type fifo_test.cpp: In member function 'void fifo_tester<freelist_t>::add()': fifo_test.cpp:116:14: error: 'uint' was not declared in this scope fifo_test.cpp:116:19: error: expected ';' before 'i' fifo_test.cpp:116:26: error: 'i' was not declared in this scope fifo_test.cpp:116:31: error: 'nodes_per_thread' was not declared in this scope fifo_test.cpp: In member function 'void fifo_tester<freelist_t>::run()': fifo_test.cpp:187:1: error: 'nodes_per_thread' was not declared in this scope "g++" -ftemplate-depth-128 -O0 -fno-inline -Wall -g -dynamic -no-cpp-precomp -gdwarf-2 -fexceptions -fPIC -I"../../.." -c -o "../../../bin.v2/libs/lockfree/test/fifo_test.test/darwin-4.5.3/debug/threading-multi/fifo_test.o" "fifo_test.cpp" ...failed darwin.compile.c++ ../../../bin.v2/libs/lockfree/test/fifo_test.test/darwin-4.5.3/debug/threading-multi/fifo_test.o... ...skipped <p../../../bin.v2/libs/lockfree/test/fifo_test.test/darwin-4.5.3/debug/threading-multi>fifo_test for lack of <p../../../bin.v2/libs/lockfree/test/fifo_test.test/darwin-4.5.3/debug/threading-multi>fifo_test.o... ...skipped <p../../../bin.v2/libs/lockfree/test/fifo_test.test/darwin-4.5.3/debug/threading-multi>fifo_test.run for lack of <p../../../bin.v2/libs/lockfree/test/fifo_test.test/darwin-4.5.3/debug/threading-multi>fifo_test... darwin.link ../../../bin.v2/libs/lockfree/test/freelist_test.test/darwin-4.5.3/debug/threading-multi/freelist_test ld: library not found for -lboost_thread collect2: ld returned 1 exit status "g++" -o "../../../bin.v2/libs/lockfree/test/freelist_test.test/darwin-4.5.3/debug/threading-multi/freelist_test" "../../../bin.v2/libs/lockfree/test/freelist_test.test/darwin-4.5.3/debug/threading-multi/freelist_test.o" -lboost_thread -lboost_unit_test_framework -g ...failed darwin.link ../../../bin.v2/libs/lockfree/test/freelist_test.test/darwin-4.5.3/debug/threading-multi/freelist_test... ...skipped <p../../../bin.v2/libs/lockfree/test/freelist_test.test/darwin-4.5.3/debug/threading-multi>freelist_test.run for lack of <p../../../bin.v2/libs/lockfree/test/freelist_test.test/darwin-4.5.3/debug/threading-multi>freelist_test... darwin.compile.c++ ../../../bin.v2/libs/lockfree/test/ringbuffer_test.test/darwin-4.5.3/debug/threading-multi/ringbuffer_test.o g++: unrecognized option '-no-cpp-precomp' ringbuffer_test.cpp:209:14: error: 'uint' does not name a type ringbuffer_test.cpp: In member function 'void ringbuffer_tester::add()': ringbuffer_test.cpp:225:14: error: 'uint' was not declared in this scope ringbuffer_test.cpp:225:19: error: expected ';' before 'i' ringbuffer_test.cpp:225:26: error: 'i' was not declared in this scope ringbuffer_test.cpp:225:31: error: 'nodes_per_thread' was not declared in this scope ringbuffer_test.cpp: In member function 'void ringbuffer_tester::run()': ringbuffer_test.cpp:284:1: error: 'nodes_per_thread' was not declared in this scope ringbuffer_test.cpp: In member function 'void ringbuffer_tester_buffering::add()': ringbuffer_test.cpp:315:14: error: 'uint' was not declared in this scope ringbuffer_test.cpp:315:19: error: expected ';' before 'i' ringbuffer_test.cpp:315:26: error: 'i' was not declared in this scope ringbuffer_test.cpp:315:31: error: 'nodes_per_thread' was not declared in this scope ringbuffer_test.cpp: In member function 'void ringbuffer_tester_buffering::run()': ringbuffer_test.cpp:386:1: error: 'nodes_per_thread' was not declared in this scope

8 63

Re: [boost] [lockfree] review
by Boehm, Hans 05 Nov '11

05 Nov '11

[Dave Abrahams pointed me at this thread.] Alexander Terekhov <terekhov <at> web.de> writes: > > Dave Abrahams wrote: > > > > on Thu Aug 25 2011, Alexander Terekhov <terekhov-AT-web.de> wrote: > > > > > Ilya Sokolov wrote: > > >> > > >> > > >> AFAIK, in the example above another thread can't observe reordering > > >> without introducing UB. > > > > > > I meant "observed" as in "check the sequence of writes in the generated > > > code". > > > > Do we care about what the generated code looks like? IIUC what counts > > is the sequence of memory states that another another thread can see. > > > > > But int can be simply changed to relaxed atomic<int> so that another > > > thread can observe reordering without UB. > > > > Sure. > > I meant that for the example upthread, with an int instead of relaxed > atomic<int>, another thread's code triggering UB does not prevent us > from observing reordered writes in the writing thread's code (in > generated code), by looking at it. > > Changing int to relaxed atomic<int> simply removes UB but does not > change the relevant code in the writing thread. > > regards, > alexander. > I agree with Alexander and most of the recent postings. If I write mx.lock(); x = 1; mx.unlock(); my.lock(); y = 1; my.unlock(); There is nothing to prevent the stores to x and y from becoming visible out of order at the hardware level. Enforcing ordering here would add needless and substantial cost. But a data-race-free program cannot observe such reordering. (One reference for that is Sarita Adve's and my PLDI 08 paper. Unofficial TR version at http://www.hpl.hp.com/techreports/2008/HPL-2008- 56.html. I believe Mark Batty et al have a much more complete and formal proof.) If we change x and y to be atomic variables, and the stores to be memory_order_relaxed, then an observer can tell the difference. I.e. if x and y are initially zero, and another thread does r1 = y; r2 = x; (or the acquire versions), it can see r1 = 1 and r2 = 0, since there are no synchronizes-with relationships between threads, and thus nothing to enforce ordering. If you use memory_order_relaxed, or even the acquire/release forms, things do get MUCH more complicated. The equivalent rules for other languages are an interesting story. I believe Posix implentors assume the above rules. I have a PPoPP 2007 paper that explains why that's not exactly what Posix actually states. OpenMP 3.0 has stricter rules which are also not consistently obeyed, and are somewhat fixed in OpenMP 3.1. (See my MSPC 11 paper for some details.) Java has arguably the same rules as C++ in this respect. In my mind, the main way in which sequential consistency differs from the cheaper acquire/release semantics that Alexander wants is that a) Dekker's algorithm (which by itself isn't that practically interesting), plus a number of real lock-free algorithms (which do matter) don't work. b) In my mind, acquire/release is a far more difficult model to explain to non- experts than the model for C++ with only sequentially consistent atomics. You can no longer reason about interleaving thread actions, either for purposes of determining the existence of a data-race, nor when defining what data-race- free programs mean. This was extensively discussed in C++ meetings starting in about 2005. The current solution with default-sequentially-consistent atomics, but explicit support for weaker ordering, was the resulting committee compromise. Hans

6 19

Determining interest in Delegates submission
by Jared McKee 05 Nov '11

05 Nov '11

I would like to determine interest in a possible library submission. I have written some code which converts a member function and object pointer combination to a free function for use in C style callbacks. It has some limitations which I will describe shortly. The basic idea is to be able to convert: R (B::*)(T0,T1,…) and B* to R (*)(T0,T1,…) Here's an example usage: class foo { int x; int test(int v) {return x + v;} }; foo* a = new foo; a->x = 3; int (*f)(int) = delegate(a, &foo::inc); cout << f(4) << endl; // outputs "7" When I first attempted this I used a technique where I allocated some executable memory in the heap and dynamically created a free function to call the member function for the instance. It was fun attempting that but, as you can imagine, as soon as I used the optimizer flags on my compiler I would get segment faults :) My second approach was to use templates and the Boost Preprocessor library to create appropriate static arrays of pointers to free functions matching the required signatures and then hand those pointers out each time the delegate() function is called. The two downsides to this are: you can only call delegate() for a certain function signature a limited number of times, and it adds a lot of potentially unused code to your executable. Here's the code (I've stripped out error checking for the sake of illustration): #include <boost/preprocessor.hpp> #ifndef _delegate_h_ #define _delegate_h_ #define MAX_DELEGATES 256 #define DELEGATE_PARAMS 0 #include "delegate_template.hpp" #undef DELEGATE_PARAMS #define DELEGATE_PARAMS 1 #include "delegate_template.hpp" #undef DELEGATE_PARAMS // … #endif // delegate_template.hpp #define DELEGATE_STORE BOOST_PP_CAT(DELEGATE_STORE,**DELEGATE_PARAMS) template <class B, class R BOOST_PP_ENUM_TRAILING_PARAMS(**DELEGATE_PARAMS, class T) > struct DELEGATE_STORE { typedef B* objectPointer; typedef R (B::*memberFunction)( BOOST_PP_ENUM_PARAMS(DELEGATE_**PARAMS, T) ); typedef R (*freeFunction)( BOOST_PP_ENUM_PARAMS(DELEGATE_**PARAMS, T) ); static int delegateCount; static int delegateMax; static objectPointer delegateObjectPointer[MAX_**DELEGATES]; static memberFunction delegateMemberFunction[MAX_**DELEGATES]; template <int i> static R func( BOOST_PP_ENUM_BINARY_PARAMS(**DELEGATE_PARAMS, T, v) ) { return (delegateObjectPointer[i]->***delegateMemberFunction[i])( BOOST_PP_ENUM_PARAMS(DELEGATE_**PARAMS, v) ); } static const freeFunction delegateFreeFunction[MAX_**DELEGATES]; static freeFunction getDelegate(objectPointer o, memberFunction m) { int delegateIndex = delegateCount++; delegateObjectPointer[**delegateIndex] = o; delegateMemberFunction[**delegateIndex] = m; return delegateFreeFunction[**delegateIndex]; } }; template <class B, class R BOOST_PP_ENUM_TRAILING_PARAMS(**DELEGATE_PARAMS, class T) > int DELEGATE_STORE<B,R BOOST_PP_ENUM_TRAILING_PARAMS(**DELEGATE_PARAMS, T) >::delegateCount = 0; template <class B, class R BOOST_PP_ENUM_TRAILING_PARAMS(**DELEGATE_PARAMS, class T) > int DELEGATE_STORE<B,R BOOST_PP_ENUM_TRAILING_PARAMS(**DELEGATE_PARAMS, T) >::delegateMax = MAX_DELEGATES; template <class B, class R BOOST_PP_ENUM_TRAILING_PARAMS(**DELEGATE_PARAMS, class T) > typename DELEGATE_STORE<B,R BOOST_PP_ENUM_TRAILING_PARAMS(**DELEGATE_PARAMS, T) >::memberFunction DELEGATE_STORE<B,R BOOST_PP_ENUM_TRAILING_PARAMS(**DELEGATE_PARAMS, T) > ::delegateMemberFunction[MAX_**DELEGATES] = {0}; > template <class B, class R BOOST_PP_ENUM_TRAILING_PARAMS(**DELEGATE_PARAMS, class T) > typename DELEGATE_STORE<B,R BOOST_PP_ENUM_TRAILING_PARAMS(**DELEGATE_PARAMS, T) >::objectPointer DELEGATE_STORE<B,R BOOST_PP_ENUM_TRAILING_PARAMS(**DELEGATE_PARAMS, T) > ::delegateObjectPointer[MAX_**DELEGATES] = {0}; > #define FUNC_POINTER(z, n, params) &DELEGATE_STORE<B,R BOOST_PP_ENUM_TRAILING_PARAMS(**DELEGATE_PARAMS, T) >::template func< n >, template <class B, class R BOOST_PP_ENUM_TRAILING_PARAMS(**DELEGATE_PARAMS, class T) > const typename DELEGATE_STORE<B,R BOOST_PP_ENUM_TRAILING_PARAMS(**DELEGATE_PARAMS, T) >::freeFunction DELEGATE_STORE<B,R BOOST_PP_ENUM_TRAILING_PARAMS(**DELEGATE_PARAMS, T) > ::delegateFreeFunction[MAX_**DELEGATES] = { > BOOST_PP_REPEAT(MAX_DELEGATES, FUNC_POINTER,) }; template <class B, class R BOOST_PP_ENUM_TRAILING_PARAMS(**DELEGATE_PARAMS, class T) > R (*delegate( B* b, R (B::*f)( BOOST_PP_ENUM_PARAMS(DELEGATE_**PARAMS, T) ) ))( BOOST_PP_ENUM_PARAMS(DELEGATE_**PARAMS, T) ) { return DELEGATE_STORE<B,R BOOST_PP_ENUM_TRAILING_PARAMS(**DELEGATE_PARAMS, T) >::getDelegate(b, f); } // end Thankyou very much if you managed to read all the way to here! By the way, this is my first active participation in any open source project :) Jared

3 5

[BGL] map_as_graph.hpp
by Shaun Jackman 04 Nov '11

04 Nov '11

Hi, In the spirit of vector_as_graph.hpp, I created map_as_graph.hpp. One useful feature is that the vertex_descriptor can be any user-defined type, such as a string or an arbitrary object. It's not in a form that's ready to be included in Boost, but I have found it occasionally useful. I though I'd post it in the case that someone else found it useful. If someone found it useful enough that he or she where interested in further developing to the point where it could be included in Boost, please be my guest. Cheers, Shaun #ifndef MAP_AS_GRAPH_HPP #define MAP_AS_GRAPH_HPP 1 #include <boost/graph/graph_traits.hpp> #include <cassert> #include <map> #include <utility> // for make_pair namespace boost { /** * A std::map is a model of a directed graph. * @author Shaun Jackman <sjackman(a)gmail.com> */ template <typename V, typename T> struct graph_traits<std::map<V, T> > { // Graph typedef V vertex_descriptor; typedef boost::directed_tag directed_category; struct traversal_category : boost::adjacency_graph_tag, boost::vertex_list_graph_tag { }; typedef boost::disallow_parallel_edge_tag edge_parallel_category; // IncidenceGraph typedef std::pair<vertex_descriptor, vertex_descriptor> edge_descriptor; typedef size_t degree_size_type; /** Iterate through the out edges of a vertex. */ struct out_edge_iterator : std::map<V, typename T::mapped_type>::const_iterator { typedef typename std::map<V, typename T::mapped_type>::const_iterator It; out_edge_iterator(const It& it, vertex_descriptor src) : It(it), m_src(src) { } edge_descriptor operator*() const { return edge_descriptor(m_src, It::operator*().first); } private: vertex_descriptor m_src; }; // BidirectionalGraph typedef void in_edge_iterator; // AdjacencyGraph /** Iterate through the adjacent vertices of a vertex. */ struct adjacency_iterator : std::map<V, typename T::mapped_type>::const_iterator { typedef typename std::map<V, typename T::mapped_type>::const_iterator It; adjacency_iterator(const It& it) : It(it) { } const vertex_descriptor& operator*() const { return It::operator*().first; } }; // VertexListGraph /** Iterate through the vertices of this graph. */ struct vertex_iterator : std::map<V, T>::const_iterator { typedef typename std::map<V, T>::const_iterator It; vertex_iterator(const It& it) : It(it) { } const vertex_descriptor& operator*() const { return It::operator*().first; } }; typedef size_t vertices_size_type; // EdgeListGraph typedef void edge_iterator; typedef void edges_size_type; }; // graph_traits<std::map> // IncidenceGraph template <typename V, typename T> std::pair< typename graph_traits<std::map<V, T> >::out_edge_iterator, typename graph_traits<std::map<V, T> >::out_edge_iterator> out_edges( typename graph_traits<std::map<V, T> >::vertex_descriptor u, const std::map<V, T>& g) { typedef typename graph_traits<std::map<V, T> >::out_edge_iterator out_edge_iterator; typename std::map<V, T>::const_iterator it = g.find(u); assert(it != g.end()); return make_pair( out_edge_iterator(it->second.begin(), u), out_edge_iterator(it->second.end(), u)); } template <typename V, typename T> typename graph_traits<std::map<V, T> >::degree_size_type out_degree( typename graph_traits<std::map<V, T> >::vertex_descriptor u, const std::map<V, T>& g) { typename std::map<V, T>::const_iterator it = g.find(u); assert(it != g.end()); return it->second.size(); } // AdjacencyGraph template <typename V, typename T> std::pair<typename graph_traits<std::map<V, T> >::adjacency_iterator, typename graph_traits<std::map<V, T> >::adjacency_iterator> adjacent_vertices( typename graph_traits<std::map<V, T> >::vertex_descriptor u, const std::map<V, T>& g) { typename std::map<V, T>::const_iterator it = g.find(u); assert(it != g.end()); return make_pair(it->second.begin(), it->second.end()); } // VertexListGraph template <typename V, typename T> std::pair<typename graph_traits<std::map<V, T> >::vertex_iterator, typename graph_traits<std::map<V, T> >::vertex_iterator> vertices(const std::map<V, T>& g) { return make_pair(g.begin(), g.end()); } // AdjacencyMatrix template <typename V, typename T> std::pair< typename graph_traits<std::map<V, T> >::edge_descriptor, bool> edge( typename graph_traits<std::map<V, T> >::vertex_descriptor u, typename graph_traits<std::map<V, T> >::vertex_descriptor v, std::map<V, T>& g) { typename std::map<V, T>::const_iterator it = g.find(u); return std::make_pair(make_pair(u, v), it == g.end() ? false : it->second.count(v) > 0); } // VertexMutableGraph template <typename V, typename T> void remove_vertex( typename graph_traits<std::map<V, T> >::vertex_descriptor u, std::map<V, T>& g) { size_t n = g.erase(u); assert(n == 1); (void)n; } // EdgeMutableGraph template <typename V, typename T> void clear_out_edges( typename graph_traits<std::map<V, T> >::vertex_descriptor u, std::map<V, T>& g) { typename std::map<V, T>::iterator it = g.find(u); assert(it != g.end()); it->second.clear(); } template <typename V, typename T> std::pair< typename graph_traits<std::map<V, T> >::edge_descriptor, bool> add_edge( typename graph_traits<std::map<V, T> >::vertex_descriptor u, typename graph_traits<std::map<V, T> >::vertex_descriptor v, std::map<V, T>& g) { typename edge_property<std::map<V, T> >::type ep; return make_pair(std::make_pair(u, v), g[u].insert(make_pair(v, ep)).second); } template <typename V, typename T> void remove_edge( typename graph_traits<std::map<V, T> >::vertex_descriptor u, typename graph_traits<std::map<V, T> >::vertex_descriptor v, std::map<V, T>& g) { size_t n = g[u].erase(v); assert(n == 1); (void)n; } // PropertyGraph template <typename V, typename T> no_property get(vertex_bundle_t, const std::map<V, T>&, typename graph_traits<std::map<V, T> >::vertex_descriptor) { return no_property(); } template <typename V, typename T> const typename T::mapped_type& get(edge_bundle_t, const std::map<V, T>& g, typename graph_traits<std::map<V, T> >::edge_descriptor e) { typename std::map<V, T>::const_iterator u = g.find(source(e, g)); assert(u != g.end()); typename T::const_iterator v = u->second.find(target(e, g)); assert(v != u->second.end()); return v->second; } // MutablePropertyGraph namespace boost { template <typename V, typename T> class vertex_property<std::map<V, T> > { public: typedef no_property type; }; template <typename V, typename T> class edge_property<std::map<V, T> > { public: typedef typename T::mapped_type type; }; } template <typename V, typename T> std::pair< typename graph_traits<std::map<V, T> >::edge_descriptor, bool> add_edge( typename graph_traits<std::map<V, T> >::vertex_descriptor u, typename graph_traits<std::map<V, T> >::vertex_descriptor v, typename edge_property<std::map<V, T> >::type ep, std::map<V, T>& g) { return make_pair(std::make_pair(u, v), g[u].insert(std::make_pair(v, ep)).second); } } // namespace boost #endif

1 0

Remembering that T(a) can cause dangerous conversion like a C-style cast
by Kazutoshi Satoda 04 Nov '11

04 Nov '11

An essential question: Should boost::lambda::constructor<int>()("") compiles? It does compile with Boost 1.47.0 . But I think it shouldn't. I have crafted a general replacement of T(a) as a workaround for dangerous conversions caused by T(a) which may happen in some kinds of templates. http://ideone.com/iZE1Z unary_initialized<T>(a).value And I thought of that the above workaround (or something similar) may be suitable to be provided within boost::initialized . Now I want to share the idea and to hear interests or evaluations in the community about such extension and underlying issues, before starting further acts. Here is the background story: A while ago, I had a conversation about dangerous conversion that can be caused by the following expression with variadic templates in C++11. T(std::forward<Args>(args)...) This expression is meant to obtain a prvalue of type T which is direct initialized from any given argument list. But if a single argument was given, this becomes T(std::forward<Arg>(arg)) and further, for example, may become int("") and compiles as reinterpret_cast which is likely unexpected. Here is a relevant quote from the standard 5.2.3 p1: > ... If the expression list is a single expression, the type conversion > expression is equivalent (in definedness, and if defined in meaning) to > the corresponding cast expression (5.4). ... (Note: 5.2.3 describes the behavior of T(a), and 5.4 describes the behavior of (T)a.) To avoid the unexpected conversion, I first proposed use of T{...} . But it is not a perfect solution because it changes the meaning in some cases like std::vector<int> . After that, I crafted a tricky workaround. http://ideone.com/FLoDk pack_initialized<T>(std::forward<Args>(args)...).value The above story was about C++11. But it revealed that similar dangerous conversion can be also formed in C++98, C++03 as T(a) in some kinds of templates. Searching in the boost directory (trunk r75213), I found some occurrences of the problem: boost/lambda/construct.hpp:37: http://www.boost.org/doc/libs/1_47_0/boost/lambda/construct.hpp return T(a1); boost/xpressive/regex_actions.hpp:632: http://www.boost.org/doc/libs/1_47_0/boost/xpressive/regex_actions.hpp return T(a0); As shown in the top of this message, I picked boost::lambda::constructor as a concrete example, and verified that the problem really exists in the wild. Thinking more, I wonder why such dangerous conversion was explicitly injected to T(a) in the first place. I first thought of some C-compatibility issues. But now I think it cannot be, because T(a) is a new construct in C++. Is it possible to remove this dangerous conversion path in a future revision of the standard? Perhaps I should go to comp.std.c++ about the last question. -- k_satoda

2 2

[release][1.48] Several merge requests
by Daniel James 04 Nov '11

04 Nov '11

Hi, Please can I merge the following changes: This prevents standard containers from being forward declared for gcc's 'profile' mode: https://svn.boost.org/trac/boost/changeset/75016 Trivial change to improve a couple of quickbook warnings (obviously not vital, but simple enough): https://svn.boost.org/trac/boost/changeset/75088 In unordered, avoid using a name that clashes with a macro defined by a header included from ASIO: https://svn.boost.org/trac/boost/changeset/75123 Missing html redirect, fixes some links to Boost.Move (documentation change): https://svn.boost.org/trac/boost/changeset/75141 Unordered wasn't working on gcc 4.7 in c++0x mode because of changes to std::pair's constructor. Unfortunately, the gcc 4.7 tester hasn't run since this change and I don't have access to it, so I haven't verified that it fixes the problem. But it does work fine on everything it has been tested with. https://svn.boost.org/trac/boost/changeset/75158 This stops using a hack on Visual C++ which was breaking for certain versions (although it didn't show up on any tester). But this is moving from a hacky implementation to a slightly less capable but more reliable implementation, so I think it's a good change regardless. https://svn.boost.org/trac/boost/changeset/75167 thanks, Daniel

2 1

"Best so far" for C level i/o of Unicode text with Windows console
by Alf P. Steinbach 03 Nov '11

03 Nov '11

This may be of interest to developers of Boost libraries that deal with text. I found that the Visual C++ implementation of the C library i/o generally does not support console input of international characters. It can deal with narrow character input from the current codepage, if that codepage is not UTF-8. For example: <code> #include <stdio.h> int main() { printf( "? " ); char buffer[80]; scanf( "%s", buffer ); printf( "%s\n", buffer ); } </code> <result> d:\dev\test> chcp 1252 Active code page: 1252 d:\dev\test> utf8test ? abcæøå abcæøå d:\dev\test> chcp 65001 Active code page: 65001 d:\dev\test> utf8test ? abcæøå ��, d:\dev\test> _ </result> I placed a comment about this at the blog of Microsoft's Unicode guru Michael Kaplan, http://blogs.msdn.com/b/michkap/archive/2008/03/18/8306597.aspx In particular, with active codepage 65001 (UTF-8), functions such as wscanf just fail outright on non-ASCII characters. The IMO best compromise that I have managed to come up with is a kind of hybrid, where the active input codepage is set to 1252, Windows ANSI Western, because that's a superset of Latin 1 which is a subset of Unicode. Output is converted to UTF-8. Input from e.g. a file accepts UTF-8. This means that e.g. Norwegian text can be input interactively (restricted to Latin 1 character set) or from a pipe or file (as UTF-8) without problems, and can be automatically translated (by the C i/o level) to UTF-16 encoding inside the program. However, I'm guessing that the C level input will garble e.g. Russian text no matter what one does, if one desires some Unicode based encoding inside the program. The Windows and Visual C++ support is just full of bugs -- e.g. as the crash of `more` showed in an earlier thread. Initialization of streams for the compromize scheme: static void msvcCompatibleInit() { struct Fix { static void mode( FILE* f, char const errorText[] ) { int const fileNo = _fileno( f ); bool const isConsoleInput = (f == stdin && _isatty( fileNo )); if( isConsoleInput ) { // Bytes are received as per the active codepage in the console. // Except if that active codepage is 65001, in which case non-ASCII // characters fail. Also, _setmode just causes non-ASCII fail. // // Setting the console codepage to 1252 might be practically helpful, // since cp 1252, Windows ANSI Western, is a superset of Latin 1 // which is a subset of Unicode. However, non-Latin 1 characters will // then be incorrect, just as with web pages in the old days. } else { int const newMode = _setmode( fileNo, _O_U8TEXT ); hopefully( newMode != -1 ) || throwX( errorText ); } } }; Fix::mode( stdin, "_setmode stdin failed" ); Fix::mode( stdout, "_setmode stdout failed" ); Fix::mode( stderr, "_setmode stderr failed" ); } Cheers & hth., - Alf

3 3

[interprocess] message_queue hangs when another process dies
by Sergei Politov 03 Nov '11

03 Nov '11

Hi, I have found the following problem with message_queue on win32 (MSVC 2008 + Windows Vista). Suppose we have 2 processes, one sends messages to queue, another reads them. When reading process dies (for instance using End process) during message_queue.receive the another process hangs in send. As I found during investigation, it tries to lock interprocess mutex, but it is already locked by dead process. So this message queue instance becomes unusable. I attached the example. Steps to reproduce: 1) Start "mq.exe s" (i.e. with argument s) It outs: sender: $PID 2) Start mq.exe without arguments. It outs: receiver: $PID 0 1 2 3 4 This time sender outs: send done: 3) At this point the message queue is empty and receiver waits for messages. End it with Task Manager. 4) Enter some number in sender console and press Enter. 5) The sender hangs in message_queue.send Best Regards, Sergei

6 13

[Boost.Endian] Review Results
by joel falcou 03 Nov '11

03 Nov '11

Hi everyone, after some delay, here is the result of the review of Beman Dawes' Boost.Endian library. First, I want to thanks all participants of the review that lead to very deep and interesting discussions on the matter. 5 votes were cast : 2 unconditionally in favor, 3 conditionally in favor after changes made and there is a mini-review. The verdict is that Boost.Endian is **CONDITIONNALY ACCEPTED** Here is what needs to be done to get the library ready for a mini-review: * Common use case scenarios should be developed. * Example programs should be developed for the common use case scenarios. * Documentation should illuminate the differences between endian integer/float type and endian conversion approaches to the common use case scenarios, and provide guidelines for choosing the most appropriate approach in user's applications. * Conversion functions supplying results via return should be provided. * Platform specific performance enhancements such as use of compiler intrinsics or relaxed alignment requirements should be supported. * Endian integer (and floating) types should be implemented via the conversion functions. If that can't be done efficiently, consideration should be given to expanding the conversion function signatures to resolve the inefficiencies. * Benchmarks that measure performance should be provided. It should be possible to compare platform specific performance enhancements against portable base implementations, and to compare endian integer approaches against endian conversion approaches for the common use case scenarios. * Float (32-bits) and double (64-bits) should be supported. IEEE 754 is the primary use case. * Support for user defined types (UDTs) is desirable, and should be provided where there would be no conflict with the other concerns. * There is some concern that endian integer/float arithmetic operations might used inadvertently or inappropriately. The impact of adding an endian_buffer class without arithmetic operations should be investigated. * Stream insertion and extraction of the endian integer/float types should be documented and included in the test coverage. * Binary I/O support that was investigated during development of the Endian library should be put up for mini-review for inclusion in the Boost I/O library. From this point, I will let Beman prepare Endian for the mini-review and I already volunteer to manage the mini-review so informations are not scattered around. Regards

1 0

[tree] more questions (was: [tree] associative containers)
by Cromwell Enage 03 Nov '11

03 Nov '11

From: Erik Erlandson > I'm not entirely sure about the relative merits of that versus defining > a parallel zoology of Hierarchical Containers that is basically > isomorphic to the traditional Container hierarchy, and leaving the > cursor definition more lightweight: perhaps just "iterator plus > parent(), begin() and end()", or alternatively not having a separate > cursor type, and simply having traditional iterators over children at > any given node. I'm curious as to what tree algorithms can take better advantage of the cursor interface as-is. Also: * What are the primary differences between a plain hierarchy and a multiway hierarchy? * Why shouldn't one assume that an on-top cursor is dereferenceable? TIA, Cromwell D. Enage

1 0