August 2006 - Boost - lists.preview.boost.org

Re: [boost] Boost.Bimap - Informal Review Request
by Wang Weiwei 09 Aug '06

09 Aug '06

Hello Matias Capeletto, The library is exactly what I was finding several days ago. The first impression it gives me is that it's quite well documented. Thanks. Max >Hello, > >Boost.Bimap, my SoC project is ready to confront the list. >The project is being mentored by Joaqu�n L�pez Mu�oz. I want >to publicly thank him. > >With Boost.Bimap you can create associative containers where >both types can be used as key. You can think a bimap<X,Y> as >a merge of a std::map<X,Y> and a std::map<Y,X>. The learning >curve of bimap is almost zero if you know how to use standard >containers. > >The original project that encompasses the creation of a one to >one bidirectional map has been extended into a framework that >extends the standard mapping scheme. A bimap is a very flexible >and powerful container, but the interface of the library allows >a user to use it out of the box. > >The project information, docs and sources can be found here: >http://cablemodem.fibertel.com.ar/mcape/oss/projects/mc_projects/boost_proj… > >I will be very pleased if you can make some spare time to review >the interface, design, implementation and documentation of this >library and comment on it. >Because it is better to go clean from the beginning, these are >some of the questions that will surely rise a discussion. > >* Do you like the usage interface? > >* In relation with Boost.MultiIndex, Do you think that it is > worth to have a bidirectional map library in Boost, that trades > generality for a better specialized user interface? > (Because this library was encouraged by the boost mentors the > answer will surely be yes, but it is a nice discussion to have) > >* Do you like the extended mapping framework? > Do you think it is intuitive for someone with a stl background? > >* What do you think of the design of operator[]? > Is there a better way to be coherent with the stl that does not imply > throwing exceptions? > >* What is your evaluation of the implementation? > I am very interested in your reaction to the zero-overhead achieved > by the almost-standard mutant_relation class, and the standard > compliant label that this library acquires by including the > standard_relation class. > A big part of the library implementation is ContainerAdaptor. > Do you deem Boost.ContainerAdaptor worth eventually proposing to > Boost? > >Looking forward to getting your feedback, > >Matias Capeletto >_______________________________________________ >Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

1 0

[interprocess] New snapshot and some explanations
by Ion Gaztañaga 09 Aug '06

09 Aug '06

Hi to all, I've uploaded to the boost repository and Boost.Vault/Concurrent Programming: (http://boost-consulting.com/vault/index.php?directory=Concurrent%20Programm…) the first Boost.Interprocess version with documentation. The previous code had no documentation so this is the biggest change. You can find online documentation here: http://ice.prohosting.com/newfunk/boost/libs/interprocess The new documentation tries to explain better the basic operating system wrappers, like synchronization primitives, shared memory objects, essential file mapping, etc... The second part of the documentation is taken and adapted from Shmem. The library still needs some breaking changes, specially, error reporting with proposed boost system exception library. Since Boost.Interprocess offers a wide range of operating system primitives, I want to use the same error report machinery as Boost.Filesystem and Boost.Asio. For the moment, Boost.Interprocess throws interprocess_exception on error. Interesting additions are new named synchronization utilities and the use of move semantics to implement lock transfers, following this proposal: http://home.twcny.rr.com/hinnant/cpp_extensions/threads_move.html Boost.Inteprocess implements upgradable_mutex (a read-write mutex on steroids) with the addition of timed functions and several scoped lock types. You can read about them in the proposal and in Boost.Interprocess documentation: * Upgradable mutex http://ice.prohosting.com/newfunk/boost/libs/interprocess/doc/html/interpro… * Lock Transfers http://ice.prohosting.com/newfunk/boost/libs/interprocess/doc/html/interpro… The move semantics emulation is custom code, but obviously, I'm very interested in a Boost.Move library and I will update the code to use it if that's included in Boost. If the C++ committee chooses a different mutex proposal as the way to go, or modifies this proposal, I will adapt Boost.Interprocess to the new interface. *** Future work *** * Atomic initializations I'm still working on this. My first try has failed, because file locking is not thread-safe in POSIX (the file descriptor is a process-wide resource, and file locking functions don't mutually exclude threads from the same process). Adding an static thread-mutex in the code would not allow using Boost.Interproces in dll-s. Flyweight can't be used, because it relies on the old Boost.Interprocess global mutex to achieve this, so this is a recursive problem ;-). We'll see. * scoped_ptr vs. unique_ptr and move semantics Good old Shmem has it's own scoped_ptr (that has a custom deleter to be able to erase dynamically allocated shared memory objects) and Boost.Interprocess still has it, but I would like to drop it and use a unique_ptr that could be placed in shared memory. This can also substitute scoped_ptr for RAII tasks and we could use it to construct containers of unique_ptr's and avoid tedious hand-deletions. Move semantics could also be applied to other types, like shared memory strings and vectors. A vector of strings in shared memory with move semantics and in-place expansion should be killer. * Allocation algorithm I would want to add the option to allocate memory with alignment restrictions, so that we can request N bytes of memory with at least A byte alignment. This is a usual user request and I think that can be used for some new tricks. ...And of course, I must change the documentation according to the review. Thanks to all for all bug reports! Regards, Ion

