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

Proposed addition to the iterator library for iterating over all tuples.
by Alex Mendes da Costa 19 Jun '09

19 Jun '09

Hi folks: I quite often have to write code to do the following: Given N sequences, generate all the N-tuples s.t. the i'th element in each tuple is drawn from the i'th sequence. For example, if sequence S1 is { 1, 2, 3 } and sequence S2 is { 10, 20 }, I need to generate these tuples: (1, 10), (2, 10), (1, 20), (2, 20). I think this problem could be solved elegantly with a iterator similar to zip_iterator. I have some questions: (1) Is there already a way to do this in boost? (2) If not, would this be a worthwhile addition to the iterator library? (3) If so, could I contribute code for this, or must the existing library owners write it? (4) If so, how would I go about getting my code added? Most of the docs seem to be about submitting entire libraries, rather than extensions to existing libraries. Thanks, Alex

4 18

[variant, MPL] Is there a variant -> mpl sequence metafunction ?
by Jaakko Järvi 13 Nov '06

13 Nov '06

make_variant_over<Seq>::type creates a variant type from an MPL Sequence. Is there an operation that would do the opposite, create an MPL sequence from a variant? I cannot just use the type parameter list as such because the types that stand for an empty type are different in both libraries: boost::detail::variant::void_ in variant, and something else in MPL. Best, Jaakko -- Jaakko Järvi, jarvi(a)cs.tamu.edu

8 12

[jamboost] Boost.Build V2, Milestone 10 released
by Vladimir Prus 04 Nov '06

04 Nov '06

I'm pleased to announce that the next milestone release of Boost.Build V2 is available at http://prdownloads.sourceforge.net/boost/boost-build-2.0-m10.tar.bz2 http://prdownloads.sourceforge.net/boost/boost-build-2.0-m10.zip See also http://boost.org/boost-build2/ for online docs (a copy is included in distribution). Due to large number of improvements all users are encouraged to upgrade. Changes in this release: Many toolsets were added: Intel, Metrowerks, Comeau, aCC, vacpp. Documentation was converted to BoostBook and improved. Performance was improved. - Toolsets initialization syntax is much more uniform. Compiler and linker flags can now be specified. - The algorithm for computing build properties was improved. Conditional requirements can be chained, and a number of bugs were fixed. - Specific order of properties can be specified. - The main target rules can be called from everywhere, not necessary from Jamfile. - Check for "unused sources" removed. - The <library> feature affects only linking now. - The <file> feature now works only for libraries. - Simpler syntax for "searched" libraries was added. - New <dependency> feature. Unix: The right order of static libraries on Unix is automatically computed. The <hardcode-dll-paths> feature is the default. gcc: The -fPIC option is passed when creating shared libraries. Problems with distcc were solved. Sun: It's now possible to use the sun linker (as opposed to gnu), and to compile C files. Darwin: Shared libraries are now supported. MSVC: Before resource files compilation, the setup script is invoked. Options deprecated in 8.0 are not longer used. The following bugs were fixed: - The <unit-test> rule did not handle the <library> property. - Don't add "bin" to the build directory explicitly specified by the user. - Allow <include-type> to select staged targets, even with <traverse-dependencies>off. - Includes for the form '# include <whatever>" did not work. - (Qt) Add paths to all dependent libs to uic command line, which helps if the UI files uses plugins. - Using <toolset-msvc:version>xxx in requirements was broken. - Error message printed when target can be found is much more clear. - Inline targets in sources of 'stage' did not work. - Don't produce 'independent target' warnings on Windows - (gcc) The <link-runtime>static did not work. - (gcc) Suppress warnings from the 'ar' tool on some systems. - (gcc) Don't try to set soname on NT. Developer visible changes: - Generator priorities are gone, explicit overrides are used. - 'Active' features were removed - Support for VMS paths was added. Thanks to Christopher Currie, Pedro Ferreira, Philipp Frauenfelder, Andre Hentz, Jurgen Hunold, Toon Knapen, Johan Nilsson, Alexey Pakhunov, Brock Peabody, Michael Stevens and Zbynek Winkler who contributed code to this release. - Volodya

3 5

[Python] Slice test fails on Intel 8.1 at runtime
by Stefan Slapeta 23 Oct '06

23 Oct '06

This is not a new failure, but the failure is reported for the first time. Please could anybody have a look at it? See http://tinyurl.com/4n2fx Thanks, Stefan

