- Boost - lists.boost.org

Re: [boost] Asio multithreaded server
by berserker_r 20 Nov '06

20 Nov '06

Christopher Kohlhoff wrote: > Well, yesterday I was able to reproduce the problem exactly as > you described using the performance/server test program. That > problem no long occurs for me using the latest version of asio > in CVS. Perhaps there's something different with your > application? You'll have to send a program that reproduces the > problem against the latest version in CVS. Any hope to use the CVS version of asio with boost 1.33.1? Bye

1 0

[Boost.Build] Multi-Threaded Build to Leverage Multiple Cores
by Dean Michael Berris 20 Nov '06

20 Nov '06

Hi Everyone, Is there already an option for bjam to leverage multi-core systems? I noticed that it only uses one processor in a sequential fashion. In make, there's a '-j' option to define the number of jobs to be spawned. Insights would be most appreciated. Have a great day! -- Dean Michael C. Berris C++ Software Architect Orange and Bronze Software Labs, Ltd. Co. web: http://software.orangeandbronze.com/ email: dean(a)orangeandbronze.com mobile: +63 928 7291459 phone: +63 2 8943415 other: +1 408 4049532 blogs: http://mikhailberis.blogspot.com http://3w-agility.blogspot.com http://cplusplus-soup.blogspot.com

2 2

[RC_1_34_0] Boost.Serialization in BBv2 linking requires different library name
by Dean Michael Berris 20 Nov '06

20 Nov '06

Hi Everyone, I did a recent export of the Boost RC_1_34_0 from the CVS and built it in Windows XP using MSVC 8 (edited user-config.jam to `using msvc`). I'm trying to build an application which requires Boost.Serialization and Boost.Date_Time, and I get these when I do a bjam --v2 in the application source (configured to use BBv2): LINK : fatal error LNK1104: cannot open file 'libboost_date_time-vc80-mt-gd-1_34.lib' LINK : fatal error LNK1104: cannot open file 'libboost_serialization-vc80-mt-gd-1_34.lib' I went into the lib/ directory of MSVC 8 where I set as a prefix to `bjam --v2 debug release install ` and saw that I dont have these files but noticed that I had most of the libs not containing the '80' as in 'vc80'. So instead of the above required files, I see: libboost_date_time-vc-mt-gd-1_34.lib libboost_serialization-vc-mt-gd-1_34.lib Perhaps a bug in the jam files? HTH -- Dean Michael C. Berris C++ Software Architect Orange and Bronze Software Labs, Ltd. Co. web: http://software.orangeandbronze.com/ email: dean(a)orangeandbronze.com mobile: +63 928 7291459 phone: +63 2 8943415 other: +1 408 4049532 blogs: http://mikhailberis.blogspot.com http://3w-agility.blogspot.com http://cplusplus-soup.blogspot.com

2 2

[function_types]
by Steven Watanabe 20 Nov '06

20 Nov '06