4 10

Boost regression notification (2006-08-08 [RC_1_34_0])
by Douglas Gregor 08 Aug '06

08 Aug '06

Boost Regression test failures Report time: 2006-08-08T07:27:38Z 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… 238 failures in 23 libraries algorithm/string (1) concept_check (1) filesystem (4) graph (5) io (1) iostreams (10) mpl (6) numeric/conversion (4) numeric/interval (1) numeric/ublas (7) parameter (20) program_options (9) python (58) random (1) rational (4) regex (2) serialization (24) signals (16) spirit (1) test (2) tr1 (51) typeof (9) utility (1) |algorithm/string| regex: borland-5_6_4 |concept_check| class_concept_check_test: vc-7_1-stlport |filesystem| mbcopy: sun-5.8 operations_test: vc-7_1-stlport operations_test_dll: vc-7_1-stlport wide_test: sun-5.8 |graph| adjacency_matrix_test: vc-7_0 csr_graph_test: sun-5.8 graphviz_test: msvc-8.0 msvc-8.0 vc-7_1-stlport |io| ios_state_unit_test: gcc-4.1.0_linux_x86_64 |iostreams| bzip2_test: msvc-7.1 msvc-8.0 compose_test: borland-5_6_4 example_test: vc-6_5-stlport filtering_stream_test: vc-7_1-stlport finite_state_filter_test: cw-9.4 gzip_test: msvc-7.1 msvc-8.0 zlib_test: msvc-7.1 msvc-8.0 |mpl| multiset: gcc-4.0.3_linux gcc-4.1.0_linux gcc-4.1.0_linux_x86_64 gcc-4.1.1_sunos_i86pc gcc-4_0_3_tru64 vector_c: sun-5.8 |numeric/conversion| converter_test: borland-5_8_2 traits_test: borland-5_8_2 udt_example_0: borland-5_8_2 udt_support_test: borland-5_8_2 |numeric/interval| test_float: vc-7_1-stlport |numeric/ublas| concepts: vc-7_1-stlport vc-7_1-stlport test1: vc-7_1-stlport test2: vc-7_1-stlport test4: vc-7_1-stlport test5: vc-7_1-stlport vc-7_1-stlport |parameter| duplicates: borland-5_6_4 borland-5_8_2 maybe: vc-6_5 vc-6_5-stlport vc-7_0 preprocessor: borland-5_6_4 borland-5_8_2 sun-5.8 vc-6_5 vc-6_5-stlport python-parameter-test: vc-6_5 vc-6_5-stlport vc-7_0 sfinae: borland-5_8_2 vc-6_5-stlport singular: borland-5_6_4 borland-5_8_2 unnamed_fail: vc-6_5 vc-6_5-stlport vc-7_0 |program_options| cmdline_test_dll: cw-9.4 options_description_test_dll: cw-9.4 parsers_test_dll: cw-9.4 positional_options_test_dll: cw-9.4 unicode_test_dll: borland-5_8_2 cw-9.4 variable_map_test_dll: borland-5_8_2 cw-9.4 winmain_dll: cw-9.4 |python| andreas_beyer: sun-5.8 args: sun-5.8 auto_ptr: sun-5.8 back_reference: sun-5.8 ben_scott1: sun-5.8 bienstman1: sun-5.8 bienstman2: sun-5.8 bienstman3: sun-5.8 callbacks: sun-5.8 data_members: sun-5.8 defaults: sun-5.8 docstring: sun-5.8 enum: sun-5.8 exec: cw-9.4 darwin-4.0.1 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 extract: sun-5.8 implicit: sun-5.8 indirect_traits_test: sun-5.8 injected: sun-5.8 iterator: sun-5.8 keywords: sun-5.8 list: sun-5.8 long: sun-5.8 multi_arg_constructor: sun-5.8 nested: sun-5.8 numpy: sun-5.8 opaque: sun-5.8 operators: sun-5.8 pearu1: sun-5.8 pickle1: sun-5.8 pickle2: sun-5.8 pickle3: sun-5.8 pickle4: sun-5.8 pointer_vector: sun-5.8 polymorphism: sun-5.8 polymorphism2: sun-5.8 polymorphism2_auto_ptr: sun-5.8 properties: sun-5.8 raw_ctor: sun-5.8 return_arg: sun-5.8 select_from_python_test: darwin-4.0.1 shared_ptr: sun-5.8 slice: sun-5.8 staticmethod: sun-5.8 stl_iterator: sun-5.8 string_literal: sun-5.8 test_pointer_adoption: sun-5.8 try: sun-5.8 vector_indexing_suite: sun-5.8 virtual_functions: sun-5.8 voidptr: sun-5.8 wrapper_held_type: sun-5.8 |random| random_test: intel-linux-9.0 |rational| rational_test: borland-5_6_4 vc-6_5 vc-6_5-stlport vc-7_0 |regex| regex_regress_threaded: gcc-3_4_4_tru64 gcc-4_0_3_tru64 |serialization| test_class_info_load_text_warchive: vc-6_5 test_non_default_ctor2_text_archive: qcc-3.3.5_cpp qcc-3.3.5_cpp qcc-3.3.5_cpp test_non_default_ctor2_text_archive_dll: qcc-3.3.5_cpp qcc-3.3.5_cpp qcc-3.3.5_cpp test_non_default_ctor2_text_warchive: qcc-3.3.5_cpp qcc-3.3.5_cpp qcc-3.3.5_cpp test_non_default_ctor2_text_warchive_dll: qcc-3.3.5_cpp qcc-3.3.5_cpp qcc-3.3.5_cpp test_reset_object_address: vc-7_0 test_reset_object_address_dll: vc-7_0 test_simple_class_binary_archive_dll: vc-6_5 test_simple_class_text_archive_dll: vc-6_5 test_simple_class_text_warchive_dll: vc-6_5 test_simple_class_xml_archive_dll: vc-6_5 test_simple_class_xml_warchive_dll: vc-6_5 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| dead_slot_test: gcc-3.3.6 gcc-3.3.6_linux qcc-3.3.5_cpp qcc-3.3.5_cpp qcc-3.3.5_cpp qcc-3.3.5_gpp qcc-3.3.5_gpp qcc-3.3.5_gpp trackable_test: gcc-3.3.6 gcc-3.3.6_linux qcc-3.3.5_cpp qcc-3.3.5_cpp qcc-3.3.5_cpp qcc-3.3.5_gpp qcc-3.3.5_gpp qcc-3.3.5_gpp |spirit| mix_and_match_trees: sun-5.8 |test| parameterized_test_test: vc-6_5 vc-6_5-stlport |tr1| run_random: sun-5.8 std_run_complex_overloads: sun-5.8 std_run_random: sun-5.8 std_test_bind: sun-5.8 std_test_complex: sun-5.8 std_test_function: sun-5.8 std_test_hash: sun-5.8 std_test_mem_fn: sun-5.8 std_test_random: sun-5.8 std_test_reference_wrapper: sun-5.8 std_test_reference_wrapper_tricky: gcc-3.2.3_linux gcc-3.3.6_linux gcc-3.4.5_linux gcc-3.4.5_linux_x86_64 gcc-4.0.3_linux gcc-4.1.0_linux_x86_64 intel-linux-9.0 mingw-3_4_2 msvc-7.1 msvc-8.0 qcc-3.3.5_cpp qcc-3.3.5_cpp qcc-3.3.5_gpp qcc-3.3.5_gpp vc-7_1-stlport std_test_result_of: sun-5.8 std_test_shared_ptr: sun-5.8 std_test_tuple: sun-5.8 std_test_tuple_tricky: sun-5.8 std_test_type_traits: sun-5.8 test_boost: vc-7_1-stlport test_hash: vc-7_1-stlport test_random: sun-5.8 vc-7_1-stlport test_reference_wrapper_tricky: gcc-3.2.3_linux gcc-3.3.6_linux gcc-3.4.5_linux gcc-3.4.5_linux_x86_64 gcc-4.0.3_linux gcc-4.1.0_linux_x86_64 intel-linux-9.0 mingw-3_4_2 msvc-7.1 msvc-8.0 qcc-3.3.5_cpp qcc-3.3.5_cpp qcc-3.3.5_gpp qcc-3.3.5_gpp test_regex: vc-7_1-stlport test_type_traits: sun-5.8 tr1_tky_function_type_test: sun-5.8 |typeof| function_binding_emulation: sun-5.8 function_binding_native: vc-6_5 vc-6_5-stlport vc-7_0 nested_typedef_emulation: cw-9.4 odr_no_uns: vc-6_5 vc-6_5-stlport vc-7_0 template_tpl_emulation: sun-5.8 |utility| operators_test: gcc-3.4.5_linux_x86_64

