- Boost - lists.boost.org

[gil]:support for png palette images
by Andreas Pokorny 04 Nov '07

04 Nov '07

Hello, I just stumbled across missing support for PNG_COLOR_TYPE_PALETTE in gil. Somehow most monochrome images e.g. generated with gimp use PNG_COLOR_TYPE_PALETTE with two colors, instead of _GRAY with a bit depth of one. So I thought, maybe someone else already added support for such files? regards Andreas

1 0

Deterimining interest in: Optional Polymorphic Value object with Small Object optimization
by Corrado Zoccolo 04 Nov '07

04 Nov '07

Hi Following the recent interest in clone pointers and Polymorphic value object wrappers, I developed a slightly feature enriched Polymorphic Value object, that implements the small object optimization, and models the Optional Pointee concept. It follows a non-intrusive approach to cloning. The code can be found in the boost vault: *http://tinyurl.com/3a6sq8* Motivation: Dynamic polymorphism is a valuable but underestimated tool to the modern C++ programmer. It for example allows the implementation of type erasure and other techniques for physical decoupling. It is also unavoidable every time dynamic dispatching is needed. Unfortunately solutions based on it may often be slow, because traditional dynamic polymorphism is always paired with dynamic allocation. The proposed tool is targeted to ease the usage of dynamic polymorphism in modern C++ context, by giving value semantics to polymorphic objects, as well as providing a well known optimization technique to avoid dynamic allocation when the involved objects are small. Dynamic polymorphism, value semantics and small object optimization constitute a powerful receipt to solve such problems. As evidence boost::function, among the most valuable tools for type erasure and physical decoupling available in boost, is using all three of them. This tool is meant to be a low level tool, on which powerful abstractions like boost::function could be built easily. Basic Usage Example: #include "optional_poly.hpp" #include <iostream> // class with one virtual method but not virtual destructor // optional_poly will know the derived type, so it will call the correct destructor nevertheless struct B { virtual operator int() {return 0;}}; // lack of virtual destructor is intentional // Derived class, with side effect in destructor to show functionality, and overloaded virtual method to determine which one was called struct D : B { operator int() {return 1;} ~D() { std::cerr<<"Got it\n"; } void swap(D&) {} private: void operator=(D const &); }; // swap reachable via ADL. optional_poly will prefer (by default) this to implement its swap method. Using a trait, you can specify if a swap method or no swap at all should be used for a given type void swap(D& a,D& b) { a.swap(b); } int main() { // optional_poly constructor and operator= require that the static type match the dynamic one. // The following commented code is invalid, and will assert at runtime // const B& d=D(); // boost::optional_poly<B> z=d; // asserts, because optional_poly should be constructed with the concrete derived type // this is the correct way to initialize optional_poly. D must be derived from B (static assertion otherwise). boost::optional_poly<B> z=D(); std::cerr<<*z<<"\n"; // this prints 1 boost::optional_poly<B> s; // uninitialized (empty) optional_poly for interface B s.swap(z); // now s has a D, while z is empty std::cerr<<*s<<"\n"; // prints 1 return 0; } A bit more complex example: #include "optional_poly.hpp" #include <boost/none.hpp> #include <iostream> // we will show how simple callable objects can be returned easily and efficiently from a function (i.e. we implement a really small subset of boost::function) struct Callable { virtual void operator()() const=0; }; // inheritance is used here. This wrapper can host function pointers or functors seamlessly, exposing to the outside the Callable interface template<class T> struct MakeCallable: Callable { MakeCallable(const T& t) : val(t) {} T val; void operator()() const { val(); } }; void my_fun() { std::cout<<"got 1\n"; } struct MyFunc { void operator()() const { std::cout<<"got 2\n"; } }; // the function returning different Callable objects depending on the value of the parameter boost::optional_poly<Callable> foo(int i) { switch(i) { case 1: return MakeCallable<void (*)()>(my_fun); case 2: return MakeCallable<MyFunc>(MyFunc()); } return boost::none; } // main shows how foo() is invoked, and its result is used int main() { boost::optional_poly<Callable> c; for(int i=0;i<3; ++i) { c=foo(i); if(c) { std::cout<<"Going to call c for "<<i<<" ... ";(*c)(); } else { std::cout<<"empty c for "<<i<<"\n"; } } return 0; } Output: empty c for 0 Going to call c for 1 ... got 1 Going to call c for 2 ... got 2 Wasn't this easy? And this small example did not dynamically allocate any memory, because the Callable objects are all smaller than the small object threshold (default value is 128, can be overridden specifying a second template parameter to optional_poly, e.g. optional_poly<Callable,0> will always allocate from the heap). Sounds interesting for being submitted to boost? Corrado -- __________________________________________________________________________ dott. Corrado Zoccolo mailto: zoccolo(a)di.unipi.it PhD - Department of Computer Science - University of Pisa, Italy --------------------------------------------------------------------------

14 42

[1.35] Where to place PDF versions of docs?
by John Maddock 03 Nov '07

03 Nov '07

Folks I think we need to get organised with PDF's now that we have many more libraries with quickbook/boostbook docs. I don't particularly want these in SVN trunk: apart from anything else it needlessly bloats the download size if folks are happy with HTML versions. Previously I've placed these in the vault, but there's a file size limit there and the new Boost.Math PDF's are too large :-( Another alternative would be the sourceforge file release system, but I don't believe all developers have access to that? So.... how about we either have a directory in the "website" area of SVN for these, or else in the sandbox maybe? Thoughts? John.

