- Boost - lists.boost.org

[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

Boost regression notification (2006-11-19 [RC_1_34_0])
by Douglas Gregor 19 Nov '06

19 Nov '06

Boost Regression test failures Report time: 2006-11-19T13:18:19Z This report lists all regression test failures on release platforms. Detailed report: http://engineering.meta-comm.com/boost-regression/CVS-RC_1_34_0/developer/i… 275 failures in 23 libraries concept_check (60) date_time (2) filesystem (1) graph (2) io (1) iostreams (10) iterator (3) lambda (1) math (24) mpl (3) numeric/interval (2) optional (1) parameter (2) python (117) random (1) regex (4) serialization (7) signals (4) spirit (3) statechart (13) test (12) thread (1) utility (1) |concept_check| class_concept_fail_expected: borland-5.6.4 borland-5.8.2 borland-5.8.2 cw-9.4 darwin-4.0.1 gcc-3.2.3_linux gcc-3.3.6 gcc-3.3.6_linux gcc-3.4.4 gcc-3.4.5_linux gcc-3.4.5_linux_x86_64 gcc-4.0.3_linux gcc-4.1.0_linux gcc-4.1.0_linux_x86_64 gcc-4.1.1_sunos_i86pc hp_cxx-71_006_tru64 intel-linux-9.0 intel-vc71-win-9.1 intel-vc8-win-9.1 msvc-6.5 msvc-7.0 msvc-7.1 msvc-7.1 msvc-8.0 msvc-8.0 qcc-3.3.5_cpp qcc-3.3.5_cpp qcc-3.3.5_gpp qcc-3.3.5_gpp sun-5.8 concept_check_fail_expected: borland-5.6.4 borland-5.8.2 borland-5.8.2 cw-9.4 darwin-4.0.1 gcc-3.2.3_linux gcc-3.3.6 gcc-3.3.6_linux gcc-3.4.4 gcc-3.4.5_linux gcc-3.4.5_linux_x86_64 gcc-4.0.3_linux gcc-4.1.0_linux gcc-4.1.0_linux_x86_64 gcc-4.1.1_sunos_i86pc hp_cxx-71_006_tru64 intel-linux-9.0 intel-vc71-win-9.1 intel-vc8-win-9.1 msvc-6.5 msvc-7.0 msvc-7.1 msvc-7.1 msvc-8.0 msvc-8.0 qcc-3.3.5_cpp qcc-3.3.5_cpp qcc-3.3.5_gpp qcc-3.3.5_gpp sun-5.8 |date_time| testduration: borland-5.8.2 testgenerators_dll: gcc-4.1.0_linux |filesystem| fstream_test: msvc-6.5 |graph| adj_list_cc: qcc-3.3.5_gpp bfs: intel-linux-9.0 |io| ios_state_test: borland-5.8.2 |iostreams| bzip2_test: msvc-7.1 msvc-8.0 file_descriptor_test: cw-9.4 finite_state_filter_test: cw-9.4 gzip_test: msvc-7.1 msvc-8.0 mapped_file_test: cw-9.4 newline_test: borland-5.8.2 zlib_test: msvc-7.1 msvc-8.0 |iterator| filter_iterator_test: borland-5.8.2 lvalue_concept_fail: borland-5.8.2 msvc-7.1 |lambda| bind_tests_simple: intel-linux-9.0 |math| common_factor_test: borland-5.8.2 cw-9.4 darwin-4.0.1 gcc-3.2.3_linux gcc-3.3.6 gcc-3.3.6_linux gcc-3.4.4 gcc-3.4.5_linux gcc-3.4.5_linux_x86_64 gcc-4.0.3_linux gcc-4.1.0_linux gcc-4.1.0_linux_x86_64 gcc-4.1.1_sunos_i86pc hp_cxx-71_006_tru64 intel-linux-9.0 intel-vc71-win-9.1 intel-vc8-win-9.1 msvc-6.5 msvc-7.0 msvc-7.1 msvc-7.1 msvc-8.0 msvc-8.0 sun-5.8 |mpl| int: borland-5.8.2 integral_c: borland-5.8.2 size_t: borland-5.8.2 |numeric/interval| mul: borland-5.8.2 test_float: borland-5.8.2 |optional| optional_test: borland-5.8.2 |parameter| python_test: gcc-3.4.4 msvc-7.1 |python| andreas_beyer: gcc-3.4.4 msvc-7.1 args: gcc-3.4.4 msvc-7.1 auto_ptr: gcc-3.4.4 msvc-7.1 back_reference: gcc-3.4.4 msvc-7.1 ben_scott1: gcc-3.4.4 msvc-7.1 bienstman1: gcc-3.4.4 msvc-7.1 bienstman2: gcc-3.4.4 msvc-7.1 bienstman3: gcc-3.4.4 msvc-7.1 builtin_converters: gcc-3.4.4 msvc-7.1 callbacks: gcc-3.4.4 msvc-7.1 const_argument: gcc-3.4.4 msvc-7.1 crossmod_exception: gcc-3.4.4 msvc-7.1 crossmod_opaque: gcc-3.4.4 msvc-7.1 data_members: gcc-3.4.4 msvc-7.1 defaults: gcc-3.4.4 msvc-7.1 dict: gcc-3.4.4 msvc-7.1 docstring: gcc-3.4.4 msvc-7.1 enum: gcc-3.4.4 msvc-7.1 exception_translator: gcc-3.4.4 msvc-7.1 extract: gcc-3.4.4 msvc-7.1 implicit: gcc-3.4.4 msvc-7.1 injected: gcc-3.4.4 msvc-7.1 iterator: gcc-3.4.4 msvc-7.1 keywords: gcc-3.4.4 msvc-7.1 list: gcc-3.4.4 msvc-7.1 long: gcc-3.4.4 msvc-7.1 map_indexing_suite: gcc-3.4.4 msvc-7.1 minimal: gcc-3.4.4 msvc-7.1 multi_arg_constructor: gcc-3.4.4 msvc-7.1 nested: gcc-3.4.4 msvc-7.1 numpy: gcc-3.4.4 msvc-7.1 object: gcc-3.4.4 msvc-7.1 opaque: gcc-3.4.4 msvc-7.1 operators: gcc-3.4.4 msvc-7.1 pearu1: gcc-3.4.4 msvc-7.1 pickle1: gcc-3.4.4 msvc-7.1 pickle2: gcc-3.4.4 msvc-7.1 pickle3: gcc-3.4.4 msvc-7.1 pickle4: gcc-3.4.4 msvc-7.1 pointer_vector: gcc-3.4.4 msvc-7.1 polymorphism: gcc-3.4.4 msvc-7.1 polymorphism2: gcc-3.4.4 msvc-7.1 polymorphism2_auto_ptr: gcc-3.3.6 gcc-3.4.4 msvc-7.1 properties: gcc-3.4.4 msvc-7.1 raw_ctor: gcc-3.4.4 msvc-7.1 return_arg: gcc-3.4.4 msvc-7.1 shared_ptr: gcc-3.4.4 msvc-7.1 slice: gcc-3.4.4 msvc-7.1 staticmethod: gcc-3.4.4 msvc-7.1 stl_iterator: gcc-3.4.4 msvc-7.1 str: gcc-3.4.4 msvc-7.1 test_pointer_adoption: gcc-3.4.4 msvc-7.1 try: gcc-3.4.4 msvc-7.1 tuple: gcc-3.4.4 msvc-7.1 vector_indexing_suite: gcc-3.4.4 msvc-7.1 virtual_functions: gcc-3.4.4 msvc-7.1 voidptr: gcc-3.4.4 msvc-7.1 wrapper_held_type: gcc-3.4.4 msvc-7.1 |random| random_test: intel-linux-9.0 |regex| regex_regress: borland-5.8.2 regex_regress_dll: borland-5.8.2 regex_regress_threaded: borland-5.8.2 test_grep: msvc-6.5 |serialization| test_reset_object_address: msvc-7.0 test_reset_object_address_dll: msvc-7.0 test_utf8_codecvt: borland-5.8.2 test_variant_xml_archive: borland-5.8.2 test_variant_xml_archive_dll: borland-5.8.2 test_variant_xml_warchive: borland-5.8.2 test_variant_xml_warchive_dll: borland-5.8.2 |signals| deletion_test: msvc-6.5 ordering_test: msvc-6.5 signal_n_test: msvc-6.5 trackable_test: msvc-6.5 |spirit| switch_tests_single_debug: intel-linux-9.0 symbols_add_null: msvc-7.1 symbols_add_null_debug: msvc-7.1 |statechart| BitMachineExample: cw-9.4 hp_cxx-71_006_tru64 qcc-3.3.5_cpp qcc-3.3.5_cpp qcc-3.3.5_gpp qcc-3.3.5_gpp CameraExample: cw-9.4 PerformanceExample: cw-9.4 PingPongExample: hp_cxx-71_006_tru64 TransitionTestBoth: qcc-3.3.5_gpp qcc-3.3.5_gpp TransitionTestRelaxed: qcc-3.3.5_gpp qcc-3.3.5_gpp |test| prg_exec_fail1: intel-vc71-win-9.1 intel-vc8-win-9.1 msvc-6.5 msvc-7.0 msvc-7.1 msvc-8.0 prg_exec_fail2: darwin-4.0.1 prg_exec_fail3: borland-5.8.2 cw-9.4 msvc-7.1 test_case_template_test: borland-5.8.2 test_fp_comparisons: cw-9.4 |thread| test_tss_lib: borland-5.8.2 |utility| operators_test: gcc-3.4.5_linux_x86_64

1 0

Re: [boost] [function_types]
by Steven Watanabe 18 Nov '06

18 Nov '06

AMDG > Tobias Schwinger wrote: > > >> Now folks complain more about the tags than before. Worse >> than that, I haven't been presented a single clearly >> superior alternative! Because there isn't one? >> Steven Watanabe wrote: >> >>> 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 found it preferable to have a one-type representation, >> but I'm currently not feeling to strong about it anymore. >> Your proposal might be a good idea -- I'll think about it. >> I don't have anything in particular against a one type representation. It is probably quite useful. I just don't think giving an mpl sequence a special meaning is the right way to do it. >> Two things: >> >> 1. How to specify the properties for type synthesis? >> >> You proposed to strip it out, but I think that the compromising the symmetry of the library is far >> to high of a price for unspecified aesthetical reasons. >> If the tags can't be cleanly eliminated from the synthesis metafunctions too, then I agree completely. I can only think of two ways to do this. Neither one is completely satisfactory. 1. template<class R, class Args, class Option1, class Option2, class Option3> struct function_type : original_function_type<typename mpl::push_front<Args, R>::type, tag<Option1, Option2, Option3> > {}; 2. template<class ReturnTypeAndArgsAndTagsRolledIntoASingleType> struct function_type : ... {}; The first may be a little better, but then again it could work even with tags--in which case it is just extra syntactic sugar. The second one would basically be the inverse of components. In the second case a "constructor" for components with signature template<class R, class Args, class ... Options> would be needed. > 2. The primary interface would be "shape shifting" based on the configuration: > > is_fastcall_cc > is_stdcall_cc > is_*_cc > What about is_same<calling_convention<F>::type, fastcall_cc>? > Further: none of the reviewers (except Doug Gregor, who was talking about the issue in the very specific context of merger with another library) did answer the following question: > > What's wrong with the tag types (other than personal taste) in the first place? > Anything that can be made to work with a different interface will work with the tags. So, to a large degree they are a matter of personal taste. I've had a lot of trouble trying to figure out why I didn't like them. I think it can be summarized as 1. They depart from existing (TypeTraits) usage for no particular gain. This is not really important especially since the default arguments make this invisible for the most common case and it would be very bad to forbid potential improvements just because they are different. 2. Why are they used for some things and not others? The tags are used for variadicness, constness, and calling convention, but (from a user's perspective) they are not used for member pointer vs. function vs. function pointer. 3. Why separate the return type and the parameters from everything else? I would prefer to either combine or separate EVERYTHING. That, however, is just personal taste. > A "reject" vote for a matter of personal taste is pretty tough, IMO. But sadly it wouldn't surprise me much after reading some of the material from the GIL review... > > > Regards, > > Tobias > In Christ, Steven Watanabe

2 4

GIL review ends tommorrow - October 25, 2006
by Tom Brinkman 18 Nov '06

18 Nov '06

Get your reviews in. The official GIL review ends tommorow (October 25, 2006), but if you are going to submit a late review, or just have some general comments, let me know and I'll wait for you. Thanks again to the GIL library authors for their submission. Tom Brinkman, Review Manager

10 28