5 12

TR2 and C++0x heads up
by Beman Dawes 23 Sep '06

23 Sep '06

The C++ standards committee's Library Working Group has proposed a schedule for library changes and extensions: * October 2005: cutoff date for C++0x major library proposals * October 2006: cutoff date for library TR2 proposals * April 2007: cutoff date for C++0x library clean-up papers The usual rule-of-thumb is that new library components go in TR2, while changes to existing components go in C++0x. The LWG will consider exceptions to the rule on a case-by-case basis. The LWG is planning to issue a "Call for Proposals" with details, but in the meantime Boost developers might want to start thinking about which Boost libraries they want to propose to the LWG. Because most proposals go through one or more revisions before being accepted, it helps a proposal's chances if it reaches the committee as many meetings as possible before the final cut-off. So far there are plans to propose Boost.Threads, Boost.Filesystem, and Boost.Signals. As well as proposals for some of the more major libraries, I personally hope someone will do a sweep through Boost looking at some of the smaller utilities and helpers for a possible "Small Additions" proposal. --Beman

36 149

New implementation of remove_xxx for vintage compilers
by Peder Holt 28 Mar '06

28 Mar '06

Hi. I have started implementing some of the missing type_traits functionality for vintage compilers using typeof. The following are complete, and seem to work flawlessly on VC 6.5 and 7.0: remove_pointer remove_reference remove_bounds The source is available at: http://groups.yahoo.com/group/boost/files/typeof_vintage.zip The use of typeof in this respect, makes remove_xxx much more flexible. Would it be possible to start using this scheme for compilers without partial template specialization support? #define BOOST_MAX_TYPEOF_SIZE 20 #include <boost/test/minimal.hpp> //Include typeof_define.hpp in all header files where new types are added to typeof. #include <boost/typeof/typeof_define.hpp> #include <complex> #include <boost/type_traits/remove_reference.hpp> #include <boost/type_traits/remove_pointer.hpp> #include <boost/type_traits/remove_bounds.hpp> #include <boost/type_traits/is_same.hpp> template<typename A0> struct X {}; template<typename A0,unsigned int A1> struct Y {}; template<typename A0,typename A1,long A2> struct Z {}; BOOST_TYPEOF_DEFINE_TEMPLATE(X,1,(typename)) BOOST_TYPEOF_DEFINE_TEMPLATE(Y,2,(typename,unsigned int)) BOOST_TYPEOF_DEFINE_TEMPLATE(Z,3,(typename,typename,long)) BOOST_TYPEOF_DEFINE_TEMPLATE(std::complex,1,(typename)) int test_main(int, char*[]) { BOOST_TEST((boost::is_same<X<int>* const[8][9],boost::remove_bounds<X<int>* const[5][8][9]>::type>::value)); BOOST_TEST((boost::is_same<Z<X<double&>,Y<bool[4][7],12324>,0>* const*,boost::remove_pointer<Z<X<double&>,Y<bool[4][7],12324>,0>* const**volatile>::type>::value)); //VC7.1 fails to compile remove_reference. BOOST_TEST((boost::is_same<Y<int,345>** const,boost::remove_reference<Y<int,345>** const&>::type>::value)); typedef BOOST_TYPEOF(5.+std::complex<double>(6,7)) result_type; BOOST_TEST((boost::is_same<result_type,std::complex<double> >::value)); return 0; } -- Peder Holt

8 29

Bind comparisons
by David Abrahams 03 Feb '06

03 Feb '06

Is it really true that I can write bind(f, _1) > _2 but can't write _1 > _2 ?? I can't imagine a good reason for that restriction, but I don't see any indication that the latter is supported in the docs. -- Dave Abrahams Boost Consulting www.boost-consulting.com

5 25

[ANN] Phoenix-2 Preview
by Joel de Guzman 01 Dec '05

01 Dec '05

Hi, Hi. Here's a preview of Phoenix V2. This will probably be the last release of the library. Phoenix V2 will be the basis of the Phoenix and Boost.Lambda merger. You can get it here: http://spirit.sourceforge.net/dl_more/phoenix-2.zip You can browse the draft docs here: http://tinyurl.com/6crgp What's new? A lot. This is a total rewrite based on earlier discussions with Jaakko Jarvi. The library's is built on top of Fusion and of course MPL. Of particular interest are local variables and lambda-lambda scopes: http://tinyurl.com/3mn6w There is also a set of lazy functions that work on STL sequences (e.g. push_back etc.): http://tinyurl.com/46bbm and pretty soon, a final TODO item (built on top of scopes/ lambda), lazy STL algorithms (e.g. find_if, etc). The scopes section (link provided above) in the docs illustrates how to write lazy functions that accept higher order functions (e.g. for_each). Regards, -- Joel de Guzman http://www.boost-consulting.com http://spirit.sf.net