1 0

Re: [boost] library for type erasure
by Steven Watanabe 08 Aug '06

08 Aug '06

AMDG Alexander, This method seems to cover everything I can think of that is actually possible: struct plus : function<plus, anyT (anyT const&, anyT const&)> { template<class R, class T0, class T1> R entry(const T0& t0, const T1& t1) { return(t0 + t1); } } template<> struct overload<plus, int> { typedef typename transform< integral_types, binary_function<promotion_traits<int, _1>, int, _1> >::type type; } //other integral types are similar template<> struct overload<plus, string> { typedef vector< string(const string&, const string&), string(const string&, const char*), string(const char*, const string&) > type; }; This allows new types to be added without changing plus at all. It should be fast since in most cases there will not be a lot of possible overloads after the initial lookup. There would of course be a catch-all when none of the overloads matches. By default it should probably be something like: void no_match(const any<L>& any0, const any<L>& any1) { throw(undefined_function(typeid(plus), any0.type(), any1.type())); } I haven't thought of any real disadvantages to this approach. But, as I haven't tried to implement it yet, I may have missed something. In Christ, Steven Watanabe

2 1

A possible addition to the boost license FAQ
by Gennaro Prota 08 Aug '06

08 Aug '06

Hi, a question I get frequently asked is "Can I dual-license a project or a library under the GPL and the Boost Software License?". I suppose I know the answer, but I thought some of you, perhaps Dave or Beman, might have reliable wording from Devin Smith or other lawyers who participated to the license development. -- [ Gennaro Prota, C++ developer for hire ]