AMDG I'm not sure whether function_types is ready now or not. I don't really like the tags. Dividing the parameters into two groups (the type arguments and everything else) doesn't seem like the cleanest solution. Even with them it will sometimes be necessary to and_<> several predicates together mpl::and_<is_function<F>, mpl::equal_to<arity<F>, mpl::int_<1> > > so I think making certain properties should not be treated specially. I think that components should probably integrate all the properties a little better. Instead of making it the union of a tag and an mpl sequence would it be better to make it more like mpl metaobjects with appropriate mutators: typedef components<void(int, char)> c; typedef set_result<c, bool>::type c1 typedef set_param<c1, 0, const int&>::type c2; typedef make_variadic<c2>::type c3; typedef get<c3>::type f; // is bool(const int&, char, ...) (Although maybe set_param is asking too much since I don't see the corresponding operation in mpl.) and querying metafunctions: typedef is_variadic<c>::type b; //inherits from mpl::false_ These could be overloaded to take callable builtins too, but that might cause too much overhead translating back and forth between two representations. For both components and the synthesis metafunctions, having the result type as the first element of the sequence doesn't really make sense to me. I would expect that the return type would often need to be handled separately from the parameters in the cases where anything other than simply passing the result of components to function_type<...> is needed. I would like a way to find out what a tag is composed of. I saw represents<> in the code but it isn't documented (unless I missed it) I compiled the following on all the compilers I have with different values for N_TYPES. note that this only uses one partial specialization #include <boost/function_types/components.hpp> #include <boost/function_types/result_type.hpp> #include <boost/function_types/parameter_types.hpp> #include <boost/preprocessor/repetition/repeat.hpp> #include <boost/preprocessor/cat.hpp> #define N_TYPES ... namespace ft = boost::function_types; template<int N> struct Y {}; #define TYPE_AT(n) Y<n> #define CAT(a, b, c) BOOST_PP_CAT(a, BOOST_PP_CAT(b, BOOST_PP_CAT(_, c))) #define TYPE_NAME(n1, n2) CAT(type, n1, n2) #define FUNCTION_TYPE(z, n1, n2) typedef void TYPE_NAME(n2, n1)(TYPE_AT(n2), TYPE_AT(n1)); #define OUTER(z, n, data) BOOST_PP_REPEAT_##z(N_TYPES, data, n) #define NESTED_REPEAT(macro) BOOST_PP_REPEAT_1(N_TYPES, OUTER, macro) NESTED_REPEAT(FUNCTION_TYPE); #define USE_FT_COMPONENTS(z, n1, n2) typedef ft::parameter_types<TYPE_NAME(n2, n1)>::type CAT(component, n2, n1); NESTED_REPEAT(USE_FT_COMPONENTS); msvc 8.0 debug w/o debug N_TYPES time pp time pp 0 1 1 1 1 5 2 1 1 1 10 3 1 2 1 20 10 1 8 1 40 98 2 87 1 msvc 7.1* debug w/o debug N_TYPES time pp time pp 0 2 2 2 2 5 3 2 2 2 10 3 2 2 2 20 17 2 15 2 40 39** 2 37** 2 *I had to use -D"BOOST_FT_CONFIGURATION_OK" **fatal error C1204: compiler limit : internal structure overflow codewarrior 9.2 N_TYPES time pp 0 1 1 5 2 1 10 2 1 20 3 1 30 9 2 40 29 2 A few minor things. pp_tags/master.hpp BOOST_STATIC_CONSTANT(bits_t, combined_bits = LHS_bits ^ RHS_bits ^ (LHS_bits & RHS_mask) ); works but seems obscure to me would (LHS_bits & ~RHS_mask) | RHS_bits be clearer? Here are the mistakes I made when I looked at the documentation initially. If no one else runs into these don't worry about it. It's probably just me. I thought ClassTransform applied to all the parameters not just this. I didn't realize that components was a tag. I saw the capitalized and linked MPL <../../../../../mpl/index.html> - Front <../../../../../mpl/doc/refmanual/front-extensible-sequence.html> / Back <../../../../../mpl/doc/refmanual/back-extensible-sequence.html>Extensible <../../../../../mpl/doc/refmanual/extensible-sequence.html>Random Access Sequence <../../../../../mpl/doc/refmanual/random-access-sequence.html> of all component types and missed the trailing "... and property tag " In Christ, Steven Watanabe

3 5

Re: [boost] mistaken uses of <iostream>
by Rajat Monga 20 Nov '06

20 Nov '06

This issue is with gcc, but a much earlier version - 2.95. I had to compile my code recently with gcc 2.95 where I ran into lack of ostream issues. So this change should be done only if gcc 2.95 is not to be supported moving forward. -Rajat ----- Original Message ---- From: Beman Dawes <bdawes(a)acm.org> To: boost(a)lists.boost.org Sent: Sunday, November 19, 2006 7:12:23 PM Subject: Re: [boost] mistaken uses of <iostream> Douglas Gregor wrote: > On Nov 18, 2006, at 10:20 AM, Howard Hinnant wrote: >> I did a brief survey of boost 1.33.1 and found many "relaxed" uses of >> <iostream> under the boost/ directory (i.e. non test-case code). So >> in practice it does appear that using <iostream> as a shortcut is >> considered acceptable practice. However I wanted to highlight the >> point just in case people do view this as a bug that has simply snuck >> in under the radar to date. > > IIRC, at one point we were supporting a platform that had <iostream> > but not <istream> or <ostream>, so I got in the habit of using > <iostream> despite its cost. That platform might not matter any more, > and I'd support fixing Boost's headers to avoid including > iostream.... just not for 1.34.0 :) I agree. I have a vague recollection the platform was GCC, although that was many years ago so I may be mistaken. Out of curiosity, I changed the uses of <iostream> in my local copy of the random library to use other std headers, and it still passes regression tests for GCC 3.3.4. --Beman _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