5 19

[database]
by Brock Peabody 10 Nov '05

10 Nov '05

Hi, I've added the code for the database project to the sandbox. I've also made the following changes based on feedback from Caleb and Jonathan: 1) fixed <: digraphs 2) added transaction functions to the abstract interface. Added a reference_counted_transaction_manager class for use in implementations that don't support nested transactions. 3) made the interface support null field detection via boost.optional 4) iteration supports BiDirectional model instead of RandomAccess 5) added a transaction class for scoped transaction management on the to-do list: 1) documentation - this is going to be a word document or something at first since I know nothing about html. 2) make .jam files 3) test cases - I'm not sure how these are going to work. 4) investigate possibility of supporting a prepare_statement function

5 8

Macros at namespace scope: trailing semicolon?
by David Abrahams 14 Oct '05

14 Oct '05

I am defining a macro, BOOST_PARAMETER_KEYWORD(tag_namespace, name) that declares a keyword for the Parameter library. It has to be used at namespace scope. I have the option to define it so that correct usage requires a trailing semicolon, or so that the trailing semicolon is forbidden. Unfortunately I don't have the ability to make it optional. Which should I choose? IMO there's no chance of confusing it with a function call, since a function call would be illegal in the context in which it's used, and people are naturally more likely to add a semicolon without thinking about it, and if I design the macro so that a semicolon is required it will interact more smoothly with editors and pretty-printers. So I can't see any good reason not to require the semicolon. Arguments? -- Dave Abrahams Boost Consulting www.boost-consulting.com

19 87

[range] How to extend Boost.Range?
by Eric Niebler 21 Sep '05

21 Sep '05

While investigating test failures with Boost.Foreach, I found this in Boost.Range's documentation for extending the Range library: http://boost.org/libs/range/doc/boost_range.html#minimal_interface This seems to suggest that the only way to extend Boost.Range is for user-defined types to implement a std-container-like interface, with nested iterator and const_iterator types, and begin() and end() member functions. Is this really the intention? I seem to recall some discussion about a more accomodating extensibility mechanism that makes allowances for non-std-container-like user-defined range types. In fact, Boost.Foreach assumes such an interface, with disastrous results. What became of Boost.Range's extensibility mechanism? Is it documented anywhere, and I'm just not seeing it? -- Eric Niebler Boost Consulting www.boost-consulting.com

9 74

[lambda] extension question
by Brock Peabody 18 Sep '05

18 Sep '05

Hi, I'm trying to learn how to make my own lambda compatible function objects and I'm hoping that someone can nudge me in the right direction. My first try is called tuple_element. It takes an index as a template parameter and a tuple as an argument, returning the element at the given index: //should print "x" cout << tuple_element<1>(_1)(tuple<int,std::string>(2, "x")); I've got everything working except for the sig template. tuple_element looks like (mostly copied from lambda source code): template <int Index> struct tuple_element_action {}; template <int Index, typename Arg> inline const lambda_functor< lambda_functor_base< tuple_element_action<Index>, tuple<lambda_functor<Arg> > > > tuple_element(const lambda_functor<Arg>& a) { return lambda_functor_base< tuple_element_action<Index>, tuple<lambda_functor<Arg> > > ( tuple<lambda_functor<Arg> >(a)); } and the action: template<typename Args, int Index> class lambda_functor_base<tuple_element_action<Index>, Args> { public: Args args; template <class T> struct sig : tuples::element<Index,T> {}; explicit lambda_functor_base(const Args& a) : args(a) {} template<class RET, CALL_TEMPLATE_ARGS> RET call(CALL_FORMAL_ARGS) const { return detail::select(get<0>(args), CALL_ACTUAL_ARGS).get<Index>(); } }; When I try to compile my example in VC 7.1 I get an error that seems to indicate that the type being passed to the sig template is boost::tuples::null_type. Everything works if I hardwire it like: template <class T> struct sig { typedef std::string type; }; Any ideas? Thanks, Brock

5 13