8 12

Re: [boost] feature request for optional
by Sascha Krissler 08 Aug '06

08 Aug '06

Fernando wrote: > > [...] > > But when i store values where the type has an > > inline NaT value (for example NULL pointers) i cannot and need not > > use optional. > > Can you explain why you cannot use optional<>? > I definitely see that you don't need it, but for the sake of genericity I > just wouldn't mind the fact that some types do have an identifiable null > value and use optional<> all along. Well i could use it but i do not want to. The space complexity is linear as i have to store it for every entry and a perfect hash could grow alot even for a small number of entries. Further arguments: The interface change would be backward compatible as you add a template parameter which has a default value (indicating the old behaviour). With the change i would have both the more optimal solution and the genericity. My problem is that the implementation of optional is not as trivial as it seems and i cannot wrap the class so i would have to copy and modify the source. And i guess using optional in containers and having both types of values (pointers are a good example for the inline NaT case) is not such a far fetched scenario. In the special case of pointers it would make sense not to have a static member indicating the null value but a Discriminate template parameter having the special value 'class NullPtrTag { };'. Another solution would be to make a detail::generic_optional with all the operator foo and let optional inherit from it. That would be infinitesimal backward-incompatible ;)

3 6

multiple dispatch, once more
by Sascha Krissler 08 Aug '06

08 Aug '06