10 15

[thread] Missing #include
by Andrey Semashev 03 Nov '07

03 Nov '07

Hi, I think boost/thread/pthread/shared_mutex.hpp in trunk is missing #include <boost/thread/thread.hpp>. Now it complains it doesn't know what this_thread is. I also noticed lots of warnings "unused variable 'res'" and alikes while compiling my projects with GCC 4.2.1 on OpenSUSE. These warnings mostly come from boost/thread/pthread/pthread_mutex_scoped_lock.hpp, boost/thread/pthread/once.hpp, boost/thread/pthread/mutex.hpp, boost/thread/pthread/condition_variable.hpp. I didn't investigate closely, though.

5 6

[Thread] Currently broken on Darwin?
by John Maddock 03 Nov '07

03 Nov '07

As well as none of the Boost.Thread tests currently building on Darwin, I'm seeing runtime errors from the regex tests of the kind: terminate called after throwing an instance of 'boost::system_error' Any ideas? Or better still planned fixes :-) Thanks, John.

2 1

Comments about N2320
by Yuval Ronen 03 Nov '07

03 Nov '07

Hi, After reading most of N2320, I have a few comments: * thread::id has operator== and operator!= declared twice. Once in namespace scope, and a second time inside class thread. Second time is with operator< and his friends. * Thread cancellation is new, and disable_cancellation/restore_cancellation are even newer. They are new for C++ programmers, and maybe new for *all* programmers (I never heard of a language with them). I'm not sure if it's a good idea to standardize them before we get some real-life experience with thread cancellation. * Time issues. To my eyes, it looks not pretty trying to get threading with time issues standardized before we have std::date_time. Making it a templated type not because we want genericity, but because we don't have the type we want yet, makes it look coerced. I think it's best to drop the time-related stuff, and add it properly together with date_time. Using the timed version of thread::join(), mutex::lock() and condition::wait() are very rare, and I think (hope) they can be implemented externally using native_handle(). * I see that you chose not go accept a mutex in condition's constructor. If that is so, why make the condition class templated, instead of only the wait() functions, as is in Boost.Thread? * If C++0x is going to have lambda support (is it?), then maybe the not-accepting-predicate overloads of condition::wait are no longer needed, and can be removed? I think the major reason why people use that overload is because they are too lazy to write a functor. With core support for lambda, it's a breeze. This will solve the other problem (mentioned in some other thread in this ML) about absolute vs. relative times. * Back then we had a discussion about unique_lock, which was never finished. I claim that there is no need for a state where mutex() != 0 && owns() == false, which means that defer_lock is not needed. There is one example in the document using defer_lock, which I think can be done in another way. That example goes like: Record& Record::operator=(const Record& r) { if (this != &r) { std::unique_lock<std::mutex> this_lock(mut, std::defer_lock); std::unique_lock<std::mutex> that_lock(r.mut, std::defer_lock); std::lock(this_lock, that_lock); // Both source and destination are locked // Safe to assign // ... } return *this; } If we change the first 3 lines of the 'if' to: std::lock(mut, r.mut); std::unique_lock<std::mutex> this_lock(mut, std::accept_ownership); std::unique_lock<std::mutex> that_lock(r.mut, std::accept_ownership); then it works without defer_lock. This allows us to: 1. Make unique_lock's interface simpler. 2. Make sizeof(unique_lock) smaller - no need for bool owns. 3. Make unique_lock more similar to unique_ptr, which makes it more intuitive. 4. Make std::lock simpler in the way that it doesn't need to accept locks, only mutexes. In general it seems you paid a lot of attention to being able to pass a lock instead of a mutex wherever possible. I think it's absolutely not necessary. It's an undue complication. * Other than that - very nice :) Yuval

15 48

[test] Sun 5.9 broken
by Beman Dawes 03 Nov '07

03 Nov '07

It looks like test is broken on Sun 5.9. Please fix immediately, or revert the change that caused the breakage. --Beman "../boost/test/impl/debug.ipp", line 420: Error: mkstemp is not a member of file level. "../boost/test/impl/debug.ipp", line 603: Error: getenv is not a member of file level. "../boost/test/impl/debug.ipp", line 856: Error: mkstemp is not a member of file level. "../boost/test/impl/debug.ipp", line 871: Error: exit is not a member of file level. "../boost/test/impl/debug.ipp", line 876: Error: getenv is not a member of file level. "../boost/test/impl/debug.ipp", line 885: Error: exit is not a member of file level. 6 Error(s) detected.

4 6

[Report] 524 failures on trunk (2007-11-03)
by Douglas Gregor 03 Nov '07

03 Nov '07

Boost regression test failures Report time: 2007-11-03T06:34:49Z This report lists all regression test failures on release platforms. Detailed report: http://boost.org/regression/trunk/developer/issues.html 524 failures in 41 libraries asio (5) assign (1) bimap (42) circular_buffer (1) concept_check (8) conversion (5) crc (1) date_time (1) disjoint_sets (1) dynamic_bitset (5) foreach (11) function (1) fusion (63) gil (5) graph (22) integer (1) interprocess (21) io (1) lambda (2) logic (3) math (101) mpl (1) multi_array (4) numeric/conversion (1) numeric/interval (12) optional (9) parameter (1) ptr_container (2) python (70) regex (7) serialization (23) spirit (31) system (10) test (3) thread (29) tr1 (5) typeof (1) utility (3) utility/enable_if (7) wave (1) xpressive (3) |asio| io_service: darwin-4.0.1 io_service_select: darwin-4.0.1 strand: darwin-4.0.1 darwin-4.0.1 strand_select: darwin-4.0.1 |assign| ptr_list_of: gcc-3.3.6 |bimap| assign: sun-5.8 foreach: hp_cxx-71_006_tru64 sun-5.8 lambda: sun-5.8 property_map: sun-5.8 range: sun-5.8 serialization: sun-5.8 test_bimap_assign: sun-5.8 test_bimap_convenience_header: sun-5.8 test_bimap_extra: sun-5.8 test_bimap_info: hp_cxx-71_006_tru64 sun-5.8 test_bimap_lambda: sun-5.8 test_bimap_list_of: sun-5.8 test_bimap_modify: sun-5.8 test_bimap_multiset_of: sun-5.8 test_bimap_mutable: sun-5.8 test_bimap_operator_bracket: gcc-3.3.6 sun-5.8 test_bimap_ordered: gcc-3.3.6 hp_cxx-71_006_tru64 sun-5.8 test_bimap_project: sun-5.8 test_bimap_property_map: sun-5.8 test_bimap_range: sun-5.8 test_bimap_sequenced: sun-5.8 test_bimap_serialization: sun-5.8 test_bimap_set_of: sun-5.8 test_bimap_unconstrained: sun-5.8 test_bimap_unordered: gcc-3.3.6 hp_cxx-71_006_tru64 sun-5.8 test_bimap_unordered_multiset_of: sun-5.8 test_bimap_unordered_set_of: sun-5.8 test_bimap_vector_of: sun-5.8 test_mutant: sun-5.8 test_mutant_relation: sun-5.8 test_structured_pair: sun-5.8 test_tagged: sun-5.8 typeof: sun-5.8 xpressive: gcc-3.3.6 sun-5.8 |circular_buffer| bounded_buffer_comparison: darwin-4.0.1 |concept_check| class_concept_fail_expected: sun-5.8 old_concept_class_fail: gcc-3.3.6 sun-5.8 old_concept_function_fail: gcc-3.3.6 sun-5.8 stl_concept_check: hp_cxx-71_006_tru64 usage_fail: sun-5.8 where_fail: sun-5.8 |conversion| lexical_cast_loopback_test: gcc-4.1.2_sunos_i86pc gcc-mingw-3.4.5 msvc-8.0 msvc-8.0 numeric_cast_test: sun-5.8 |crc| crc_test: sun-5.8 |date_time| testtime_serialize_xml_std_config: darwin-4.0.1 |disjoint_sets| disjoint_set_test: sun-5.8 |dynamic_bitset| dyn_bitset_unit_tests2: sun-5.8 dyn_bitset_unit_tests3: hp_cxx-71_006_tru64 sun-5.8 dyn_bitset_unit_tests4: intel-linux-9.0 sun-5.8 |foreach| array_byref: sun-5.8 array_byval: sun-5.8 call_once: sun-5.8 cstr_byref: sun-5.8 cstr_byval: sun-5.8 dependent_type: sun-5.8 pair_byref: sun-5.8 pair_byval: sun-5.8 stl_byref: sun-5.8 stl_byval: sun-5.8 user_defined: sun-5.8 |function| lambda_test: sun-5.8 |fusion| adapt_assoc_struct: sun-5.8 adapt_struct: sun-5.8 all: sun-5.8 any: sun-5.8 array: sun-5.8 as_list: sun-5.8 as_set: sun-5.8 as_vector: sun-5.8 back_extended_deque: sun-5.8 count: sun-5.8 count_if: sun-5.8 deque_comparison: sun-5.8 deque_iterator: sun-5.8 deque_make: sun-5.8 deque_misc: sun-5.8 erase: sun-5.8 filter: sun-5.8 filter_if: sun-5.8 filter_view: acc hp_cxx-71_006_tru64 intel-linux-9.0 sun-5.8 find: sun-5.8 find_if: sun-5.8 for_each: sun-5.8 front_extended_deque: sun-5.8 fused: acc gcc-3.3.6 sun-5.8 fused_function_object: acc fused_procedure: acc gcc-3.3.6 insert: sun-5.8 insert_range: sun-5.8 invoke: gcc-3.3.6 invoke_procedure: gcc-3.3.6 iterator_range: sun-5.8 make_fused: acc gcc-3.3.6 make_fused_function_object: acc make_fused_procedure: acc gcc-3.3.6 map: sun-5.8 none: sun-5.8 pop_back: sun-5.8 pop_front: sun-5.8 push_back: sun-5.8 push_front: sun-5.8 remove: sun-5.8 remove_if: sun-5.8 repetitive_view: gcc-3.3.6 reverse_view: sun-5.8 set: sun-5.8 std_pair: sun-5.8 unfused_generic: sun-5.8 unfused_lvalue_args: sun-5.8 unfused_rvalue_args: sun-5.8 unfused_typed: sun-5.8 vector_iterator: sun-5.8 vector_n: sun-5.8 zip_view: sun-5.8 zip_view2: sun-5.8 zip_view_ignore: sun-5.8 |gil| main: acc gcc-3.3.6 gcc-4.1.2_sunos_i86pc hp_cxx-71_006_tru64 sun-5.8 |graph| adj_list_edge_list_set: sun-5.8 all_planar_input_files_test: sun-5.8 basic_planarity_test: sun-5.8 csr_graph_test: sun-5.8 cycle_ratio_tests: msvc-8.0 sun-5.8 dominator_tree_test: sun-5.8 graphml_test: msvc-8.0 graphviz_test: msvc-8.0 kolmogorov_max_flow_test: acc hp_cxx-71_006_tru64 sun-5.8 make_biconnected_planar_test: sun-5.8 make_connected_test: sun-5.8 make_maximal_planar_test: sun-5.8 matching_test: sun-5.8 max_flow_test: acc hp_cxx-71_006_tru64 sun-5.8 parallel_edges_loops_test: sun-5.8 transitive_closure_test: gcc-4.1.2_sunos_i86pc hp_cxx-71_006_tru64 |integer| integer_test: sun-5.8 |interprocess| condition_test: darwin-4.0.1 hp_cxx-71_006_tru64 deque_test: hp_cxx-71_006_tru64 message_queue_test: darwin-4.0.1 mutex_test: darwin-4.0.1 hp_cxx-71_006_tru64 named_condition_test: darwin-4.0.1 intel-linux-9.0 named_mutex_test: darwin-4.0.1 hp_cxx-71_006_tru64 named_recursive_mutex_test: darwin-4.0.1 named_semaphore_test: darwin-4.0.1 hp_cxx-71_006_tru64 named_upgradable_mutex_test: darwin-4.0.1 hp_cxx-71_006_tru64 node_pool_test: hp_cxx-71_006_tru64 recursive_mutex_test: darwin-4.0.1 semaphore_test: darwin-4.0.1 hp_cxx-71_006_tru64 upgradable_mutex_test: darwin-4.0.1 hp_cxx-71_006_tru64 |io| ios_state_test: sun-5.8 |lambda| bind_tests_simple: sun-5.8 bind_tests_simple_f_refs: sun-5.8 |logic| tribool_io_test: sun-5.8 tribool_rename_test: sun-5.8 tribool_test: sun-5.8 |math| dist_binomial_incl_test: sun-5.8 dist_neg_binom_incl_test: sun-5.8 dist_poisson_incl_test: sun-5.8 powm1_sqrtp1m1_test: intel-linux-9.0 std_real_concept_check: hp_cxx-71_006_tru64 sun-5.8 test_bessel_i: intel-linux-9.0 test_bessel_j: darwin-4.0.1 intel-linux-9.0 sun-5.8 test_bessel_k: intel-linux-9.0 test_bessel_y: intel-linux-9.0 sun-5.8 test_beta: intel-linux-9.0 test_beta_dist: intel-linux-9.0 test_binomial_coeff: intel-linux-9.0 test_binomial_double: intel-linux-9.0 sun-5.8 test_binomial_float: sun-5.8 test_binomial_long_double: intel-linux-9.0 sun-5.8 test_binomial_real_concept: intel-linux-9.0 sun-5.8 test_carlson: intel-linux-9.0 test_cauchy: intel-linux-9.0 test_chi_squared: intel-linux-9.0 test_classify: sun-5.8 test_constants: intel-linux-9.0 test_digamma: intel-linux-9.0 test_ellint_1: intel-linux-9.0 test_ellint_2: intel-linux-9.0 test_ellint_3: intel-linux-9.0 test_erf: intel-linux-9.0 test_factorials: intel-linux-9.0 test_find_location: sun-5.8 test_find_scale: sun-5.8 test_fisher_f: intel-linux-9.0 test_gamma: intel-linux-9.0 sun-5.8 test_gamma_dist: intel-linux-9.0 test_ibeta_double: darwin-4.0.1 intel-linux-9.0 test_ibeta_inv_ab_double: hp_cxx-71_006_tru64 intel-linux-9.0 test_ibeta_inv_ab_long_double: intel-linux-9.0 test_ibeta_inv_ab_real_concept: intel-linux-9.0 sun-5.8 test_ibeta_inv_double: hp_cxx-71_006_tru64 intel-linux-9.0 test_ibeta_inv_long_double: hp_cxx-71_006_tru64 intel-linux-9.0 sun-5.8 test_ibeta_inv_real_concept: intel-linux-9.0 test_ibeta_long_double: hp_cxx-71_006_tru64 intel-linux-9.0 sun-5.8 test_ibeta_real_concept: intel-linux-9.0 test_igamma: intel-linux-9.0 test_igamma_inv_double: hp_cxx-71_006_tru64 intel-linux-9.0 test_igamma_inv_long_double: intel-linux-9.0 test_igamma_inv_real_concept: intel-linux-9.0 test_igamma_inva_double: hp_cxx-71_006_tru64 intel-linux-9.0 test_igamma_inva_long_double: intel-linux-9.0 test_igamma_inva_real_concept: intel-linux-9.0 sun-5.8 test_instantiate1: sun-5.8 test_legendre: intel-linux-9.0 test_lognormal: intel-linux-9.0 test_minima: intel-linux-9.0 test_negative_binomial_double: intel-linux-9.0 sun-5.8 test_negative_binomial_float: sun-5.8 test_negative_binomial_long_double: intel-linux-9.0 sun-5.8 test_negative_binomial_real_concept: intel-linux-9.0 sun-5.8 test_normal: intel-linux-9.0 test_pareto: intel-linux-9.0 test_poisson_double: intel-linux-9.0 sun-5.8 test_poisson_float: intel-linux-9.0 test_poisson_long_double: intel-linux-9.0 sun-5.8 test_poisson_real_concept: intel-linux-9.0 sun-5.8 test_policy_2: gcc-mingw-3.4.5 test_policy_sf: intel-linux-9.0 sun-5.8 test_rayleigh: intel-linux-9.0 test_roots: intel-linux-9.0 test_spherical_harmonic: intel-linux-9.0 test_students_t: intel-linux-9.0 test_tgamma_ratio: intel-linux-9.0 test_toms748_solve: intel-linux-9.0 test_traits: gcc-3.3.6 sun-5.8 test_triangular: intel-linux-9.0 test_weibull: intel-linux-9.0 tools_roots_inc_test: sun-5.8 |mpl| apply: gcc-4.1.2_sunos_i86pc |multi_array| assert: sun-5.8 idxgen1: sun-5.8 range1: sun-5.8 storage_order_convert: sun-5.8 |numeric/conversion| numeric_cast_test: sun-5.8 |numeric/interval| add: sun-5.8 fmod: sun-5.8 mul: darwin-4.0.1 darwin-4.0.1 sun-5.8 overflow: darwin-4.0.1 darwin-4.0.1 sun-5.8 pi: darwin-4.0.1 darwin-4.0.1 sun-5.8 pow: sun-5.8 |optional| optional_test: darwin-4.0.1 darwin-4.0.1 darwin-4.0.1 gcc-4.1.2_sunos_i86pc gcc-mingw-3.4.5 hp_cxx-71_006_tru64 optional_test_inplace: sun-5.8 optional_test_io: sun-5.8 optional_test_tie: sun-5.8 |parameter| python_test: intel-linux-9.0 |ptr_container| incomplete_type_test: sun-5.8 serialization: sun-5.8 |python| andreas_beyer: intel-linux-9.0 args: intel-linux-9.0 auto_ptr: intel-linux-9.0 back_reference: intel-linux-9.0 bases: intel-linux-9.0 ben_scott1: intel-linux-9.0 bienstman1: intel-linux-9.0 bienstman2: intel-linux-9.0 bienstman3: intel-linux-9.0 borrowed: intel-linux-9.0 callbacks: intel-linux-9.0 const_argument: intel-linux-9.0 crossmod_exception: intel-linux-9.0 crossmod_opaque: intel-linux-9.0 data_members: intel-linux-9.0 defaults: intel-linux-9.0 dict: intel-linux-9.0 docstring: intel-linux-9.0 enum: intel-linux-9.0 exception_translator: intel-linux-9.0 exec: gcc-4.1.2_sunos_i86pc intel-linux-9.0 extract: intel-linux-9.0 implicit: intel-linux-9.0 import_: intel-linux-9.0 injected: intel-linux-9.0 iterator: intel-linux-9.0 keywords: intel-linux-9.0 list: intel-linux-9.0 long: intel-linux-9.0 minimal: intel-linux-9.0 multi_arg_constructor: intel-linux-9.0 nested: intel-linux-9.0 numpy: intel-linux-9.0 object: intel-linux-9.0 object_manager: intel-linux-9.0 opaque: intel-linux-9.0 operators: intel-linux-9.0 operators_wrapper: intel-linux-9.0 pearu1: intel-linux-9.0 pickle1: intel-linux-9.0 pickle2: intel-linux-9.0 pickle3: intel-linux-9.0 pickle4: intel-linux-9.0 pointee: intel-linux-9.0 pointer_type_id_test: intel-linux-9.0 pointer_vector: intel-linux-9.0 polymorphism: intel-linux-9.0 polymorphism2: intel-linux-9.0 polymorphism2_auto_ptr: intel-linux-9.0 properties: intel-linux-9.0 pytype_function: intel-linux-9.0 raw_ctor: intel-linux-9.0 return_arg: intel-linux-9.0 select_arg_to_python_test: intel-linux-9.0 select_from_python_test: intel-linux-9.0 select_holder: intel-linux-9.0 shared_ptr: intel-linux-9.0 slice: intel-linux-9.0 staticmethod: intel-linux-9.0 stl_iterator: intel-linux-9.0 str: intel-linux-9.0 test_pointer_adoption: intel-linux-9.0 try: intel-linux-9.0 tuple: intel-linux-9.0 upcast: intel-linux-9.0 vector_indexing_suite: intel-linux-9.0 virtual_functions: intel-linux-9.0 voidptr: intel-linux-9.0 wrapper_held_type: intel-linux-9.0 |regex| regex_regress_threaded: darwin-4.0.1 darwin-4.0.1 regex_token_iterator_eg_2: darwin-4.0.1 static_mutex_test: darwin-4.0.1 gcc-4.1.2_sunos_i86pc hp_cxx-71_006_tru64 test_collate_info: sun-5.8 |serialization| test_contained_class_binary_archive_dll: darwin-4.0.1 test_demo_portable_archive: darwin-4.0.1 test_demo_portable_archive_dll: darwin-4.0.1 test_exported_binary_archive: gcc-4.1.2_sunos_i86pc hp_cxx-71_006_tru64 test_exported_binary_archive_dll: gcc-4.1.2_sunos_i86pc hp_cxx-71_006_tru64 test_exported_text_archive: gcc-4.1.2_sunos_i86pc hp_cxx-71_006_tru64 test_exported_text_archive_dll: gcc-4.1.2_sunos_i86pc hp_cxx-71_006_tru64 test_exported_text_warchive: gcc-4.1.2_sunos_i86pc hp_cxx-71_006_tru64 test_exported_text_warchive_dll: gcc-4.1.2_sunos_i86pc hp_cxx-71_006_tru64 test_exported_xml_archive: gcc-4.1.2_sunos_i86pc hp_cxx-71_006_tru64 test_exported_xml_archive_dll: gcc-4.1.2_sunos_i86pc hp_cxx-71_006_tru64 test_exported_xml_warchive: gcc-4.1.2_sunos_i86pc hp_cxx-71_006_tru64 test_exported_xml_warchive_dll: gcc-4.1.2_sunos_i86pc hp_cxx-71_006_tru64 |spirit| bug_000008: darwin-4.0.1 hp_cxx-71_006_tru64 custom_real_parser: acc darwin-4.0.1 darwin-4.0.1 darwin-4.0.1 gcc-3.3.6 gcc-4.1.2_sunos_i86pc gcc-mingw-3.4.5 hp_cxx-71_006_tru64 intel-linux-9.0 msvc-8.0 msvc-8.0 sun-5.8 custom_real_parser_debug: acc darwin-4.0.1 darwin-4.0.1 darwin-4.0.1 gcc-3.3.6 gcc-4.1.2_sunos_i86pc gcc-mingw-3.4.5 hp_cxx-71_006_tru64 intel-linux-9.0 msvc-8.0 msvc-8.0 sun-5.8 grammar_mt_tests: darwin-4.0.1 hp_cxx-71_006_tru64 mix_and_match_trees: sun-5.8 owi_mt_tests: darwin-4.0.1 hp_cxx-71_006_tru64 |system| error_code_test: sun-5.8 error_code_test_dll: sun-5.8 error_code_user_test: sun-5.8 error_code_user_test_dll: sun-5.8 header_only_test: sun-5.8 initialization_test: sun-5.8 system_error_test: gcc-mingw-3.4.5 sun-5.8 system_error_test_dll: gcc-mingw-3.4.5 sun-5.8 |test| minimal_test: sun-5.8 prg_exec_fail1: sun-5.8 prg_exec_fail3: intel-linux-9.0 |thread| test_barrier: darwin-4.0.1 msvc-8.0 test_barrier_lib: darwin-4.0.1 msvc-8.0 test_condition: darwin-4.0.1 test_condition_lib: darwin-4.0.1 test_mutex: darwin-4.0.1 hp_cxx-71_006_tru64 msvc-8.0 test_mutex_lib: darwin-4.0.1 hp_cxx-71_006_tru64 msvc-8.0 test_once: darwin-4.0.1 test_once_lib: darwin-4.0.1 test_shared_mutex: darwin-4.0.1 gcc-4.1.2_sunos_i86pc test_shared_mutex_lib: darwin-4.0.1 gcc-4.1.2_sunos_i86pc gcc-mingw-3.4.5 test_thread: darwin-4.0.1 test_thread_lib: darwin-4.0.1 test_tss: darwin-4.0.1 darwin-4.0.1 hp_cxx-71_006_tru64 msvc-8.0 test_tss_lib: darwin-4.0.1 hp_cxx-71_006_tru64 msvc-8.0 test_xtime_lib: darwin-4.0.1 |tr1| std_test_tuple_tricky: sun-5.8 test_istream_std_header: darwin-4.0.1 test_tuple_tricky: sun-5.8 tr1_is_member_pointer_test: darwin-4.0.1 tr1_is_reference_test: darwin-4.0.1 |typeof| type_emulation: darwin-4.0.1 |utility| base_from_member_test: sun-5.8 result_of_test: sun-5.8 value_init_test: sun-5.8 |utility/enable_if| constructors: sun-5.8 dummy_arg_disambiguation: sun-5.8 lazy_test: sun-5.8 member_templates: sun-5.8 namespace_disambiguation: sun-5.8 no_disambiguation: sun-5.8 partial_specializations: sun-5.8 |wave| testwave: gcc-mingw-3.4.5 |xpressive| test_actions: gcc-3.3.6 test_assert: gcc-3.3.6 test_symbols: gcc-3.3.6

1 0

Re: [boost] Deterimining interest in: Optional Polymorphic Value object with Small Object optimization
by Mat Marcus 03 Nov '07

03 Nov '07

[sorry if resend--the first posting attempt (via gmail) seems to have failed] On Oct 20, 2007 1:15 PM, Corrado Zoccolo <czoccolo(a)gmail.com> wrote: > Hi Simon > > > On 10/20/07, Simon Francis <thejello(a)gmail.com> wrote: > > > > http://opensource.adobe.com/classadobe_1_1poly.html > > > > I already knew adobe poly, when I started writing optional_poly. The aim > is similar, but the approach is completely different. > With Adobe poly, you have to design the interfaces, and write "concept maps" > to specifically to work with it. > > Example, from Adobe poly test: > > struct poly_measurable_interface : adobe::poly_copyable_interface > { > virtual double size() const = 0; > > virtual ~poly_measurable_interface() { } > }; > > /*************************************************************************** **********************/ > // This class template implements the abstract measurable interface in terms > of a type T that > // Models the MeasurableConcept > > template <typename T> > struct poly_measurable_instance : adobe::optimized_storage_type<T, > poly_measurable_interface>::type > { > ADOBE_CLASS_REQUIRE(T, , MeasurableConcept); > > poly_measurable_instance(const T& x) > : adobe::optimized_storage_type<T, > poly_measurable_interface>::type(x) {} > > poly_measurable_instance(poly_measurable_instance& x, adobe::move_ctor > m) > : adobe::optimized_storage_type<T, > poly_measurable_interface>::type(x, m) {} > > double size() const > { > return MeasurableConcept<T>::size(this->get()); > } > }; > > /*************************************************************************** **********************/ > // Another boilerplate class, measurable serves as a template parameter to > the poly<> machinery > // tying together the interface and implementation above. > > struct measurable : adobe::poly_base<poly_measurable_interface, > poly_measurable_instance> > { > // No delegating constructors (yet), so we call base constructor > manually > template <typename T> > explicit measurable(const T& s) > : adobe::poly_base<poly_measurable_interface, > poly_measurable_instance>(s) { } > > measurable(measurable& x, adobe::move_ctor m) > : adobe::poly_base<poly_measurable_interface, > poly_measurable_instance>(x, m) {} > > // No forwarding in C++, so we do it manually > double size() const > { return interface_ref().size(); } > }; > > typedef adobe::poly<measurable> poly_measurable; > > Thanks to all this boilerplate code, you can use the usual dot notation to > access the members of the class. > > My approach is different. You don't have to change the interfaces to use > optional_poly (so it is non intrusive with existing hierarchies), and you > don't need all this boilerplate code, but you have to use the -> operator to > access members of the class. [snip] -------------- There have been a few posts on the boost lists recently mentioning the adobe::poly library. Since the poly documentation is still somewhat incomplete, except for a few research-orineted papers, I thought I'd give a bit more detail here, to help clarify the differences between poly<> and possibly similar libraries. You correctly note that the adobe::poly library requires more machinery to be provided by certain stakeholers. It does not, however, intrude into existing concrete classes. To better understand where the adobe::poly library lives in the design continuum, I'll consider a possible manner in which a piece of code may over its lifetime. I'll start with a (toy example of a) class that automatically sizes and positions widgets from a particular GUI library inside of a dialog. In this scenario, users of the layout engine first "append" widgets to the layout collection. Once all the widgets have been appended, the user can ask the engine to "solve" the layout. In order to solve the layout, the engine will call a measure function on each widget to obtain its desired extents and other layout constraints. When the layout is solved, the engine informs the widgets of their final location by invoking the place(Widget, extents_t) member function: // // Code evolution: stage 1-- //layout engine operating on aspecific concrete type class Widget {/*...*/}; // API-specific widget class class extents_t {/*...*/}; // encapsulates screen object size and location struct layout_engine { void append(Widget placeable) { placeables_m.push_back(placeable); } void solve() { extents_m.resize(placeables_m.size()); for(int i = 0; i != placeables_m.size(); ++i) measure(placeables_m[i], extents_m[i]); // ommitted: code to solve layout constraints // and update place_data_m (ommitted) for(int i = 0; i != placeables_m.size(); ++i) place(placeables_m[i], place_data_m[i]); } vector<extents_t> extents_m; vector<Widget> placeables_m; }; Version #1 of the engine above is designed to work on a single specific Widget type. Later in life, this code is to be ported to other platforms. One approach to generalization is to templatize the layout engine on the widget type. The code for the layout engine doesn't need to change. // // Code evolution: stage 2 --lifting the engine // (at compile time) using templates // template <class T> struct layout_engine { void append(T placeable) { placeables_m.push_back(placeable); } void solve() { extents_m.resize(placeables_m.size()); for(int i = 0; i != placeables_m.size(); ++i) measure(placeables_m[i], extents_m[i]); // ommitted: code to solve layout constraints // and update place_data_m (ommitted) for(int i = 0; i != placeables_m.size(); ++i) place(placeables_m[i], place_data_m[i]); } vector<extents_t> extents_m; vector<T> placeables_m; }; Version #2 of the code (above) assumes that measure and place operations with the right signatures are implemented for the T widget type. To improve usability of our class template, we use the boost::concept_check library to improve error messages in case the required measure and place operations are not present (not shown here). In the test code for adobe::poly that you cited above, you can see some of this machinery (ADOBE_CLASS_REQUIRE). We go even further simulating the C++ '0x concept_map feature through the use of operations qualified by MeasurableConcept. But this is not really poly<>-specific so I won't say more about it now. For the next stage of our code's evolution, we wish be able to use the layout engine in contexts where the widget type is not known until runtime. Since we don't wish to intrude on our concrete widget types to make them inherit from a base class, the usual object-oriented abstract base class approach doesn't appeal. Such an approach might not even be possible, given that we may not control the source code for the widget classes. One principle applied in the design of the poly<> library was that the ability for an object to behave polymorphically is not one that should be introduced/paid for at design-time. Instead, we support a pay-as-you-go plan at the point of polymorphic use. The adobe::poly library is a toolkit designed to facilitate the task of providing non-intrusive value-based wrappers that allow concrete classes to be used in a runtime polymorphic manner, without change of interface. We could retain the previous version of the layout_engine unchanged, instantiating it on the poly_placeable runtime polymorphic wrapper when we want runtime polymorphic behavior, and we could instantiate the layout engine "library" on a concrete type in applications where the widget type is known at compile time. For the runtime-polymorphic wrapper case this would simply look like: // Code evolution: stage 3 -- instantiating the layout_engine class on // the runtime polymorphic wrapper type poly_placeable layout_engine<poly_placeable> e; As an alternate use case (e.g. for dynamic libraries), we sometimes emphasize the runtime polymorphic usage by promoting/de-templatizing the layout_engine class template into a plain (non-templated) class: struct layout_engine { void append(poly_placeable placeable); void solve(); vector<extents_t> extents_m; vector<poly_placeable> placeables_m; }; The current version of the poly library assumes two different kinds of clients. The first kind of client (the wrapper author) is the provider of a poly "wrapper", such as the poly_measurable wrapper above. This client uses the poly library to reduce the burden of producing a particular non-intrusive polymorphic value type. Such clients must provide: an abstract base class specifying the required/available operations, (this is the role of poly_measurable_interface in the poly_test code), a class template that implementing the abstract interface in terms of concrete types that provide offer the appropriate signature (this is the role of poly_measurable_instance in the poly_test example), and a small glue class that holds the previous two artifacts together (measureable in the adobe_test example). Once those three artifacts have been written, the poly<> wrapper can be instantiated: typedef adobe::poly<measurable> poly_measurable; // in the poly_test example Poly offers a number of other features (small object optimization, move semantics using the NRVO-based adobe::move library, etc.) but I won't discuss those further. At this point the responsibilities of the first kind of poly client, the wrapper author, are complete. The second kind of client is the end user of classes such as poly_placeable. In the evolving code example above, we can look briefly at how the code that calls the layout engine evolves. The stage 1 calling sequence might look like: void place(widget, extents_t); //#0 exents_t measure(widget, extents_t); //#0 //... layout_engine e; // #1 void layout_dialog() { Widget widget1, widget2; //append some widgets: e.append(widget1); //#2 e.append(widgetn); //#3 //... e.solve(); } At stage 2, we might change #0 and #1: template <typename Widget> inline void place(poly_placeable p, extents_t ext) { p.place(ext); } //#0 template <typename Widget> inline exents_t measure(poly_placeable p , extents_t ext) { return p.measure(ext); } //#0 layout_engine<Widget> e; //#1' In keeping with our emphasis upon non-intrusiveness, the layout engine in this example makes use of free-function syntax when invoking place and measure. In the version 1 calling code, we provided overloads for the concrete widget type. In the version 2 calling code we provide function templates instead. The primary function templates above provide default implementations that delegate to member functions. For widget types that do not provide the necessary member functions we must specialize place<> and measure. At stage 3, we might also need to change #1 once more to layout_engine<poly_placeable> e; //#1'' In the conceptC++ version of poly, or in a version in which poly_constructors were non-explicit, no further changes would be required. In the current C++ '03 version, poly<> has an explicit constructor, so we also change lines #2 and #3 to: e.append(poly_placeable(widget1)); //#2'' e.append(poly_placeable(widgetn)); //#3'' I haven't touched on other adobe::poly features such as the assignability across different poly<> types, dynamic dispatch and dynamic_cast that poly can provide, but I've probably already said more than anyone wanted to hear about it in this thread. More info can be found at the following locations: http://opensource.adobe.com/ For the adobe source library (including poly) http://www.emarcus.org/papers/MPOOL2007-marcus.pdf http://www.emarcus.org/papers/MPOOL2007-slides-marcus.pdf # Runtime Polymorphic Generic Programming--Mixing Objects and Concepts in ConceptC++ Mat Marcus, Adobe Systems, Inc., Jaakko Järvi, Texas A&M University, Sean Parent, Adobe Systems, Inc. From: The 6th International Workshop on Multiparadigm Programming with Object-Oriented Languages at the ECOOP 2007. and a little bit here: http://www.speakeasy.org/~mmarcus/papers/gpce2007f-authors-version.pdf # Library Composition and Adaptation using C++ Concepts Jaakko Järvi, Texas A&M University, Mat Marcus, Adobe Systems, Inc., Jacob N. Smith, Texas A&M University. From: Proceedings of the 6th international conference on Generative programming and component engineering, 2007. Copyright ACM, 2007. This is the author's version of the work. It is posted here by permission of ACM for your personal use. Not for redistribution. The definitive version was published in the Proceedings of the 6th International Conference on Generative Programming and Component Engineering (Salzburg, Austria, October 01 - 03, 2007). GPCE '07 http://doi.acm.org/10.1145/1289971.1289984 - Mat

1 0

Boost inspect
by Maciej Sobczak 03 Nov '07

03 Nov '07

I have troubles deciphering what the inspect tool really does. In particular, the test defined in link_check.cpp - does it check the URL links in *source* files? Where can be such links located? In source comments presumably? Regards, -- Maciej Sobczak * www.msobczak.com * www.inspirel.com

2 1