- Boost - lists.boost.org

[boost::throw_exception] and platforms where it don't throw
by Thorsten Ottosen 09 Dec '05

09 Dec '05

Hi All, I'm about to replace all my throw Foo; statetements in the Pointer Container library with something else to support platforms without exceptions. Is using boost::throw_exception the way to do it? If I where on such a platform, I kinda think that I would have preferred an assertion *at the throw spot* instead of making the call stack deeper yet and then call about or something. Thanks for any feedback -Thorsten

4 6

[Defer] Decorated callbacks suggestion
by simon meiklejohn 09 Dec '05

09 Dec '05

This post suggests apply a Decorator like pattern to the Defer/Asio::demuxer style libraries. Where previously a component requests a deferred execution of a function f() it would now be possible to get f() called at the end of a chain of wrapping functions a( b( c( d( e( f() ) ) ) ) ); the decorating functions would be of the form void func( boost::function( void (void) ) ) i.e. they can be composed into a chain using boost::bind Of itself that looks pretty trivial. Where it becomes more interesting is when you consider 1. who injects the extra functions and when. 2. what can be done inside those function objects looking at the second - why would we want to decorate the eventual callback? Here are some possibilities 1. try to obtain some resource. If its not obtainable, then return without calling the decorated function 2. wait on a lock before proceeding (i.e. similar to the defer_mutex concept) 3. Create an object on the stack that helps the decorated callback - e.g. add a logging context string ("ACME callback" so when the eventual code calls LOG( "hello" ) what gets logged is "[ACME callback]hello" Apply this repeatedly - so the defer object, the defer requester and the callback target each insert a logging prefix, so LOG("hello") becomes "[DeferPool][Acme callback][My acme observer]hello" The three components that might have interesting things to insert into the chain are: 1. the owner of f() (i.e. the component registering for a callback) when it registers the callback. Lets say it inserts d() and e(). 2. the originator of the callback (e.g. the parser component from a prevoius discussion) when it initiates the callback, or when the client callback is registered 3. the provider of the defer object (e.g. main()), when it constructs the defer object. In addition to code to be executed in the chain of every callback its desirable to insert code that be executed just once by each thread in a pool (e.g. to get the pesky CoInitializeEx() called before servicing requests). Lets call these Base Thread Decorators. It may help to illustrate if i show a pseudo stack trace at the point where a callback has finally reached the innermost callback (f() in the above example). [top of stack] f() ...client supplied decorators e() d() ... callback originator decorators c() ... per defer object decorators (provided by main) b() defer_point::service_deferrals() - the thread waits for work .... base thread decorators (provided by main) a() - e.g. call CoInitEx... .... thread entry point defer_point::thread_entry() .... [bottom of stack] ------------------------------------ So i guess the point is - defer_point could usefully provide some methods for injecting decorators to be applied to all callbacks, as well as some methods to help callback recipients and callback originators to decorate their callbacks. Does this seem a useful addition? Just more crazy talk from a thread-obsessed idiot? Cheers Simon Meiklejohn

1 0

Feature Request - Combine or provide Interop between Boost Filesystem & Iostreams Library, Virtual File System
by Korcan Hussein 09 Dec '05

09 Dec '05

Just a thought if boost file-system could be user-configurable with boost iostreams library we could have a nice, clean API for virtual file-systems (VFS) not just for the OS file-system. For example the other day an associate of mine wanted to be able to read/write/etc to a zip file like a OS file-system, he couldn't use boost iostream's zip filter since it doesn't apparently provide that kind of behaviour/abstraction but boost file-system does provide that kind of abstraction/behaviour the only problem is it's pretty much tied to working with OS file-systems only as far as i'm aware.

2 1

Boost regression notification (2005-12-09 [HEAD])
by Douglas Gregor 09 Dec '05

09 Dec '05

Boost regression test failures ------------------------------ Report time: 2005-12-09T02:14:04Z This report lists all regression test failures on release platforms. Detailed report: http://engineering.meta-comm.com/boost-regression/CVS-HEAD/developer/issues… 229 failures in 17 libraries: bind (1) concept_check (14) date_time (19) foreach (5) graph (8) io (1) mpl (1) multi_array (1) parameter (1) python (1) serialization (36) smart_ptr (2) spirit (2) tr1 (90) typeof (22) wave (1) xpressive (24) |bind| bind_dm3_test: msvc |concept_check| stl_concept_covering: cw-9_4 cw-9_4 gcc-3.3.6-linux gcc-3.4.4-linux gcc-3_3-darwin gcc-3_4_3-sunos gcc-4_0-darwin intel-win32-8_1 intel-win32-9_0 intel-win32-9_0 intel-win32-9_0 msvc vc-7_1 vc-7_1 |date_time| testc_local_adjustor: msvc testclock: msvc testdst_rules: msvc testfiletime_functions: msvc testgreg_duration_operators: msvc testgreg_serialize_dll: cw-9_4 intel-win32-8_1 intel-win32-9_0 vc-7_1 vc-7_1 testiterator: msvc testlocal_adjustor: msvc testmicrosec_time_clock: msvc testparse_time: msvc testtime: msvc testtime_formatters: msvc testtime_period: msvc testwcustom_time_zone: msvc testwposix_time_zone: msvc |foreach| array_byref: cw-9_4 array_byval: cw-9_4 rvalue_const: intel-win32-9_0 stl_byref: cw-9_4 stl_byval: cw-9_4 |graph| csr_graph_test: cw-9_4 gcc-3_4_3-sunos dominator_tree_test: cw-9_4 intel-win32-9_0 vc-7_1 graphviz_test: vc-7_1 vc-7_1 layout_test: intel-win32-9_0 |io| ios_state_unit_test: intel-win32-9_0 |mpl| size_t: gcc-4_0-darwin |multi_array| index_bases: cw-9_4 |parameter| sfinae: msvc |python| stl_iterator: msvc |serialization| test_class_info_load_binary_archive: gcc-3_3-darwin gcc-3_4_3-sunos gcc-4_0-darwin test_class_info_load_binary_archive_dll: gcc-3_3-darwin gcc-3_4_3-sunos gcc-4_0-darwin test_class_info_load_text_archive: gcc-3_3-darwin gcc-3_4_3-sunos gcc-4_0-darwin test_class_info_load_text_archive_dll: gcc-3_3-darwin gcc-3_4_3-sunos gcc-4_0-darwin test_class_info_load_text_warchive: gcc-3_3-darwin gcc-3_4_3-sunos gcc-4_0-darwin test_class_info_load_text_warchive_dll: gcc-3_3-darwin gcc-3_4_3-sunos gcc-4_0-darwin test_class_info_load_xml_archive: gcc-3_3-darwin gcc-3_4_3-sunos gcc-4_0-darwin test_class_info_load_xml_archive_dll: gcc-3_3-darwin gcc-3_4_3-sunos gcc-4_0-darwin test_class_info_load_xml_warchive: gcc-3_3-darwin gcc-3_4_3-sunos gcc-4_0-darwin test_class_info_load_xml_warchive_dll: gcc-3_3-darwin gcc-3_4_3-sunos gcc-4_0-darwin test_const_save_fail1: msvc test_const_save_fail2: msvc test_const_save_fail3: msvc test_map_binary_archive_dll: msvc test_map_text_archive_dll: msvc test_map_text_warchive_dll: msvc |smart_ptr| pointer_to_other_test: msvc shared_ptr_alloc2_test: msvc |spirit| traverse_tests: intel-win32-9_0 traverse_tests_debug: intel-win32-9_0 |tr1| run_complex_overloads: cw-9_4 gcc-3_4_3-sunos std_run_complex_overloads: cw-9_4 gcc-3_4_3-sunos std_run_random: cw-9_4 std_test_array: cw-9_4 std_test_bind: cw-9_4 std_test_complex: cw-9_4 std_test_function: cw-9_4 std_test_hash: cw-9_4 std_test_mem_fn: cw-9_4 std_test_random: cw-9_4 std_test_regex: cw-9_4 std_test_result_of: cw-9_4 std_test_tr1_include: cw-9_4 std_test_tuple: cw-9_4 std_test_type_traits: cw-9_4 test_array: cw-9_4 test_bind: cw-9_4 test_complex: cw-9_4 test_function: cw-9_4 test_hash: cw-9_4 test_mem_fn: cw-9_4 test_random: cw-9_4 test_reference_wrapper: cw-9_4 test_result_of: cw-9_4 test_shared_ptr: cw-9_4 test_tr1_include: cw-9_4 test_tuple: cw-9_4 tr1_add_const_test: cw-9_4 tr1_add_cv_test: cw-9_4 tr1_add_pointer_test: cw-9_4 tr1_add_reference_test: cw-9_4 tr1_add_volatile_test: cw-9_4 tr1_aligned_storage_test: cw-9_4 tr1_alignment_of_test: cw-9_4 tr1_extent_test: cw-9_4 tr1_has_nothrow_assign_test: cw-9_4 tr1_has_nothrow_constr_test: cw-9_4 tr1_has_nothrow_copy_test: cw-9_4 tr1_has_tr1_ref_wrap_fail: cw-9_4 tr1_has_tr1_shared_ptr_fail: cw-9_4 tr1_has_tr1_tuple_fail: cw-9_4 tr1_has_trivial_assign_test: cw-9_4 tr1_has_trivial_constr_test: cw-9_4 tr1_has_trivial_copy_test: cw-9_4 tr1_has_trivial_destructor_test: cw-9_4 tr1_has_virtual_destructor_test: cw-9_4 tr1_is_arithmetic_test: cw-9_4 tr1_is_array_test: cw-9_4 tr1_is_base_of_test: cw-9_4 tr1_is_class_test: cw-9_4 tr1_is_compound_test: cw-9_4 tr1_is_const_test: cw-9_4 tr1_is_convertible_test: cw-9_4 tr1_is_empty_test: cw-9_4 tr1_is_enum_test: cw-9_4 tr1_is_floating_point_test: cw-9_4 tr1_is_function_test: cw-9_4 tr1_is_fundamental_test: cw-9_4 tr1_is_integral_test: cw-9_4 tr1_is_member_func_test: cw-9_4 tr1_is_member_obj_test: cw-9_4 tr1_is_member_pointer_test: cw-9_4 tr1_is_object_test: cw-9_4 tr1_is_pod_test: cw-9_4 tr1_is_pointer_test: cw-9_4 tr1_is_polymorphic_test: cw-9_4 tr1_is_reference_test: cw-9_4 tr1_is_same_test: cw-9_4 tr1_is_scalar_test: cw-9_4 tr1_is_signed_test: cw-9_4 tr1_is_union_test: cw-9_4 tr1_is_unsigned_test: cw-9_4 tr1_is_void_test: cw-9_4 tr1_is_volatile_test: cw-9_4 tr1_rank_test: cw-9_4 tr1_remove_all_extents_test: cw-9_4 tr1_remove_const_test: cw-9_4 tr1_remove_cv_test: cw-9_4 tr1_remove_extent_test: cw-9_4 tr1_remove_pointer_test: cw-9_4 tr1_remove_reference_test: cw-9_4 tr1_remove_volatile_test: cw-9_4 tr1_tricky_abstract_type_test: cw-9_4 tr1_tricky_add_pointer_test: cw-9_4 tr1_tricky_function_type_test: cw-9_4 tr1_tricky_incomplete_type_test: cw-9_4 tr1_tricky_is_enum_test: cw-9_4 tr1_tricky_partial_spec_test: cw-9_4 |typeof| data_member_native: cw-9_4 function_native: cw-9_4 msvc function_ptr_native: cw-9_4 function_ref_native: cw-9_4 lvalue_native: cw-9_4 msvc member_function_native: cw-9_4 modifiers_emulation: cw-9_4 modifiers_native: cw-9_4 noncopyable_native: cw-9_4 std_emulation: cw-9_4 cw-9_4 std_native: cw-9_4 template_dependent_native: cw-9_4 template_enum_native: cw-9_4 template_int_native: cw-9_4 template_multiword_native: cw-9_4 template_tpl_native: cw-9_4 msvc template_type_native: cw-9_4 type_native: cw-9_4 |wave| testwave_dll: cw-9_4 |xpressive| misc1: cw-9_4 test1: cw-9_4 test1u: cw-9_4 test2: cw-9_4 test2u: cw-9_4 test3: cw-9_4 test3u: cw-9_4 test4: cw-9_4 test4u: cw-9_4 test5: cw-9_4 test5u: cw-9_4 test6: cw-9_4 test6u: cw-9_4 test7: cw-9_4 test7u: cw-9_4 test8: cw-9_4 test8u: cw-9_4 test9: cw-9_4 test9u: cw-9_4 test_cycles: cw-9_4 test_dynamic: cw-9_4 test_non_char: cw-9_4 test_regex_primitives: cw-9_4 test_static: cw-9_4

1 0

Re: [boost] [boost::throw_exception] and platforms where itdon't throw
by Martin Bonner 09 Dec '05

09 Dec '05

----Original Message---- From: Peter Dimov [mailto:pdimov@mmltd.net] Sent: 08 December 2005 16:46 To: boost(a)lists.boost.org Subject: Re: [boost] [boost::throw_exception] and platforms where itdon't throw > Martin Bonner wrote: >> From: Peter Dimov [mailto:pdimov@mmltd.net] >> >>> And of course in a situation where throw_exception is used to throw >>> bad_alloc, an assertion makes even less sense, because there are no >>> "logic errors" involved, and presenting the effects of a failed >>> assertion to the end user would serve little purpose; the program >>> could do nothing to defend itself from the out of memory situation. >> >> But if a library is being used in an exception free environment, >> maybe presenting an assertion failure to the user is as good as you >> can do. > > Possibly, but who is "you" in the above sentence? The library author. > The whole point of using an exception is that you the library > author do not take responsibility of handling the error, leaving > it up to you the library user to do that instead. Right. But the problem is what does the author of boost::whatever do when the user wants to use boost::whatever in an environment that doesn't support exceptions? One solution is to offer two functions (like at() and operator[]) and the user who doesn't want exceptions uses the no-throw function. That's a good solution sometimes, but there are other occasions where adding all that extra machinery to support the few no-throw users is a bit much. In those circumstances, it may be better for boost::whatever to say "if your environment supports exceptions, you can handle condition x by catching y; if not, condition x will crash your program." The no-throw users may decide they know condition x is not going to happen, or that crashing is OK, or that they can't use the library. At least that way the users get to choose. -- Martin Bonner Martin.Bonner(a)Pitechnology.com Pi Technology, Milton Hall, Ely Road, Milton, Cambridge, CB4 6WZ, ENGLAND Tel: +44 (0)1223 441434

2 1

[regex][1.33.1-rc2] regression wrt 1.32.0
by Boris Kolpackov 09 Dec '05

09 Dec '05

Good day, We observe a regression in the regex library compared to 1.32.0. The following program: #include <string> #include <iostream> #include <boost/regex.hpp> int main () { using std::string; using boost::regex; using boost::regex_merge; regex expr ("(\\.(idl|cidl|cdl))?$"); std::cerr << regex_merge ( string ("test.cidl"), expr, string ("E.idl"), boost::match_default | boost::format_all ) << std::endl; } prints "testE.idlE.idl" when compiled and linked against 1.33.x and "testE.idl" against previous versions. hth, -boris

4 8

[Boost-bugs] [ boost-Support Requests-1377001 ] Compiling only needed version
by SourceForge.net 09 Dec '05

09 Dec '05

Support Requests item #1377001, was opened at 2005-12-09 02:01 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=207586&aid=1377001&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: Building Boost Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Compiling only needed version Initial Comment: I'm building boost using MinGW. I would like to know is there way to only build static-link release version of each library. I don't need debug and MinGW can't build multy-threaded libraries (or can only build them) AFAIK. Also can I disable extra tags for names (I need only one version of boost_date_time, so there is no need for extra tags since I only use that one)? e-mail: spoofer255 at gmail dot com ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=207586&aid=1377001&group_… ------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

[graph] Proposal: Algorithm for the Shortest Path Problem with Resource Constraints
by Michael Drexl 09 Dec '05

09 Dec '05

Hi, is there any interest in including an algorithm for solving the shortest path problem with resource constraints (SPPRC) in the Boost Graph library? I've implemented an exact algorithm for this NP-hard problem. The algorithm is basically a label-setting algorithm based on dynamic programming. It is parameterized on the graph type (of course) and the type of the resource container (data structures specifying what resources there are and how they are to be managed in the course of the algorithm). Some remarks on the underlying problem: The SPPRC seeks the shortest (fastest, cheapest) path in a network with arbitrary arc lengths (travel times, costs) from an origin node to a destination node subject to one or more resource constraints. For example, one might seek a path of minimum length from o to d subject to the constraints that - the total travel time must not exceed some upper bound and/or - the total amount of some good that has to be picked up at the vertices along the path be less than or equal to some capacity limit and/or - if two vertices i_1 and i_2 are visited on a path, then i_1 must be visited before i_2 - etc. The problem is NP-hard in the strong sense. If the path need not be elementary, i.e., if it is allowed that vertices or arcs are visited more than once, the problem can be solved in pseudopolynomial time. A recent survey on the problem is: Desaulniers, G.; Irnich, S. (2005): Shortest Path Problems with Resource Constraints in: Desaulniers, G.; Desrosiers, J.; Solomon, M. (eds.) (2005): Column Generation Springer, New York, pp. 33--65 (available online via www.dpor.rwth-aachen.de/de/publikationen/pdf/or_2004-01.pdf) Regards, Michael D.

3 4

[interval] unprotect &c.
by David Abrahams 09 Dec '05

09 Dec '05

I find this in the documentation, which sounds self-contradictory: > Unprotected rounding > As explained in this section, a good way to speed up computations > when the base type is a basic floating-point type is to unprotect > the intervals at the hot spots of the algorithm. This method is safe > and really an improvement for interval computations. But please > remember that any basic floating-point operation executed inside the > unprotection blocks will probably have an undefined behavior (but > only for the current thread). a. That doesn't sound "safe." 1. there's the potential undefined behavior. 2. there's the whole notion of "unprotect"-ing the computation. Don't I lose the value of interval computation? That is, will my computed results still reflect the potential error due to floating-point precision limits? b. How am I going to do any useful computation in an unprotection block without doing any basic floating-point operations? If it's not self-contradictory, could you explain what it means and, if possible, improve the wording? >From reading the docs, it's very unclear what optimization this unprotection mechanism allows, and it's unclear when/how it's mathematically valid to use the results (e.g. why not do all computations that way if it's faster?) I get only a vague sense of the answers to these questions from the docs. Yes, I read the Horner example. Finally, the use of the term "unprotection block" looks extremely misleading. It looks like you have unprotected datatypes, but "block" implies that there's a lexical scope within which unprotection is in effect. There does seem to be such a notion for rounding mode (by declaring an auto variable of I::traits_type::rounding), but not so for unprotect. Unless I'm gravely confused, which is possible, in which case, again, the docs need to be upgraded. Thanks, -- Dave Abrahams Boost Consulting www.boost-consulting.com

2 5

[shared_ptr] base class conversion problem
by Artyom Borodkin 09 Dec '05

09 Dec '05

This following code does not work, but it could. You should just add the template constructor. So, why not? #include <boost/shared_ptr.hpp> #include <iostream> class A{}; class B{}; class C : public A{}; void foo( boost::shared_ptr<A> pa ){ std::cout << "A"; } void foo( boost::shared_ptr<B> pb ){ std::cout << "B"; } int main(){ boost::shared_ptr<C> ptr(new C); foo( ptr ); return 0; } //--------------------------- If add this template constructor it will help with ambiguous problem. template< class T2 > shared_ptr( const shared_ptr<T2>& s_ptr, typename enable_if<is_convertible<T*,T2*>::result, void* >::type = 0) { ... }

1 0