-2. God, what's this? I have had fun recently doing some generic programming and as boost does not have a multiple dispatcher, i decided to send a reconnaissance posting to your mailing list. I want to TIA for your time and possible advice. -1. How to use this document This is a post to a mailing list and as such a request for comments and suggestions. There is no price to win for finding bad jokes. 0. Introduction This is a collection of algorithms for multiple dispatch and the planning phase of a C++ library implementation for multimethods that is very flexible because the algorithm to use is left as a choice to the library user. So a buzzword^W policy based multiple dispatcher framework is set as a goal of this effort. This seems not completely useless as MD is probably not going to be a language feature in this century and all prior work known to me does not do it right. 0.1 Disclamer all judgements made are misleading and are really a form of guessing and a priori estimations in disguise 0.2 Prior work Paradoxically C++ is looked down upon by folks that have multiple dispatch built into the language as in my-power-comes-from-the-outlet-in-the-wall although there is a big pile of libraries that implement multiple dispatch in C++. It seems to be a famous topic. Here is an incomplete list of such libraries: The date indicates the last change AFAIK * Modern C++ Design, Chapter 11 (2001) * Stroustrup and Meyers have some primitive implementations which i don't have access to * The cmm preprocessor (2003) * http://homepage.ntlworld.com/w.weston/multiple_dispatch.html (?) * http://www.eptacom.net/pubblicazioni/pub_eng/mdisp.html (1998) * http://archives.free.net.ph/message/20040917.110529.dcfe7ed0.en.html (2004) * http://archives.free.net.ph/message/20060301.200054.572b35f3.en.html (2006) (i didnt find files in the vault) 0.3 Source code about 4000 Lines of code, only compiled with gcc so far If you read source code for breakfast you can download it at http://k.datenfreihafen.de/~sascha/multiple-dispatch-0.0.0.tgz This is not a release, it requires some trivial preprocessing to be compilable. Some of the files have real comments. Chances are you can trade it for gold nuggets if you find a tribe of primitives (e.g. basic programmers) The file multiple-dispatch.cpp in the root of the archive is worth reading as it documents the interface used so far. It is included in this posting at the end. 0.4 Dependencies STL boost: optional, mpl, tuple (fusion in the future), type_traits, preprocessor, enable_if, call_traits, variant 1. Static dispatch algorithms (misleading naming! meaning: the set of candidate functions is known at compile time) ) 1.0 General Static dispatch algorithms dispatch a method invocation to a fixed set of candidate methods. This set is known at compile time. 1.0.1 Advantages There are some kind of dispatch algorithms that only work on a static function set. This involves all algorithms that do not primarely rely on data structures but on code generation through chaining calls to template instances that test arguments. Many use cases of multiple dispatch can be handled by static dispatchers, roughly all which need not be extensible by dynamic loading and do not express application logic through the runtime modification of the candidate function set. 1.0.2 Disadvantages A compile-time fixed set does not cover all use cases, especially it does not allow extension of a multi-method by dynamic loading of shared libraries or the use of modification of the candidate function set to express application logic. 1.0.3 Common properties Reentry: it is simple to call the next specific method of a candidate set. Because we know the types of the function that is executing we can find the next less specific function from our candidate set. The next candidate is found at compile-time, when compiling the call_next<>() expression. Intrusive: checking for the dynamic type of an argument either involves a dynamic_cast<>() or a lookup in a hand-crafted map data structure. Doing a dynamic cast is most efficient for inheritance hierarchies without multiple inheritance. For more complex hierarchies it is more efficient to make a hash of the typeids of all possible subclasses which map to an adjustment offset. Even more efficient is a perfect hash map that automatically resizes itself to prevent collisions. The hashing of the typeid would not be necessary if there is a virtual function overridden in each subclass that returns a small integer that can be used as an index into a vector instead of a hash. 1.1 Dumb dispatcher Type: code generation Complexity: O(f * a) where f is the number of functions and a is the number of arguments Description: Every candidate function is checked in turn for an argument match The candidate functions are sorted so that the first match is also the best match. Use when: the number of candidate functions is very small Implementation status: works, not extensively tested Prior work: Modern C++ design Chapter 11 "Static Dispatcher" 1.2 Logarithmic smart dispatcher Type: code generation Complexity: O(log(f) + a) Description: A compile time algorithm tries to divide the candidate function set into 2 equally sized halves depending on the test of an arbitrary type at an arbitrary position. When the 2 parts are not halves they should be as equally sized as possible. This algorithm recursively invokes itself until only one function is left to check. This last check is then a check for the exact types of the candidate function. Use when: medium sized candidate set, small memory requirements Implementation status: not finished 1.3 N-Dimensional VTable Type: data structure driven Complexity: O(a) Description: An n dimensional vtable is built at compile time with one dimension for each argument. Cool features: Table compression. The table is not really n-dimensional physically, because each argument test reduces the possible candidate functions left and thus the possible types to check for in the tests of the remaining arguments Use when: you are in need for speed Prior work: Modern C++ design Chapter 11 "Constant time dispatcher" Implementation status: not finished 2. Dynamic dispatch algorithms 2.0 General Dynamic dispatch algorithms allow for the set of candidate functions to be modified at runtime. This can either be used to extend a multi-method by dynamic loading of a shared library or by altering the candidate function set at runtime to express application logic. 2.0.1 Advantages and Disadvantages Compare static dispatcher disadvantages and advantages in reverse 2.1 Logarithmic binary tree based dispatcher ...to be done... 2.2 N-Dimensional VTable based dispatcher ...to be done... 2.3 Decision tree based algorithmic dispatcher ...to be done... 3. Source code snippet #include <Pattern/Meta/MultipleDispatch.hpp> #include <boost/progress.hpp> using namespace Pattern::Meta::MultipleDispatch; class Base; class Sub; class MoreSub; class EvenMoreSub; struct my_functor { typedef int return_t; typedef boost::mpl::vector<Sub *, Base *> args_t; static int call(Sub * s, Base * b) { std::cerr << "functor\n"; } }; // need to repeat the signatures here until C++ gets an auto keyword typedef Overload<0, Algo::Typeid> ::add<int (*)(Sub *, Sub *)>::type ::add<int (*)(MoreSub *, MoreSub *)>::type ::add<int (*)(Base *, Base *), struct predicate5 { template <typename Tuple> static bool triggers(Tuple & args) { return args.template get<0>()->dummy() == 42 && args.template get<1>()->dummy() == 23; } } >::type ::add<int (*)(Sub *, MoreSub *)>::type a_fun; int a1(int a, int b) { std::cerr << "a1\n"; } class Base { public : virtual int dummy() { return -1; } }; class Base2 { public : virtual int dummy2() { } }; class Sub : public Base2, public Base { public : int dummy() { return 42; } }; class Sub2 { public : virtual int dummy3() { } }; class MoreSub : public Sub2, public Sub { public : int dummy() { return 23; } }; class EvenMoreSub : public MoreSub { }; int a2(Sub * s1, Sub * s2) { std::cerr << "a2\n"; // call_next<a_fun>(s1, s2); } int a3(MoreSub * s1, MoreSub * s2) { std::cerr << "a3\n"; // call_next<a_fun>(s1, s2); } int a4(Sub * s1, MoreSub * s2) { std::cerr << "a4\n"; std::cerr << reinterpret_cast<int>(s1) << " " << reinterpret_cast<int>(s2) << "\n"; // call_next<a_fun>(s1, s2); } int a5(Base * b1, Base * b2) { std::cerr << "a5\n"; } main() { Sub b1, b2; MoreSub b3, b4; EvenMoreSub e1, e2; int ret; // a_fun::set(&a1); a_fun::set(&a2); a_fun::set(&a3); a_fun::set(&a4); a_fun::set(&a5); a_fun::finish(); #if 0 { boost::progress_timer t; for (int i = 0; i < 10000000; ++i) { ret = call<a_fun>((Base *)&b1, (Base *)&b3); // calls a4 } } #endif #if 0 { boost::progress_timer t2; for (int i = 0; i < 10000000; ++i) { ret = ((Base *)&b1)->dummy(); ret = ((Base *)&b1)->dummy(); } } #endif std::cerr << reinterpret_cast<int>((Sub *) &b1) << " " << reinterpret_cast<int>((MoreSub *) &e1) << "\n"; ret = call<a_fun>((Base *)&b1, (Base *)&e1); // calls a4 ret = call<a_fun>((Base *)&b1, (Base *)&e1); // calls a4 // ret = call<a_fun>((Base *)&e1, (Base *)&e2) // ret = call<a_fun>((Base *)&b3, (Base *)&b4); // calls a3 // ret = call<a_fun>((Base *)&b1, (Base *)&b2); // calls a2 // ret = call<a_fun>(1, 2); // calls a1 }