1 0

[variant] late "review"
by David Abrahams 20 Nov '06

20 Nov '06

I'm just looking through the variant library docs in detail and had the following commments: * http://www.boost.org/regression-logs/cs-win32_metacomm/doc/html/variant/tut… shows static_visitor being used with no arguments and yet http://www.boost.org/regression-logs/cs-win32_metacomm/doc/html/boost/stati… doesn't indicate any default for the first parameter. Also, once you start using an argument in the tutorial, it comes with no explanation, which is confusing. * It's not obvious why we're deriving anything from static_visitor. It seems as though it shouldn't be necessary and that it might not be simplifying anything. * I find the dual nature of apply_visitor confusing. With two arguments it is an imperative command: "apply this visitor." With one argument it is a wrapper generator or something like that: "make this visitor into a function object that operates on variant<T0,...TN> instead of on T0, ... TN directly." [Actually, I'm not sure the latter description is accurate and it wouldn't hurt to have it spelled out in the docs.] I think it would be better to use two names rather than overloading one name in these two very different ways. * I have a very clear mental model for what a non-recursive variant is doing, which gives me a clear of its costs and of where I'd use it: it's like a supercharged union. From reading your docs it's very hard to form the same kind of mental model for a recursive variant. It would help to be explicit about what the library generates for you in the recursive case. * The make_recursive_variant example is vague. It should describe what the result is equivalent to. I presume it's something like: variant<int, ... ...uhh, interesting: I don't think you can express that example in terms of just variant and recursive_wrapper. However, the text implies that make_recursive_variant is just a less-flexible way to achieve a subset of the same goals. * binary visitation: "Notably this feature requires that binary visitors are incompatible with the visitor objects discussed in the tutorial above, as they must operate on two arguments." I don't get it. I can make an object whose function call operator overload set can operate on both 1 and 2 arguments. * It seems like visitor_ptr is a very specialized name for something very general-purpose. Doesn't bind(fp) (or some other boost construct) do the same thing? -- Dave Abrahams Boost Consulting www.boost-consulting.com

3 6

Any progress on atomic ops libraries?
by Roland Schwarz 20 Nov '06

20 Nov '06