stlport toolset patches
by François Dumont 13 Sep '05

13 Sep '05

Here is a first patch to build boost using STLport 5.0 with MSVC compilers. STLport 5.0 has adopt a more simple naming schema for generated library, compiler name is not part of it anymore. Rather than changing existing variable in the .jam files I prefered to introduce a new variable STLPORT_USE_AUTO_LINK to signal support of the auto link feature. In this case no lib is specified at link phase, STLport takes care of it. Any remark on the patches will be welcome as I am a completely beginner with bjam. What I would like to achieve now is reflect in bajm files that 5.0 do not support 'wrapper' mode anymore, stlport-iostream feature has to be on per default with this version, is it possible? Bests *** msvc-stlport-tools.jam.orig Thu Aug 25 05:10:34 2005 --- msvc-stlport-tools.jam Thu Aug 25 16:36:23 2005 *************** *** 13,18 **** --- 13,19 ---- STLPORT_LIB_BASE_NAME ?= stlport_vc6 ; STLPORT_LIB_STATIC_SUFFIX ?= _static ; + STLPORT_USE_AUTO_LINK = yes ; # bring in the STLPort configuration SEARCH on stlport.jam = $(BOOST_BUILD_PATH) ; *** stlport.jam.orig Thu Aug 25 05:11:22 2005 --- stlport.jam Thu Aug 25 16:37:06 2005 *************** *** 105,111 **** flags $(CURR_TOOLSET) DEFINES <runtime-build>debug : _STLP_DEBUG=1 _STLP_DEBUG_UNINITIALIZED=1 ; flags $(CURR_TOOLSET) DEFINES <runtime-link>dynamic : _STLP_USE_DYNAMIC_LIB=1 ; ! flags $(CURR_TOOLSET) FINDLIBS <stlport-iostream>on/<runtime-build>debug/<runtime-link>static : $(STLPORT_LIB_BASE_NAME)$(STLPORT_LIB_DEBUG_SUFFIX)$(STLPORT_LIB_STATIC_SUFFIX) ; ! flags $(CURR_TOOLSET) FINDLIBS <stlport-iostream>on/<runtime-build>debug/<runtime-link>dynamic : $(STLPORT_LIB_BASE_NAME)$(STLPORT_LIB_DEBUG_SUFFIX) ; ! flags $(CURR_TOOLSET) FINDLIBS <stlport-iostream>on/<runtime-build>release/<runtime-link>static : $(STLPORT_LIB_BASE_NAME)$(STLPORT_LIB_STATIC_SUFFIX) ; ! flags $(CURR_TOOLSET) FINDLIBS <stlport-iostream>on/<runtime-build>release/<runtime-link>dynamic : $(STLPORT_LIB_BASE_NAME) ; --- 105,114 ---- flags $(CURR_TOOLSET) DEFINES <runtime-build>debug : _STLP_DEBUG=1 _STLP_DEBUG_UNINITIALIZED=1 ; flags $(CURR_TOOLSET) DEFINES <runtime-link>dynamic : _STLP_USE_DYNAMIC_LIB=1 ; ! if ! $(STLPORT_USE_AUTO_LINK) ! { ! flags $(CURR_TOOLSET) FINDLIBS <stlport-iostream>on/<runtime-build>debug/<runtime-link>static : $(STLPORT_LIB_BASE_NAME)$(STLPORT_LIB_DEBUG_SUFFIX)$(STLPORT_LIB_STATIC_SUFFIX) ; ! flags $(CURR_TOOLSET) FINDLIBS <stlport-iostream>on/<runtime-build>debug/<runtime-link>dynamic : $(STLPORT_LIB_BASE_NAME)$(STLPORT_LIB_DEBUG_SUFFIX) ; ! flags $(CURR_TOOLSET) FINDLIBS <stlport-iostream>on/<runtime-build>release/<runtime-link>static : $(STLPORT_LIB_BASE_NAME)$(STLPORT_LIB_STATIC_SUFFIX) ; ! flags $(CURR_TOOLSET) FINDLIBS <stlport-iostream>on/<runtime-build>release/<runtime-link>dynamic : $(STLPORT_LIB_BASE_NAME) ; ! } *** vc7-stlport-tools.jam.orig Thu Aug 25 05:21:13 2005 --- vc7-stlport-tools.jam Thu Aug 25 16:36:40 2005 *************** *** 3,8 **** --- 3,9 ---- flags $(gCURRENT_TOOLSET) STLPORT_LIB_BASE_NAME ; STLPORT_LIB_BASE_NAME ?= stlport_vc70 ; + STLPORT_USE_AUTO_LINK ?= yes ; # bring in the STLPort configuration SEARCH on stlport.jam = $(BOOST_BUILD_PATH) ;