1 0

Inspect Tool Update (was: Boost regression testing status)
by Gennaro Prota 07 Aug '06

07 Aug '06

On Fri, 28 Jul 2006 02:19:38 +0200, Gennaro Prota <gennaro_prota(a)yahoo.com> wrote: >On Thu, 27 Jul 2006 14:23:31 -0500, Rene Rivera ><grafikrobot(a)gmail.com> wrote: > >>It's the false negatives that are worrisome. For example: >> >>const char * x = "//foo"; int x = min(10,20); >> >>Not that I think anyone would write such code. But strange things do >>happen :-) > >Yep. I have just committed a major update to the inspect tool. Besides some fixes and improvements there's a *cautious* attempt to avoid false positives with min/max invocations. Basically, if min and max appear in a line beginning with "//" they are ignored, unless the presence of a quote or of a "*/" sequence makes the case dubious (resolving such a doubt would require scanning ahead/behind, to other lines, which is a bit uneasy with the current code and probably overkill anyway). In short, if you have something like: /* * This is a formula: * * result = min { X, Y } * ... */ it's enough to rewrite the min line as // * result = min { X, Y } to avoid spurious "detections". Changes have only been committed to the HEAD. All log messages (edit summaries) belonging to this update begin with "Inspect Tool Update" to ease future merge to the RC_1_34_0 branch. More changes may follow, with the same edit summary convention. -- [ Gennaro Prota, C++ developer for hire ]

1 1

boost image manipulation lib?
by Christian Henning 07 Aug '06

07 Aug '06

Hi there, I'm interessted in weather there are people working on a library for image manipulation ( like scaling, contrast, brightness, etc. ) that is target to be added to boost. Especially the design of the manipulation pipeline would also interest me. I have an old c++ lib that implements the pipeline as a data flow network. Basically it defines operators ( like an ImageBrightnessOperator ) that takes an input image and passes the resulting image to the next operator, and so on. Since the source code is a "little" outdated and the design is not perfect, I would like to exchange the lib. Regards, Christian

2 2

Boost regression notification (2006-08-07 [RC_1_34_0])
by Douglas Gregor 07 Aug '06

07 Aug '06