Despite the obvious interest in lock free algorithms, we still have no atomic ops library in boost. Al though there have been some discussions on the list I did not see any real attempt to come up with such a library. I am unsure about the reasons for this: 1) Is it because it is believed that this will not be possible without language change? 2) Is it because it is too hard to do? 3) There are already some developments in preparatory, but yet unpublished state? 4) Any other, I cannot imagine? Perhaps, I am on the wrong track, but I tried to implement something along Boehms N2047 proposal. I know that this is only a prototype yet, but I'd like to spur discussion about the topic. I attach the prototype, which currently is for 32bit MSVC. I am planning to add support for gcc soon. I would be very glad if this would trigger some further development and fruitful discussions, which eventually will lead into creation of such a library. I would also be glad, if someone could tell me why there is no such library yet. Roland // (C) Roland Schwarz 2006. // Use, modification and distribution are subject to the Boost Software License, // Version 1.0. (See accompanying file LICENSE_1_0.txt or copy at // http://www.boost.org/LICENSE_1_0.txt) // #ifndef ATOMIC_HPP__ #define ATOMIC_HPP__ // Al though the following compiler intrinsics are available for // msvc-6.1, the code does not compile, due to lack of partial // specialization. extern "C" { long __cdecl _InterlockedCompareExchange(void volatile*, long, long); long __cdecl _InterlockedExchange(void volatile*, long); long __cdecl _InterlockedExchangeAdd(void volatile*, long Value); // void _ReadWriteBarrier(); } #pragma intrinsic(_InterlockedCompareExchange) #pragma intrinsic(_InterlockedExchange) #pragma intrinsic(_InterlockedExchangeAdd) //#pragma intrinsic(_ReadWriteBarrier) // The interface of the atomic class is modelled after // proposal N2047 from Hans-J Boehm. // However I did not try to implement the query interface, // nor the native part, or the emulations. // // This implementation currently is for 32bit MSVC compilers, making // use of the _Interlocked* intrinsics. Also I use the __declspec(align()) // statement to control proper alignment. I hope it will be straight // forward to find similar compiler support on other compilers as // well. // // I aimed for the following properties: // 1) atomic<user_type> is a container which can be specialized // for "user_type"s that are POD and have same size as the // native atomic type of the compiler/platform. // 2) atomic<user_type> can be extended to non POD types by // emulating atomicity with a mutex that protects ctor/dtor. // 3) Can be extended to mixed 32 bit/64 bit. // 4) Works with scalars/pointers/POD's // 5) Dependency on other libs should be as minimal as possible // to make it suitable as a core class. // 6) Shall be usable in single threaded applications too. // // Open questions: // 1) Assignments between atomic<> types are currently not allowed. // This is in line with N2047. Should this feature be added? // What would it mean? // 2) N2407 has only a boolean cas. I added the "previous value // returning" cas. I named the boolean: compare_and_store and // the other: compare_and_swap. Is this reasonable? // 3) Should the scalar types further specialized to add // atomic incr and decr operators? Same question for pointers. // 4) All ordering_constraints fall back to "ordered" unless // spezialized. Does this make sense? // 5) Currently only types of same size, where object and value // representation is same (i.e POD) are allowed to make // reinterpret_cast safe. Is there a way to capture smaller // POD types as well? E.g. atomic<bool>, atomic<short> ... namespace concurrent { enum ordering_constraint {raw, acquire, release, ordered}; template <class T, int size = sizeof(T)> struct atomic { private: // no implementation so far // could be used for mutex proteced specializations atomic(); }; // specialization for types with size of native atomic template <class T> struct atomic<T, sizeof(long)> { typedef long type; atomic(const T& x = T()) : pod(x){} // store template<ordering_constraint c> void store(const T& x) { _InterlockedExchange(&data, reinterpret_cast<const long&>(x)); } template<> void store<raw>(const T& x) { data = reinterpret_cast<volatile const long&>(x); } // load template <ordering_constraint c> T load() const { long r = _InterlockedExchangeAdd(&data, 0); return reinterpret_cast<T&>(r);} template<> T load<raw>() const { return data; } // boolean cas template <ordering_constraint c> bool compare_and_store(const T& old_val, const T& new_val) { long r = _InterlockedCompareExchange(&data, reinterpret_cast<const long&>(new_val), reinterpret_cast<const long&>(old_val)); return (reinterpret_cast<T&>(r) == old_val); } // returning previous cas template <ordering_constraint c> T compare_and_swap(const T& old_val, const T& new_val) { long r = _InterlockedCompareExchange(&data, reinterpret_cast<const long&>(new_val), reinterpret_cast<const long&>(old_val)); return reinterpret_cast<T&>(r); } operator T() const { return load<ordered>(); } void operator=(const T& x) { store<ordered>(x); } private: // the union restricts usage to POD types only union { // force the alignment to requirements of compiler // intrinsics. // mutable is necessary, because the ExchangeAdd // is used to load data, so it is only conceptually // constant in the load function. __declspec(align(4)) mutable T volatile pod; __declspec(align(4)) mutable long volatile data; }; // direct assignment between atomic types is not allowed atomic(const atomic<T, sizeof(long)>&); atomic<T,sizeof(long)>& operator=(const atomic<T,sizeof(long)>&); }; }; #endif #include "atomic.hpp" using namespace concurrent; struct POD { unsigned short low; unsigned short high; }; struct nonPOD { nonPOD() : low(0), high(0) {} unsigned short low; unsigned short high; }; enum direction { north, east, south, west }; int main(int argc, char* argv[]) { atomic<POD> atomic_POD; POD aPOD= {1,2}; atomic_POD.store<ordered>(aPOD); atomic_POD.store<raw>(aPOD); atomic_POD = aPOD; aPOD = atomic_POD; atomic<int> atomic_int; int aint = 42; atomic_int.store<ordered>(aint); atomic_int.store<raw>(aint); atomic_int = aint; aint = atomic_int; atomic<long> atomic_long; long along = 42; atomic_long.store<ordered>(along); atomic_long.store<raw>(along); atomic_long = along; along = atomic_long; atomic<int*> atomic_p; int* intp; atomic_p.store<ordered>(intp); atomic_p.store<raw>(intp); atomic_p = intp; intp = atomic_p; int prev; if (atomic_int.compare_and_store<ordered>(42,0)) { prev = atomic_int.compare_and_swap<ordered>(42,0); } atomic<direction> next_move; next_move = west; atomic<float> f; f.store<ordered>(1.2f); // the following line does not (and should not) compile //atomic<nonPOD> atomic_nonPOD; return 0; }