3 3

[Boost.Thread]: consider removing catch(...) from thread_proxy
by Slawomir Lisznianski 13 Sep '05

13 Sep '05

Hello, I find the catch(...) clause in the thread_proxy function (thread.cpp) causing more harm than good. If exception "leaks" from a function executing in the context of a thread, the thread silently goes away but the application continues to operate as if nothing happend. I think, in this instance, the library simply "does too much" by trying to do the cleanup. As a user, I can always wrap the code in the catch-all, but what I cannot change is the fact that when unhandled exception is thrown, I will not see the function in the stack trace where the exception originated. Here is the proposed proxy, after trivial changes: extern "C" { #if defined(BOOST_HAS_WINTHREADS) unsigned __stdcall thread_proxy(void* param) #elif defined(BOOST_HAS_PTHREADS) static void* thread_proxy(void* param) #elif defined(BOOST_HAS_MPTASKS) static OSStatus thread_proxy(void* param) #endif { thread_param* p = static_cast<thread_param*>(param); boost::function0<void> threadfunc = p->m_threadfunc; p->started(); threadfunc(); #if defined(BOOST_HAS_WINTHREADS) on_thread_exit(); #endif #if defined(BOOST_HAS_MPTASKS) ::boost::detail::thread_cleanup(); #endif return 0; } } Regards, Slawomir

14 47

File Vault broken
by Eric Niebler 12 Sep '05

12 Sep '05

I just noticed that *everything* in the file vault is gone: http://boost-sandbox.sf.net/vault What's up? -- Eric Niebler Boost Consulting www.boost-consulting.com

6 15

[serialization] Boost.Serialization 1.33.0 Breaks Serialization Code inDLLs
by martin.ecker＠tab.at 06 Sep '05

06 Sep '05

Hello, Boost.Serialization 1.33.0 breaks serialization of derived classes referenced via base class pointers when using DLLs on Windows and VC 7.1. It might also affect shared objects on Unix, but I'm not sure how the various Unix loaders handle multiple instances of the same template member function in multiple shared objects. In particular what happens is that objects that are serialized via a base class pointer are no longer deserialized correctly when deserialized in an application that uses the DLL (and not within the DLL itself). Instead they are deserialized as NULL pointers. The problem is that the virtual equal_to and not_equal_to member functions were removed from the extended_type_info base class. These functions were previously used by extended_type_info::operator == and extended_type_info::operator !=. Now operator == simply performs an equal check on the address of the extended_type_info object, whereas the previous version that used equal_to actually did a full compare of the stored type info keys. If DLLs are used and the DLLs themselves contain serialization code and BOOST_CLASS_EXPORT macros, this will fail because the extended_type_info objects are always static objects allocated on the stack of a member template function, e.g. in extended_type_info_typeid_1::get_instance. In a DLL situation this will cause multiple DLLs that include the header file with that template function to have multiple (i.e. separate) copies of that extended_type_info object. Thus, comparing them only via their addresses leads to disaster. The fix is easy. Simply put the old code for extended_type_info::operator == and extended_type_info::operator != back in. Note that I haven't looked any further if there were other changes made to the code that also rely on the addresses of equal extended_type_info objects to be the same. This will also break serialization code in DLLs. I can only say that after I put the old code back in, our system could deserialize its data properly again. Best Regards, Martin TAB Austria Haiderstraße 40 4052 Ansfelden Austria Phone: +43 7229 78040-218 Fax: +43 7229 78040-209 E-mail: martin.ecker(a)tab.at http://www.tab.at

6 23

[boost thread rework] New version uploaded to Boost Vault
by Ion Gaztañaga 05 Sep '05

05 Sep '05

Hi to all, I've just finished implementing the lockable objects of Kevlin's proposal based on Boost mutexes and conditions. Since boost mutex operations are private and only available with locks, I haven't found a way to implement Kevlin's interface over boost threads without using some very nasty tricks. If someone has a better idea, let me know. The implementation nearly fills all the proposal of the documentation, so I will wait for new elements so that I can continue with this project. This elements are present in the current version: -> threader and joiner classes -> lockable, try_lockable, condition_lockable -> locker, try_locker -> locking_ptr There are open issues in the paper like timeout handling and new possible lockers, (for example, for conditional_lockable objects). As soon as I get more information I will continue developing it. Regards, Ion

15 57

Repository access and cvs watch
by Thomas Witt 05 Sep '05

05 Sep '05

Hi, AFAICT there is currently no way to make cvs provide writable files when checking out/updating the boost repository. This causes me some grief and I might not be the only one out there. After reading the CVS manual (well the watch part) I have concluded that this is due to the fact that somebody issued a recursive 'cvs watch on' on the boost tree. AFAICS this has not been discussed on the mailing list. This forces a certain usage of cvs on everybody else. I.e. the users have to use 'cvs edit' (or fiddle with file permissions). For now I am strongly opposed to this way of using cvs. In my experience the use of 'cvs edit' does not provide significant benefit while it adds significant overhead to my work. Most users will change the permissions locally and not bother with cvs edit anyway. If there is anybody out there who has different experiences I would be very interested to hear about them. I therefore propose to turn cvs watch off thus giving the user a choice whether she wants read-only or read-write files. Please note that this does not disable the watching of files in general. Every user still can use cvs watch add to watch files and is still guaranteed to get notified about the really interesting events (i.e. those that alter a file in the repository). What did I miss? What do you think? Thomas

16 30

Boost.Python and slightly more tricky inheritance
by Vladimir Pozdyayev 05 Sep '05

05 Sep '05

Greetings. 1. First, about a bug (Boost 1.33.0, MSVC 7.1): After exporting void test1( const char * ) { } void test2( std::string ) { } we get an assertion failure _BLOCK_TYPE_IS_VALID( ... ) on std::strings longer than a dozen of characters: test1( 'hello' ) # OK test2( 'hello' ) # OK test1( 'how do you do, tell me please' ) # OK test2( 'how do you do, tell me please' ) # failure 2a. From `Exposing Classes' tutorial section: "If Base is polymorphic, Derived objects which have been passed to Python via a pointer or reference to Base can be passed where a pointer or reference to Derived is expected." Now, that's a great feature, but I couldn't help noticing that what Boost.Python actually does, is even more useful: not only such pointers can be passed instead of Derived ones, but their Python counterparts _are_ fully qualified Derived representations, with all the methods and everything. Probably worth mentioning in dox that way. 2b. Now, suppose we have one more derived class: class Base { ... }; class Derived: public Base { ... }; class HiddenImplementation: public Derived { ... }; with Derived being no more than an interface. Naturally, we don't want to export HiddenImplementation to Python, but still want to retain automatic conversions from Base* to Derived* whenever pointer to HiddenImplementation object is passed to Python. Any way to do this? Without hack-ins? I was able to trick the system by defining the fake empty implemetation class class HiddenImplementation: public Derived { }; right before the BOOST_PYTHON_MODULE and exporting it out there, but this kind of `solution' really annoys me. And I don't understand why it works, either :) . Oh, and it's only a partial solution, too: we do not have to access the real implementation class, but we still have to export something. Comments? -- TIA, Vladimir mailto:ardatur@mail.ru

3 6

[metamath] Plans for compile time double
by Chris Weed 05 Sep '05

05 Sep '05

Hi, I was wonder what the plans are for the compile time double library, metamath. Is there a plan to develop compile time versions of the functions in math.h, such as sin, cos, pow, abs, etc.? Thanks, Chris

3 7

[intel-9.0] --arg_dep_lookup, BOOST_FUNCTION_SCOPE_USING_DECLARATION_BREAKS_ADL and __EDG_VERSION__=304
by JOAQUIN LOPEZ MU?Z 04 Sep '05

04 Sep '05

A bit of context: * Intel 9.0 has __EDG_VERSION__==304 (under Win32/Linux), whereas prior versions of the compiler have lower values of this macro. * BOOST_FUNCTION_SCOPE_USING_DECLARATION_BREAKS_ADL is defined for __EDG_VERSION__<=303, that is, for all Intel compilers up to (and including) 8.1, under Win32/Linux. * Under Win32, all Intel toolset .jams define the compiler option --arg_dep_lookup, which explicitly enables ADL (disabled by default.) I don't know what the situation of ADL is for Intel under Linux, but in any case this switch is *not* used for that OS. Current RC tests for Intel 9.0 under Linux show the problem listed at http://tinyurl.com/8f5g6 One piece of code where the error pops up is like this #if defined(BOOST_FUNCTION_SCOPE_USING_DECLARATION_BREAKS_ADL) ::boost::multi_index::detail::swap(i1,get<1>(es2)); #else using std::swap; swap(i1,get<1>(es2)); #endif Given the __EDG_VERSION__ number of this compiler, it is the second preprocessor branch that is compiled, and it fails to use the user-supplied global swap() in favor of std::swap(), hence the error. However, this same tests succesfully passes for Intel 9.0 under Win32 (same __EDG_VERSION__ as the Linux case)!! My conclusions: * The fact that the test passes under Intel 9.0 for Win32, for which BOOST_FUNCTION_SCOPE_USING_DECLARATION_BREAKS_ADL is *not* defined, suggests that __EDG_VERSION__<=303 is the right check for setting this macro. * But the same test fails under Intel 9.0 for Linux, which hints at an ADL problem other than that controlled by BOOST_FUNCTION_SCOPE_USING_DECLARATION_BREAKS_ADL. Could it be that Intel compilers under Linux also necessitate the --arg_dep_lookup compiler switch (which is currently not set)? This looks like the only sensible conslusion from the facts described. Thanks and sorry for the long post, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

3 5

[1.33.1] Goals, tasks, schedule
by Doug Gregor 03 Sep '05

03 Sep '05

Certain issues that cropped up with the 1.33.0 release that necessitate a 1.33.1 release. 1.33.1 will be for safe bug fixes to 1.33.0 only, focusing on critical issues such as the already-addressed shared_ptr problem. There are two major issues we need to resolve before we can roll a release candidate of 1.33.1: - Include order dependencies in the Serialization library - GCC 4.0 type_info problems This is also a good opportunity to work in support for three compilers that are performing reasonably well now and should be supported by Boost: - Tru64 CXX - Apple GCC 4.0 on Tiger - Intel 9.0 on Linux We'll prepare the release candidate from the RC_1_33_0 branch, hopefully within a week or so, depending on the resolution of these issues. The release candidates will be available for much longer before the final release, up to a month or so, to root out any remaining issues. No new libraries or features may be added to the RC_1_33_0 branch; they should go onto the main branch, and we'll merge fixes from RC_1_33_0 back once we've released. Doug

14 21

[Thread] read_write_mutex bug?
by Matt Hurd 03 Sep '05

03 Sep '05

Hi, Testing my own wrapper on x86_64 bit linux exposed a seeming deadlock on constructing a read_write_lock with a *::write_locked initial state in the constructor... I've distilled it to the plain code below that exhibits the same failure. Using a read_lock state on the same works without deadlock (or safety is this case) as expected. Using a scoped_write_lock worked once but deadlocked mostly. A normal mutex and recursive mutex works as expected. I'm using 1.33. Is this a known bug or am I using the read_write stuff incorrectly? Regards, Matt. matthurd(a)acm.org ____________________________________ my test in question:... void synch_test_019() { static int global_count = 0; static boost::read_write_mutex doobie( boost::read_write_scheduling_policy::writer_priority ); long number_of_threads = 10; static long inner_loop = 1000; ZOMOJO_WORKER_THREAD_BEGIN( inner_loop ) { boost::read_write_mutex::scoped_read_write_lock lk(doobie, boost::read_write_lock_state::write_locked); global_count = global_count + 1; } ZOMOJO_WORKER_THREAD_END( number_of_threads ) BOOST_MESSAGE( "orderly progression = " << inner_loop * number_of_threads ); BOOST_MESSAGE( "concurrent progression from this run = " << global_count ); BOOST_CHECK_PREDICATE(std::equal_to<int>(), (global_count)( inner_loop * number_of_threads) ); } _________________________________________________ The helper macros _________________________________________________ #ifndef ZOMOJO_THREAD_TEST_HELPER_HPP_20050816 #define ZOMOJO_THREAD_TEST_HELPER_HPP_20050816 // A poor man's barrier helper to assist in unit test cases for parallel execution #define ZOMOJO_WORKER_THREAD_BEGIN( LoopIterations ) \ static boost::read_write_mutex m_arbitrary_( boost::read_write_scheduling_policy::writer_priority ); \ struct simple_function_arbitrary_ \ { \ static void do_work_arbitrary_() \ { \ boost::read_write_mutex::scoped_read_lock lk_arbitrary_(m_arbitrary_); \ for (int j_arbitrary_ = 0; j_arbitrary_ < (LoopIterations); j_arbitrary_++) \ { #define ZOMOJO_WORKER_THREAD_END( NumberOfThreads ) \ } \ } \ }; \ \ boost::thread_group pool_arbitrary_; \ \ { \ boost::read_write_mutex::scoped_write_lock lk(m_arbitrary_); \ for (int i_arbitrary_=0; i_arbitrary_ < NumberOfThreads; ++i_arbitrary_) \ { \ pool_arbitrary_.create_thread( simple_function_arbitrary_::do_work_arbitrary_ ); \ } \ } \ \ pool_arbitrary_.join_all(); #endif // ZOMOJO_THREAD_TEST_HELPER_HPP_20050816

4 10

asio networking proposal
by Christopher Kohlhoff 02 Sep '05

02 Sep '05

As discussed in the "surveying async network io libraries" thread, I'd like to turn asio (asio.sourceforge.net) into a proposal for a boost networking library. As promised, here is a list of areas where asio could use some refinement. I'd appreciate input on: - What people think of the relative importance of the items. For example, what would be required for an initial implementation vs what could or should be left until a later revision. - Whether the proposed changes are of any value. - Any other things that should be on the list. What's Missing ============== * Asynchronous DNS operations. I think it would be reasonable to say that any operation that can block should have an asynchronous equivalent. Should these operations be cancellable (not necessarily portably implementable anyway)? * IPv6 support. I have no experience with IPv6, so it would be great if someone with experience could help out with the design here. * Asynchronous socket close. In certain circumstances closing a socket can block, so it would be reasonable to expect an asynchronous close operation. * Scatter-gather operations (sendv and recvv). * The BSD socket functions sendmsg/recvmsg (which I believe are necessary to support protocols such as SCTP). * SSL/TLS and DTLS support. This would require an external library, and how does that fit in with boost? * Other protocols (PF_UNIX, ...)? * Some type of integration (or support for) a higher-level iostreams-based socket library. * More examples. * Documentation on design and rationale. What Should Be Included and What Shouldn't ========================================== * Obviously asio::thread should not be part of a boost proposal, since that functionality is already covered by Boost.Thread. * The asio::time class should probably not be included, and wherever it's used replaced by Boost.Date-Time. Naming and Structure ==================== * The use of the word "Stream" can be confusing because its existing association in C++ with iostreams. Can anyone suggest an alternative? * Should stream_socket and dgram_socket be merged into a single socket class? There other types of sockets (e.g. sequenced packet) that would require additional classes if the current approach is retained. This would not be required if the BSD socket APIs were covered by a single class. Alternatively, should additional classes be added for the other socket types? * The current separate socket_connector implementation does not correspond to an OS resource, unlike socket_acceptor. This can be problematic, e.g. it prevents a Windows implementation using ConnectEx, and doesn't allow you to set socket options before the connection is established. Therefore I propose adding connect and async_connect operations to socket classes. Should the separate socket_connector be retained? * In designing asio I considered that people may want to customise the demultiplexing strategy associated with each resource. For example the basic_stream_socket template looks like: template <typename Service> class basic_stream_socket; where Service is a "facet" of the demuxer that provides demultiplexing facilities for the socket. The typedef for stream_socket specifies the Service type based on the target platform. However in practice I don't believe this level of customisation is required (to the best of my knowledge no existing asio user customises it), particularly if asio uses the "best" demultiplexing mechanism for each platform. Or another way of looking at it: developers who need this level of control might not use a general purpose networking library anyway. An alternative approach would to have the only template parameter be an allocator (since there is often memory allocation associated with asynchronous operations). For example: template <typename Allocator> class basic_demuxer; template <typename Allocator> class basic_stream_socket; where a stream_socket can only be used with a demuxer that has the same allocator type. The typedefs for demuxer and stream_socket would just use the default allocator. Cheers, Chris

20 65

bizarre test results: foreach, gcc-4_0-darwin
by Eric Niebler 01 Sep '05

01 Sep '05

I need help understanding some of the recent regression results. At http://tinyurl.com/72q3k you can see the most recent Foreach test results. The first and the third columns both purport to be gcc-4_0-darwin, but the results are different! How can that be? Both tests were run today, and I haven't touched the code since yesterday. -- Eric Niebler Boost Consulting www.boost-consulting.com

3 4