Boost Regression test failures Report time: 2006-08-02T06:38:31Z 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… 268 failures in 24 libraries algorithm/string (1) concept_check (1) filesystem (4) graph (5) io (1) iostreams (10) mpl (6) numeric/conversion (4) numeric/interval (1) numeric/ublas (7) parameter (22) program_options (9) python (85) random (1) rational (4) regex (1) serialization (25) signals (16) spirit (1) test (2) tr1 (51) typeof (9) utility (1) xpressive (1) |algorithm/string| regex: borland-5_6_4 |concept_check| class_concept_check_test: vc-7_1-stlport |filesystem| mbcopy: sun-5.8 operations_test: vc-7_1-stlport operations_test_dll: vc-7_1-stlport wide_test: sun-5.8 |graph| adjacency_matrix_test: vc-7_0 csr_graph_test: sun-5.8 graphviz_test: msvc-8.0 msvc-8.0 vc-7_1-stlport |io| ios_state_unit_test: gcc-4.1.0_linux_x86_64 |iostreams| bzip2_test: msvc-7.1 msvc-8.0 compose_test: borland-5_6_4 example_test: vc-6_5-stlport filtering_stream_test: vc-7_1-stlport finite_state_filter_test: cw-9.4 gzip_test: msvc-7.1 msvc-8.0 zlib_test: msvc-7.1 msvc-8.0 |mpl| multiset: gcc-4.0.3_linux gcc-4.1.0_linux gcc-4.1.0_linux_x86_64 gcc-4.1.1_sunos_i86pc gcc-4_0_3_tru64 vector_c: sun-5.8 |numeric/conversion| converter_test: borland-5_8_2 traits_test: borland-5_8_2 udt_example_0: borland-5_8_2 udt_support_test: borland-5_8_2 |numeric/interval| test_float: vc-7_1-stlport |numeric/ublas| concepts: vc-7_1-stlport vc-7_1-stlport test1: vc-7_1-stlport test2: vc-7_1-stlport test4: vc-7_1-stlport test5: vc-7_1-stlport vc-7_1-stlport |parameter| basics: borland-5_6_4 borland-5_8_2 duplicates: borland-5_6_4 borland-5_8_2 maybe: vc-6_5 vc-6_5-stlport vc-7_0 preprocessor: borland-5_6_4 borland-5_8_2 sun-5.8 vc-6_5 vc-6_5-stlport python-parameter-test: vc-6_5 vc-6_5-stlport vc-7_0 sfinae: borland-5_8_2 vc-6_5-stlport singular: borland-5_6_4 borland-5_8_2 unnamed_fail: vc-6_5 vc-6_5-stlport vc-7_0 |program_options| cmdline_test_dll: cw-9.4 options_description_test_dll: cw-9.4 parsers_test_dll: cw-9.4 positional_options_test_dll: cw-9.4 unicode_test_dll: borland-5_8_2 cw-9.4 variable_map_test_dll: borland-5_8_2 cw-9.4 winmain_dll: cw-9.4 |python| andreas_beyer: sun-5.8 args: sun-5.8 auto_ptr: sun-5.8 back_reference: sun-5.8 bases: gcc-3_4_4_tru64 gcc-4_0_3_tru64 sun-5.8 ben_scott1: sun-5.8 bienstman1: sun-5.8 bienstman2: sun-5.8 bienstman3: sun-5.8 borrowed: sun-5.8 callbacks: sun-5.8 const_argument: sun-5.8 crossmod_exception: sun-5.8 data_members: sun-5.8 defaults: sun-5.8 dict: sun-5.8 docstring: sun-5.8 enum: sun-5.8 exception_translator: sun-5.8 exec: cw-9.4 darwin-4.0.1 gcc-3_4_4_tru64 gcc-4_0_3_tru64 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 extract: sun-5.8 implicit: sun-5.8 indirect_traits_test: sun-5.8 injected: sun-5.8 iterator: sun-5.8 keywords: sun-5.8 list: sun-5.8 long: sun-5.8 minimal: sun-5.8 multi_arg_constructor: sun-5.8 nested: sun-5.8 numpy: sun-5.8 object: sun-5.8 object_manager: sun-5.8 opaque: sun-5.8 operators: sun-5.8 pearu1: sun-5.8 pickle1: sun-5.8 pickle2: sun-5.8 pickle3: sun-5.8 pickle4: sun-5.8 pointee: gcc-3_4_4_tru64 gcc-4_0_3_tru64 sun-5.8 pointer_type_id_test: gcc-3_4_4_tru64 gcc-4_0_3_tru64 sun-5.8 pointer_vector: sun-5.8 polymorphism: sun-5.8 polymorphism2: sun-5.8 polymorphism2_auto_ptr: sun-5.8 properties: sun-5.8 raw_ctor: sun-5.8 return_arg: sun-5.8 select_arg_to_python_test: sun-5.8 select_from_python_test: darwin-4.0.1 sun-5.8 select_holder: sun-5.8 shared_ptr: sun-5.8 slice: sun-5.8 staticmethod: sun-5.8 stl_iterator: sun-5.8 str: sun-5.8 string_literal: sun-5.8 test_pointer_adoption: sun-5.8 try: sun-5.8 tuple: sun-5.8 upcast: gcc-3_4_4_tru64 gcc-4_0_3_tru64 sun-5.8 vector_indexing_suite: sun-5.8 virtual_functions: sun-5.8 voidptr: sun-5.8 wrapper_held_type: sun-5.8 |random| random_test: intel-linux-9.0 |rational| rational_test: borland-5_6_4 vc-6_5 vc-6_5-stlport vc-7_0 |regex| regex_regress_threaded: gcc-4_0_3_tru64 |serialization| test_class_info_load_text_warchive: vc-6_5 test_non_default_ctor2_text_archive: qcc-3.3.5_cpp qcc-3.3.5_cpp qcc-3.3.5_cpp test_non_default_ctor2_text_archive_dll: qcc-3.3.5_cpp qcc-3.3.5_cpp qcc-3.3.5_cpp test_non_default_ctor2_text_warchive: qcc-3.3.5_cpp qcc-3.3.5_cpp qcc-3.3.5_cpp test_non_default_ctor2_text_warchive_dll: qcc-3.3.5_cpp qcc-3.3.5_cpp qcc-3.3.5_cpp test_reset_object_address: vc-7_0 test_reset_object_address_dll: vc-7_0 test_set_text_archive_dll: msvc-8.0 test_simple_class_binary_archive_dll: vc-6_5 test_simple_class_text_archive_dll: vc-6_5 test_simple_class_text_warchive_dll: vc-6_5 test_simple_class_xml_archive_dll: vc-6_5 test_simple_class_xml_warchive_dll: vc-6_5 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| dead_slot_test: gcc-3.3.6 gcc-3.3.6_linux qcc-3.3.5_cpp qcc-3.3.5_cpp qcc-3.3.5_cpp qcc-3.3.5_gpp qcc-3.3.5_gpp qcc-3.3.5_gpp trackable_test: gcc-3.3.6 gcc-3.3.6_linux qcc-3.3.5_cpp qcc-3.3.5_cpp qcc-3.3.5_cpp qcc-3.3.5_gpp qcc-3.3.5_gpp qcc-3.3.5_gpp |spirit| mix_and_match_trees: sun-5.8 |test| parameterized_test_test: vc-6_5 vc-6_5-stlport |tr1| run_random: sun-5.8 std_run_complex_overloads: sun-5.8 std_run_random: sun-5.8 std_test_bind: sun-5.8 std_test_complex: sun-5.8 std_test_function: sun-5.8 std_test_hash: sun-5.8 std_test_mem_fn: sun-5.8 std_test_random: sun-5.8 std_test_reference_wrapper: sun-5.8 std_test_reference_wrapper_tricky: gcc-3.2.3_linux gcc-3.3.6_linux gcc-3.4.5_linux gcc-3.4.5_linux_x86_64 gcc-4.0.3_linux gcc-4.1.0_linux_x86_64 intel-linux-9.0 mingw-3_4_2 msvc-7.1 msvc-8.0 qcc-3.3.5_cpp qcc-3.3.5_cpp qcc-3.3.5_gpp qcc-3.3.5_gpp vc-7_1-stlport std_test_result_of: sun-5.8 std_test_shared_ptr: sun-5.8 std_test_tuple: sun-5.8 std_test_tuple_tricky: sun-5.8 std_test_type_traits: sun-5.8 test_boost: vc-7_1-stlport test_hash: vc-7_1-stlport test_random: sun-5.8 vc-7_1-stlport test_reference_wrapper_tricky: gcc-3.2.3_linux gcc-3.3.6_linux gcc-3.4.5_linux gcc-3.4.5_linux_x86_64 gcc-4.0.3_linux gcc-4.1.0_linux_x86_64 intel-linux-9.0 mingw-3_4_2 msvc-7.1 msvc-8.0 qcc-3.3.5_cpp qcc-3.3.5_cpp qcc-3.3.5_gpp qcc-3.3.5_gpp test_regex: vc-7_1-stlport test_type_traits: sun-5.8 tr1_tky_function_type_test: sun-5.8 |typeof| function_binding_emulation: sun-5.8 function_binding_native: vc-6_5 vc-6_5-stlport vc-7_0 nested_typedef_emulation: cw-9.4 odr_no_uns: vc-6_5 vc-6_5-stlport vc-7_0 template_tpl_emulation: sun-5.8 |utility| operators_test: gcc-3.4.5_linux_x86_64 |xpressive| test7: msvc-8.0

1 0