2 2

[Boost-bugs] [ boost-Bugs-1599422 ] gcc-4.2 atomicity.h location
by SourceForge.net 20 Nov '06

20 Nov '06

Bugs item #1599422, was opened at 2006-11-20 01:04 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1599422&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Tim Blechmann (timblech) Assigned to: Nobody/Anonymous (nobody) Summary: gcc-4.2 atomicity.h location Initial Comment: hi all, it seems, that for gcc-4.2 bits/atomicity.h, that's included by detail/atomic_count_gcc.hpp moved to ext/atomicity.h thus it's not possible to build some boost libraries with gcc-4.2. thanks ... tim ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1599422&group_… ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

[graph] incremental_components bug
by Chris Weed 19 Nov '06

19 Nov '06

Hi, I have submitted this once before, and I didn't get any response. I am trying to use incremental connected components to find the connected components of an image as I randomly add pixels to the image. The graph is updated by adding edges between the added pixel and it's four neighbors (2,3 neighbors on the image edges). I calculate the number of components after each pixel is added. This crashes when I try to create the component_index at line 70 on windows using vc-8.0. Any help would be greatly appreciated. This code works when I use regular connected_components. Thanks, Chris #include <boost/graph/graph_utility.hpp> #include <boost/graph/adjacency_list.hpp> #include <boost/pending/disjoint_sets.hpp> #include <boost/graph/incremental_components.hpp> #include <algorithm> #include <numeric> #include <boost/multi_array.hpp> int main() { // Image size size_t width = 100; size_t height = 100; // Create vector of randomized indices std::vector<size_t> indices(width*height,1); indices[0] = 0; std::partial_sum(indices.begin(),indices.end(),indices.begin()); std::random_shuffle(indices.begin(),indices.end()); // Create image which holds which pixels were stored by their linear index boost::multi_array<size_t,2> added_pixels(boost::extents[height][width]); for(size_t i=0;i<height;++i) for(size_t j=0;j<width;++j) added_pixels[i][j] = 0; using namespace boost; typedef adjacency_list<vecS,vecS,undirectedS> Graph; typedef graph_traits<Graph>::vertex_descriptor Vertex; typedef graph_traits<Graph>::vertices_size_type size_type; Graph G(indices.size()); std::vector<size_type> rank(num_vertices(G)); std::vector<Vertex> parent(num_vertices(G)); typedef size_type* Rank; typedef Vertex* Parent; disjoint_sets<Rank,Parent> ds(&rank[0],&parent[0]); initialize_incremental_components(G,ds); incremental_components(G,ds); // Loop over indices and add pixels to image, and edges to graph std::vector<size_t>::iterator b_iter = indices.begin(); for(;b_iter!=indices.end();++b_iter) { size_t r = (*b_iter)/width; size_t c = (*b_iter)%width; size_t j = *b_iter; added_pixels[r][c] = j; if(r>0 && added_pixels[r-1][c]) { add_edge(j,added_pixels[r-1][c],G); ds.union_set(j,added_pixels[r-1][c]); } if(r<(height-1) && added_pixels[r+1][c]) { add_edge(j,added_pixels[r+1][c],G); ds.union_set(j,added_pixels[r+1][c]); } if(c>0 && added_pixels[r][c-1]) { add_edge(j,added_pixels[r][c-1],G); ds.union_set(j,added_pixels[r][c-1]); } if(c<(width-1) && added_pixels[r][c+1]) { add_edge(j,added_pixels[r][c+1],G); ds.union_set(j,added_pixels[r][c+1]); } // After each pixel is added and connected, compute the number of cc's typedef component_index<unsigned int> Components; Components comp(parent.begin(),parent.end()); std::cout << comp.size() << std::endl; } return 0; }

2 2

Which libs *don't* support auto-linking?
by David Abrahams 19 Nov '06

19 Nov '06

I need this info for the 1.34 getting started guide. I know Boost.Python is among them. Any others? -- Dave Abrahams Boost Consulting www.boost-consulting.com

1 0