- Boost - lists.preview.boost.org

[iterator] issues with Boost.Iterator and Boost.MultiArray
by Thomas Klimpel 28 May '10

28 May '10

Hi, The issues reporteted in <http://lists.boost.org/Archives/boost/2010/05/165798.php> are still open. Even so I wrote: > But from my point of view, the only responsibility I may > have with respect to these issues is to notify the authors > of the affected libraries, which I have done now. it seems that I wasn't yet successful in my attemps to notify the authors. The only one that has answered so far was Thomas Witt <http://lists.boost.org/Archives/boost/2010/05/165837.php>, claiming that the bug is in Boost.MultiArray. However, my personal belief is that the bug is in <http://svn.boost.org/svn/boost/trunk/boost/iterator/detail/facade_iterator_…>. But there is definitively a "quasi unrelated" bug in Boost.MultiArray on trunk (and Thomas Witt might refer to this bug), as the "resize" regression test fails on nearly all compilers on trunk but passes on release <http://lists.boost.org/Archives/boost/2010/05/165810.php> (the link contains a patch that fixes the failures). I would be most happy, if 1) Ron (or somebody else that is allowed to apply patches to Boost.MultiArray) would simply fix the failure of the "resize" regression test on trunk (either by applying the provided patch or by fixing it in some other way). 2) Dave (or somebody else that has deep knowledge about Boost.Iterator) would confirm that the failures of Boost.MultiArray on MSVC-10 are caused by an issue in Boost.Iterator (and are probably related to Jeremy Siek's patch <https://svn.boost.org/trac/boost/changeset/21683>). I guess the result if somebody will answer at all is that I will be asked to enter a track ticket for Boost.Iterator. So if this mail should stay without useful feedback, I will enter two track tickets for Boost.MultiArray and one track ticket for Boost.Iterator, in anticipation that the feedback would probably have suggested that I should do that. Regards, Thomas

3 2

Review Wizard Report for May 2010
by Ronald Garcia 28 May '10

28 May '10

============================================== Review Wizard Status Report for May 2010 ============================================== News ==== Boost 1.42 Released New Libraries: UUID Revised Libraries: Asio, Circular Buffer, Fusion, Graph, Integer, Iostreams, Program.Options, Property Map, Proto, Regex, Spirit, Unordered, Xpressive Meta State Machine (MSM) Library Accepted Boost 1.43 Released New Libraries: Functional/Factory, Functional/Forward Revised Libraries: Range, Accumulators, Array, Asio, Fusion, Iostreams, Multi-index Containers, Proto, Random, Spirit, Thread, Unordered, Uuid, Wave, Xpressive Open Issues =========== The Constrained Value Library was reviewed in December 2008 but no review result has been reported. We would appreciate it if someone who knows the review manager, Jeff Garland, could contact him. The following libraries have been accepted to Boost, but have not yet been submitted to SVN: * Time Series (accepted August 2007). * Floating Point Utilities (accepted March 2008). * Futures (accepted April 2009). * Polygon Library (accepted November 2009). * Geometry Library (accepted November 2009). * Meta State Machine (accepted January 2010). The following libraries have been accepted provisionally to Boost, but have not been submitted for mini-review and full acceptance: * Switch (accepted provisionally January 2008) * Phoenix (accepted provisionally September 2008) General Announcements ===================== As always, we need experienced review managers. The review queue has grown substantially but we have few volunteers, so manage reviews if possible and if not please make sure to watch the review schedule and participate. Please take a look at the list of libraries in need of managers and check out their descriptions. In general review managers are active boost participants or library contributors. If you can serve as review manager for any of them, email Ron Garcia or John Phillips, "garcia at osl dot iu dot edu" and "phillips at mps dot ohio-state dot edu" respectively. We are also suffering from a lack of reviewers. While we all understand time pressures and the need to complete paying work, the strength of Boost is based on the detailed and informed reviews submitted by you. A recent effort is trying to secure at least five people who promise to submit reviews as a precondition to starting the review period. Consider volunteering for this and even taking the time to create the review as early as possible. No rule says you can only work on a review during the review period. A link to this report will be posted to www.boost.org. If you would like us to make any modifications or additions to this report before we do that, please email Ron or John. If you're a library author and plan on submitting a library for review in the next 3-6 months, send Ron or John a short description of your library and we'll add it to the Libraries Under Construction below. We know that there are many libraries that are near completion, but we have hard time keeping track all of them. Please keep us informed about your progress. The included review queue isn't a classic queue. It is more an unordered list of the libraries awaiting review. As such, any library in the queue can be reviewed once the developer is ready and a review manager works with the wizards and the developer to schedule a review. It is not FIFO. Review Queue ============ * Lexer * Shifted Pointer * Logging * Join * Pimpl * Task * Endian * Conversion * Sorting * GIL.IO * AutoBuffer * String Convert * Containers * Type Traits Extensions * Interthreads * Bitfield * Lockfree * Fiber * Chrono * Sequence Properties * Static Size Linear Algebra * Locale -------------------- Lexer ----- :Author: Ben Hanson :Review Manager: Eric Neibler :Download: `Boost Vault <http://boost-consulting.com/vault/index.php?action=downloadfile&filename=bo… >`__ :Description: A programmable lexical analyser generator inspired by 'flex'. Like flex, it is programmed by the use of regular expressions and outputs a state machine as a number of DFAs utilising equivalence classes for compression. Shifted Pointer --------------- :Author: Phil Bouchard :Review Manager: Needed :Download: `Boost Vault <http://www.boost-consulting.com/vault/index.php?&direction=0&order=&directo… >`__ :Description: Smart pointers are in general optimized for a specific resource (memory usage, CPU cycles, user friendliness, ...) depending on what the user need to make the most of. The purpose of this smart pointer is mainly to allocate the reference counter (or owner) and the object itself at the same time so that dynamic memory management is simplified thus accelerated and cheaper on the memory map. Logging ------- :Author: John Torjo :Review Manager: Gennadiy Rozental :Download: http://torjo.com/log2/ :Description: Used properly, logging is a very powerful tool. Besides aiding debugging/testing, it can also show you how your application is used. The Boost Logging Library allows just for that, supporting a lot of scenarios, ranging from very simple (dumping all to one destination), to very complex (multiple logs, some enabled/some not, levels, etc). It features a very simple and flexible interface, efficient filtering of messages, thread-safety, formatters and destinations, easy manipulation of logs, finding the best logger/filter classes based on your application's needs, you can define your own macros and much more! Join ---- :Author: Yigong Liu :Review Manager: Needed :Download: http://channel.sourceforge.net/ :Description: Join is an asynchronous, message based C++ concurrency library based on join calculus. It is applicable both to multi-threaded applications and to the orchestration of asynchronous, event-based applications. It follows Comega's design and implementation and builds with Boost facilities. It provides a high level concurrency API with asynchronous methods, synchronous methods, and chords which are "join-patterns" defining the synchronization, asynchrony, and concurrency. Pimpl ----- :Author: Vladimir Batov :Review Manager: Needed :Download: | `Boost Vault <http://www.boost-consulting.com/vault/index.php?action=downloadfile&filenam… >`__ | http://www.ddj.com/cpp/205918714 (documentation) :Description: The Pimpl idiom is a simple yet robust technique to minimize coupling via the separation of interface and implementation and then implementation hiding. This library provides a convenient yet flexible and generic deployment technique for the Pimpl idiom. It's seemingly complete and broadly applicable, yet minimal, simple and pleasant to use. Task ---- :Author: Oliver Kowalke :Review Manager: Needed :Download: `Boost Vault <http://www.boostpro.com/vault/index.php?action=downloadfile&filename=bo… >`__ :Description: Formerly called Thread Pool The library provides: * thread creation policies: * determines the management of worker threads: * fixed set of threads in pool * create workerthreads on demand (depending on context) * let worker threads ime out after certain idle time * channel policies: manages access to queued tasks: * bounded channel with high and low watermark for queuing tasks * unbounded channel with unlimited number of queued tasks * rendezvous syncron hand-over between producer and consumer threads * queueing policy: determines how tasks will be removed from channel: * FIFO * LIFO * priority queue (attribute assigned to task) * smart insertions and extractions (for instance remove oldest task with certain attribute by newest one) * tasks can be chained and lazy submit of taks is also supported (thanks to Braddocks future library). * returns a task object from the submit function. The task it self can be interrupted if its is cooperative (means it has some interruption points in its code -> ``this_thread::interruption_point()`` ). Endian ------ :Author: Beman Dawes :Review Manager: Needed :Download: http://mysite.verizon.net/beman/endian-0.10.zip :Description: Conversion ---------- :Author: Vicente Botet :Review Manager: Needed :Download: `Boost Vault <http://www.boostpro.com/vault/index.php?action=downloadfile&filename=co… >`__ :Description: Generic explicit conversion between unrelated types. Boost.Conversion provides: * a generic ``convert_to`` function which can be specialized by the user to make explicit conversion between unrelated types. * a generic ``assign_to`` function which can be specialized by the user to make explicit assignation between unrelated types. * conversion between ``std::complex`` of explicitly convertible types. * conversion between ``std::pair`` of explicitly convertible types. * conversion between ``boost::optional`` of explicitly convertible types. * conversion between ``boost::rational`` of explicitly convertible types. * conversion between ``boost::interval`` of explicitly convertible types. * conversion between ``boost::chrono::time_point`` and ``boost::ptime``. * conversion between ``boost::chrono::duration`` and ``boost::time_duration``. Sorting ------- :Author: Steven Ross :Review Manager: Needed :Download: `Boost Vault <http://www.boostpro.com/vault/index.php?action=downloadfile&filename=al… >`__ :Description: A grouping of 3 templated hybrid radix/comparison-based sorting algorithms that provide superior worst-case and average-case performance to std::sort: integer_sort, which sorts fixed-size data types that support a rightshift (default of >>) and a comparison (default of <) operator. float_sort, which sorts standard floating-point numbers by safely casting them to integers. string_sort, which sorts variable-length data types, and is optimized for 8-bit character strings. All 3 algorithms have O(n(k/s + s)) runtime where k is the number of bits in the data type and s is a constant, and limited memory overhead (in the kB for realistic inputs). In testing, integer_sort varies from 35% faster to 8X as fast as std::sort, depending on processor, compiler optimizations, and data distribution. float_sort is roughly 7X as fast as std::sort on x86 processors. string_sort is roughly 2X as fast as std::sort. GIL.IO ------ :Author: Christian Henning :Review Manager: Needed :Download: `GIL Google Code Vault <http://gil-contributions.googlecode.com/files/rc2.zip >`__ :Description: I/O extension for boost::gil which allows reading and writing of/in various image formats ( tiff, jpeg, png, etc ). This review will also include the Toolbox extension which adds some common functionality to gil, such as new color spaces, algorithms, etc. AutoBuffer ---------- :Author: Thorsten Ottosen :Review Manager: Needed :Download: `Here <http://www.cs.aau.dk/~nesotto/boost/ auto_buffer.zip>`__ :Description: Boost.AutoBuffer provides a container for efficient dynamic, local buffers. Furthermore, the container may be used as an alternative to std::vector, offering greater flexibility and sometimes better performance. String Convert -------------- :Author: Vladimir Batov :Review Manager: Needed :Download: `Boost Vault <http://www.boostpro.com/vault/index.php?action=downloadfile&filename=bo… >`__ :Description: The library takes the approach of boost::lexical_cast in the area of string-to-type and type-to-string conversions, builds on the past boost::lexical_cast experience and advances that conversion functionality further to additionally provide: * throwing and non-throwing conversion-failure behavior; * support for the default value to be returned when conversion fails; * two types of the conversion-failure check -- basic and better/safe; * formatting support based on the standard I/O Streams and the standard (or user-defined) I/O Stream-based manipulators (like std::hex, std::scientific, etc.); * locale support; * support for boost::range-compliant char and wchar_t-based string containers; * no DefaultConstructibility requirement for the Target type; * consistent framework to uniformly incorporate any type-to-type conversions. It is an essential tool with applications making extensive use of configuration files or having to process/prepare considerable amounts of data in, say, XML, etc. Containers ---------- :Author: Ion Gaztanaga :Review Manager: Needed :Download: http://www.boostpro.com/vault/index.php?action=downloadfile&filename=boost.… :Documentation: http://svn.boost.org/svn/boost/sandbox/move/libs/container/doc/html/index.h… :Description: Boost.Container library implements several well-known containers, including STL containers. The aim of the library is to offers advanced features not present in standard containers or to offer the latest standard draft features for compilers that comply with C++03. Type Traits Extensions -------------------------- :Author: Frederic Bron :Review Manager: Needed :Download: http://svn.boost.org/trac/boost/browser/sandbox/type_traits :Description: The purpose of the addition is to add type traits to detect if types T and U are comparable in the sense of <, <=, >, >=, == or != operators, i.e. if t<u has a sens when t is of type T and u of type U (same for <=, >, >=, ==, !=). The following traits are added: is_equal_to_comparable<T,U> is_greater_comparable<T,U> is_greater_equal_comparable<T,U> is_less_comparable<T,U> is_less_equal_comparable<T,U> is_not_equal_to_comparable<T,U> The names are based on the corresponding names of the standard template library (<functional> header, section 20.3.3 of the standard). The code has the following properties: * returns true if t<u is meaningful and returns a value convertible to bool * returns false if t<u is meaningless. * fails with compile time error if t<u is meaningful and returns void (a possibility to avoid compile time error would be to return true with an operator, trick but this has little sens as returning false would be better) InterThreads ------------------- :Author: Vicente J. Botet Escriba :Review Manager: Needed :Download: `Boost Vault <http://www.boostpro.com/vault/index.php?action=downloadfile&filename=in… >`__ :Description: Boost.InterThreads extends Boost.Threads adding some features: * thread decorator: thread_decorator allows to define setup/cleanup functions which will be called only once by thread: setup before the thread function and cleanup at thread exit. * thread specific shared pointer: this is an extension of the thread_specific_ptr providing access to this thread specific context from other threads. As it is shared the stored pointer is a shared_ptr instead of a raw one. * thread keep alive mechanism: this mechanism allows to detect threads that do not prove that they are alive by calling to the keep_alive_point regularly. When a thread is declared dead a user provided function is called, which by default will abort the program. * thread tuple: defines a thread groupe where the number of threads is know statically and the threads are created at construction time. * set_once: a synchonizer that allows to set a variable only once, notifying to the variable value to whatever is waiting for that. * thread_tuple_once: an extension of the boost::thread_tuple which allows to join the thread finishing the first, using for that the set_once synchronizer. * thread_group_once: an extension of the boost::thread_group which allows to join the thread finishing the first, using for that the set_once synchronizer. (thread_decorator and thread_specific_shared_ptr) are based on the original implementation of threadalert written by Roland Schwarz. Boost.InterThreads extends Boost.Threads adding thread setup/cleanup decorator, thread specific shared pointer, thread keep alive mechanism and thread tuples. Bitfield --------------- :Author: Vicente J. Botet Escriba :Review Manager: Needed :Download: http://svn.boost.org/svn/boost/sandbox/bitfield with documentation available at http://svn.boost.org/svn/boost/sandbox/bitfield/libs/bitfield/doc/index.html :Description: Portable bitfields traits. Boost.Bitfield consists of: * a generic bitfield traits class providing generic getter and setter methods. * a BOOST_BITFIELD_DCL macro making easier the definition of the bitfield traits and the bitfield getter and setter functions. Lockfree ------------------ :Author: Tim Blechmann :Review Manager: Needed :Download: http://www.boostpro.com/vault/index.php?action=downloadfile&filename=bo… ; :Documentation: http://tim.klingt.org/boost_lockfree/ :Description: boost.lockfree provides implementations of lock-free data structures. lock-free data structures can be accessed by multiple threads without the necessity of blocking synchronization primitives such as guards. lock-free data structures can be used in real-time systems, where blocking algorithms may lead to high worst-case execution times, to avoid priority inversion, or to increase the scalability for multi-processor machines. boost.lockfree provides: * boost::lockfree::fifo, a lock-free fifo queue * boost::lockfree::stack, a lock-free stack the code is available from from my personal git repository: * git://tim.klingt.org/boost_lockfree.git * http://tim.klingt.org/git?p=boost_lockfree.git Fiber ----- :Author: Oliver Kowalke :Review Manager: Needed Download: http://www.boostpro.com/vault/index.php?action=downloadfile&filename=bo… ; :Description: C++ Library for launching fibers (micro-threads) and synchronizing data between the fibers. Chrono ------ :Author: Vicente Botet :Review Manager: Needed :Download: http://www.boostpro.com/vault/index.php?action=downloadfile&filename=ch… ; :Documentation: http://svn.boost.org/svn/boost/sandbox/chrono/libs/chrono/doc/html/index.ht… . :Description: The Boost Chrono library provides: The C++0x Standard Library's common_type. The C++0x Standard Library's compile-time rational arithmetic. The C++0x Standard Library's time utilities, including: Class template duration Class template time_point Clocks: system_clock monotonic_clock high_resolution_clock typeof registration for classes duration and time_point Process clocks: process_real_CPU_clocks, capturing real-CPU times. process_user_CPU_clocks, capturing user-CPU times. process_system_CPU_clocks, capturing system-CPU times. process_cpu_clock, tuple-like class capturing at once real, user- CPU, and system-CPU times. Stopwatches: stopwatch, capturing elapsed Clock times. stopwatch_accumulator, capturing cummulated elapsed Clock times. scoped helper classes allowing to pairwise start/stop operations, suspend/resume and resume/suspend a Stopwatch. Stopclocks or Stopwatch reporters: stopwatch_reporter, convenient reporting of models of Stopwatch results. stopclock<Clock> shortcut of stopwatch_reporter<stopwatch<Clock>> Support wide characters for stopwatch formatters Sequence Properties ------------------- :Author: Grant Erickson :Review Manager: Needed :Download: http://www.boostpro.com/vault/index.php?action=downloadfile&filename=cr… :Description: The creasing algorithm templates define four template functions for determining the order properties of sequences, specifically: * Increasing * Decreasing * Strictly Increasing * Strictly Decreasing The implementation is a fairly trivial composition of the STL adjacent_find, not2 and {greater,less,greater_equal,less_equal}. For the purposes of sequence ordering validation, using these templates is more efficient and straightforward than creating a temporary, sorted version of some sequence and comparing it against the original sequence. Example: :: bool CheckPoints(const Points & inPoints) { const bool strictlyIncreasing = is_strictly_increasing(inPoints.begin(), inPoints.end()); if (!strictlyIncreasing) { cerr << "Points must be in increasing order with " "no duplicate values." << endl; } return strictlyIncreasing; } Static Size Linear Algebra -------------------------- :Author: Emil Dotchevski :Review Manager: Needed :Download: :Description: Locale ------ :Author: Artyom Beilis :Review Manager: Needed :Download: https://sourceforge.net/projects/cppcms/files/boost_locale/boost_locale_for… :Description: Boost.Locale is powerful localization library that provides powerful localization tool extending existing built-in C++ localization facilities in Unicode aware way. Libraries under development =========================== Persistent ---------- :Author: Tim Blechmann :Description: A library, based on Boost.Serialization, that provides access to persistent objects with an interface as close as possible to accessing regular objects in memory. * object ownership concepts equivalent to the ones used by Boost.SmartPtr: shared, weak, scoped (and raw) * ACID transactions, including recovery after a crash and "Serializable" isolation level * concurrent transactions, nested transactions, distributed transactions * concurrent access containers: STL containers whose nodes are implemented as persistent objects and can be accessed without moving the container to memory. Concurrent transactions modifying the container are only repeated in the rare cases the same container node is changed simultanisouly by 2 threads. * extensible by other transactional resources, e.g. an object relational mapper based on the upcoming Boost.Rdb library. Multiple resources can be combined to one database, with distributed transactions among them. Please let us know of any libraries you are currently developing that you intend to submit for review. See http://svn.boost.org/trac/boost/wiki/LibrariesUnderConstruction for a current listing of libraries under development.

9 13

[GIL] 2D kernel convolution
by fabien.castan＠free.fr 27 May '10

27 May '10

I looked at the documentation and examples of GIL, but if I have well understood, the extension "numeric convolve" does not allow to do a convolution with a 2D kernel ? Is there another extension ? Or has someone a good code sample (with convolve_boundary_option, etc.) ? Best regards, Fabien

3 2

[concept] why is `requires` plural?
by Lorenzo Caminiti 27 May '10

27 May '10

Hello all, This might be a very silly curiosity: Does anyone know why `requires` (plural) is used to specify concept requirements? Most keywords (all?) are not plural so I would have expexted `require` to be used instead of `requires`. Howerver, the C++0x proposals and ConceptC++ use `requires`. Consequently, Boost.ConceptCheck uses BOOST_CONCEPT_REQUIRES(). Do you know why the plural form was selected? Thank you. -- Sent from my mobile device Lorenzo

4 7

Re: [boost] [MSM] compiling MSM with GCC 4.4.1 and -fno-exception
by Christophe Henry 27 May '10

27 May '10

Hi Richard, >Hi Christophe > >Yes it works with typedef int no_exception_thrown; >I was using typedef int no_exception; which is used in euml examples >than I have look at the code and I figured out that it is actually >no_exception_thrown instead of no_exception. Yes, euml uses another name (which is an instance of an internal type, and not a type definition like no_exception_thrown but I disgress). >So now I can compile with -fno-rtti and -fno-exception thank you very >much for the support !!!!!. Great! >I have a question related to the fix for no-rtti the define >BOOST_NO_RTTI removes function definition : HandledEnum >process_any_event( ::boost::any const& evt); >which is called in flavor_compile_time in case of composite state. > >In case if I'm using favor_runtime_speed which is the default I >believe than I can still use composite states with no-rtti ?. > >Br. >Richie Yes of course. The method process_any_event is simply there for the favor_compile_time policy (to allow compiling submachines on different cores). So without rtti, all you lose is the possibility to trade runtime speed in exchange for a better compile time, which is in your case probably unimportant as you seem to be more interested in performance. Regards, Christophe

1 0

Re: [boost] [MSM] compiling MSM with GCC 4.4.1 and -fno-exception
by Richard Szabo 27 May '10

27 May '10

>> Hi Christophe >> >> Thanks for the fix of no-rtti I will try out shortly. >> >> I have discovered a similar issue with exceptions. >> GCC 4.4.1 reports errors when it parses MSM that exceptions are >> disabled but there is code using that. >> >> Thanks >> Richie > >Hi Richard, > >I tried it out and it works. The default event dispatching occurs >inside a try/catch but you can deactivate it by adding a typedef to >the fsm declaration: >typedef int no_exception_thrown; >(see in MsmSimple.cpp) >Now it should compile properly with -fno-exceptions (and dispatch >events slightly faster). >HTH, >Christophe Hi Christophe Yes it works with typedef int no_exception_thrown; I was using typedef int no_exception; which is used in euml examples than I have look at the code and I figured out that it is actually no_exception_thrown instead of no_exception. So now I can compile with -fno-rtti and -fno-exception thank you very much for the support !!!!!. I have a question related to the fix for no-rtti the define BOOST_NO_RTTI removes function definition : HandledEnum process_any_event( ::boost::any const& evt); which is called in flavor_compile_time in case of composite state. In case if I'm using favor_runtime_speed which is the default I believe than I can still use composite states with no-rtti ?. Br. Richie

1 0

BOOST_NO_EXTERN_TEMPLATE
by Stefan Strasser 27 May '10

27 May '10

Hi, Boost.Config defines the macro BOOST_NO_EXTERN_TEMPLATE, which probably [1] refers to suppressing the instantiation of a template using the "extern" keyword. This is part of the C++0x draft but has long been implemented by several compilers, including MSVC[2] and GCC[3]. BOOST_NO_EXTERN_TEMPLATE is still defined for both compilers, why is that? do those implementations differ from the proposed C++0x behaviour[4], so the macro is defined because it refers to a C++0x feature? Or is this a bug? Is using "extern template" recommended for boost libraries (under construction)? specifically, the library lends itself to seperate precompiled source and started out as such, but making it more configurable turned seperate source code into templates and increased compile time. the default use case (which was the only use case before) could still be compiled seperately if "extern template" is available. [1] the documentation says the macro indicates no support for explicit instantiation. I assume this is a documentation bug, because of its name and it's listed as a C++0x feature: http://www.boost.org/doc/libs/1_43_0/libs/config/doc/html/boost_config/boos… [2] http://msdn.microsoft.com/en-us/library/by56e477.aspx [3] http://gcc.gnu.org/onlinedocs/gcc/Template-Instantiation.html [4] http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n1987.htm

2 2

[boost-build] restrict target directory to dependent features (repost)
by Sandeep Gupta 26 May '10

26 May '10

Hi, This is a repost from boost-build mailing list. It failed to catch an attention. Would appreciate any help any this problem. Essentially my question is that can I specify a symmetric feature to be non-propagated. To elaborate: Is it possible in bjam to restrict target directory to generators features? I can better state the problem with an example. Lets say I have two generators G1 (maps .foo to .g1), G2 (maps .g1 to .g2), with corresponding feature F1, F2. If I import both generators than then the target directory is bin/debug/F1-f1/F2-f2 even if I am activating G1 generator. Ideally what I would like is the output be restricted by the generators features i.e let say I have g1 xx.g1 : xx.foo : <F1> f1 ; g2 xx.g2 : xx.g1 : <F2>f2 <F1>f1 ; then the target for g1 should be /bin/debug/F1-f1/, and target for g2 should be bin/debug/F1-fi/F2-f2 and it should look for g1 in directory bin/debug/F1-fi/F2-f2. Is there a way to configure bjam to adopt the later policy?. Thanks. Sandeep

1 0

[c++-sig]Python binding for templated constructor
by Sandeep Gupta 26 May '10

26 May '10

Hi, I have a class with a generic constructor as follows : class X { indexes m_idx; template<class strategy> X(){ build_indexes<strategy>() }; My problem is that I am not able to figure out the syntax to export this constructor. Is the above class not well defined ?. Thanks. Sandeep

2 2

Re: [boost] [MSM] compiling MSM with GCC 4.4.1 and -fno-exception
by Christophe Henry 26 May '10

26 May '10

> Hi Christophe > > Thanks for the fix of no-rtti I will try out shortly. > > I have discovered a similar issue with exceptions. > GCC 4.4.1 reports errors when it parses MSM that exceptions are > disabled but there is code using that. > > Thanks > Richie Hi Richard, I tried it out and it works. The default event dispatching occurs inside a try/catch but you can deactivate it by adding a typedef to the fsm declaration: typedef int no_exception_thrown; (see in MsmSimple.cpp) Now it should compile properly with -fno-exceptions (and dispatch events slightly faster). HTH, Christophe

1 0

Review Request: Boost.Locale
by Artyom 26 May '10

26 May '10

Hello, I want to request a formal review for Boost.Locale library. Short Description: ------------------ Boost.Locale is powerful localization library that provides powerful localization tool extending existing built-in C++ localization facilities in Unicode aware way. Documentation: -------------- - Reference: http://cppcms.sourceforge.net/boost_locale/html/index.html - Tutorial: http://cppcms.sourceforge.net/boost_locale/html/tutorial.html Sources: -------- - https://sourceforge.net/projects/cppcms/files/boost_locale/boost_locale_for… Tested Compilers: ----------------- - GCC 3.4, 4.1, 4.2, 4.3, 4.4 (including C++0x support of new Unicode characters) - MSVC 2008 - Intel 11.0 - Sun Studio 12 with STLPort Tested Platforms: ----------------- - Linux 2.6 - FreeBSD 8.0 - OpenSolaris - Windows XP/SP2: incuding MSVC, MinGW and Cygwin Updates from previous versions: ------------------------------- - Redesigned Context information support in message catalogs: switched to native gettext msgctxt support. - Cleanup of MSVC warnings. - MSVC8 fixes. - Build Cleanup. Thank You, Artyom Beilis

7 23

missing checks of compilation flags in boost/detail/container_fwd.hpp
by F.S. 26 May '10

26 May '10

Hello everybody, I don't how to send patches to you. This is a very small one, which allows to compile boost libraries with gnu c++ library using the Profile or Parallel mode. Maybe it's useful for you: *************** *** 13,19 **** #include <boost/config.hpp> #include <boost/detail/workaround.hpp> ! #if ((defined(__GLIBCPP__) || defined(__GLIBCXX__)) && ( defined(_GLIBCXX_DEBUG) || defined(_GLIBCXX_PROFILE) || defined(_GLIBCXX_PARALLEL))) \ || BOOST_WORKAROUND(__BORLANDC__, > 0x551) \ || BOOST_WORKAROUND(__DMC__, BOOST_TESTED_AT(0x842)) \ || (defined(__SGI_STL_PORT) || defined(_STLPORT_VERSION)) --- 13,19 ---- #include <boost/config.hpp> #include <boost/detail/workaround.hpp> ! #if ((defined(__GLIBCPP__) || defined(__GLIBCXX__)) && defined(_GLIBCXX_DEBUG)) \ || BOOST_WORKAROUND(__BORLANDC__, > 0x551) \ || BOOST_WORKAROUND(__DMC__, BOOST_TESTED_AT(0x842)) \ || (defined(__SGI_STL_PORT) || defined(_STLPORT_VERSION)) Regards Florian

2 1

[serialization] Warnings from spirit header in XML archive headers (non_terminal/rule.hpp)
by Number Cruncher 26 May '10

26 May '10

I'm encountering many warning about a deprecated header when writing my own XML input archive class: In file included from /opt/cfs/include/boost/archive/impl/basic_xml_grammar.hpp:59, from /opt/cfs/include/boost/archive/impl/xml_iarchive_impl.ipp:41, /opt/cfs/include/boost/spirit/core/non_terminal/rule.hpp:18:4: warning: #warning is a GCC extension /opt/cfs/include/boost/spirit/core/non_terminal/rule.hpp:18:4: warning: #warning "This header is deprecated. Please use: boost/spirit/include/classic_rule.hpp" This is because the serialization library is using "Spirit.Classic" and should be including different headers: http://www.boost.org/doc/libs/1_43_0/libs/spirit/doc/html/spirit/what_s_new… I've noticed patches related to this on the web, e.g. http://gitorious.org/ryppl/doc/commit/2711cc4a1e8751455f9188ffefa9b34de1379… ... and have repackaged a patch against the current 1.43.0 which fixes these warnings? Please could this be committed for the next release? Regards, Simon

2 2

[MSM] compiling MSM with GCC 4.4.1 and -fno-exception
by Richard Szabo 26 May '10

26 May '10

Hi Christophe Thanks for the fix of no-rtti I will try out shortly. I have discovered a similar issue with exceptions. GCC 4.4.1 reports errors when it parses MSM that exceptions are disabled but there is code using that. Thanks Richie

1 0

[thread] r62122 fix for #3178 introduces duplicate symbol
by Lars Viklund 26 May '10

26 May '10

Hi list. In trunk, revision 62122 (which fixes a negative sleeping time bug #3178) added a detail helper function pin_to_zero at boost/thread/win32/thread_data.hpp:148, which isn't marked inline. This leads to multiple symbol definitions for anything that tries to link to Boost.Thread. The fix is trivial, just add an inline. -- Lars Viklund | zao(a)acc.umu.se

2 1

CGI / FastCGI library update
by Darren Garvey 26 May '10

26 May '10

Hi, I have packaged a version of a CGI / FastCGI library* up to sourceforge and would very much appreciate feedback and critique from interested parties. Feedback from this list has been invaluable in the past. You can download the library from: http://sf.net/projects/cgi/files The documentation still needs work, which I am doing as I can find the time. It can be found online at: http://cgi.sf.net/docs and a brief feature list can be found from: http://cgi.sf.net The library interface has reached a relatively stable point after a savage bunch of changes recently and I'm quite pleased with how it is shaping up. A brief list of features of the library are: * Out of the box support for FastCGI and CGI, tested with Apache 2.2 and mod_fcgid on Windows XP, 7 and linux. * Type-safe access to different request data (eg. get / post / environment / cookies) * Access to request data in STL-like constructs, with some CGI-specific helper functions. * Optional support for user-defined, strongly-typed sessions. * A lightweight utility wrapper for using HTML / XML / etc. templates - dubbed "stencils". * A traits-based design that allows library users to alter the implementation of parts of the library at compile time. For reference, the code is also in the Boost sandbox at: https://svn.boost.org/svn/boost/sandbox/SOC/2007/cgi/trunk Cheers, Darren * the one started way back in the GSoC of 2007...

7 21

[log] Forward Declarations
by Christoph Heindl 26 May '10

26 May '10

Andrey, are you thinking about providing a header containing forward declarations of boost.log datatypes? If not, I'd like to request that feature. Best regards, Christoph

3 6

[fusion] type in doc
by vicente.botet 25 May '10

25 May '10

Hi, I guess there is a typo in fusion/extension/sequence_facade.html " The sequence_facade template provides an intrusive mechanism for producing a conforming Fusion iterator. " Instead of iterator should be sequence, isn't it? _____________________ Vicente Juan Botet Escribá http://viboes.blogspot.com/

1 0

Re: [boost] [MSM] compiling MSM with GCC 4.4.1 and -fno-rtti
by Christophe Henry 25 May '10

25 May '10

>> Interestingly, this also happens with gcc by simply including >> <boost/function.hpp>. > > I think I fixed this some time ago? Which Boost and which g++? Sorry, you're right, I was trying with 1.40. With 1.42, it works. >> I see there is a BOOST_NO_RTTI switch, does someone see a problem if I >> use it as a way to disable the features making use of any or function? > > BOOST_NO_RTTI is the right switch for any, for function (before the fix) > you'd have needed BOOST_NO_TYPEID. There is a difference on, for example, > MSVC. The switch is actually pretty cool and made my life way easier :) Richard, I just committed the fix in the trunk (https://svn.boost.org/svn/boost/trunk/boost/msm/back/state_machine.hpp) it should work now. Thanks, Christophe

1 0

Re: [boost] [MSM] compiling MSM with GCC 4.4.1 and -fno-rtti
by Christophe Henry 25 May '10

25 May '10

> Hi All > > I try to compile boost msm in an embedded target with gcc 4.4.1 for > performance reasons I want to disable RTTI. > I'm having problems because backend is using boost::any which is uses RTTI. > Is it possible to remove this dependency ?. > or introduce some compile switch like in shared pointers .... > BOOST_NO_STD_TYPEINFO > > Thanks in advance. > Richie Hi all, Interestingly, this also happens with gcc by simply including <boost/function.hpp>. I see there is a BOOST_NO_RTTI switch, does someone see a problem if I use it as a way to disable the features making use of any or function? Christophe

2 1

[serialization] Binary iarchive invalid signature
by Gevorg Voskanyan 25 May '10

25 May '10

Hi, Binary iarchive is supposed to throw invalid_signature archive_exception when the archive content doesn't start with the expected signature. However in some cases a different behavior is observed when trying to load from an invalid archive. For example, if the supposed signature size being read ends up a huge number (can easily happen trying to load from an arbitrary file not created with Boost.Serialization), the program spends a few seconds on line 111 of basic_binary_iprimitive.ipp (s.resize(l);) allocating a big chunk of memory to read the signature into, then tries to read that many bytes from the stream, which, assuming the file is not that large, reads less bytes than requested so it all ends up throwing archive_exception(stream_error) at basic_binary_iprimitive.hpp:164. Another example is when the 'signature size' being read happens to be a larger number still, then s.resize(l); throws std::bad_alloc when in fact the user would want to get archive_exception(invalid_signature) instead. I've attached a patch for archive/impl/basic_binary_iarchive.ipp against Boost 1.43 version that fixes the problem for me. Comments? Thanks, Gevorg P.S. Boost 1.43, Win XP SP2, MSVC 8

2 2

[parameter] arg_list.hpp depends on maybe.hpp
by Andrey Semashev 25 May '10

25 May '10

I've been inspecting my code for a possible compilation speedup. The code uses Boost.Parameter and thus my attention shifted to it as well. I noticed that the parameter/aux_/arg_list.hpp header depends on parameter/aux_/maybe.hpp, which appears to be quite heavy due to its usage of Boost.Optional and other headers. From the code it looks like this "maybe" is only related to python binding, and the only thing arg_list.hpp needs from it is the maybe_base class, which is trivial. Is it possible to extract this class to a separate header and remove the dependency on maybe.hpp from arg_list.hpp or am I missing something? The change looks quite harmless. If I'm not missing anything, am I allowed to apply the change?

4 7

[config] Major upgrade to Boost.Config symbol visibility macros
by Beman Dawes 25 May '10

25 May '10

The upgrade to Boost.Config symbol visibility macros that has been under discussion has been committed to trunk. This lays the groundwork for resolving #2144, #2309, #3697. See https://svn.boost.org/trac/boost/changeset/62140 Thanks Jürgen Hunold for his patches and much other work on symbol visibility issues. The changeset also applied the changes to Boost.System to act as a testbed to ensure the changes are correct. That's a concern because any breakage in Boost.Config could break a lot of other stuff. We also want to get the Boost.Config changes right the first time as they kick off rebuilds of everything that uses the config system. The changes have been tested locally on Windows, Linux, and the Mac, and Boost.Filesystem has been retested on those systems as a reality check that unmodified user code continues to work. As trunk regression tests cycle and our confidence builds, we will start to suggest and/or apply changes to other libraries to make use of the new facilities. --Beman

7 9

[ptr_container] clone_ptr library
by raffimoni 25 May '10

25 May '10

Hello everybody, I did not find any boost library that handle with a situation described below, so that I request for your comments. Is there any interest in such a library? ===================== MOTIVATION ===================== Every time we need a class that owns some pointer (so that class is responsible for freeing it), we always need to define destructor, copy constructor and assignment operator. This is example implementation: class SomeClass { Base* ptr_; public: SomeClass( Base* ptr ): ptr_(ptr) {} ~SomeClass() { delete ptr_; } SomeClass(const SomeClass& s); //must be implemented const SomeClass& operator =(const SomeClass& s); //must be implemented }; In order to avoid a need of defining destructor we can use auto_ptr: class SomeClass { std::auto_ptr<Base> ptr_; public: SomeClass( Base* ptr ): ptr_(ptr) {} SomeClass(const SomeClass& s); //must be implemented const SomeClass& operator =(const SomeClass& s); //must be implemented }; But we need still implement copy constructor and assignment operator. Of course we can declare SomeClass noncopyable by deriving from boost::noncopyable to avoid this, but suppose this is not special case class and copying should be allowed. The best elegant solution to this problem is using a clone_ptr: class SomeClass { clone_ptr< Base > ptr_; public: SomeClass( Base* ptr ): ptr_(ptr) {} }; We can think about clone_ptr in two different ways: -as auto_ptr with different copy semantics (this is exactly what clone_ptr is) -as one-element ptr_container clone_ptr frees programmer from managing pointer the same way ptr_container for container of pointers does. So during copying the above class with clone_ptr behaves exactly like this: class SomeClass { //suppose this contains only one pointer boost::ptr_vector< Base > ptr_; public: SomeClass( Base* ptr ) {ptr_.push_back( ptr );} }; Notice that we do not need longer to define destructor, copy constructor and assignment operator. The default behaviour of these methods makes a deep copy of pointer and we should not be bothered by this anymore. clone_ptr uses the same concept of cloning that ptr_containers do, so new_clone function should be defined for Base class, if it is not and clone_ptr< Base > points to some type that derives from Base, an appropriate assert will fail the same way it does with ptr_container. Defining new_clone for Base makes it cloneable for ptr_pointer and clone_ptr simultaneously. ===================== SAMPLE IMPLEMENTATION ===================== class clone_ptr { private: T* ptr_; public: explicit clone_ptr(T* ptr) throw(): ptr_( ptr ) {} ~clone_ptr() { delete ptr_; }; clone_ptr(const clone_ptr<T>& ptr) { ptr_ = new_clone( *ptr.ptr_ ); //default is defined in ptr_container library assert( typeid( *ptr_ ) == typeid( *ptr.ptr_ ) ); } public: void reset( T* ptr = 0) throw() { if (ptr != ptr_) { delete ptr_; ptr_ = ptr; } } T* operator -> () const throw() { return ptr_; } }; Of course this implementation is not complete. Notice the way copy constructor is implemented. ===================== REMARKS ===================== clone_ptr should definitely not be used with stl containers (e.g. stl::vector< clone_ptr< Base > >) because of performance, ptr_containers are the best way to achieve such functionality. I'm looking forward to your feedback. Best Regards, Rafal Moniuszko

5 5

[test] [Patch] Unconditional use of non-standard functions.
by John Maddock 25 May '10

25 May '10

Boost.Test has just started using ::fedisableexcept and ::feenableexcept unconditionally - even though these are GLIBC specific extensions - which presumably is why Boost.Test is currently failing so many tests :-( I've just committed a patch to restrict the use of these functions to GLIBC platforms that have the GNU extensions enabled: see https://svn.boost.org/trac/boost/changeset/62194/trunk/boost/test/impl/exec…. Please feel free to change the logic for any other platforms that may have these functions.... but for now, hopefully we can get back to testing Boost again! Cheers, John.

1 0

[fusion] flat fusion sequence of all the node of a type
by vicente.botet 24 May '10

24 May '10

Hi, I want to create a fusion sequence that give access to all the nodes of a struct/class/array that inherit from a given class TO. If we remove this constraint, the fusion sequence can be seen as flattening the tree of nodes in a given order. Once I will have this I can use filter_if<is_base_of<TO,_> > Given class TO; struct W { TO t; }; struct X : TO { // direct TO* to_ptr; char c; }; struct Y : TO { // direct with embeddeds X x; int i; }; struct Z { // with embeddeds Y y[2]; TO t; W w; }; Z z; the flat view corrsponds to z.w.t, z.w, z.t, z.y[0].x.to_ptr, z.y[0].x.c, z.y[0].x, z.y[0], z.y[1].x.to_ptr, z.y[1].x.c, z.y[1].x, z.y[1], z.y, z The filtered view corrsponds to Y z.y[0] X z.y[0].x Y z.y[1] X z.y[1].x TO z.t TO z.w.t If I have fusion sequence struct adaptors for W, X, Y, Z. Is there a simple and run-time efficient way to get this fusion sequence adaptor or I need to do something similar to the struct adaptor? Have others had a similar need already? Best, Vicente P.S. For my personal usage I need only a forward sequence.

1 0

[MSM] compiling MSM with GCC 4.4.1 and -fno-rtti
by Richard Szabo 24 May '10

24 May '10

Hi All I try to compile boost msm in an embedded target with gcc 4.4.1 for performance reasons I want to disable RTTI. I'm having problems because backend is using boost::any which is uses RTTI. Is it possible to remove this dependency ?. or introduce some compile switch like in shared pointers .... BOOST_NO_STD_TYPEINFO Thanks in advance. Richie

1 0

Maintenance Patches and cleaning up trac
by Christopher Jefferson 24 May '10

24 May '10

Having recent been browsing through boost trac I have noticed that it seems to be getting a little clogged with some very simple patches. Examples of simple patches: https://svn.boost.org/trac/boost/ticket/3402 - simple documentation patch, 6 months old, duplicated. https://svn.boost.org/trac/boost/ticket/3669 - add stdint.h to thread, fixes comeau, 6 months old. https://svn.boost.org/trac/boost/ticket/4060 - boost thread support for BOOST_NO_IOSTREAM I notice these 3 are in 'thread', and several others are in 'filesystem'. I do not wish to maintain these libraries myself, and it appears no-one else is coming forward to keep these libraries ticking over on a day-to-day basis. I would however personally be happy (possibly with help) to look at applying these patches, and applying the to trunk, and then release in time, assuming they pass regression testing. I would suggest a policy something like the following: 1) If a patch is considered to be "trivially obvious", mark the patch in trac, by leaving a comment, as a 'maintenance patch'. 2) If no-one disagrees within some period of time (2 weeks? 3?), then the patch is applied to trunk. If it passes regression testing it is then moved to release. Any thoughts on the topic? Chris

8 14

Re: [boost] [Boost-docs] Maintaining boost.org
by David Abrahams 24 May '10

24 May '10

At Tue, 25 May 2010 00:32:02 +0800, Joel de Guzman wrote: > > On 5/24/10 10:41 PM, Rene Rivera wrote: > > > > One idea I had, before Boostcon when the whole where should Boost go > > discussion came up, was to move to using something like the Drupal model > > for sub-projects <http://drupal.org/project/Modules>. Particularly how > > the projects each have their own web area. And also how the groups > > section area of Drupal works <http://groups.drupal.org/>. > > > > Note, I'm not suggesting Drupal (even if I do currently use it). Just > > some of the structure they employ for projects since it does mirror the > > conglomerate project structure Boost has. > > Last November, we switched the Spirit site to Wordpress. > > http://boost-spirit.com/home/ > > After having tried Drupal, Joomla, and a couple of other > CMS, we settled on Wordpress because of its simplicity, > low entry barrier and low maintenance. It's just perfect for > people on the go, like us. Agreed; WP rocks. Consider WPMU (or WP3.0) and/or BuddyPress also. I am using those at http://techarcana.net, although I haven't had time to make everything really nice yet. -- Dave Abrahams Meet me at BoostCon: http://www.boostcon.com BoostPro Computing http://www.boostpro.com

1 0

How to build Boost with C++0x compilers
by vicente.botet 24 May '10

24 May '10

Hi, I don't know how to build Boost with C++0x compilers. Which option must be used with bjam? Should the user.config file be modified? Can someone help me? Best, Vicente

5 6

Testing macros..
by Rene Rivera 24 May '10

24 May '10

Once upon a time I did a bunch of work towards a Boost Predef library. The goal was to have a consistent set of version and feature definitions as could be determined from the predefined macros of toolsets <https://svn.boost.org/svn/boost/sandbox/predef/>. But the work stalled for one basic reason.. How do I write tests for such a library? The only other library that approaches the domain of this one is Boost Config and, AFAICT, it doesn't test the macros themselves. As I'm looking to finish of this lib for eventual submission I'm looking for ideas on this. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org (msn) - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim,yahoo,skype,efnet,gmail

3 2

Is there a plan to provide a C++0x std library repository in Boost?
by vicente.botet 24 May '10

24 May '10

Hi, Boost provides a lot of C++0x accepted libraries that could be in the std namespace. As it was done for std::tr1, is there a plan to provide these libraries on namespace std? Best, Vicente

4 5

[challenge!] find a common domain
by Eric Niebler 23 May '10

23 May '10

I recently solved a devilish C++ coding problem related to the new sub-domain feature of Proto. I don't care for my solution, so I thought I'd throw it out there and see if some smart person could do better. I'm sending along the skeleton of the solution and some tests that it needs to satisfy. The rest is up to you. The problem goes like this. Every Proto expression has a "domain", which is a type defined something like this: struct my_domain : domain<> {}; A domain can be a sub-domain of another domain, defined like this: struct my_sub_domain : domain<my_domain> {}; When combining sub-expressions into larger expressions, the new expression has some domain that depends on the domains of its children. This domain is calculated according to some rules. - Domains that share no common super-domain are incompatible with each other. The result should be not_a_domain. - A sub-domain is "stronger" than its super-domain. - For a set of domains, the common domain is the strongest domain that is a super-domain of every domain in the set. - default_domain is special; it is compatible with (and dominated by) all other domains. - A sub-domain of default_domain is stronger than default_domain and still compatible with and dominated by all other domains. Your job: implement the deduce_domain3 template that finds the common domain of 3 domains. You're allowed to use decltype, but you get bonus points for a solution that doesn't. Bonus also for instantiating fewest templates. The challenge is for the ternary case, but your solution should scale to N domains. If your solution is better than mine, I'll use it in Proto and credit you! Good luck. P.S. I haven't checked my solution in yet, so you can't look in trunk and cheat. ;-) -- Eric Niebler BoostPro Computing http://www.boostpro.com

8 24

Proposal regarding "boost::add_const".
by Michael Soliman. 23 May '10

23 May '10

Moin Moin. First of all, this is my first boost posting, and as all I could find on "http://lists.boost.org/mailman/listinfo.cgi/boost" told my to post my proposal to this address, I did so (despite of being astonished, that there does not seem to be a directory of subgroups to browse.). However, at least on MSVC 9 as well as on ICL 11 there exists the problem, that the "BOOST_MPL_ASSERT" terms in the attached "consten.rar\consten\consten.cpp" do fail for "boost::add_const" but not for "consten", meaning, that "boost::add_const" was not capable to add constness to reference-types, which "consten" is. Hence my proposal is, to create a service-pack to "boost::add_const" based on "consten" and similarly to all other affected traits, such as "boost::add_volatile" and the like. With kind regards, Michael. P.S.: Is there a web-based, thematically browsable discussion-list (I know it to be sounding typical for windows-users, but these types of lists do save time.). -- __________________________________________ Michael Soliman. Web: http://soliman.de Email: mailto:michel@soliman.de Adresse: Dresdener Strasse 6 64839 Muenster GERMANY Telephon: +(49)6071420815 Handy: +(49)1705605430 Skype: skypeto:michel_soliman_de Oeffentlicher PGP-Schluessel: http://soliman.de/pgp.asc __________________________________________ Alopex GbR (Inhaber.: Michael Soliman & Henning Voß) Gross-Bieberauer Strasse 4, 64354 Reinheim. __________________________________________ Alopex-IT GmbH&Co KG, Eingetragener Name: "Alopex Informationstechnologie GmbH & Co. KG (pers. haft. Gesell.: Alopex Verwaltungsgesellschaft mbH ) ", Ort und Nr. des Registereintrages: Darmstadt, HR A 32356/Darmstadt, HR B 33834, Alopex-Patente GmbH&Co KG, Eingetragener Name: "Alopex Patentverwertungsgesellschaft mbH & Co. KG (pers. haft. Gesell.: Alopex Verwaltungsgesellschaft mbH ) ", Ort und Nr. des Registereintrages: Darmstadt, HR A 32357/Darmstadt, HR B 33834, Sitze: Gross-Bieberauer Strasse 4, 64354 Reinheim, Rechtsformen: GmbH&Co KG, Geschaeftsfuehrer: Voss, Henning und Soliman, Michael. ------------------------------ Zeitweise auch taetig fuer: NETWORK PEOPLE AG Alsfelder Straße 11, 64289 Darmstadt, Germany fon: + 49 . 6151 . 35076-0 fax: + 49 . 6151 . 35076-10 eMail: m.soliman(a)networkpeople.de visit: www.networkpeople.de Vorsitzender des Vorstands: Dipl.-Ing. Siamak Mashayekhi Aufsichtsrat: Dipl.-Chem. Michael Schnieder (Vors.) Sitz: 64283 Darmstadt Amtsgericht Darmstadt HRB 7604 Umsatzsteuer ID: DE204157624 Steuer-Nr.: 007 240 00336 ------------------------------ Diese Mail enthält vertrauliche und/oder rechtlich geschützte Informationen. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrtümlich erhalten haben, informieren Sie bitte sofort den Absender und vernichten Sie diese Mail. Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser Mail ist nicht gestattet. This eMail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this eMail in error) please notify the sender immediately and destroy this eMail. Any unauthorised copying, disclosure or distribution of the material in this eMail is strictly forbidden.

2 1

[test] broken on trunk under cygwin
by Eric Niebler 23 May '10

23 May '10

Eric@AERIX ~/boost/org/trunk/libs/proto/test $ bjam toolset=gcc-4.5 ...patience... ...patience... ...found 1435 targets... ...updating 71 targets... gcc.compile.c++ ../../../bin.v2/libs/proto/test/noinvoke.test/gcc-4.5/debug/link-static/noinvoke.o noinvoke.cpp: In function ‘void test_noinvoke()’: noinvoke.cpp:67:36: warning: unused variable ‘t2’ gcc.compile.c++ ../../../bin.v2/libs/test/build/gcc-4.5/debug/link-static/compiler_log_formatter.o In file included from ../../../boost/config.hpp:57:0, from ../../../boost/detail/workaround.hpp:41, from ../../../boost/test/utils/basic_cstring/basic_cstring_fwd.hpp:19, from ../../../boost/test/utils/basic_cstring/basic_cstring.hpp:20, from ../../../boost/test/detail/global_typedef.hpp:18, from ../../../boost/test/output/compiler_log_formatter.hpp:19, from ../../../boost/test/impl/compiler_log_formatter.ipp:19, from C:\cygwin\home\Eric\boost\org\trunk\libs\test\src\compiler_log_formatter.cpp:1 6: ../../../boost/config/suffix.hpp:484:18: warning: ISO C++ 1998 does not support ‘long long’ ../../../boost/config/suffix.hpp:485:18: warning: ISO C++ 1998 does not support ‘long long’ In file included from ../../../boost/test/unit_test_log_formatter.hpp:23:0, from ../../../boost/test/output/compiler_log_formatter.hpp:20, from ../../../boost/test/impl/compiler_log_formatter.ipp:19, from C:\cygwin\home\Eric\boost\org\trunk\libs\test\src\compiler_log_formatter.cpp:1 6: ../../../boost/test/execution_monitor.hpp:366:5: error: expected ‘}’ before ‘BOOST_FPE_INV’ ../../../boost/test/execution_monitor.hpp:366:41: error: invalid conversion from ‘int’ to ‘boost::fp e::masks’ ../../../boost/test/execution_monitor.hpp:367:1: error: expected ‘,’ or ‘;’ before ‘}’ token ../../../boost/test/execution_monitor.hpp:367:2: warning: extra ‘;’ ../../../boost/test/execution_monitor.hpp:375:1: error: expected declaration before ‘}’ token "/usr/local/gcc-4.5/bin/g++.exe" -ftemplate-depth-128 -O0 -fno-inline -Wall -pedantic -g -DBOO ST_ALL_NO_LIB=1 -I"../../.." -c -o "C:\cygwin\home\Eric\boost\org\trunk\bin.v2\libs\test\build\gcc- 4.5\debug\link-static\compiler_log_formatter.o" "C:\cygwin\home\Eric\boost\org\trunk\libs\test\src\c ompiler_log_formatter.cpp" ...failed gcc.compile.c++ ../../../bin.v2/libs/test/build/gcc-4.5/debug/link-static/compiler_log_for matter.o... -- Eric Niebler BoostPro Computing http://www.boostpro.com

2 1

[nt2] Code from Boostcon 2010
by Ravi 23 May '10

23 May '10

Hi, Is the code for NT2 (presented at BoostCon 2010) publicly available? There is an empty repository on gitorious and another seemingly inactively-developed version on sourceforge. My google-fu fails me in finding a more up-to-date copy. Regards, Ravi

3 4

[castor] Interest in Logic Paradigm for C++ ?
by Roshan Naik 23 May '10

23 May '10

Based on suggestions from some Boost community experts, I would like to gauge interest to see if there is broader interest for including the Castor library into Boost. In short, Castor's aim is to foster multiparadigm programming in C++ by supporting techniques from the Logic Paradigm. See below for a longer description. ============== Description: ============== Logic Paradigm (LP) is a general purpose declarative programming paradigm. It focuses on "what" to compute and not "how" to compute. Although LP has been well explored in Computer Science as a fundamental computational model, it remains unavailable for main stream software development due to lack of support in popular programming languages. Prolog is perhaps the most commonly known language among those that support LP. Castor takes a pure library approach (i.e. without language extensions) for introducing LP to C++. Instead of providing a Logic interpreter or evaluation engine in library form, Castor provides a few simple library primitives on which LP techniques can be supported. This approach allows a natural and deep integration of declarative code into the language and also provides the flexibility of freely combining Logic with the other paradigms such as OO, generics, functional etc. STL concepts like iterators, containers and streams can also be used in declarative code. For an introductory tutorial on LP in C++ and Castor please refer to http://mpprogramming.com/downloads/betaTutorial.pdf. Castor is intended to be a free standing library that depends only on the standard C++ library. It does not depend on Boost or other libraries. It is a pure header library. ============== Current State: ============== A stable 1.0 version has been available since 2008 on www.mpprogramming.com/cpp under the MIT license. Work on version 1.1 is in progress and an early beta is now available. Current efforts are directed largely towards making Castor a richer "standard library" for working with LP in C++. Castor was not originally targeted for Boost but more recently I have been giving it more serious consideration regarding inclusion into Boost. At the upcoming BoostCon 2010 I will be presenting 'Logic Paradigm for C++'. If there is interest, my thought is that feedback from the Boost review/submission process and modifications to satisfy other Boost requirements/guidelines will perhaps yield a 1.2 version that will become the real Boost candidate. Any help in this space will be much appreciated. ================== Links for Castor - v1.1 beta (ported to Gcc 4.4.1 and VC++ 2008) : ================== Library+docs: http://mpprogramming.com/downloads/prebeta-1.1.zip Individually downloadable documentation: Tutorial: http://mpprogramming.com/downloads/betaTutorial.pdf Reference Manual: http://mpprogramming.com/downloads/betaRefManual.pdf Design doc: http://mpprogramming.com/downloads/betaDesignDoc.pdf - Roshan Naik

16 52

[config] GCC symbol visibility across shared libraries
by Beman Dawes 22 May '10

22 May '10

There are several outstanding tickets (2114, 2309, 3697) dealing with GCC symbol visibility across shared libraries (DSO's on UNIX-like systems, DLL's on Windows-like systems). A particular problem that is affecting several Boost libraries (system, filesystem, threads, etc) is that with compiler switch -fvisibility=hidden an exception thrown in one library cannot be caught in another library or in the main program. For more background, see http://gcc.gnu.org/wiki/Visibility Ticket 2114 provided patches to fix the problem, and work started on getting them ready for trunk. But that work seems to have stalled. See http://svn.boost.org/trac/boost/ticket/2114 What needs to be done to restart this effort? It would be better is discussion could occur on this list, rather than as comments attached to the ticket. That will ensure more eyeballs look at this. --Beman

8 33

boost:: program_options
by Vijay Samuel 22 May '10

22 May '10

Hi, I have a query regarding boost:: program_options. Is it possible for multiple programs to use a single configuration file? If so, then how? I have two programs which have to use a single configuration file. Both programs have both similar and unique options but have different default values. Thanks in advance. Cheers, -Vijay Samuel

2 2

Clang Builds Boost
by Doug Gregor 22 May '10

22 May '10

Hi all, Well, we didn't make it before the end of BoostCon, but now we have: Clang successfully builds all of Boost's regression tests on the release branch. More information available at http://blog.llvm.org/2010/05/clang-builds-boost.html . - Doug

17 25

[Atomic] Any multi-threaded tests?
by Phil Endecott 21 May '10

21 May '10

Dear Helge & others, I now have a working ARM Linux system again and I feel I should test the atomics code that I submitted late last year. Is there any test code that actually exercises the atomics across threads? Currently I can see only one test program, and it doesn't seem to involve any concurrency. (Let's not lose momentum on this important library....) Regards, Phil.

1 0

[1.43.0][preprocessor] BOOST_PP_SEQ_FOR_EACH doesn't work recursively
by Adam Badura 21 May '10

21 May '10

BOOST_PP_SEQ_FOR_EACH macro when used within another BOOST_PP_SEQ_FOR_EACH does not expand at all (and the same happens with _R versions). I use Visual Studio 2005. A simple test is: >>>>>>>>>>>>>>>>>>>> #include <boost/preprocessor.hpp> #define SEQ \ ( ( n1 )( n2 )( n3 ) ) \ ( ( n4 )( n5 )( n6 ) ) #define CAT( _r, _data, _elem ) \ BOOST_PP_CAT( _data, _elem ) #define JOIN( _r, _seq ) \ BOOST_PP_SEQ_FOR_EACH_R( _r, CAT, ::, _seq ) #define MAKE( _r, _data, _elem ) \ JOIN( _r, _elem ) BOOST_PP_SEQ_FOR_EACH( MAKE, nil, SEQ ) <<<<<<<<<<<<<<<<<<<< The expected result is something like: >>>>>>>>>>>>>>>>>>>> ::n1 ::n2 ::n3 ::n4 ::n5 ::n6 <<<<<<<<<<<<<<<<<<<< while it is not. Instead we get something like: >>>>>>>>>>>>>>>>>>>> BOOST_PP_SEQ_FOR_EACH_M(3, (CAT, ::, ( n1 )( n2 )( n3 ) (nil))) BOOST_PP_SEQ_FOR_EACH_M(4, (CAT, ::, ( n2 )( n3 ) (nil))) BOOST_PP_SEQ_FOR_EACH_M(5, (CAT, ::, ( n3 ) (nil))) BOOST_PP_SEQ_FOR_EACH_M(4, (CAT, ::, ( n4 )( n5 )( n6 ) (nil))) BOOST_PP_SEQ_FOR_EACH_M(5, (CAT, ::, ( n5 )( n6 ) (nil))) BOOST_PP_SEQ_FOR_EACH_M(6, (CAT, ::, ( n6 ) (nil))) <<<<<<<<<<<<<<<<<<<< It seems to me that something is wrong with BOOST_PP_SEQ_FOR_EACH(_R) because following JOIN macro works well in this test case: >>>>>>>>>>>>>>>>>>>> #define JOIN( _r, _seq ) \ BOOST_PP_LIST_FOR_EACH_R( \ _r, \ CAT, \ ::, \ BOOST_PP_TUPLE_TO_LIST( BOOST_PP_SEQ_SIZE( _seq ), BOOST_PP_SEQ_TO_TUPLE( _seq ) ) \ ) <<<<<<<<<<<<<<<<<<<< While all it does it to use BOOST_PP_LIST_FOR_EACH_R instead of BOOST_PP_SEQ_FOR_EACH_R and change the given sequence to a tuple and then that tuple to a list. Adam Badura

2 1

[Booster] Or boost is useless for library developers
by Artyom 21 May '10

21 May '10

Hello, I want to bring up an important issue that boost developers are not aware of: anybody who develops a library and wants to keep any kind of backward compatibility can-not use Boost. Issue, let's assume I want to develop a small library that keeps backward comparability well. Let's assume I want to use `boost::shared_ptr` as one of the most important parts of boost in my library interface... Impossible. why? Even, for such a small part of boost with stable (even tr1) definitions it is impossible to promise that it would not be broken between releases. Why boost::details::sp_counted_base may be changed because in next version atomic counter was implemented using assembly rather then pthread's mutex... which affects the layout of boost::details::sp_counted_base and thus breaks compatibility. That is not a first time I bring up this issue. But at this point I started to bring a some kind of solution. I do need boost for my FOSS project CppCMS <http://cppcms.sf.net>. I was trying for a long period use renamed version of Boost (with a small tool I written similar to BCP's renamer) inside the library not showing the interface outside but finally I realized that I need boost in interface. I need ASIO, I need shared_ptr, I need regex, I need thread and much more... So I created a small library I called "booster" as part of CppCMS project that has a goal - provide backward compatible and stable boost like library that can be used by other libraries. It has following libraries: - smart_ptr: intrusive_ptr, shared_ptr, - function - locale (full copy of Boost.Locale I develop) - regex (pcre-wrapper, no replace functionality, no wide api) - system (meanwhile without error_condition) - thread (partial) - aio - my own ASIO like library. - ptime - Posix time (very different from boost one) For this purposes I did: - Adopted some of boost code to booster (shared_ptr/intrusive_ptr) and made sure that it would not break ABI with internal changes. - Wrapped pthreads with boost.thread like interface (in any case boost.thread is more like pthreads with C++ interface). So under windows it requires pthreads-win32 library. - I wrapped pcre library with boost.regex like interface. - I had written my own Boost.Asio like library (Booster.AIO) that has very limited use of templates. It uses epoll/devpoll/kqueue where available and poll or select on other platforms (no IOCP as it adds many limitations). - It uses CMake instead of Boost.Build. - It supports **only** modern compilers: gcc>=3.4, MSVC-2008 (2005 should work as well, but not tested), intel 11 compiler. - It is little bit less Windows friendly then Boost - no auto-link, no wide api, no IOCP support. Believe me it wasn't simple decision to start writing this library. But I just had no other choice. ------------------------------------------------ The source code can be found there (svn): https://cppcms.svn.sourceforge.net/svnroot/cppcms/framework/branches/refact… - I do not encourage anybody use it over boost, but if you have similar problems with boost as I have, you are welcome to take a look on it, try it. - I do think that boost is great library. - I would really prefer to use boost if it was not breaking ABI every few month. - I would probably adopt more boost libraries into booster (where possible) ------------------------------------------------------------- I want boost community to think about it... Is it right that developers of many libraries can't use Boost. Think of GTKmm, think of Qt, think of kdelib - that no-one can use it just because they promise backward compatibility. Maybe there is something wrong with it? Artyom.

27 110

Re: [boost] [challenge!] find a common domain
by Krishna Achuthan 21 May '10

21 May '10

"Eric Niebler" <eric(a)boostpro.com> wrote in message news:< 4BF5CA3B.8090807(a)boostpro.com>... > On 5/20/2010 10:54 AM, John Bytheway wrote: > > On 19/05/10 07:02, Eric Niebler wrote: > > <snip> > >> Your job: implement the deduce_domain3 template that finds the > >> common domain of 3 domains. You're allowed to use decltype, but you > >> get bonus points for a solution that doesn't. Bonus also for > >> instantiating fewest templates. The challenge is for the ternary > >> case, but your solution should scale to N domains. If your solution > >> is better than mine, I'll use it in Proto and credit you! > > > > I attach my solution for completeness, though I think Daniel's is > > neater. I used a similar idea to him, but without the use of > > sizeof/decltype, and with the distance-to-not_a_domain implemented > > as a metafunction, rather than injected into the definition of domain. > > > > I think we use about the same number of instantiations, but Daniel's > > lends itself to unrolling much more than mine. I might argue that > > my implementation is a little easier to follow than his, but it > > would be a pretty feeble claim. > > Thanks, John. I'll need to investigate more closely. Everybody's code > is easy to follow when they wrote it! :-) Though I admit, Daniel's > solution is subtle and had me scratching my head for a while. > > And for completeness, here is my (decltype-based) solution. I tried to > make one giant expression that calculates the result in one shot. Like > Daniel, I use inheritance and overloading, but I build a parallel > hierarchy instead of reusing the domains. (For reasons that aren't > relevant, I don't want domains to actually inherit from other domains > in > Proto.) > > -- > Eric Niebler > BoostPro Computing > http://www.boostpro.com > Here's another try. No inheritance or function overloading. I have no idea how many template instantiations are there in this code and if it is acceptable. There is some influence from Daniel's solution in getting the default_domain resolutions right. - Krishna Achuthan

1 0

Let's use stack exchange!
by Gennadiy Rozental 21 May '10

21 May '10

Hi, I've always envied a bit how stackoverflow site was operating. I like the interface much better than mailing lists. Search, filtering, thread tracking... Now that the engine behind it is free http://www.joelonsoftware.com/items/2010/04/13.html I think we can benefit a lot from using it for boost. In addition it should help us with review managers issues. We can use "reputation" based system to qualify potential managers. In practice: who should agree to this and who would do the work? Gennadiy

9 13

[thread] Compiler eoorrs while running the tests
by vicente.botet 21 May '10

21 May '10

Hi, I get some compile errors with boost 1.43 gcc.compile.c++ ..\..\..\bin.v2\libs\thread\test\test_thread_return_local_lib.test\gcc-mingw-4.4.0\debug\threading-multi\test_thread_return_local.o ..\..\../boost/thread/detail/thread.hpp: In function 'boost::thread make_thread_return_local(boost::thread::id*)': ..\..\../boost/thread/detail/thread.hpp:111: error: 'boost::thread::thread(boost::thread&)' is private test_thread_return_local.cpp:16: error: within this context How can the following compile? boost::thread make_thread_return_local(boost::thread::id* the_id) { boost::thread t(do_nothing,the_id); return t; } Best, _____________________ Vicente Juan Botet Escribá http://viboes.blogspot.com/

2 8

Re: [boost] [challenge!] find a common domain
by Krishna Achuthan 21 May '10

21 May '10

----- Original Message ----- From: <daniel(a)boostpro.com> Newsgroups: gmane.comp.lib.boost.devel To: <boost(a)lists.boost.org> Sent: Thursday, May 20, 2010 6:05 AM Subject: Re: [challenge!] find a common domain > On Wed, May 19, 2010 at 03:54:29PM -0700, Eric Niebler wrote: >> On 5/19/2010 3:29 PM, Daniel Wallin wrote: >> > On Tue, May 18, 2010 at 11:02:56PM -0700, Eric Niebler wrote: >> >> Your job: implement the deduce_domain3 template that finds the common >> >> domain of 3 domains. You're allowed to use decltype, but you get bonus >> >> points for a solution that doesn't. Bonus also for instantiating fewest >> >> templates. The challenge is for the ternary case, but your solution >> >> should scale to N domains. >> > >> > Here's mine. It's decltype based, but I guess it could be sizeof based >> > in C++03. >> >> Wow! SO much simpler than my solution. I'll need to study this in depth. >> I also specialized domain<default_domain> to insert an extra level in >> the inheritance tree like you did. That's a great simplification, but it >> took me a week to see that. Kudos. > > Thanks. :) > >> BTW, you're creating a zero-sized array in sized_type<0>. I just >> bumped all the integers by one and it works fine on msvc-10. > > Duh, good catch. > >> This looks more efficient at compile-time, too. I'll be embarrassed to >> post my solution. :-O But not yet. Anybody care to eliminate decltype so >> I can use this in Proto? Anybody think they can instantiate fewer templates? > > Here's one without decltype. The changes needed were pretty minor. It > might still be possible to reduce the number of instantiations. For > instance, you could specialize nth_domain<> on some more indicies (I'm > guessing the number of super domains should be fairly low), but I don't > know what the cost of specialization compared to instantiation is. > > -- > Daniel Wallin > BoostPro Computing > http://www.boostpro.com When I tried to compile the code using VC 2005, it failed with the following error: error C2064: term does not evaluate to a function taking 1 arguments deduce_domain.cpp 53 After I broke the struct into two pieces like below, it works fine. template <class D0, class D1> struct domain_depth { static const int value = domain<D0>::index - sizeof(domain<D0>::deduce((D1*)0)); }; template <class D0, class D1, int DefaultCase = sizeof(default_case((D0*)0, (D1*)0))> struct deduce_common : nth_domain<domain_depth<D0, D1>::value, D0> {}; - Krishna Achuthan

2 1

[geometry][units] Vector Class
by Terry Golubiewski 21 May '10

21 May '10

I imagine that using geometry/unit together will be common. I just posted these files on boost-user too, but I wanted the geometry/units developers to see what I've done. I think it was too difficult to make a Vector<quantity<U,T>> class. However, it could be done, so that is very good! The problem is that the geometry library assumes that the types of T*T and sqrt(T) is the same as T. terry

5 7

[Test] WinCE patch for floating point changes
by David Deakins 20 May '10

20 May '10

Hi Gennadiy, I noticed the recent floating point feature broke testing on Windows CE since it does not have the _controlfp_s function like full-blown Windows. Do you mind if I apply the attached patch to make testing work again (at least until a suitable real implementation is found for WinCE if possible). Thanks, -Dave

1 0

boost thread slow with only one thread
by Natacha Fort 20 May '10

20 May '10

hi! here is my problem i am multithreading my program with boost but i don't get what i expect, and i can't understand why! i just run one thread and wait for it, and the fps are divide by 3. basically with no thread i have 30fps, and with 1 thread i have 10fps. here is the code: Code: boost::thread_group forces_threads; forces_threads.create_thread(boost::bind(&ElasticRods::computeBendingForces,this,edges,kb,edges_initial)); forces_threads.join_all(); i use thread_group because i want to run 7 thread but it is already too slow! do you have an idea of why this is so slow? thank you for your help!

3 2

[config] Is there a macro to check if we are compiling in C++0x mode?
by vicente.botet 20 May '10

20 May '10

Hi, In Boost.Config I see "Macros that describe C++0x features not supported", but there is a macro to check if the compiler is working on C++0x mode? Best, _____________________ Vicente Juan Botet Escribá http://viboes.blogspot.com/

2 2

Re: [boost] [MSM] move to trunk
by Christophe Henry 19 May '10

19 May '10

> On 5/18/2010 8:22 AM, Christophe Henry wrote: >> >> I'm a bit jetlagged but (luckily) had an uneventfull trip back. And >> the BoostCon was worth it! > > Indeed! It was great to meet you. It was great to meet you too! >> I plan to check in into the trunk in the next few weeks, I really want >> MSM to be in 1.44. >> I only need to write some unit tests so it should be pretty quick. >> I'll post a mail as soon as I'm done. > > If it's just a matter of unit tests and the interfaces are stable, I > suggest just merging it to trunk now and working on the tests there. > When it's ready, you can merge to release. > > -- > Eric Niebler > BoostPro Computing > http://www.boostpro.com Yes the interfaces and docs are stable, so it is just a matter of writing test cases and add a jam file. Then I will merge MSM to the trunk fast (probably tomorrow) and then start writing the tests. Thanks! Christophe

1 0

sparse_vector class
by Neil Girdhar 19 May '10

19 May '10

boost/numeric/ublas/vector_sparse.hpp implements a "sparse vector" for arithmetic types. I generalized this for default constructible types, and was wondering if anything like this has been considered for inclusion as a separate boost library. Code available on request.

1 0

Boostcon followup - Boost Lockfree review - On behalf of Mark Moir
by Tomas Puverle 19 May '10

19 May '10

I have been in touch with Mark Moir (he was one of the transactional memory speakers at boostcon), wrt the boost lockfree library. As an expert in the field, he was kind enough to do a mini-review. I am posting his comments here and am hoping that these don't get lost in the usual fray of activity, as he is one of the few bona-fide experts in the field that will take the time to actually review the submission. His comments are below: ==== This is mostly a matter of taste, but I don't much care for the approach of having CAS increment the version number, rather than having this explicit in the algorithm, for at least the following reasons: - it is not in keeping with standard cas operations, so an important part of the algorithm appears to be missing; at a minimum, cas should be renamed to cas_and_bump_version or something. - not all algorithms need to increment the version number on every CAS, for example, the stack algorithm is correct provided we increment the version number of every pop; it does not need to be done on push. This is only a (probably minor) performance concern in the stack algorithm, but one can imagine cases in which it would be important not to increment the version every time, and for such cases, a different library would be needed. - There is an awkward mix of handling version numbers in the fifo code. The node constructor explicitly increments the version number, whereas all other dealing with the version number are hidden behind cas, etc. Furthermore, this explicit incrementing is unnecessary, as far as I can tell. To avoid a "late" enqueue accidentally succeeding, the version number of a node's next pointer should be incremented once for each time it goes through the queue. But this is done by the cas of the enqueue that installs a node after it, and I think this is sufficient. I don't like "just in case" code. The authors should understand whether it's really necessary, and if so, document the reason. If (as I suspect), it's not, they should get rid of it. - I also think there should be more comments about these kinds of subtle issues, especially because the Michael & Scott paper played a little fast and loose with this. (Although they do confess to using a free list, there is a strong suggestion that nodes can be "freed" (as opposed to being put in a type-stable free list), and also no discussion of the importance of preserving version numbers of nodes in the free list. - I think there is a bug in the empty method of the fifo, at least for some memory models. (Note too that M*S did not present an empty method, so again additional comments would be appropriate IMO.) The problem is that the order of the reads is critical to ensure correctness, but there is no memory barrier to enforce this ordering. (Note that if either the compiler or the processor reorders the two loads, it is possible for empty to read tail while the queue is nonempty, then another enqueue happens, then all items that were in the queue when tail was read are removed. Now head has the same value as was read from tail previously, so the comparison can succeed and empty can return true, but the queue was never empty.) Again, I think a comment would be appropriate. ====== Hope this is helpful. Best wishes, Tom PS: It was a real pleasure meeting everyone at the conference.

3 4

BoostCon 2011 Hotel Reservation Billing
by David Abrahams 19 May '10

19 May '10

FYI, last year the Meadows' move to an automated reservation system caused some issues with the amount people were charged for reservations. After inquiring specifically into billing for 2011 reservations, this is what I heard back from Doug Crawford: > I met with our reservations team. > For your group, we'll go back to manual deposits. > Aspen Meadows will agree to the following: > Room reservations will be accepted with 1 night deposit > > Balance due 30 days prior to arrival > > Reservations made 30 days or less prior to arrival will be > charged in full. > > Standard reservations cancellations policies apply - > reservations are non refuncable less than 14 days of arrival. ^----------------sounds intriguing, but I think this is meant to say “non-refundable.” ;-) Cheers, -- Dave Abrahams Meet me at BoostCon: http://www.boostcon.com BoostPro Computing http://www.boostpro.com

1 0

Can Boost accept libraries that works only with C++0x compilers?
by vicente.botet 18 May '10

18 May '10

Hi, Boost has a high reputation due, between others, to having high portable libraries. I was wondering if this portability goal would not return against Boost, and limit the expressivenes of the libraries that can be included if we continue to force them to work with C++98 compilers. Even if C++0x is not yet released, there are already some compilers that allow to release these C++0X specific libraries. In order to have the best of both worlds, what do you think about start accepting libraries that are portable on C++0x compilers? This could be released as a separated package, that will, of course, depend on the current Boost package. I don't know if we need a specific namespace for these kind of libraries. Comments are welcome. Best, Vicente

7 11

Re: [boost] [contract] Boost spoiled function declarations
by Andrzej Krzemienski 18 May '10

18 May '10

> See examples below: Is Boost.Contract parenthesized syntax really more > complex than Boost.Parameter or Boost.Interface? > 1) While I recognize the ugliness of the Boost.Contract parenthesized > syntax, I think it is actually simpler than Boost.Parameter or > Boost.Interface syntax because it is essentially "the usual C++ syntax > with all the tokens wrapped within parenthesis". > 2) It is possible to provide Boost.Contract with macros similar to > ones of Boost.Parameter. Hi, I think you are succesfully making the point that Boost.Contract syntax is no worse than that of Boost.Parameter; and since the latter made it into Boost, the syntax of Boost.Contract should be considered acceptable too. What is interesting is whether it is possible to define a function that validates contracts and allows named parameters at the same time. You already said it was possible. I paste an example from your post below. struct g { CONTRACT_CLASS( (g) ) BOOST_PARAMETER_MEMBER_FUNCTION( (void), depth_first_search, tag, (required (graph, *) ) (optional (visitor, *, boost::dfs_visitor<>()) (root_vertex, *, *vertices(graph).first) (index_map, *, get(boost::vertex_index, graph)) (in_out(color_map), *, default_color_map(num_verticies(graph), index_map)) ) ) CONTRACT_FUNCTION( (public) (template)( (typename)(graph_type) (typename)(visitor_type) (typename)(root_vertex_type) (typename)(index_map_type) (typename)(color_map_type) ) (void) (depth_firt_search)( (graph_type&)(graph) (visitor_type&)(visitor) (root_vertex_type&)(root_vertex) (index_map_type&)(index_map) (copyable)(color_map_type&)(color_map) ) (postcondition) ({ CONTRACT_ASSERT( color_map == CONTRACT_OLDOF(color_map) + 10 ); }) (body) ({ color_map += 10; std::cout << "graph=" << graph << std::endl; std::cout << "visitor=" << visitor << std::endl; std::cout << "root_vertex=" << root_vertex << std::endl; std::cout << "index_map=" << index_map << std::endl; std::cout << "color_map=" << color_map << std::endl; }) ) }; This example is for sure more complex than any Boost.Parameter or Boost.Contract. I believe it should be possible to add another set of macros that would allow defining functions with named parameters and contract verification in a more simpler manner. E.g. something like: struct g { CONTRACT_CLASS( (g) ) CONTRACT_NAMED_PARAM_FUNCTION( // a new macro (public) (void) (depth_firt_search)( (CONTRACT_NAMED_PARAM_REQUIRED_ARG(&graph) CONTRACT_NAMED_PARAM_OPTIONAL_ARG(&visitor)(boost::dfs_visitor<>()) CONTRACT_NAMED_PARAM_OPTIONAL_ARG(&root_vertex)(*vertices(graph).first) CONTRACT_NAMED_PARAM_OPTIONAL_ARG(&index_map)(get(boost::vertex_index, graph)) CONTRACT_NAMED_PARAM_OPTIONAL_ARG(copyable)(color_map_type&)(color_map) (default_color_map(num_verticies(graph), index_map)) ) (postcondition) ({ CONTRACT_ASSERT( color_map == CONTRACT_OLDOF(color_map) + 10 ); }) (body) ({ color_map += 10; std::cout << "graph=" << graph << std::endl; std::cout << "visitor=" << visitor << std::endl; std::cout << "root_vertex=" << root_vertex << std::endl; std::cout << "index_map=" << index_map << std::endl; std::cout << "color_map=" << color_map << std::endl; }) ) }; Obviously, my example is syntactically wrong and may be impossible, but I think you get the general idea. I am not sure if it is Boost's requirement that different libraries should interoperate smoothly with one another, but it would surely be elegant. I am not sure if this is achievable, as the macro tricks employed in the above libraries are beyond my comprehension. Also, it is not clear whether it should be a task for Boost.Contract maintainer or Boost.Parameter maintainer - the issue seems symmetrical. Regards, &rzej

3 4

[MSM] move to trunk
by Christophe Henry 18 May '10

18 May '10

>Hello Christophe - > >I hope you had an uneventful trip home after boostcon. > >I am starting to use MSM 2.1 this week in a project. I have gotten the >tarball from the sandbox; however, it would be convenient to use the >library from the svn trunk so I can monitor changes before release. Do >you have a time line for checking in the library to trunk? > >Thank you for your time. Take care - >michael Hi Michael, I'm a bit jetlagged but (luckily) had an uneventfull trip back. And the BoostCon was worth it! I plan to check in into the trunk in the next few weeks, I really want MSM to be in 1.44. I only need to write some unit tests so it should be pretty quick. I'll post a mail as soon as I'm done. Cheers, Christophe

2 1

[shared_ptr] enable_shared_from_any ?
by Philip Warner 18 May '10

18 May '10

Many apologies if this has already been debated and discarded, but I have been using boost for a little while now, and most specifically boost::shared_ptr. I recently found enable_shared_from_this{2} and, in SVN, enable_shared_from_raw, and while both of these are extremely useful, ISTM they do not go quite far enough. Specifically, what I would like to see is a solution to the following code: C1 *p = new C1(); shared_ptr<C1> ptr(p); ... ...some time later.... shared_ptr<C1> ptr2<p>; and the resulting mess because of double-deallocation. Yes, one solution id discipline, but for a library developer, a better solution might be robustness in the face of (mild) ignorance or misuse. And yes, this is sloppy, but in our case we have a set of interfaces that want to implement variant function return types based on derived class pointers, and we can not do that by returning shared_ptr objects. We need to return raw pointers, then rewrap them. One solution is shared_from_this etc. Another is to extend shared_from_this so that *any* shared_ptr created from and object that inherits, say, enable_shared_from_any, will always get a shared pointer that works as one might expect. To this end we have built a (trivial) class that inherits from shared_ptr<T> and a matching base class, that together function to achieve what we need. The only real problem is we have to duplicate some parts of shared_ptr (constructors and operators mainly), the second problem is that not being experts in the very fine details of templates, boost, and cross-platform development, it would be extremely convenient if this functionality were implemented within shred_ptr in a similar way to the way enable_shared_from_this is done -- ie. only for those classes that implement an appropriate base class. The third problem is that because it does not have access to shared_ptr internals, it is not as efficient as it might be. Is submitting a patch to shared_ptr the appropriate way forward? Has this been discussed, debated and discarded before? If there is interest I am very happy to submit a patch, and I would also welcome any pointers (no pun intended) as to where the disadvantages and advantages of this kind of approach have been discussed before.

4 7

A Remedy for the Review Manager Starvation
by Joachim Faulhaber 18 May '10

18 May '10

Dear list, at boostcon (which was awesome :) we talked about the "review manager starvation" that boost is suffering from. I have offered a proposal on this topic, which seemed to have found a good acceptance at Tuesday evening's session. I'd like to share this proposal on the list now, in order to develop a more concrete policy, based on the proposal and its discussion. Where does the motivation come from? There is a huge amount of motivation in the "boost process". People really work their butts off. But this motivation is not everywhere in "boost world". Obviously it is lacking in the field of being a review manager. The motivation is mostly in the field of developing and contributing high quality generic libraries: Being a boost contributor. * People have a general desire to contribute something useful. * Boost contributors generally are passionate about generic library development. * Boost as a high quality library collection is THE platform for a contributor to place its contribution. * The boost community and list is an opportunity to learn from an elite in the field of generic library programming. * The formal review is both a reality test of the quality of a contribution and an acknowledgement by the experts. * The motivation to get into boost is caused by its high standards, because it makes boost attractive. * This in turn motivates not everyone, but those who are passionate about high quality generic programming. Boost is like a beautiful woman that is not easy to win. And this is a good thing. Let's be honest: Being accepted into boost and winning a beautiful woman has this in common: It extends our ego for a large part. (Whether this is always wise is another story ... but that's where we're after). So this is my suggestion: (1) Let's increase the standards: Let's make it more difficult for a library to be accepted into boost. (2) Let's create a new role: The Review Manager Assistant (RMA), who does almost all the work that is needed to manage a formal review. (3) To take on the job as a review manager assistant will be a precondition for a contributor to submit his own library. So we are making the contributors lives even harder with this... We should give them something on "the other side of the coin": (4) Let's foster a general culture of acknowledgement in boost. (5) Contribution must not be discouraged by inaction. (6) Contribution to boost is a win win game: Even if a library is not accepted there will be a value for the contributor and the boost community. To make this more concrete: (ad 1) Standards: The list of standards that a library submitted for review has to fulfill should be very clear, so the contributor can prepare his lib using that check list *and* the RMA can check the submission thoroughly. This list should be more explicit and more transparent than what we have now: To fulfill the list of requirements for a submission which is checked by the RMA is then the first certifiable standard of quality that a library can obtain in the review process. Included in the list of requirement for first time contributors should be: (1.1) 2 previews on the boost mailing list OR 1 boostcon presentation with a sufficient feedback of interest from the community (1.2) Issuing reviews for 2 formal reviews of other contributors. (1.3) Being RMA for another library once. (ad 2) A Review Manager Assistant (RMA) ... (2.1) does all the work that is necessary to check a library submission, organizes the process, moderates and files a final report, (2.2) unburdens the review manager from all kinds of detail work, except for the final verdict. (2.3) rejects the library submission, if it not yet fulfills all requirements. An RMA will probably be highly motivated, because he learns all about the standards and the review process that helps him for his own library project. (ad 5) An RMA is not necessarily needed for a review. If no RMA is found the review manager can do the job himself (current procedure). If an RMA volunteers he can start to organizing the review process. He checks the lib and requests a review manager, if necessary. If no one steps forward, the RMA starts the review process, which can not be halted by mere inaction. Any acceptable review manager can take that role. If no one takes action, the review is managed by the RMA. The RMA files the final report on the review within 2 weeks after it ends. The RM declares the result within 4 weeks after the review on the basis of the RMA's summary. (ad 6) Based on the high standards that are checked rigorously by the RMA a library submitted to boost gets certified as "conforms boost standards" or similar, even if it fails to be accepted into boost. In addition to the accepted boost libraries, there will be a collection of associated libraries (boost friends) that can be listed on a web page and that officially are allowed to use some logo that informs about the certified state. (ad 4) This is a form of acknowledgement for those who took on the project of a boost contribution but didn't make it into the core collection and to make them friends or associates of boost rather than "boost losers". So this is my proposal. I wanted to post this on the list because it is a result of this years boostcon and also the topic is kind of urgent. On the other hand you can not expect me to participate very much in this discussion for the next week, because I am on vacations. I'm looking forward to your thoughts and I will be back next week. Cheers Joachim P.S.: BoostCon was really great this year! Lot's of interesting talks and the sessions that addressed topics of the boost community were quite inspiring and creative. Not to mention the picnic and jam session (very enjoyable despite cold weather).

11 28

safe bool operator
by Domagoj Saric 18 May '10

18 May '10

While examining source and binary code for the various safe_bool/unspecified_bool_type implementations two issues can be noticed: - source code verbosity/repetition - binary code inefficiency The first issue is made worse by the fact that even this simple idiom is broken on some compilers ('pointed out' by workarounds in smart_ptr/detail/operator_bool.hpp) so workarounds must also be copied/'rediscovered'... The second issue (related to the usual implementation with member function pointers) has two sides, one is that taking the address of a function will force it to be included in the resulting binary even if it is never used or is always inlined and the second is that some compilers produce non-optimal code. For example for the following source code: boost::optional<int> test1; boost::optional<int> test2; __declspec( noinline ) void func() { if ( test1 ) test2 = *test1; } MSVC++ 8.0 and 9.0 will produce the following binary code ... 0F923A26 movzx eax,byte ptr [test1 (0F968210h)] 0F923A2D neg eax 0F923A2F sbb eax,eax 0F923A31 test eax,offset boost::optional_detail::optional_base<int>::is_initialized (0F923B9Eh) 0F923A36 je ... ... but if the if line is changed to if ( test1.is_initialized() ) the following code will be produced: ... 0F923A26 cmp byte ptr [test1 (0F968210h)],0 0F923A2D je ... ... At first I tried a solution that takes advantage of the fact that MSVC++ has plain-pointer-sized/register-sized member function pointers for plain single inheritance non virtual member functions and worked properly but than I found old discussions about the same subject: http://lists.boost.org/Archives/boost/2003/09/52846.php http://lists.boost.org/Archives/boost/2002/10/38624.php where the solution for MSVC++ was to use a pointer member data which gives the same results as my initial solution... Anyways I've attached a .hpp file with a draft implementation proposal (missing the compiler workarounds from smart_ptr/smart_ptr/detail/operator_bool.hpp for example) that uses both approaches... It enables a one liner implementation for a safe_bool operator: class my_class { public: bool some_is_valid_function() const; operator boost::unspecified_bool_type() const { return boost::make_safe_bool( some_is_valid_function() ); } //or by using a macro BOOST_SAFE_BOOL_FROM_FUNCTION( some_is_valid_function() ) } -- "What Huxley teaches is that in the age of advanced technology, spiritual devastation is more likely to come from an enemy with a smiling face than from one whose countenance exudes suspicion and hate." Neil Postman begin 666 safe_bool.hpp M(W!R86=M82!O;F-E#0HC:69N9&5F('-A9F5?8F]O;%]H<' -"B-D969I;F4@ M<V%F95]B;V]L7VAP< T*+R\M+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM M+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM M+2TM+2T-"B-I;F-L=61E(")M<&PO8F]O;"YH<' B#0HO+RTM+2TM+2TM+2TM M+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM M+2TM+2TM+2TM+2TM+2TM+2TM+2TM+0T*;F%M97-P86-E(&)O;W-T#0I[#0HO M+RTM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM M+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+0T*#0IN86UE<W!A M8V4@9&5T86EL#0I[#0H@(" @<W1R=6-T('5N<W!E8VEF:65D7V)O;VQ?='EP M95]H96QP97(-"B @("![#0H@(" @(" @('9O:60@;65M8F5R7V9U;F-T:6]N M*"D@>WT[#0H@(" @(" @(&EN="!M96UB97)?9&%T85\[#0H@(" @?3L-"@T* M(" @('1Y<&5D968@=F]I9" H=6YS<&5C:69I961?8F]O;%]T>7!E7VAE;'!E M<CHZ*G5N<W!E8VEF:65D7V)O;VQ?='EP95]F=6YC=&EO;BD@*"D[#0H@(" @ M='EP961E9B!I;G0@("!U;G-P96-I9FEE9%]B;V]L7W1Y<&5?:&5L<&5R.CHJ M=6YS<&5C:69I961?8F]O;%]T>7!E7V1A=&$@(" @(" @(#L-"@T*(" @('5N M:6]N(&9A<W1?<V%F95]B;V]L#0H@(" @>PT*(" @(" @("!U;G-I9VYE9"!L M;VYG(" @(" @(" @(" @(" @(" @<&QA:6Y?<&]I;G1E<E]P;&%C96AO;&1E M<CL-"B @(" @(" @=6YS<&5C:69I961?8F]O;%]T>7!E7V9U;F-T:6]N('!O M:6YT97)?=&]?;65M8F5R(" @(" @(" [#0H@(" @?3L-"@T*(" @("\O(" @ M270@:7,@87-S=6UE9"!T:&%T(&EF('1H92!C;VUP:6QE<B!I<R!A8FQE('1O M(&9I="!A('!L86EN+"!S:6YG;&4-"B @(" O+R!I;FAE<FET86YC92!M96UB M97(@9G5N8W1I;VX@<&]I;G1E<B!I;G1O('-I>F5O9B@@=F]I9" J("D@=&AA M="!I=',@;G5L; T*(" @("\O(&)I;F%R>2!R97!R97-E;G1A=&EO;B!I<R!I M9&5N=&EC86P@=&\@82!P;&%I;B!N=6QL('9O:60@<&]I;G1E<B H86QL(&)I M=',-"B @(" O+R!Z97)O960I+B!7:71H;W5T(&$@=V%Y('1O(&-H96-K('1H M:7,@870@8V]M<&EL92!T:6UE('1H:7,@87-S97)T960@870-"B @(" O+R!R M=6YT:6UE+@T*(" @("\O(" @5&AE(&%B;W9E(&YE960@;F]T(&AO;&0@9F]R M(&1A=&$@;65M8F5R('!O:6YT97)S("AE+F<N($U35D,K*R!U<V5S("TQ#0H@ M(" @+R\@9F]R(&YU;&PM9&%T82!M96UB97(@<&]I;G1E<G,I+@T*(" @('1Y M<&5D968(a);7!L.CIB;V]L7SPH('-I>F5O9B@@9F%S=%]S869E7V)O;VP@*2 \ M/2!S:7IE;V8H('5N<VEG;F5D(&QO;F<@*2 I/B!C86Y?=7-E7V9A<W1?8F]O M;%]H86-K.PT*#0H@(" @='EP961E9B!M<&PZ.FEF7PT*(" @(" @(" @(" @ M/ T*(" @(" @(" @(" @(" @(&-A;E]U<V5?9F%S=%]B;V]L7VAA8VLL#0H@ M(" @(" @(" @(" @(" @=6YS<&5C:69I961?8F]O;%]T>7!E7V9U;F-T:6]N M+ T*(" @(" @(" @(" @(" @('5N<W!E8VEF:65D7V)O;VQ?='EP95]D871A M#0H@(" @(" @(" @(" ^.CIT>7!E('5N<W!E8VEF:65D7V)O;VQ?='EP93L- M"@T*(" @(&EN;&EN90T*(" @('5N<W!E8VEF:65D7V)O;VQ?='EP92!M86ME M7W-A9F5?8F]O;%]W;W)K97(H(&)O;VP@8V]N<W0@=F%L=64L(&UP;#HZ=')U M95\@+RIU<V4@9F%S="UH86-K('9E<G-I;VXJ+R I#0H@(" @>PT*(" @(" @ M("!F87-T7W-A9F5?8F]O;"!C;VYS="!F87-T4V%F94)O;VP@/2![('9A;'5E M('T[#0H@(" @(" @(&%S<V5R= T*(" @(" @(" H#0H@(" @(" @(" @(" H M("$A9F%S=%-A9F5";V]L+G!O:6YT97)?=&]?;65M8F5R(#T]("$A=F%L=64@ M*2 F)@T*(" @(" @(" @(" @(E1H92!V;VED+7!O:6YT97(M<VEZ960@;65M M8F5R('!O:6YT97(@;G5L;"!B:6YA<GDB#0H@(" @(" @(" @(" B<F5P<F5S M96YT871I;VX@87-S=6UP=&EO;B!D;V5S(&YO="!H;VQD(&9O<B!T:&ES(@T* M(" @(" @(" @(" @(F-O;7!I;&5R+W!L871F;W)M+B(-"B @(" @(" @*3L- M"B @(" @(" @<F5T=7)N(&9A<W13869E0F]O;"YP;VEN=&5R7W1O7VUE;6)E M<CL-"B @("!]#0H-"B @("!I;FQI;F4-"B @("!U;G-P96-I9FEE9%]B;V]L M7W1Y<&5?9G5N8W1I;VX-"B @("!M86ME7W-A9F5?8F]O;%]S=&%N9&%R9%]W M;W)K97(H(&)O;VP@8V]N<W0@8F]O;%]V86QU92P@=6YS<&5C:69I961?8F]O M;%]T>7!E7V9U;F-T:6]N(&-O;G-T(&YU;&Q?=F%L=64@*0T*(" @('L-"B @ M(" @(" @<F5T=7)N(&)O;VQ?=F%L=64@/R F=6YS<&5C:69I961?8F]O;%]T M>7!E7VAE;'!E<CHZ;65M8F5R7V9U;F-T:6]N(#H@;G5L;%]V86QU93L-"B @ M("!]#0H@(" @:6YL:6YE#0H@(" @=6YS<&5C:69I961?8F]O;%]T>7!E7V1A M=&$-"B @("!M86ME7W-A9F5?8F]O;%]S=&%N9&%R9%]W;W)K97(H(&)O;VP@ M8V]N<W0@8F]O;%]V86QU92P@=6YS<&5C:69I961?8F]O;%]T>7!E7V1A=&$@ M(" @(&-O;G-T(&YU;&Q?=F%L=64@*0T*(" @('L-"B @(" @(" @<F5T=7)N M(&)O;VQ?=F%L=64@/R F=6YS<&5C:69I961?8F]O;%]T>7!E7VAE;'!E<CHZ M;65M8F5R7V1A=&%?(" @(#H@;G5L;%]V86QU93L-"B @("!]#0H-"B @("!I M;FQI;F4-"B @("!U;G-P96-I9FEE9%]B;V]L7W1Y<&4@;6%K95]S869E7V)O M;VQ?=V]R:V5R*"!B;V]L(&-O;G-T('9A;'5E+"!M<&PZ.F9A;'-E7R O*G5S M92!S=&%N9&%R9"!V97)S:6]N*B\@*0T*(" @('L-"B @(" @(" @<F5T=7)N M(&UA:V5?<V%F95]B;V]L7W-T86YD87)D7W=O<FME<B@@=F%L=64L('5N<W!E M8VEF:65D7V)O;VQ?='EP92@@," I("D[#0H@(" @?0T*?2 O+R!N86UE<W!A M8V4@9&5T86EL#0H-"@T*='EP961E9B!D971A:6PZ.G5N<W!E8VEF:65D7V)O M;VQ?='EP92!U;G-P96-I9FEE9%]B;V]L7W1Y<&4[#0H-"@T*:6YL:6YE#0IU M;G-P96-I9FEE9%]B;V]L7W1Y<&4@;6%K95]S869E7V)O;VPH(&)O;VP@8V]N M<W0@=F%L=64@*0T*>PT*(" @(')E='5R;B!D971A:6PZ.FUA:V5?<V%F95]B M;V]L7W=O<FME<B@@=F%L=64L(&1E=&%I;#HZ8V%N7W5S95]F87-T7V)O;VQ? M:&%C:R@I("D[#0I]#0H-"B\O($EF('=E(&-O=6QD('5S92!M96UB97(@<&]I M;G1E<G,@8F5F;W)E('1H92!M96UB97(@:7,@86-T=6%L;'D@9&5C;&%R960O M<V5E;@T*+R\@=V4@8V]U;&0@=7-E($-25% M8F%S960@:&5L<&5R(&-L87-S M97,@9F]R(&UI;FEM=6T@=F5R8F]S:71Y('-A9F5?8F]O; T*+R\@:6UP;&5M M96YT871I;VYS.@T*+R\@=&5M<&QA=&4@/&-L87-S($)A<V4L(&)O;VP@*$)A M<V4Z.BIB;V]L7V9U;F-T:6]N*2 H*2!C;VYS=#X-"B\O(&-L87-S('-A9F5? M8F]O; T*+R\@>PT*+R\@(" @(&]P97)A=&]R('5N<W!E8VEF:65D7V)O;VQ? M='EP92@I(&-O;G-T('L@<F5T=7)N(&UA:V5?<V%F95]B;V]L*"!S=&%T:6-? M8V%S=#Q"87-E(&-O;G-T("H^*"!T:&ES("DM/BIB;V]L7V9U;F-T:6]N*"D@ M*3L@?0T*+R\@?3L-"B\O#0HO+R!C;&%S<R!M>5]C;&%S<R Z('!U8FQI8R!S M869E7V)O;VP\;7E?8VQA<W,L("9M>5]C;&%S<SHZ=F%L:60^#0HO+RXN+@T* M#0HO+RXN+FEN<W1E860@=V4@87)E(&QE9G0@=VET:"!M86-R;W,N+BX-"B-D M969I;F4@0D]/4U1?4T%&15]"3T],7T923TU?1E5.0U1)3TXH(&-O;G-T365M M8F5R1G5N8W1I;VX@*2!<#0H@(" @;W!E<F%T;W(@8F]O<W0Z.G5N<W!E8VEF M:65D7V)O;VQ?='EP92@I(&-O;G-T('L@<F5T=7)N(&)O;W-T.CIM86ME7W-A M9F5?8F]O;"@@8V]N<W1-96UB97)&=6YC=&EO;B@I("D[('T-"@T*(V1E9FEN M92!"3T]35%]3049%7T)/3TQ?1E)/35]$051!*" @(" @8V]N<W1-96UB97)$ M871A(" @(" I(%P-"B @("!O<&5R871O<B!B;V]S=#HZ=6YS<&5C:69I961? M8F]O;%]T>7!E*"D@8V]N<W0@>R!R971U<FX@8F]O<W0Z.FUA:V5?<V%F95]B M;V]L*"!C;VYS=$UE;6)E<D1A=&$@(" @(" @*3L@?0T*#0H-"B\O+2TM+2TM M+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM M+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM#0I]("\O(&YA;65S<&%C92!B M;V]S= T*+R\M+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM M+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2T-"B-E 7;F1I9B O+R!S869E7V)O;VQ?:'!P#0H` ` end

7 9

Library for base64
by deninok 18 May '10

18 May '10

Hi all! Is there any interest in a library for base64 encoding? Something like this: int main() { base64_encoder encode; std::string pure = "Hello world!"; std::string enc; encode( pure, enc ); // In enc: SGVsbG8gd29ybGQh ... } Library uses boost::dynamic_bitset. Denis -- View this message in context: http://old.nabble.com/Library-for-base64-tp28561821p28561821.html Sent from the Boost - Dev mailing list archive at Nabble.com.

8 10

[iterator] why isn't there a mapped_type iterator adaptor in boost?
by Mostafa 18 May '10

18 May '10

Hi all, Why isn't there a mapped_type/key_type iterator adaptor in boost? (Just in case it's not clear, something which allow one to iterator over the keys or the mapped-values of a map/multimap.) I would think this is a pretty common need. By the way, going through the archives this is all I could dig up: http://thread.gmane.org/gmane.comp.lib.boost.devel/117946 Additionaly something with a clearer syntax than the following would be great: make_transform_iterator( map.begin(), boost::bind( &MAP_TYPE::value_type::first, _1 )) ie, something along the lines of: take_mapped_type(map.begin()) Thanks, -Mostafa

6 13

[BGL] All-pair problem on a subset of vertices
by Cosimo Calabrese 18 May '10

18 May '10

Hi to all, if we want to find the shortest distance between *every* pair of vertices in a graph, we can use the Jonson's or Floyd-Warshall's algorithm, obtaining a NxN matrix of distances, where N is the total number of the graph's vertices. The problem is: how can I do if I don't need the distance of *every* pair of graph's vertices, but I'm interested in only a subset of vertices? In other words, I would to obtain a MxM matrix, where M<N. In every case, I'm not interested in path from the pairs, but only in the distance. My solution is to execute M times the Dijkstra algorithm from every vertex of the subset, and to abort every exploration when I've founded the Mth vertex of the subset. Are there something of more efficent? My graphs contain approximately 12 millions of vertices, but I'm interested in a subset of 10.000 vertices. Thanks in advance, Cosimo Calabrese.

2 2

[Boost][Thread] Non-copyable boost::thread
by Belcourt, Kenneth 18 May '10

18 May '10

Hi, The Boost.Thread documentation points out that boost::thread is non- copyable but then goes on to provide rational for why it should be possible to return by value from make_thread_return_local(). Intel-11.1 on Darwin is a recent compiler that will not compile this code. [ from libs/thread/test/test_thread_return_local.cpp ] boost::thread make_thread_return_local(boost::thread::id* the_id) { boost::thread t(do_nothing,the_id); return t; } The same error message is generated in both debug and release builds on Darwin (though strangely it doesn't appear to be an error with Intel 11.1 on Linux). "/opt/intel/Compiler/11.1/067/bin/intel64/icpc" -xc++ -w1 -O0 -g - inline-level=0 -vec-report0 -DBOOST_ALL_NO_LIB=1 - DBOOST_TEST_NO_AUTO_LINK=1 -DBOOST_THREAD_POSIX - DBOOST_THREAD_USE_LIB=1 -I".." -c -o "/Volumes/Scratch/kbelco/boost/ results/boost/bin.v2/libs/thread/test/ test_thread_return_local_lib.test/intel-darwin-11.1/debug/threading- multi/test_thread_return_local.o" "../libs/thread/test/ test_thread_return_local.cpp" ../libs/thread/test/test_thread_return_local.cpp(16): error #373: "boost::thread::thread(boost::thread &)" (declared at line 111 of "../ boost/thread/detail/thread.hpp") is inaccessible return t; ^ Any ideas how to work around this failure? Thanks. -- Noel

3 10

feenablexcept doesn't exist on Darwin
by Christopher Jefferson 17 May '10

17 May '10

boost::test recently started using feenableexcept, which is not supported on Darwin / Apple. See https://svn.boost.org/trac/boost/ticket/4222 for patch. This bug is particularly annoying as it is causing many failures, as the problem is in the testing code.

3 2

Visual Studio 2010 Template Limits
by Daniel Larimer 17 May '10

17 May '10

I have written some code that makes heavy use of templates and which compiles just fine using g++; however, when I recently tried to compile the code in VC++ 2010 I got a fatal error C1063: compiler limit : compiler stack overflow. It directs me to this template... See reference to class template instantiation 'delegate<T1>::overloads<1,S0,ptr0>' being compiled The general code structure is... template<T1> class delegate { template<typename RTN, typename TY PARAM_TNS, RTN (TY::*m_ptr)(PARAM_PTS)> class method_impl<RTN (TY::*)(PARAM_PTS), m_ptr> : public method; // specialized for n with BOOST_PP_ITERATE (blows up even if n == 1) template<int, typename S0, S0 ptr0> class overloads<n, PARAM_TYPES> : public method_impl<S0,ptr0>, public method_impl<S1,ptr1> ... { }; }; I don¹t even need to instantiate delegate<ForSomeType>, simply including the header causes it to blow up. Considering the extent to which boost uses and ³abuses² templates I thought I would ask whether anyone here knows of some limitation or constructs which I must avoid? Is there some way to increase the ³stack² for VC++¹s CL program? Dan

2 1

[contract] Boost spoiled function declarations
by Lorenzo Caminiti 17 May '10

17 May '10

Hello all, I have been looking into other Boost libraries besides my Boost.Contract that spoil function declarations using macros. I found that both Boost.Parameter (approved) and Boost.Interface (under construction) significantly spoil function declarations. Boost.ConceptCheck also spoils function declarations but its REQUIRE macro has a very simple syntax so I am not comparing it with Boost.Contract. See examples below: Is Boost.Contract parenthesized syntax really more complex than Boost.Parameter or Boost.Interface? Boost.Contract (under construction) BOOST_CONTRACT_FUNCTION( (inline) (double) (sqrt)( (double)(x) ) (precondition)( (x >= 0.0) ) (postcondition)(result)( (result == x * x) ) ({ ... }) ) Note that the usual C++ syntax would have been essentially the same as above but without the extra parenthesis `()`. Boost.Parameter (approved) BOOST_PARAMETER_FUNCTION( (void), depth_first_search, tag, (required (graph, *) ) (optional (visitor, *, boost::dfs_visitor<>()) (root_vertex, *, *vertices(graph).first) (index_map, *, get(boost::vertex_index,graph)) (in_out(color_map), *, default_color_map(num_vertices(graph), index_map) ) ) ) { ... } Boost.Interface (under construction) BOOST_INTERFACE_BEGIN(IShape) BOOST_INTERFACE_CONST_FUNCTION0(GetX, int) BOOST_INTERFACE_CONST_FUNCTION0(GetY, int) BOOST_INTERFACE_CONST_FUNCTION0(GetArea, double) BOOST_INTERFACE_FUNCTION2(SetXY, void, (int, x), (int, y)) BOOST_INTERFACE_FUNCTION2(OffSetXY, void, (int, x), (int, y)) BOOST_INTERFACE_CONST_FUNCTION0(GetName, const char*) BOOST_INTERFACE_END(IShape) 1) While I recognize the ugliness of the Boost.Contract parenthesized syntax, I think it is actually simpler than Boost.Parameter or Boost.Interface syntax because it is essentially "the usual C++ syntax with all the tokens wrapped within parenthesis". 2) It is possible to provide Boost.Contract with macros similar to ones of Boost.Parameter. However, Boost.Parameter only supports const/non-const members while Boost.Contract also supports volatile, virtual, inline/extern, auto/register, function templates, and everything else. If specific macros were to be provided for all these different function traits plus their combinations, Boost.Contract will have a *lot* of macros. For example, just to support qv-qualifiers, Boost.Contract should provide CONTRACT_FUNCTION(), CONTRACT_FUNCTION_CONST(), CONTRACT_FUNCTION_VOLATILE(), CONTRACT_FUNCTION_CONST_VOLATILE(). Plus all these qv-qualifier macros will have to be combined with inline, virtual, etc -- the number of macros grows combinatorially in the number of function traits! Instead the parenthesized syntax allows you to specify or omit the function traits directly in the function declarations so all the traits can be combined as usual in C++ and with the use of one single macro CONTRACT_FUNCTION(). Regards, -- Lorenzo

1 0

[MSM] move to trunk
by Michael Caisse 17 May '10

17 May '10

Hello Christophe - I hope you had an uneventful trip home after boostcon. I am starting to use MSM 2.1 this week in a project. I have gotten the tarball from the sandbox; however, it would be convenient to use the library from the svn trunk so I can monitor changes before release. Do you have a time line for checking in the library to trunk? Thank you for your time. Take care - michael -- ---------------------------------- Michael Caisse Object Modeling Designs www.objectmodelingdesigns.com

1 0

Namespace for a Boost Hashing Library
by Scott McMurray 17 May '10

17 May '10

I initially used boost::hash, forgetting that the unordered containers have already claimed that name. A number of alternatives have been proposed, so I hoped to get some thoughts from the wider community. The intention for the library is to provide concepts and some implementations for checksums (like CRC32), plain hash functions (for hash tables), and cryptographic hash functions (like MD5 or SHA-256). Some possibilities: - boost::hashes Following the usual boost method of a plural namespace when a class exists. - boost::hash_algo or boost::hash_algorithms Following the string_algo precedent. - boost::hashing or boost::hashing_algorithms Using a gerund for a change. - boost::digests or boost::message_digest Using the name of the result of a hash, rather than the process. - boost::fingerprint (or boost::dactylogram) An alternative name for the result of a hash. - Something else better that you come up with Some complaints raised about those options: - boost::hashes or boost::hashing or boost::digests It's hard to remember when namespaces aren't singular as usual (especially for the first two, when the library doesn't provide anything named "hash"). - boost::hash_algo It would be better to not use an abbrev. - boost::hash_algorithms or boost::hashing_algorithms or boost::message_digest Shorter namespaces are generally preferred, where possible. - boost::fingerprint (or boost::dactylogram) Implies a particular use and certain minimum length of result. Which one(s) do you prefer or dislike? Thanks, ~ Scott McMurray

10 15

www.boost.org: update link to boost Jam 3.1.18 instead of 3.1.17?
by Wolfgang Fertsak 17 May '10

17 May '10

Hi, I just noticed that the link to Boost Jam in the download-section in www.boost.org still points to Version 3.1.17, although 3.1.18 is available since march... Best regards, Wolfgang

1 0

[Boost.Thread] Patch for Intel on Darwin
by Belcourt, Kenneth 17 May '10

17 May '10

Hi, The thread library is failing to build with Intel on Darwin with this error. "/opt/intel/Compiler/11.1/067/bin/intel64/icpc" -xc++ -w1 -O0 -g - inline-level=0 -vec-report0 -DBOOST_ALL_NO_LIB=1 - DBOOST_THREAD_BUILD_DLL=1 -DBOOST_THREAD_POSIX -I".." -c -o "/Volumes/ Scratch/kbelco/boost/results/boost/bin.v2/libs/thread/build/intel- darwin-11.1/debug/threading-multi/pthread/thread.o" "../libs/thread/ src/pthread/thread.cpp" ../libs/thread/src/pthread/thread.cpp(385): error: identifier "get_nprocs" is undefined return get_nprocs(); ^ The fix is to test for Apple and Intel before the GNU test. Index: libs/thread/src/pthread/thread.cpp =================================================================== --- libs/thread/src/pthread/thread.cpp (revision 61969) +++ libs/thread/src/pthread/thread.cpp (working copy) @@ -381,6 +381,10 @@ { #if defined(PTW32_VERSION) || defined(__hpux) return pthread_num_processors_np(); +#elif defined(__APPLE__) && defined (__INTEL_COMPILER) + int count; + size_t size=sizeof(count); + return sysctlbyname("hw.ncpu",&count,&size,NULL,0)?0:count; #elif defined(_GNU_SOURCE) return get_nprocs(); #elif defined(__APPLE__) || defined(__FreeBSD__) This has been tested on Darwin and Linux. Okay to commit? -- Noel

2 1

[website] [1.43.0] broken link
by Mostafa 17 May '10

17 May '10

FYI, The following webpage: http://www.boost.org/doc/libs/1_43_0/libs/range/doc/html/range/reference.ht… has a broken link at the "Overview" section, ie, http://www.boost.org/doc/libs/1_43_0/libs/range/doc/html/range/reference/ov… -Mostafa

3 3

Re: [boost] New moderators request unclear? (was: A Remedy for the Review Manager Starvation)
by Thomas Klimpel 17 May '10

17 May '10

Manfred Doudar wrote: > And now, I think a little more about Joachim's mail, and the stated > reception his ideas had at BoostCon (no, I wasn't there - but take > Joachim on his word); and now also recall Beman's email of a while > back, asking for persons to come forward and nominate themselves to > moderate the list - because: Oh, maybe I completely misunderstood Beman's request then. I'm not a native speaker, but I even looked up "nominate" at <http://dict.leo.org>. It seems to mean something like "to elect somebody". (I had looked it up, because it was unclear to me whether "nomination" includes asking the person for permission first.) But as you put it, it seems to mean something like "to volunteer". > "[existing moderators'] day job responsibilities have changed, or > other distractions are preventing them from giving list moderation > the attention it deserves." > > ..this makes me think that there is a call of sorts for "new-blood", > because some boosters are moving on, in some respects (not > necessarily entirely, but other responsibilities keep them away, and > they may not be able to devote as much time as they once did, be it > moderation or otherwise). I wasn't sure here whether Beman was explicitly asking for new blood, or just formulating his request in a way that it was clear that new blood was also allowed. But if somebody would nominate Eric Niebler, Daniel James, Rene Rivera, Hartmut Kaiser, Vladimir Prus, Robert Ramey, Gennadiy Rozental, Joel de Guzman or any other of the usual suspect, I'm pretty sure that Beman wouldn't object. So if I understood Beman's request correctly, he is still waiting for additional nominations. If I understood him incorrectly, and he is just waiting for volunteers, I think he should add a clarification to his request that is also understandable for non-native speakers (that are unaware of the connotations of the word "nomination", if these connotations should really exist). Regards, Thomas

3 2

[test] New location of fraction_tolerance()
by Jeremiah Willcock 16 May '10

16 May '10

There used to be a function named fraction_tolerance() in boost::test_tools (in <boost/test/floating_point_comparison.hpp>) that marked that a floating-point comparison uses a fraction as its tolerance value. That function seems to have disappeared in one of the recent checkins. What is the intended replacement? There is no boost::math::fpc::fraction_tolerance which is what appears from the new naming pattern to be the correct name. Is there an equivalent to that function? -- Jeremiah Willcock

2 1

[contract] static assertions
by Lorenzo Caminiti 16 May '10

16 May '10

Hello all, Shall Boost.Contract static static assertions? 1) N1962 removed static assertions previously added by revisions N1866 and N1773 of the same proposal -- why? 2) In my experience, I never used static assertions within the contracts. However, I am thinking to provide them because they might be useful to better document contract interfaces with assertions that can be efficiently evaluated at compile-time. For example: template<typename T> struct x { CONTRACT_CLASS( (x) ) public: CONTRACT_FUNCTION( (public) (void) (f)( (T)(val) ) (precondition)( (static)(sizeof(T) <= sizeof(long)) // static assertion (checked at compile-time) (val != 0) // run-time assertion ) ({ ... }) }; This code will use one of the BOOST_MPL_ASSERT() to assert the static condition in the precondition function generated by the CONTRACT_FUNCTION() macro. I think this is similar to asserting BOOST_MPL_ASSERT((sizeof(T) <= sizeof(long))) in the function body or at class scope. However, having the static assertion in the contracts has the following advantages: (+) The static assertion compilation and check can be selectively enabled/disabled when preconditions/postcondition/invariants are turned on/off using CONTRACT_CHECK_PRECONDITON/etc. (+) It more clearly documents that the (static) requirement `sizeof(T) <= sizeof(long)` is added by the function f (instead of the class or some other member function). -- Lorenzo

3 4

[fiber] new version
by Oliver Kowalke 16 May '10

16 May '10

I've uploaded a new version of boost.fiber (0.4.2) to boost-vault. The context/stack swapping is implemented in assembler for i386 and x86_64 (see documentation). Because of the limitations of boost.build you have to compile bjam with python support (see docu of boost.fiber). Please note that I plan to refactor boost.fiber into boost.continuation and boost.microthread. Oliver

3 4

[Boost'Con] Thanks for very fruitful week
by joel falcou 16 May '10

16 May '10

Hi all, again this year Boost'con was a success. I wanted to thanks everbody involved for your dedication to make this event such a wonderful place to be. See you next year -- ___________________________________________ Joel Falcou - Assistant Professor PARALL Team - LRI - Universite Paris Sud XI Tel : (+33)1 69 15 66 35

3 2

[type_traits] is_base_of<> GCC error for v1.42.0
by Lorenzo Caminiti 16 May '10

16 May '10

Hello all, The following code gives the GCC compiler error below for Boost 1.42.0 while it compiles just fine for Boost 1.34.1. Is this a bug in Boost.TypeTraits for 1.42.0? // File: b00.cpp #include <boost/type_traits.hpp> #include <iostream> struct y {}; struct x: y { static const bool v = boost::is_base_of<y, x>::value; }; int main() { std::cout << x::v << std::endl; return 0; } $ g++ -Wall -Werror b00.cpp /usr/include/boost/type_traits/is_base_and_derived.hpp: In instantiation of ‘boost::detail::is_base_and_derived_impl2<y, x>’: /usr/include/boost/type_traits/is_base_and_derived.hpp:219: instantiated from ‘const bool boost::detail::is_base_and_derived_impl<y, x>::value’ /usr/include/boost/type_traits/is_base_of.hpp:29: instantiated from ‘const bool boost::detail::is_base_of_imp<y, x>::value’ /usr/include/boost/type_traits/is_base_of.hpp:35: instantiated from ‘boost::is_base_of<y, x>’ b00.cpp:8: instantiated from here /usr/include/boost/type_traits/is_base_and_derived.hpp:145: error: invalid application of ‘sizeof’ to incomplete type ‘x’ /usr/include/boost/type_traits/is_base_and_derived.hpp:145: error: invalid application of ‘sizeof’ to incomplete type ‘boost::STATIC_ASSERTION_FAILURE<false>’ $ g++ --version g++ (GCC) 4.2.4 (Ubuntu 4.2.4-1ubuntu4) Copyright (C) 2007 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. Thank you. -- Lorenzo

3 3

[website] Dates on pages are always the current date
by Jeremiah Willcock 15 May '10

15 May '10

One issue I noticed with the Boost documentation pages is that the rendered versions always have today's date on them, regardless of which Boost version the docs are for. This means that searches for Boost libraries on Google often find pages for old versions in preference to new versions; I think that changing the "Date" header to the date of the correct Boost release would make Google prefer more up-to-date docs. Is this a change that is easy to make? -- Jeremiah Willcock

2 1

[metagraph] mpl_graph and MSM
by Gordon Woodhull 14 May '10

14 May '10

Friends, I'm pleased to announce that I'll soon be submitting mpl_graph for review. This is an implementation of the BGL concepts for compile time metaprogramming. Currently it supports incidence list, adjacency list, depth first search, and breadth first search. It is available in the sandbox under metagraph. I'll write some documentation soon; for now consult BGL's concepts, which are almost the same, just s/()/ typename <>::type/ ;-) It's pretty small - 825 lines of code so far. Standing on the shoulders of MPL... I've also provided a minimal example of running depth first search on the canonical MSM CD Player example. See sandbox/metagraph/libs/ metagraph/example/msm_adaptor.cpp Christophe, thanks for prodding me to get this out the door in your talk here at BoostCon! It sounds like we should write a connected components algorithm to get the features you are looking for, which will be easy with the right dfs visitor. Running DFS does cost in compile time. I haven't yet attempted to profile or optimize the template instantiations, and would appreciate any advice. On this example, it increases the compile time from 3.775 to 5.634 seconds on gcc 4.4. Since the metadata graph structure is lazy (you pay approximately for each graph concept that you exercise), construction of the graph is only 0.2s out of the 1.85s. Interestingly, running BFS in addition to DFS on the same graph adds less than 0.2s -- this makes sense because the big expense should be generating the mpl::maps which support vertex and edge lookup. Here is the test I ran. (I took the median time from each DFS level.) for((dfs=0;dfs<6;++dfs)); do echo; echo DFS=$dfs, 5 runs; for((i=0;i<5;++i)); do time g++ -D DO_DFS=$dfs -I ../../.. -I ~/src/MSMv2.10 -I ~/src/boost- trunk msm_adaptor.cpp -o msm_adaptor; done ; done The good news is that it takes less than 25 lines of code to turn the transition table into a graph and run DFS on it. Thanks to everyone for a truly awesome BoostCon! Gordon P.S. mpl_graph is part of a larger effort to generate patterns of objects from graph metadata. (Metagraph to me means "graph of graphs".) Would people rather I submitted mpl_graph separately, or keep it as a sublibrary of metagraph? (The full metagraph is still months or years away.) P.P.S. Gurtovoy/Abrahams, is the name OK? It's meant to emphasize that it's a simple extension of MPL into graphs.

2 2

[GIL] How do you use GIL?
by Lubomir Bourdev 14 May '10

14 May '10

If you are using GIL in your project and don’t mind being quoted, could you please email me your name, your project/company or university and any optional comments? We will be giving a tutorial for Boost.GIL at the CVPR 2010 conference in San Francisco on June 13. CVPR is an international conference in computer vision attended by many people from both industry and academia. This is an opportunity to promote the boost libraries in general. Thanks, Lubomir

1 0

Fwd: [MPI] Test Processor Counts
by Belcourt, Kenneth 14 May '10

14 May '10

Sent to the users list by mistake. Begin forwarded message: > From: "Belcourt, Kenneth" <kbelco(a)sandia.gov> > Date: May 14, 2010 11:03:23 AM MDT > To: "boost-users(a)lists.boost.org" <boost-users(a)lists.boost.org> > Subject: [MPI] Test Processor Counts > > Hi, > > While running the trunk tests, we've found that occasionally the > system load average jumps up over 100 and occasionally hits 200. As > you can imagine for 8 to 32 core systems, this adversely impacts users > on those systems. > > The issue is that I'm running the trunk tests in parallel, usually -j8 > to -j32 and when the MPI tests run, we run into the high load > problem. Some of the MPI tests run up to 17 processors so the > combination of parallel testing and large processor count tests cause > this issue. Now the high load average may last for only 5 to 15 > minutes or so but this is enough to trigger a sysadmin question asking > what I'm up. > > I'm looking for a solution that wouldn't require significantly > reducing testing throughput. Possible solutions might include > serializing the execution of the MPI tests using something like the > link-semaphore in Boost.Build, reducing the processor counts of the > MPI tests, only running the larger tests on unchecked or unknown MPI > implementations, setting up an MPI machine file to run the MPI tests > off of the local system that built the executable, etc... > > Any other ideas on how to manage this? > > Thanks. > > -- Noel >

1 0

[regex] Last VC6 version
by Roger Orr 13 May '10

13 May '10

The page http://www.boost.org/doc/libs/1_43_0/libs/regex/doc/html/boost_regex/install .html still states that VC6 can be used to build regex, but this no longer appears to be actually the case. Does anyone know which was the last version of boost regex to support VC6? Regards, Roger.

2 2

Patch to value_initialized
by Christopher Jefferson 13 May '10

13 May '10

I just wanted to make people away of a suggested patch to value_initialized, explicitly adding the default constructor, copy constructor and operator=, given in https://svn.boost.org/trac/boost/ticket/4213 . The default constructor is necessary for clang and comeau (in strict mode) to allow const value_initialized values without an explicit value. I believe this is correct behaviour, but other compilers are more lack. I believe this patch is small and should work fine, but I know that this has been a very sensitive bit of code in the past, prone to kicking up minor compiler problems. My preferred option would be to try submitting this patch to trunk and see if any tester kicks up a fuss. If any do, then I am happy to introduce some macros.

2 2

trac database locked
by Kim Barrett 13 May '10

13 May '10

I'm trying to submit a patch via trac and get the error "OperationalError: database is locked"

2 2

[interprocess] flat_set/flat_map should add front(), back(), operator[], pop_back()
by Thorsten Ottosen 13 May '10

13 May '10

Hi Ion, When using e.g. a flat_set as a priority queue, it is annoying not to have back() and pop_back() available. As for operator[](), then of couse cont.begin()[n] works, but this is somewhat less pretty compared to just cont[n]. Therefore I would really like to see all the above functions added to the interface. kind regards Thorsten

2 2

[LA] vector_traits for setters
by Daniel Pfeifer 13 May '10

13 May '10

Hi Emil and others, Qt 4.6 brought support for some vector and matrix types. While it is easy to define matrix_traits for QGenericMatrix and QMatrix4x4, i am struggling with the vector_traits for QVector2D, QVector3D and QVector4D. The problem is that Qt's vector types have setters and no non-const-ref getters. Is there a plan for (Boost).LA to support types with setters? cheers, Daniel Documentation for Qt's vector and matrix types can be found here: http://doc.qt.nokia.com/4.6/qmatrix4x4-members.html http://doc.qt.nokia.com/4.6/qgenericmatrix-members.html http://doc.qt.nokia.com/4.6/qvector2d-members.html http://doc.qt.nokia.com/4.6/qvector3d-members.html http://doc.qt.nokia.com/4.6/qvector4d-members.html

4 10

[exception] warnings from BOOST_THROW_EXCEPTION
by Steven Watanabe 13 May '10

13 May '10

AMDG The attached patch fixes warnings like ..\..\../boost/property_tree/string_path.hpp:216: error: control reaches end of non-void function Okay to commit? In Christ, Steven Watanabe

3 3

[svn sandbox access] svn sandbox access requested via correct method but no reply
by Dan Walters 12 May '10

12 May '10

Hi all, I emailed boost-owner(a)lists.boost.org on 27 April 2010 23:32 requesting sandbox svn access but am yet to recv a reply. After asking in #boost, DHulme recommended that I post here mentioning this. Thanks for your time, Dan

3 3

[trac] New components
by Daniel James 12 May '10

12 May '10

Hi, Please can someone add functional/foward and functional/factory to the components on trac? They should be owned by t_schwinger. thanks, Daniel

2 1

IOChain Old Version
by Sebastian Redl 12 May '10

12 May '10

Hi, You can download the code of the old IOChain version here: http://www.cornedbee.com/iochain.tar.bz2 Sebastian

1 0

[Trac] Where's the SPAM?
by Rene Rivera 12 May '10

12 May '10

Since we've had a variety of SPAM that we have not been able to delete for some time it's likely that it's accumulated in Trac. So if you notice some of it during your trac reading, either delete it (assuming you have the permission) or post the link to the ticket so I can delete it. Delete happy, Rene :-) -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org (msn) - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim,yahoo,skype,efnet,gmail

3 3

[Trac] We're getting spammed!
by John Maddock 12 May '10

12 May '10

The Trac ticket system seems to be getting spammed on a regular basis at the moment, here are *four* of my old tickets that just got hit today: https://svn.boost.org/trac/boost/ticket/3632 https://svn.boost.org/trac/boost/ticket/1648#comment:4 https://svn.boost.org/trac/boost/ticket/2445#comment:2 https://svn.boost.org/trac/boost/ticket/3425#comment:2 Is there anything we can do to prevent this? John.

3 9

"Is Boost Broken?". - post script
by Robert Ramey 12 May '10

12 May '10

Last night I gave my presentation "Is Boost Broken?". I just wanted to add a few observations now that I've had an opportunity to sleep on it. Those who are interested, can download the powerpoint presentation at http://www.rrsd.com/software_development/boost/BoostCon2010/index.htm . A large part of the content was really contained in the response from the participants which is not available. Someday there maybe a video in which you'll be able to appreciate my bombastic personal delivery. I was surprised at how positively the proposals presented were received. I had feared the worst but hoped that some of the ideas presented might worm their way into Boost. It seems that there was more interest than that. I had crafted my proposal after having spent a lot of time following the mailing lists and I believe that proposal reflects a lot of the concerns that others have raised in piecemeal fashion. So in retrospect maybe I should have been more optimistic. I was careful to keep the focus on what facilities I think Boost needs and not get too involved in what it would take to implement these ideas or the specific form they might take. But given the interest, I'm now thinking more seriously of what it would take to make the ideas in this proposal reality. I'm here at Boost Con 2010 if you want to help in some way with this. Also, tonight, Dave Abrahams is scheduled to present his project "ryppl". I'm not privy to any of the details, but I suspect that this might dovetail with my own presentation. It will very likely bring out more discussion on the future of Boost. Robert Ramey BoostCon 2010 Aspen, Colorado

5 6

BOOST_NO_EXTERN_TEMPLATE check is broken
by Doug Gregor 12 May '10

12 May '10

The current Boost.Config check for BOOST_NO_EXTERN_TEMPLATE uses incorrect syntax. The test, in libs/config/test/boost_no_extern_template.ipp, looks like this: namespace boost_no_extern_template { extern template<class T> void f(T); int test() { return 0; } } The "extern" in C++0x extern templates can only be placed on explicit template instantiations. Here's a better test: namespace boost_no_extern_template { template<typename T, typename U> void f(T* p1, U* p2) { p1 = p2; } extern template void f(int*, float*); int test() { return 0; } } If the compiler rejects or ignores the "extern" in that explicit template instantiation declaration, we'll get an (invalid) compiler error. Grepping through the compiler configurations, BOOST_NO_EXTERN_TEMPLATE is set for several compilers that do in fact have support for C++0x extern templates, namely GCC and EDG-based compilers (when in either in C++0x or non-strict mode). - Doug

2 1

[fusion] [mpl] associative containers, compile time performance
by Domagoj Saric 12 May '10

12 May '10

(Boost 1.42, MSVC++ 9.0 SP1) Recently, I was finally forced to do some serious refactoring because the 'unbareable' turned to 'not working at all' (read: the compiler was hitting the 32 bit limit with 'out of heap space' errors), I got from hundreds of thousands of template instantiations down to 'just' thousands in a particular TU [meassured with Steven Watanabe's profiler...Steven you do miracles ;-D ...I also managed to get the Templight profiler to work with MSVC++ 9.0 but it just crashed with a project like this one...], and a peak cl.exe allocation of about 0.5 GB with a clean rebuild taking under 2 minutes which is acceptable... In the process I found out that: - the Fusion associative containers are always slower than random access containers (even if you use them only for/with by-key access). For example, I have a Fusion vector of different 'parameter' classes (it is therefore a 'unique random access set') for which a I wish to genereate a container of corresponding widget classes. Considering I later need to access the widget container using a parameter type as a key ('give me the widget for this parameter') it seems logical to use a map ( of pair<Parameter, Widget>s) but as it turns out accessing this map is several times! slower (compile-time wise) than using a plain vector for the widgets and then doing a linear search on the original parameter container to find the index of the parameter and then accessing the widget vector using that index... - the MPL associative containers are faster than random access ones only if you use them solely for by-key access, if any sequential or indexed access (using begin+advance) is also used (even if 'minor' to the amount of by-key access) this immediately kills the compiler. The size of the container might have also played a part in the distinction...in the end what worked best for me was to use mpl::maps for smaller collections (less than 10 types) that are only accessed by key, and mpl::vectors for large collections (50 types) that need to be accessed by index and by key... If these things are somehow 'ancient knowledge' maybe it would be worthwhile to document them so...In fact the Fusion documentation for associative sequences actually states "An Associative Sequence allows efficient retrieval of elements based on keys..." while in my case this turned out quite the opposite of truth...maybe this was referening to runtime-efficiency but then again this should be more clearly stated in the documentation (especially considering that, given the compile time nature of Fusion, it is reasonable to apriori expect that there is no runtime/generated code difference between different Fusion containers with most half decent compilers)... Looking at the implementations of Fusion associative containers it can be seen that, in fact, they do use vectors for implementation and do linear searches... One more thing that might help with Fusion associative container related compile-time defficiencies is to add the non-variadic/fixed sized versions for sets and maps (e.g. I frequently have this information and could specify the size exactly instead of being forced to use the variadic versions)...Just specifying FUSION_MAX_SET_SIZE=10 instead of 20 provided a measurable compile-time improvement... Additionaly, fusion::joint_view lacks the vital at<>() implementation(s) even though it states it is a model of a forward sequence so one is forced to use begin+advance... As for MPL, it still lacks the implementation of at<Seq, Key, Default> (that would be of significant help for my case) even though it is documented for 'who knows how long'... Even more usefull would be if MPL associative containers would not only provide the order<> 'getter' but also allow access using the order value (with same efficiency as key-based access of course)...this is usefull when you need to 'export' your 'typelist' outside of your library/'DLL' and allow outside code to specify the type that it wishes to create using an ID (like a factory that takes an ID as a parameter)...without the ability to use the 'order' as the ID you are forced to use the index...which then forces you to use vectors (because indicies simply 'kill' the compiler when used with a set) even though you also need key-based access at other places... ps. What does BOOST_MPL_LIMIT_UNROLLING actually do/configure? :) -- "What Huxley teaches is that in the age of advanced technology, spiritual devastation is more likely to come from an enemy with a smiling face than from one whose countenance exudes suspicion and hate." Neil Postman

1 0

Interlibrary version cchecking
by Robert Ramey 12 May '10

12 May '10

Turns out that the idea of a single boost library deployment has come up a couple of times here at BoostCon 2010. While preparing my presentation I considered the problem of what would happen if one installed one library which depended on an newer version of a different library than the user already had installed. I actually woke up in the middle of the night imagining someone would ask about that during my talk. I puzzled about it for some time and the day before I found a way to address it - in my own mind at least. It also seems that it turns out that there are tools that can also manage this. It's not that I don't trust tools but I wear a belt AND suspenders. So I would like a method which guarentees that when I build one library, I don't accidently include code from a prerequisite library which is a version so old that things won't work. I would also like to know that I'm not accidently running with a DLL built with an old version. Basically each library includes a file "manifest.hpp". This get's included when any header get's includes (once at most due to include guards). This includes a static assert that checks that the prequiste libraries are of sufficiently recent version that a dependent library (or user application) requires. There is also a manifest.cpp file included in the library which checks any prequiste DLLS. This would be an exheedingly small overhead to avoid what could be an incredibly large headache. I just verified that the code compiles so at this point it's only an idea. But it seems that some kind of check like this is un-avoidable of one want's to deploy libraries as needed rather than as a monolithic distribution. FYI - no one asked me about this problem at my presentation. Add one more confirmation of Murphy's law. Robert Ramey begin 666 manifest.hpp M(VEF;F1E9B!"3T]35%]315))04Q)6D%424].7TU!3DE&15-47TA04 T*(V1E M9FEN92!"3T]35%]315))04Q)6D%424].7TU!3DE&15-47TA04 T*#0HO+R!- M4R!C;VUP871I8FQE(&-O;7!I;&5R<R!S=7!P;W)T("-P<F%G;6$@;VYC90T* M(VEF(&1E9FEN960H7TU30U]615(I("8F("A?35-#7U9%4B ^/2 Q,#(P*0T* M(R!P<F%G;6$@;VYC90T*(V5N9&EF#0H-"B\O+R\O+R\O+S$O+R\O+R\O+R\R M+R\O+R\O+R\O,R\O+R\O+R\O+S0O+R\O+R\O+R\U+R\O+R\O+R\O-B\O+R\O M+R\O+S<O+R\O+R\O+R\X#0HO+R!M86YI9F5S="YH<' Z(%9E<FEF>2!T:&%T M(&%L;"!D97!E;F1E;G0@;&EB<F%R:65S(&%R92!A="!T:&4@8V]R<F5C= T* M+R\@=F5R<VEO;G,-"@T*+R\@*$,I($-O<'ER:6=H=" R,#$P(%)O8F5R="!2 M86UE>2 M(&AT=' Z+R]W=W<N<G)S9"YC;VT@+B -"B\O(%5S92P@;6]D:69I M8V%T:6]N(&%N9"!D:7-T<FEB=71I;VX@:7,@<W5B:F5C="!T;R!T:&4@0F]O M<W0@4V]F='=A<F4-"B\O($QI8V5N<V4L(%9E<G-I;VX@,2XP+B H4V5E(&%C M8V]M<&%N>6EN9R!F:6QE($Q)0T5.4T5?,5\P+G1X="!O<B!C;W!Y(&%T#0HO M+R!H='1P.B\O=W=W+F)O;W-T+F]R9R],24-%3E-%7S%?,"YT>'0I#0H-"@T* M(VEN8VQU9&4@/&)O;W-T+VET97)A=&]R+VUA;FEF97-T+FAP<#X-"@T*(VEN M8VQU9&4@/&)O;W-T+VUP;"]I;G0N:'!P/@T*(VEN8VQU9&4@/&)O;W-T+W-T M871I8U]A<W-E<G0N:'!P/@T*#0IN86UE<W!A8V4@8F]O<W0@>PT*;F%M97-P M86-E('-E<FEA;&EZ871I;VX@>PT*#0IC;&%S<R!M86YI9F5S="![#0HO+R!V M97)I9GD@870@8V]M<&EL92!T:6UE('1H870@=&AE('-E<FEA;&EZ871I;VX@ M;&EB<F%R>2!I<R!C;VUP:6QE9 T*+R\@=VET:"!T:&4@8V]R<F5C="!V97)S M:6]N<R!O9B!I="=S('!R97%U:7-I=&5S#0I"3T]35%]35$%424-?05-315)4 M* T*"3$@/#T@8F]O<W0Z.FET97)A=&]R.CIM86YI9F5S=#HZ:6YT97)F86-E M7W9E<G-I;VXZ.G9A;'5E#0H)+R\@)B8@8F]O<W0Z.FUP;#HZ8F]O;%\\=')U M93X@+RH@>6]U(&]T:&5R(&-O;F1I=&EO;G,@:&5R92 A("HO#0HI.PT*#0IP M<FEV871E.@T*"7-T871I8R!M86YI9F5S="!M7W9A;&ED871O<CL-"@T*<'5B M;&EC.@T*"2\O('-P96-I9GD@=&AE(&-U<G)E;G0@=F5R<VEO;B!N=6UB97)S M(&9O<B!T:&ES(&QI8G)A<GD-"@ET>7!E9&5F(&)O;W-T.CIM<&PZ.FEN=%\\ M,CX@:6YT97)F86-E7W9E<G-I;VX[#0H)='EP961E9B!B;V]S=#HZ;7!L.CII M;G1?/#,^(&EM<&QE;65N871I;VY?=F5R<VEO;CL-"@T*"2\O('9E<FEF:7D@ M870@<G5N('1I;64@=&AA="!T:&4@<V5R:6%L:7IA=&EO;B!L:6)R87)Y(&ES M(&QI;FME9"!W:71H( T*"2\O(&-O<G)E8W0@1$Q,4PT*"7-T871I8R!I;G0- M"@EG971?:6YT97)F86-E7W9E<G-I;VXH*3L-"@ES=&%T:6,@:6YT#0H)9V5T M7VEM<&QE;65N=&%T:6]N7W9E<G-I;VXH*3L-"@T*"2\O(&UA:V4@<W5R92!C M;VYS=')U8W1O<B!C<F%S:&5S(&EF('1H97)E)W,@82!P<F]B;&5M('=I=&@@ M=F5R<VEO;G,-"@EM86YI9F5S="@I.PT*?3L-"@T*?2 O+R!S97)I86QI>F%T M:6]N#0I]("\O(&)O;W-T#0H-"B-E;F1I9B O+R!"3T]35%]315))04Q)6D%4 224].7TU!3DE&15-47TA04 T* ` end begin 666 manifest.hpp M(VEF;F1E9B!"3T]35%])5$52051/4E]-04Y)1D535%](4% -"B-D969I;F4@ M0D]/4U1?251%4D%43U)?34%.249%4U1?2%!0#0H-"B\O($U3(&-O;7!A=&EB M;&4@8V]M<&EL97)S('-U<'!O<G0@(W!R86=M82!O;F-E#0HC:68@9&5F:6YE M9"A?35-#7U9%4BD@)B8@*%]-4T-?5D52(#X](#$P,C I#0HC('!R86=M82!O M;F-E#0HC96YD:68-"@T*+R\O+R\O+R\O,2\O+R\O+R\O+S(O+R\O+R\O+R\S M+R\O+R\O+R\O-"\O+R\O+R\O+S4O+R\O+R\O+R\V+R\O+R\O+R\O-R\O+R\O M+R\O+S@-"B\O(&UA;FEF97-T+FAP<#H@5F5R:69Y('1H870@86QL(&1E<&5N M9&5N="!L:6)R87)I97,@87)E(&%T('1H92!C;W)R96-T#0HO+R!V97)S:6]N M<PT*#0HO+R H0RD@0V]P>7)I9VAT(#(P,3 @4F]B97)T(%)A;65Y("T@:'1T M<#HO+W=W=RYR<G-D+F-O;2 N( T*+R\@57-E+"!M;V1I9FEC871I;VX@86YD M(&1I<W1R:6)U=&EO;B!I<R!S=6)J96-T('1O('1H92!";V]S="!3;V9T=V%R M90T*+R\@3&EC96YS92P@5F5R<VEO;B Q+C N("A3964@86-C;VUP86YY:6YG M(&9I;&4@3$E#14Y315\Q7S N='AT(&]R(&-O<'D@870-"B\O(&AT=' Z+R]W M=W<N8F]O<W0N;W)G+TQ)0T5.4T5?,5\P+G1X="D-"@T*(VEN8VQU9&4@/&)O M;W-T+VUP;"]I;G0N:'!P/@T*#0IN86UE<W!A8V4@8F]O<W0@>PT*;F%M97-P M86-E(&ET97)A=&]R('L-"@T*8VQA<W,@;6%N:69E<W0@>PT*<'5B;&EC.@T* M"2\O('-P96-I9GD@=&AE(&-U<G)E;G0@=F5R<VEO;B!N=6UB97)S(&9O<B!T M:&ES(&QI8G)A<GD-"@ET>7!E9&5F(&)O;W-T.CIM<&PZ.FEN=%\\,CX@:6YT M97)F86-E7W9E<G-I;VX[#0H)='EP961E9B!B;V]S=#HZ;7!L.CII;G1?/#,^ M(&EM<&QE;65N871I;VY?=F5R<VEO;CL-"GT[#0H-"GT@+R\@<V5R:6%L:7IA M=&EO;@T*?2 O+R!B;V]S= T*#0HC96YD:68@+R\@0D]/4U1?251%4D%43U)? ,34%.249%4U1?2%!0 ` end begin 666 manifest.cpp M+R\O+R\O+R\O,2\O+R\O+R\O+S(O+R\O+R\O+R\S+R\O+R\O+R\O-"\O+R\O M+R\O+S4O+R\O+R\O+R\V+R\O+R\O+R\O-R\O+R\O+R\O+S@-"B\O(&UA;FEF M97-T+F-P<#H-"@T*+R\@*$,I($-O<'ER:6=H=" R,#$P(%)O8F5R="!286UE M>2 M(&AT=' Z+R]W=W<N<G)S9"YC;VT@+B -"B\O(%5S92P@;6]D:69I8V%T M:6]N(&%N9"!D:7-T<FEB=71I;VX@:7,@<W5B:F5C="!T;R!T:&4@0F]O<W0@ M4V]F='=A<F4-"B\O($QI8V5N<V4L(%9E<G-I;VX@,2XP+B H4V5E(&%C8V]M M<&%N>6EN9R!F:6QE($Q)0T5.4T5?,5\P+G1X="!O<B!C;W!Y(&%T#0HO+R!H M='1P.B\O=W=W+F)O;W-T+F]R9R],24-%3E-%7S%?,"YT>'0I#0H-"B\O("!3 M964@:'1T<#HO+W=W=RYB;V]S="YO<F<@9F]R('5P9&%T97,L(&1O8W5M96YT M871I;VXL(&%N9"!R979I<VEO;B!H:7-T;W)Y+@T*#0HC:68@*&1E9FEN960@ M7TU30U]615(I("8F("A?35-#7U9%4B ]/2 Q,C P*0T*(R @<')A9VUA('=A M<FYI;F<@*&1I<V%B;&4@.B T-S@V*2 O+R!T;V\@;&]N9R!N86UE+"!H87)M M;&5S<R!W87)N:6YG#0HC96YD:68-"@T*+R\@=&AI<R!M;V1U;&4@:7,@<&QA M8V5D(&EN(&$@;&EB<F%R>2!T;R!P97)M:70@<G5N=&EM92!V86QI9&%T:6]N M#0HO+R!O9B!M86YI9F5S=',@=7-E9"!W:71H($1,3%,N($ET)W,@:G5S="!A M;B!E>&%M<&QE+B @5&AE('-E<FEA;&EZ871I;VX-"B\O(&QI8G)A<GD@9&]E M<VXG="!U<V4@86YY(&]T:&5R(')U;G1I;64@;&EB<F%R:65S('-O('1H:7,@ M:6X-"B\O(&9A8W0@=V]U;&1N)W0@8F4@;F5C97-S87)Y+@T*#0HC9&5F:6YE M($)/3U-47U-%4DE!3$E:051)3TY?4T]54D-%#0H-"B-I;F-L=61E(#QS=&1E M>&-E<'0^#0HC:6YC;'5D92 \8F]O<W0O<V5R:6%L:7IA=&EO;B]M86YI9F5S M="YH<' ^#0H-"FYA;65S<&%C92!B;V]S="![#0IN86UE<W!A8V4@<V5R:6%L M:7IA=&EO;B![#0H-"B\O('1H:7,@9V5T)W,@8V]N<W1R=6-T960@:6X@82!$ M3$P-"G-T871I8R!M86YI9F5S="!M7W9A;&ED871O<CL-"@T*;6%N:69E<W0Z M.FUA;FEF97-T*"E[#0H)+R\@=VAI8V@@<')O=F]K97,@=&AE(&-H96-K:6YG M(&]F('9E<G-I;VYS(&%T(')U;G1I;64-"@D-"@DO+R!T:&4@<V5R:6%L:7IA M=&EO;B!L:6)R87)Y(&1O97-N)W0@=7-E(&%N>2!O=&AE<B!R=6YT:6UE#0H) M+R\@;&EB<F%R:65S('-O('1H:7,@8V%N(&)E(&$@;F\@;W -"@EI9B@@(2@- M"@D)+R\@=&AE(&ET97)A=&]R(&QI8G)A<GD@9&]E<VXG="!N965D('1O(&EM M<&QE;65N="!T:&ES( T*"0DO+R!S:6YC92!I="=S(&$@:&5A9&5R(&]N;'D@ M;&EB<F%R>2X-"@D)+R\Q(#P](&)O;W-T.CII=&5R871O<CHZ;6%N:69E<W0Z M.F=E=%]I;G1E<F9A8V5?=F5R<VEO;B@I#0H)"2\O)B8@( T*"0ET<G5E("\O M(')E<&QA8V4@=VET:"!Y;W5R(&]T:&5R(')U;G1I;64@8V]N:61I;VYS("$- M"@D)+R\@+BXN#0H)*2D-"@D)=&AR;W<@<W1D.CIO=71?;V9?<F%N9V4H(DEN M=F%L:60@;&EB<F%R>2!V97)S:6]N(BD[#0I]#0H-"B\O(&EM<&QE;65N="!R M=6YT:6UE(')E=')I979A;"!O9B -"FEN= T*;6%N:69E<W0Z.F=E=%]I;G1E M<F9A8V5?=F5R<VEO;B@I>PT*"7)E='5R;B!I;G1E<F9A8V5?=F5R<VEO;CHZ M=F%L=64[#0I]#0II;G0-"FUA;FEF97-T.CIG971?:6UP;&5M96YT871I;VY? M=F5R<VEO;B@I>PT*"7)E='5R;B!I;7!L96UE;F%T:6]N7W9E<G-I;VXZ.G9A K;'5E.PT*?0T*#0I]("\O('-E<FEA;&EZ871I;VX-"GT@+R\@8F]O<W0-"@`` ` end

1 0

performance of a linear algebra/matrix library
by DE 11 May '10

11 May '10

hi all i work on a linear algebra library with an intent to propose it for inclusion into boost collection of libs so my question is: how fast such a lib should be to make everybody happy? i found that to increase the performance of a generic linear algebra library one must complicate the implementation to a very high degree (though this statement should be obvious to everyone) i struggled with poor performance of matrix multiplication and finally identified the bottleneck i improved the implementation (seriosly complicating it, i'm afraid i will forget how it works in a month) and now it performs some 33% slower than C code for virtually any size of matrix the C code is as follows: typedef double type; const size_t n = 42; type *a = new type[n*n], *a1 = new type[n*n], *a2 = new type[n*n]; //filling 'a1' and 'a2' for (size_t i = 0; i<n; ++i) { type * const a_i = a + i*n; for (size_t j = 0; j<n; ++j) a_i[j] = 0.; for (size_t k = 0; k<n; ++k) { type *a = a_i; const type a1_ik = a1[i*n + k]; const type *a2_k = a2 + k*n; for (size_t j = 0; j<n; ++j, ++a, ++a2_k) *a += a1_ik*(*a2_k); } } the C++ code is just matrix<type> m(n, n), m1(n, n), m2(n, n); //filling 'm1' and 'm2' m.assign(m1, m2); more detailed results: 'n' is the dimensions of matrices, 'ratio' is runtime of C++ code divided by runtime of C code (time_cpp/time_c) n | 2 | 4 | 8 | 16 | 32 | 64 | 128 | 256 | 512 | 1024 | 2048 ratio | 1,77 | 1,57 | 1,34 | 1,12 | 1,05 | 1,12 | 1,32 | 1,33 | 1,23 | 1,23 | 1,23 as you can see starting with 8 by 8 matices C++ code is roughly 33% slower than C code is that enough to make you (the reader) happy? -- Pavel

9 24

Re: [boost] Parallel Boost Algorithm
by anil khadka 10 May '10

10 May '10

Thanks for the prompt response. I haven't tried the non-distributed (name is confusing though) version. I am using regular version with unweighted graph (I am not passing any weight parameter, as default is unweighted). I used "0.7.0 beta" (parallel-bgl-0.7.0.tar.gz). I think i should try the non-distributed version as 80K quite smaller than 2^20 nodes. (BTW, I also have a graph with more than millions nodes too, but that comes later.) You said that we can have each process read a disjoint portion of the edge set and use the in-place CSR ctors to build the graph, Are there any examples in the source code for this?? One more thing, I also want to calculate the Closeness Centrality, and i do not want to re-processed the whole graph, as most of the calculation(like shortest path) is same as betweenness. Can't we calculate Closeness centrality on the same pass? I'll also tune the parameters(like message-buffer), and post the result here. Metanil. ________________________________ From: Nick Edmonds <ngedmond(a)cs.indiana.edu> To: boost(a)lists.boost.org Sent: Sat, May 1, 2010 9:14:39 PM Subject: Re: [boost] Parallel Boost Algorithm On Apr 30, 2010, at 11:49 AM, anil khadka wrote: > I am pretty new to both boost and parallel boost. > > I am using Brandes Centrality algorithm, but the performance really doesn't meet my expectation. > > If I used Java, which is only using 1 CPU core would complete it in around 30 hrs. > The parallel version which use 8 CPU cores tooks 17 hours!! > > I don't know why there is just around 13 hours gain if i use 8 cores against 1, unless there are lots and lots of communication between each cores. > I am using just 1 machine (not a cluster), right now. > > Graph size is Node 80K, edges 120K > > I am reading edges from files. I used distributed compressed_sparse_row to represent graph. > Right now, it seems like all the cpu cores are reading files on its own, I am assuming each CPU core will takes its graph part automatically (distributed algorithm do it ?). > > Note: I downloaded the parallel version from: http://osl.iu.edu/research/pbgl/software/ > > Any help/suggestions would be really appreciated. Which version of the parallel Betweenness Centrality algorithm are you using? There's a non-distributed version that replicates the graph as opposed to distributing it that should be much faster for small graphs like the one you describe. This algorithm should scale much closer to linearly than the distributed version. I've used the non-distributed version to solve instances up to 2^20 vertices and 2^23 edges if I remember right (it might be 2^19/2^22). The non-distributed version parallelizes the outer loop over source vertices, while the distributed version computes one shortest-path tree at a time using a distributed SSSP algorithm. Is your graph weighted or unweighted? This determines whether the algorithm is O(n^2) or O(n^2 log n). The scaling you're seeing is about what I'd expect for a very small graph instance distributed 8-ways, there simply isn't enough work to hide the latency in the MPI layer. You can try adjusting the size of message buffers in the process group (smaller buffers mean less coalescing, lower latency, and potentially more computation/communication overlap). Check out the --batch-buffer-size parameter to libs/graph_parallel/test/algorithm_performance for an example of how to specify a message buffer size to the process group ctor and then pass the process group to a graph instance. The distributed-memory implementation in PBGL is sub-optimal for shared memory because accessing data stored on other processes goes through the entire MPI layer as opposed to simply reducing to a memory reference. The non-distributed BC algorithm only performs communication to perform property map reductions so this is much less of a problem in that case though you still replicate the graph once per process. In either case the distributed data structures impose some overhead, as does the serialization performed in Boost.MPI (there's a BOOST_MPI_HOMOGENOUS (IIRC) compile time flag that disables some serialization though a 'null-serialization' option that doesn't perform any serialization would be a very useful performance optimization). I'm in the process of rewriting the PBGL to leverage shared-memory parallelism more effectively, though it's unlikely it will every be an optimal shared-memory-only library (because of the overhead imposed by the distributed addressing sche me etc.). There's definitely room for a "Multicore BGL" library, though my lab doesn't have the resources/interest to do it at the moment. All the graph generators in the PBGL assume that every node reads the entire graph's edge set and filters out non-local edges. It's possible to write scalable graph generators which don't do this (the indexed dimacs reader is one example), but this generally requires some sort of preprocessing. Alternately you can have each process read a disjoint portion of the edge set and use the in-place CSR ctors to build the graph. This last approach is how we fit graphs that take a very large fraction of main memory to represent. The PBGL svn trunk at http://osl.iu.edu/research/pbgl/software should be a proper superset of the 1.42 Boost release, the 0.7 tarball should be almost exactly equivalent. New features are pushed to Boost in a coarse-grained fashion when they're tested/stable. Let me know if you have any more questions. Thanks, Nick _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

2 1

[parameter] compiler errors with operator()
by Lorenzo Caminiti 10 May '10

10 May '10

Hello all, I am trying to compile the example from Boost.Parameter section 2.2 but I get the GCC errors below. The errors go aways if I name the member function `f` instead of `operator()`. What am I doing wrong? How do I use Boost.Parameter with member operators? // File: "c2.cpp". #include <boost/parameter.hpp> #include <iostream> BOOST_PARAMETER_NAME(arg1) BOOST_PARAMETER_NAME(arg2) struct callable2 { BOOST_PARAMETER_CONST_MEMBER_FUNCTION( (void), operator(), tag, (required (arg1,(int))(arg2,(int)))) { std::cout << arg1 << ", " << arg2 << std::endl; } }; int main() { callable2 c2; c2(1, 2); c2(2, 1); return 0; } $ g++ -Wall -Werror example/Own/parameter/c2.cpp example/Own/parameter/c2.cpp:10: error: expected unqualified-id before ‘)’ token example/Own/parameter/c2.cpp:10: error: expected unqualified-id before ‘)’ token example/Own/parameter/c2.cpp:10: error: expected unqualified-id before ‘)’ token example/Own/parameter/c2.cpp:10: error: expected nested-name-specifier before ‘boost_param_result_11operator’ example/Own/parameter/c2.cpp:10: error: expected initializer before ‘<’ token example/Own/parameter/c2.cpp:10: error: expected nested-name-specifier before ‘boost_param_result_11operator’ example/Own/parameter/c2.cpp:10: error: expected initializer before ‘<’ token example/Own/parameter/c2.cpp:10: error: ‘boost_param_default_11operator’ declared as function returning a function example/Own/parameter/c2.cpp: In member function ‘int callable2::boost_param_default_11operator()’: example/Own/parameter/c2.cpp:13: error: ‘arg1’ was not declared in this scope example/Own/parameter/c2.cpp:13: error: ‘arg2’ was not declared in this scope cc1plus: warnings being treated as errors example/Own/parameter/c2.cpp:14: warning: no return statement in function returning non-void example/Own/parameter/c2.cpp: In function ‘int main()’: example/Own/parameter/c2.cpp:19: error: no match for call to ‘(callable2) (int, int)’ example/Own/parameter/c2.cpp:20: error: no match for call to ‘(callable2) (int, int)’ $ g++ --version g++ (GCC) 4.2.4 (Ubuntu 4.2.4-1ubuntu4) I am using Boost v1.42.0 Thank you very much. -- Lorenzo P.S. Shall I report these type of questions on this mailing list or in Boost's TRAC? I am new to Boost.Parameter so I am not sure these are actual bugs...

1 0

Re: [boost] Namespace for a Boost Hashing Library
by Anders Dalvander 10 May '10

10 May '10

Scott McMurray wrote: > Some possibilities: > > - boost::hashes > - boost::hash_algo or boost::hash_algorithms > - boost::hashing or boost::hashing_algorithms > - boost::digests or boost::message_digest > - boost::fingerprint (or boost::dactylogram) > > Which one(s) do you prefer or dislike? > > Thanks, > ~ Scott McMurray > My votes goes to, in order: 1. boost::hash_algo 2. boost::crypto_hash 3. boost::hashes 4. boost::c11c_hash (not an actual proposal) Regards, Anders Dalvander

1 0

[website] favicon path was incorrect
by Jeremiah Willcock 10 May '10

10 May '10

Look at https://svn.boost.org/favicon.ico or the file I attached; /htdocs/site/favicon.ico is still the old, larger icon. -- Jeremiah Willcock

1 0

New list moderators needed!
by Beman Dawes 10 May '10

10 May '10

It is high time we added additional mailing list moderators. The current moderators have been in place for years, but in the meantime their day job responsibilities have changed, or other distractions are preventing them from giving list moderation the attention it deserves. While the current moderators will make the final decision, it would be helpful to hear nominations from the list for several new moderators. Who are some regular posters with the "right stuff" to keep the list civil, productive, and interesting? Actually moderating postings doesn't take a lot of time, since only postings from new posters need manual moderation. But we need moderators who read all or most postings, and step in when guidelines aren't being observed. --Beman

4 4

[cstdint] Why no cstdint.hpp merge from trunk for 1.43.0?
by Number Cruncher 10 May '10

10 May '10

I've just been looking at the latest 1.43 and noticed the same issue with the redefinition of INT*_C macros as 1.42, yet the fix was committed to the trunk 3 months ago: https://svn.boost.org/trac/boost/changeset/59430/trunk/boost/cstdint.hpp Any ideas why this didn't make the 1.43 release? Thanks, Simon

2 1

[asio] boost include problem
by Elimentz 10 May '10

10 May '10

Hey I'm trying to use a Boost asio Basic_serial_port in my project, so I include the file asio.hpp like this: #include <boost/asio.hpp> This file contains a lot of other includes, but it seems it is impossible for my project to include these, not a single one... how can I fix this? I mean, this should work, right? these files were written by the developers themselves!! -- View this message in context: http://old.nabble.com/-asio--boost-include-problem-tp28502931p28502931.html Sent from the Boost - Dev mailing list archive at Nabble.com.

1 0

[thread] thread_specific_ptr and static initialization order
by Tanguy Fautré 09 May '10

09 May '10

Hi, After upgrading from 1.42 to 1.43 (using VC10 x64), I encounter an access violation related to thread_specific_ptr. The program used to run fine with previous version of Boost on several platforms (Win x32, Win x64 and Linux x64). I've managed to create a small program that reproduces the problem. It seems to be a static initialization order related problem. If the TSS is initialized by a static object, the program fails (nullptr exception). However, if the static object is commented out, and the TSS is solely initialized in the main, the program runs fine. Is thread_specific_ptr supposed to work even when initialized by another static object? Or does it require to be initialized only after entering main? Regards, Tanguy #include <boost/thread/thread.hpp> #include <boost/thread/tss.hpp> #include <iostream> #include <stdexcept> namespace { boost::thread_specific_ptr<int> tss; void verifyTss() { if (tss.get() == nullptr) throw std::runtime_error("verifyTss failed (nullptr)"); } class InitTss { public: InitTss() { tss.reset(new int); } }; InitTss init_tss; } int main(int argc, char argv[]) { try { tss.reset(new int); verifyTss(); boost::thread thread([] () { tss.reset(new int); }); thread.join(); verifyTss(); } catch (const std::exception & error) { std::cerr << "ERROR: " << error.what() << std::endl; } }

2 4

Is release branch open for merges?
by Andrey Semashev 09 May '10

09 May '10

Now that 1.43 is released, is the release branch open for merges?

2 1

[lambda][cast] 1.42 and 1.43 boost/lambda/cast.hpp requires #include before it - bug?
by Krzysztof Czainski 09 May '10

09 May '10

I have noticed, that with includes in this order: #include <boost/lambda/cast.hpp> #include <boost/lambda/lambda.hpp> later using ll_static_cast fails to compile with first message (gcc-4.3): /usr/include/boost/lambda/casts.hpp:93: error: ‘return_type_N’ is not a template However, including lambda.hpp before cast.hpp fixes the error. I have tested this with boost 1.42.0 and 1.43.0. Regards Krzysztof Czainski

2 1

Like boost::enable_if, but takes a "priority number" and changes overload resolution order
by Dennis Ferron 09 May '10

09 May '10

>From the Boost documentation: "The enable_if family of templates is a set of tools to allow a function template or a class template specialization to include or exclude itself from a set of matching functions or specializations based on properties of its template arguments." Sometimes instead of completely excluding a function from overload resolution, I only really want to "tweak" C++'s overload resolution order, or disambiguate an edge case. Instead of relying on C++'s overload priorities, sometimes I'd like to explicitly set the overload priority, like this: template <typename T> void func(boost::overload_priority<1> dummy, ArgType1 arg) {} template <typename T> void func(boost::overload_priority<2> dummy, ArgType2 arg) {} template <typename T> void func(boost::overload_priority<3> dummy, ArgType3 arg) {} Whereas enable_if causes a "hard" error to trigger SFINAE and take a function out of consideration, overload_priority would have some sort of "soft" effect that "tricks" the C++ compiler into thinking it is a less specific match than it is, moving it down in the order of which gets chosen, without actually invalidating it. It isn't obvious that this is even possible, but then, I would never have believed "enable_if" was possible before I heard of it. Whereas enable_if works by wrapping the return type of the function, I believe this would have to wrap a function argument to work. What I have in mind is that the overload_priority class would look like this: template <int N> class overload_priority { public: overload_priority(int x) { ... } }; You would call the overloaded function like this: func(0, the_actual_arg); I'm thinking it would affect the overload priority by some trick like causing an N-deep nested conversion sequence (overload_priority<3> constructed from overload_priority<2>, from overload_priority<1>, from the integer 0) or by the constructor having N extra parameters with default arguments. Any comments or ideas for improving this?

2 1

[parameter] accessing param type within signature
by Lorenzo Caminiti 09 May '10

09 May '10

Hello all, I am new to Boost.Parameter. I am having troubles getting the depth_first_search() example from the documentation section 2.1.5.6.2 to compile. Was the example in section 2.1.5.6.2 even compiled? If so, can someone point to the code that can be compiled? (I did look into Boost sandbox libs/parameter/... but I did not see it there.) 1) I need to access graph_type to write type requirements of following parameters. 2) The documentation section 2.1.5.6.1 says I can use graph_type (or xyz_type in general) from within the signature to refer to the parameter type. However, that seems not to be the case (also looking at the preprocessed code, xyz_type is a template parameter available only in the function body but not in the signature). 3) The documentation section 2.1.5.6.2 seems to use tag::graph::_ instead of graph_type to access the type (also sometimes graphs::graph::_ is used but I think that might be a typo... because the tag namespace should be there as in graphs::tag::graph::_). 4) Finally, even when I try to use tag::graph::_ to refer to graph_type, I get the GCC error below. What am I doing wrong? // File: g00.cpp #include <boost/parameter.hpp> namespace graphs { BOOST_PARAMETER_NAME(graph) BOOST_PARAMETER_NAME(graph2) BOOST_PARAMETER_FUNCTION( (void), depth_first_search, tag, (required (graph, *) (graph2, (tag::graph::_)) // Trying to use graph's type here... but I can't use graph_type and graph::_ does not compile... ) ) { // Here I can use graph_type. } } // namespace int main() { graphs::depth_first_search(1, 2); return 0; } $ g++ -Wall -Werror -I./src -DCONTRACT_CHECK_BLOCK_INVARIANT -DCONTRACT_CHECK_CLASS_INVARIANT -DCONTRACT_CHECK_PRECONDITION -DCONTRACT_CHECK_POSTCONDITION example/Own/parameter/g00.cpp /usr/include/boost/parameter/value_type.hpp: In instantiation of ‘boost::parameter::value_type<mpl_::arg<2>, graphs::tag::graph, boost::parameter::void_>’: example/Own/parameter/g00.cpp:9: instantiated from ‘typename graphs::boost_param_result_17depth_first_search<Args>::type graphs::boost_param_impldepth_first_search(const Args&) [with Args = boost::parameter::aux::arg_list<boost::parameter::aux::tagged_argument<graphs::tag::graph2, const int>, boost::parameter::aux::arg_list<boost::parameter::aux::tagged_argument<graphs::tag::graph, const int>, boost::parameter::aux::empty_arg_list> >]’ example/Own/parameter/g00.cpp:9: instantiated from ‘typename graphs::boost_param_result_17depth_first_search<typename boost::parameter::aux::argument_pack<graphs::boost_param_params_17depth_first_search<int>, const ParameterArgumentType0, const ParameterArgumentType1, boost::parameter::void_, boost::parameter::void_, boost::parameter::void_>::type>::type graphs::depth_first_search(const ParameterArgumentType0&, const ParameterArgumentType1&, typename boost::parameter::aux::match<graphs::boost_param_params_17depth_first_search<int>, ParameterArgumentType0, ParameterArgumentType1, boost::parameter::void_, boost::parameter::void_, boost::parameter::void_>::type) [with ParameterArgumentType0 = int, ParameterArgumentType1 = int]’ example/Own/parameter/g00.cpp:24: instantiated from here /usr/include/boost/parameter/value_type.hpp:60: error: no type named ‘binding’ in ‘struct mpl_::arg<2>’ /usr/include/boost/parameter/value_type.hpp:62: error: no type named ‘binding’ in ‘struct mpl_::arg<2>’ example/Own/parameter/g00.cpp: In function ‘typename graphs::boost_param_result_17depth_first_search<Args>::type graphs::boost_param_impldepth_first_search(const Args&) [with Args = boost::parameter::aux::arg_list<boost::parameter::aux::tagged_argument<graphs::tag::graph2, const int>, boost::parameter::aux::arg_list<boost::parameter::aux::tagged_argument<graphs::tag::graph, const int>, boost::parameter::aux::empty_arg_list> >]’: example/Own/parameter/g00.cpp:9: instantiated from ‘typename graphs::boost_param_result_17depth_first_search<typename boost::parameter::aux::argument_pack<graphs::boost_param_params_17depth_first_search<int>, const ParameterArgumentType0, const ParameterArgumentType1, boost::parameter::void_, boost::parameter::void_, boost::parameter::void_>::type>::type graphs::depth_first_search(const ParameterArgumentType0&, const ParameterArgumentType1&, typename boost::parameter::aux::match<graphs::boost_param_params_17depth_first_search<int>, ParameterArgumentType0, ParameterArgumentType1, boost::parameter::void_, boost::parameter::void_, boost::parameter::void_>::type) [with ParameterArgumentType0 = int, ParameterArgumentType1 = int]’ example/Own/parameter/g00.cpp:24: instantiated from here example/Own/parameter/g00.cpp:9: error: no matching function for call to ‘boost::parameter::aux::cast<void ()(boost::parameter::value_type<mpl_::arg<2>, graphs::tag::graph, boost::parameter::void_>)>::execute(const int&)’ /usr/include/boost/parameter/aux_/cast.hpp:99: note: candidates are: static boost::parameter::aux::use_default_tag boost::parameter::aux::cast<void ()(T)>::execute(boost::parameter::aux::use_default_tag) [with T = boost::parameter::value_type<mpl_::arg<2>, graphs::tag::graph, boost::parameter::void_>] /usr/include/boost/parameter/aux_/cast.hpp:109: note: static T boost::parameter::aux::cast<void ()(T)>::execute(T) [with T = boost::parameter::value_type<mpl_::arg<2>, graphs::tag::graph, boost::parameter::void_>] example/Own/parameter/g00.cpp:9: error: return-statement with a value, in function returning 'void' $ g++ --version g++ (GCC) 4.2.4 (Ubuntu 4.2.4-1ubuntu4) Copyright (C) 2007 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. I have tried this on Boost 1.42.0 and 1.34.1 (same errors). Thank you very much. -- Lorenzo

1 0

Problem with Property Tree under WinXP, Eclipse, mingw
by Rouven Walter 09 May '10

09 May '10

Hello, I have posted the message below in the users boost mailinglist before. But there was no satisfying answer, so I decided to post it once again on the developers list. It seems to be a more technical problem. I'm looking forward for your answers, thanks, Cyraid ---- Hello, I use Windows XP with MinGW and Eclipse for C++ developing. I want to use the xml parser included in the property tree library of boost. I started trying the example at [1]http://www.boost.org/doc/libs/1_43_0/doc/html/boost_propertytree/tutorial .html but it failed with the following error: **** Build of configuration Debug for project Test CPP Project **** **** Internal Builder is used for build **** g++ -IC:\Programme\boost_1_42_0 -O0 -g3 -Wall -c -fmessage-length=0 -osrc\Test.o ..\src\Test.cpp C:/Programme/boost_1_42_0/boost/property_tree/detail/ptree_utils.hpp:In function `std::string boost::property_tree::detail::narrow(const Ch*) [with Ch = wchar_t]': C:/Programme/boost_1_42_0/boost/property_tree/string_path.hpp:62: instantiated from here C:/Programme/boost_1_42_0/boost/property_tree/detail/ptree_utils.hpp:76: warning: comparison between signed and unsigned integer expressions C:/Programme/boost_1_42_0/boost/property_tree/detail/ptree_utils.hpp:76: warning: comparison is always false due to limited range of data type C:/Programme/boost_1_42_0/boost/property_tree/detail/xml_parser_read_rapidxm l.hpp: In function `void boost::property_tree::xml_parser::read_xml_internal(std::basic_istream<typen ame Ptree::key_type::value_type, std::char_traits<typename Ptree::key_type::value_type> >&, Ptree&, int, const std::string&) [with Ptree = boost::property_tree::basic_ptree<std::string, std::string, std::less<std::string> >]': C:/Programme/boost_1_42_0/boost/property_tree/xml_parser.hpp:85: instantiated from `void boost::property_tree::xml_parser::read_xml(const std::string&, Ptree&, int, const std::locale&) [with Ptree = boost::property_tree::ptree]' ..\src\Test.cpp:39: instantiated from here C:/Programme/boost_1_42_0/boost/property_tree/detail/xml_parser_read_rapidxm l.hpp:108: error: non-constant `(((int)f_c) | 3072)' cannot be used as template argument C:/Programme/boost_1_42_0/boost/property_tree/detail/xml_parser_read_rapidxm l.hpp:108: error: no matching function for call to `rapidxml::xml_document<char>::parse(char*)' Build error occurred, build is stopped Time consumed: 4109 ms. I have included the necessary header files in the eclipse project properties. For me, the error message seems to be some internal failure in the library? Or where could I have done a mistake ? Best regards, Cyraid GRATIS: Movie-Flat mit über 300 Top-Videos. Für WEB.DE Nutzer dauerhaft kostenlos! Jetzt freischalten unter http://movieflat.web.de References 1. http://www.boost.org/doc/libs/1_43_0/doc/html/boost_propertytree/tutorial.h…

1 0

[1.43.0] PDF build of docs now available.
by John Maddock 09 May '10

09 May '10

The PDF build of the documentation for 1.43 (for those libraries that support this) is now available from the sourceforge download page: http://sourceforge.net/projects/boost/files/ The direct links are: http://sourceforge.net/projects/boost/files/boost-docs/1.43.0/boost_pdf_1_4… http://sourceforge.net/projects/boost/files/boost-docs/1.43.0/boost_pdf_1_4… http://sourceforge.net/projects/boost/files/boost-docs/1.43.0/boost_pdf_1.4… http://sourceforge.net/projects/boost/files/boost-docs/1.43.0/boost_pdf_1.4… Enjoy! John.

1 0

Problem building Boost test framework
by Matthias Troyer 09 May '10

09 May '10

Hi, I am trying to build the libraries for the Boost test framework myself (using my own CMake files) instead of using bjam. When trying to link the file execution_monitor.cpp debug.cpp cpp_main.cpp into a dynamic library libboost_prg_exec_monitor.dylib I get the following linker erros: Linking CXX shared library libboost_prg_exec_monitor.dylib ld: warning: duplicate dylib /usr/lib/libpthread.dylib Undefined symbols: "boost::debug::attach_debugger(bool)", referenced from: _execution_monitor_attaching_signal_handler in execution_monitor.cpp.o "boost::debug::under_debugger()", referenced from: boost::execution_monitor::execute(boost::unit_test::callback0<int> const&)in execution_monitor.cpp.o Do I need to link additional files? Matthias

2 1

[xint] Third release is ready, requesting preliminary review
by Chad Nelson 09 May '10

09 May '10

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I'm happy to announce that the third release of the Extended Integer library is ready, in both the sandbox and the Vault. This is a major overhaul of the library, taking into account all of the feedback and recommendations provided on the first two: * The exception-blocking system is gone, replaced by a separate nothrow_integer class. * There's now a fixed_integer class template as well. * The test functions now use Boost.Test, and the documentation has been moved to Doxygen. * Nearly every function received a thorough examination as well; many of them were tweaked, and a few completely replaced. Please take a look and let me know what you think of the changes. I'm very happy with them. - -- Chad Nelson Oak Circle Software, Inc. * * * -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkvabA0ACgkQp9x9jeZ9/wSwvACcCJ18QkRbKWmByYO7Q1xe6qYx EUYAnRl4+mzw9X2VvGCCFPl0Q0VWLhRN =fhbW -----END PGP SIGNATURE-----

21 230

Re: [boost] [rfc] Preliminary Hash Library
by Sean Chittenden 08 May '10

08 May '10

re: Possible namespaces. Why not use boost::digest? "Cryptographic hashes" are more pedantically known as one-way digests of blobs of data. A "hash," as hijacked by perl (or dictionary, or unordered_map), is an ADT comprised of a digest of a key and a value. crc's a digest as well, but for legacy reasons already has a top-level namespace. Some digests are crypto grade, some aren't, but they all fall in to the digest category. $0.02. -sc -- Sean Chittenden sean(a)chittenden.org

1 0

[constrained-value] with 1.43.0
by Neal Becker 08 May '10

08 May '10

I found my code using constrained_value compiles with boost-1.42.0, but not with 1.43.0. Rather mysterious error message: /usr/local/src/boost.hg/boost/constrained_value/constrained.hpp:64: error: 'template<class ExceptionType> struct boost::constrained_value::throw_exception' is not a function, /usr/local/src/boost.hg/boost/throw_exception.hpp:74: error: conflict with 'template<class E> void boost::throw_exception(const E&)' /usr/local/src/boost.hg/boost/throw_exception.hpp:54: error: in call to 'throw_exception' scons: *** [mod/fixed_pt.os] Error 1

3 8

[proto][can_be_called]
by Andy Venikov 08 May '10

08 May '10

Currently, can_be_called<> expects only functors. Is it possible to extend it so that it can take any type and return true if that type can be called with the list of given parameters. For example, function<int (int, char, long)> functor; int f(int, char, long); int dummyInt; int main(int argc, char ** argv) { assert(false == test(functor, argc, 11, argv)); assert(true == test(functor, 10, 11, 12)); assert(true == test(f, 10, 11, 12)); assert(false == test(dummyInt, 1)); } Thanks, Andy.

5 10

Re: [boost] [castor] Interest in Logic Paradigm for C++ ?
by William Byrd 08 May '10

08 May '10

Hi Roshan! I'm a newbie C++ programmer, but I have experience designing logic programming languages (e.g., miniKanren in Scheme). I'm curious why Castor doesn't implement full unification. Is this because of the historical relationship between Castor and Leda? There are many interesting logic programs that can't be written naturally without full unification. (My dissertation contains many such programs, so I'm biased!) Many people in the logic programming community don't consider Mercury to be a real logic programming language precisely because it doesn't support full unification. Is Castor aiming towards the Mercury model, with the idea of adding mode annotations, etc., in the future? That might be a nice sweet spot for the Boost libraries. Otherwise, I would prefer to see full unification in any official Boost logic programming language/library. How hard would it be to add full unification to Castor, or to at least allow full unification as an option? --Will

2 1

Re: [boost] [rfc] Preliminary Hash Library
by Minh Phanivong 08 May '10

08 May '10

How about boost::hash_algo? Sent from my iPhone On 08/05/2010, at 11:51 PM, "Stewart, Robert" <Robert.Stewart(a)sig.com> wrote: Scott McMurray wrote: On 6 May 2010 06:01, Daniel James <dnljms(a)gmail.com> wrote: This will collide with the existing 'boost::hash' (an implementation of 'std::hash'). The simplest fix would be just changing the namespace to boost::hashes. Alternatively, the library could be renamed to Cryptographic_Hash and use boost::cryptographic_hash as its namespace, though that would cut off the possibility of following Paul Bristow's suggestion. Adding just one letter at the end makes for a rather slim differentiator, but I don't think it will hurt. We already have boost::tuple and boost::tuples, right? Unless you intend to create the Boost Cryptographic Hashing Library versus one that supports a wider range of hashing algorithms, don't include "cryptographic" in the name or namespace. What about Boost Hashing Algorithms Library with namespace boost::hashing_algorithms? A handy namespace alias would be "hal" or "ha." ;) _____ Rob Stewart robert.stewart(a)sig.com Software Engineer, Core Software using std::disclaimer; Susquehanna International Group, LLP http://www.sig.com IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses. _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

1 0

[rfc] Preliminary Hash Library
by Scott McMurray 08 May '10

08 May '10

I've boostified, cleaned up, and documented the Hash Library I mentioned here about a month ago. Comments, complaints, suggestions, and questions appreciated. Source code is in the sandbox at http://svn.boost.org/svn/boost/sandbox/hash/ Documentation can be read online at http://www.cs.mcgill.ca/~smcmur/hash/ I was very pleased by how the implementation came together, as templates mean that all the hash algorithms share a substantial portion of their code. Those details are all hidden from the user, though. Here's an example showing the simplest use of the library: #include <boost/hash.hpp> #include <iostream> #include <string> int main() { std::string s = "Hello World!"; typedef boost::hash::sha2<256> HashPolicy; HashPolicy::digest_type digest = boost::hash::compute_digest<HashPolicy>(s); std::cout << digest << "\n"; } Thanks, ~ Scott McMurray

7 14

[ASIO] Compilation improvements of 1.43 (well done)
by Artyom 08 May '10

08 May '10

Hello, In release notes of 1.43.0 version of Boost.Asio I had noticed improvements in compilation times and executable size. I must admit: WELL DONE!!! I'm in process of replacement of Boost.Asio event loop with my own that has very similar API but uses templates only where they absolutely necessary. I did some comparisons of my CppCMS library that implements with Asio. - HTTP server (tcp), - SCGI-server (tcp+unix-sockets), - FCGI-server (tcp+unix-sockets). - Memcached-like blocking-client and non-blocking server (TCP). Compiled with g++-4.3.2, on Debian, amd64, Linux 2.6.26 ------------------------------------------------------- Library size (after strip -s): ------------------------------ Boost.Asio 1.41.0 - 3,527,856 Boost.Asio 1.43.0 - 3,003,504 My AIO - 2,607,848 (2,455,344 cppcms-lib + 152,504 aio-lib). Moving from 1.41 to 1.43 reduced library by 0.5mb and this is huge difference However replacing Asio with my AIO (that hides almost everything behind pimpl) reduced additional 0.4mb Compilation times: HTTP-Server (tcp) 1.41.0 - 12.87s 1.43.0 - 7.45s my-aio - 4.30s SCGI-Server (tcp&unix) note Asio requires template based implementation as Unix socket class is different from tcp/ip ones so code almost can't be shared. My-AIO has same class so the code is not template based 1.41.0 - 14.31s 1.43.0 - 7.12s my-aio - 2.55s Again - huge difference: moving from 1.41 to 1.43 reduces time by half, but my-aio gives even better improvements. ---------------------------------------------- My Notes: 1. I'm really interested what had been done to give such huge improvements from 1.41 to 1.43? 2. Maybe it is wide to consider making Asio compiled library rather then header-only one? Artyom ------------ P.S.: I replace ASIO with my own library for several reasons not connected to quality of this specific library (it is great) but rather with issues I have with Boost and it's design. Also my library influenced by boost.asio API so rewriting was almost as simple as running several "sed" scripts over the source code.

2 1

[Serialization] 1.42.0 oserializer.hpp:394 bug?
by Krzysztof Czainski 08 May '10

08 May '10

File: serialization/oserializer.hpp, line 394: if(NULL == true_type){ boost::serialization::throw_exception( archive_exception( archive_exception::unregistered_class, true_type->get_debug_info() ) ); } I think, that if true_type is NULL, then true_type->get_debug_info() is UB.

3 2

Re: [boost] [Iterators] Iterators and higher-order programming
by Thomas Jordan 07 May '10

07 May '10

Mathias Gaunard wrote: -------------------------------------------------------------------- Message: 2 Date: Sun, 25 Apr 2010 12:33:51 +0100 From: Mathias Gaunard <mathias.gaunard(a)ens-lyon.org> To: boost(a)lists.boost.org Subject: Re: [boost] [Iterators] Iterators and higher-order programming Message-ID: <hr19av$sgp$1(a)dough.gmane.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Thomas Jordan a ?crit : > Hi, > One of the interesting things about the iterators library, it seems to me, is the additional support it gives for higher-order, > functional-style programming. For example, you can use the transform and filter iterators to produce a simple 'Comprehension' object > which permits list-comprehension type of syntax to be used, instead of conventional loops You might want to look at the range library then, which has been recently modified to add support for things like: some_range | transformed(f) | filtered(p) ----------------------------------------- Thanks/merci, Mathias (and apologies for my late reply), I am now looking at 1.43.0 Boost::Range! T.

2 1

bjam's use of O_NONBLOCK in execunix.c
by Dan Gohman 07 May '10

07 May '10

Hello, Why does bjam on "unix" platforms set the O_NONBLOCK flag when creating standard output and error pipes from the child process to the parent process? https://svn.boost.org/trac/boost/browser/trunk/tools/jam/src/execunix.c#L189 This was introduced in change r38009: https://svn.boost.org/trac/boost/changeset/38009 The parent process uses select(2) to block and wait for output from children, so it doesn't appear to need non-blocking file descriptors. Child processes are unrelated programs, and it seems mistaken to assume that they will want their stdout and stderr to be non-blocking. A project that I'm involved in recently had to add code to handle EAGAIN from a write(2) call by spinning until it succeeds, and it seems to be fairly common practice. It would seem to be better if the parent would just leave the file descriptors in blocking mode. Thanks, Dan

2 1

[fusion] BOOST_FUSION_ADAPT_CLASS* not documented
by Michael Caisse 07 May '10

07 May '10

I may be able to submit a patch after boostcon but I thought I would first check to see if this is just an issues with the latest docs not being checked in. I just verified the trunk is missing docs about the class adaption macros. regards - michael -- ---------------------------------- Michael Caisse Object Modeling Designs www.objectmodelingdesigns.com

2 1

[paired ptr] Proposing a new smart pointer object for managing bidirectional relationships between objects
by Dan Walters 07 May '10

07 May '10

Dear all, I have been working on a proposal for a useful utility for managing non hierarchal, bi-directional relationships between objects and as a useful tool in object composition. This utility is in the form of a type of templated smart pointer that can connect to one single other pointer and manage the relationship between the two pointers. This paired_ptr object is intended for use as a member of (or at least contained within) a user defined object and is conceptualized from the needs of object composition. Prototype source code, a usage example and brief documentation is available here: http://www.boostpro.com/vault/index.php?action=downloadfile&filename=paired… Doumentation only is available here: (this is a google doc and is continually being updated) http://docs.google.com/View?id=dc33pnfx_442s22z7d6 I am posting here in the hope it will generate suitable interest that it may be worth developing as a full library for submission. Best wishes, Dan

5 14

Re: [boost] [MSM] passing constructor arguments to frontend asreference.
by Christophe Henry 06 May '10

06 May '10

> Hi, All > > we might found a problem when passing constructor arguments to the > front end in case constructor arguments are passed by reference. > In that case you do not pass the argument as reference in the first > place rather copy construct a new object and pass that object as > reference to the front end. > We looked into the preprocessor code which we believe verified our assumption: > > (code snippet only contains the first part with one constructor argument!) > > template < class ARG0> > state_machine<Derived,HistoryPolicy,CompilePolicy >( ARG0 t0 ) > :Derived( t0) ,m_events_queue() ,m_deferred_events_queue() > ,m_history() ,m_event_processing(false) ,m_is_included(false) > ,m_visitors() ,m_substate_list() { ::boost::mpl::for_each< > seq_initial_states, ::boost::msm::wrap<mpl::placeholders::_1> > > (init_states(m_states)); m_history.set_initial_states(m_states); > fill_states(this); } > > > In our case, if we want to pass a reference, ARG0 has to be declared as follows: > template < class ARG0> > state_machine<Derived,HistoryPolicy,CompilePolicy >( ARG0& t0 ) > :Derived( t0) .... > > The "Derived" class looks like as follows: > class "Derived" > { > public: > Derived(SomeClass& cl_) {} > } > > Do you have any idea how to solve this? > > Thanks in advance. > > Richie & Michi Hi, It's a classical issue with template arguments and something I definitely should have written in the doc. To pass arguments by reference, you need to use boost::ref (or boost::cref for const references), for example: // The "Derived" class looks like as follows: class Derived : public msm::front::state_machine_def<Derived> { public: Derived(SomeClass& cl_) {} ... } typedef msm::back::state_machine<Derived> MyFsm; SomeClass stuff; ... MyFsm fsm (boost::ref(stuff)); Thanks for pointing this out, I will update the doc. Note: I fly tomorrow to the BoostCon, so I might be a bit less responsive (jetlagged) the first few days. HTH, Christophe

1 0

[1.43.0] Release Candidate available
by Beman Dawes 06 May '10

06 May '10

The 1.43.0 release candidate files are available at http://boost.cowic.de/rc/ Before these get pushed out to SourceForge, we like to get verification that they download and build OK. So please download one of these for your favorite platform, try a build, and report success or failure here. Thanks, --Beman

8 12

[1.43.0] Release notice
by Beman Dawes 06 May '10

06 May '10

Release 1.43.0 of the Boost C++ Libraries is now available. These open-source libraries work well with the C++ Standard Library, and are usable across a broad spectrum of applications. The Boost license encourages both commercial and non-commercial use. This release contains two new libraries (functional/factory, functional/forward), a major range library upgrade, plus numerous enhancements and bug fixes for other libraries. For details, including download links, see http://www.boost.org/users/news/version_1_43_0 The release can also be downloaded directly from SourceForge. See http://sourceforge.net/projects/boost/files/ To install this release on your system, see http://www.boost.org/doc/libs/1_43_0/more/getting_started/index.html Thanks to all who contributed, --The Boost release team

1 0

[MSM] passing constructor arguments to frontend as reference.
by Richard Szabo 06 May '10

06 May '10

Hi, All we might found a problem when passing constructor arguments to the front end in case constructor arguments are passed by reference. In that case you do not pass the argument as reference in the first place rather copy construct a new object and pass that object as reference to the front end. We looked into the preprocessor code which we believe verified our assumption: (code snippet only contains the first part with one constructor argument!) template < class ARG0> state_machine<Derived,HistoryPolicy,CompilePolicy >( ARG0 t0 ) :Derived( t0) ,m_events_queue() ,m_deferred_events_queue() ,m_history() ,m_event_processing(false) ,m_is_included(false) ,m_visitors() ,m_substate_list() { ::boost::mpl::for_each< seq_initial_states, ::boost::msm::wrap<mpl::placeholders::_1> > (init_states(m_states)); m_history.set_initial_states(m_states); fill_states(this); } In our case, if we want to pass a reference, ARG0 has to be declared as follows: template < class ARG0> state_machine<Derived,HistoryPolicy,CompilePolicy >( ARG0& t0 ) :Derived( t0) .... The "Derived" class looks like as follows: class "Derived" { public: Derived(SomeClass& cl_) {} } Do you have any idea how to solve this? Thanks in advance. Richie & Michi

1 0

Web site problems
by Beman Dawes 06 May '10

06 May '10

In a private email, Chris Ahlstrom reported: >On quite a few pages, when I enter the URL, a blank page comes up. > >Here's one example: > > http://www.boost.org/doc/tools/build/index.html It is actually weirder than that. The URL should be: http://www.boost.org/tools/build/index.html which should forward to: http://www.boost.org/doc/tools/build/v2/index.html but instead http://www.boost.org/doc/tools/build/index.html appears, and as a blank page. Any ideas? --Beman

2 5

1.43.0 range_ex
by Neal Becker 06 May '10

06 May '10

Before 1.43.0, range_ex had boost::make_reversed_range. In 1.43.0, it seems to have been renamed to boost::adaptors::reverse. This is unfortunate, as there is also a boost::reverse function that means something different.

5 7

[gsoc] heaps & queues
by Tim Blechmann 06 May '10

06 May '10

hi all, i'm the student, working on the heaps&queues project during this year's summer of code. i have also been in touch with my mentor about this, but thought, it may be a good idea to hear some comments from other boost devs. i would like to implement the priority queue data as intrusive data structures, which can simply be wrapped to non-intrusive ones. the main reason for this approach is the mutable property. in order to provide a mutable priority queue, one would either need a handle to the inner node (like in dietmar kuehl's pri_queue) or provide a lookup table (as in boost/pending/mutable_queue). both approaches are somehow problematic. otoh, if i want to change the priority of a node, it would be natural to use an intrusive data structure for this. the non-intrusive version would be simply a wrapped version of the intrusive implementation, and would simply lack the mutable property. the question then would be, whether i should try to introduce it into boost.intrusive, or implement it as a library on its own. boost.intrusive already provides a treap, so it would be quite logical to include heap data structures as well. otoh, having a heap library with both intrusive and non- intrusive data structures, one would have everything in one place. so, i see benefits in both approaches, but would like to hear, what other people think about it ... cheers, tim -- tim(a)klingt.org http://tim.klingt.org The first question I ask myself when something doesn't seem to be beautiful is why do I think it's not beautiful. And very shortly you discover that there is no reason. John Cage.

2 3

[1.43.0] Release Candidate available
by Ralf Globisch 06 May '10

06 May '10

boost_1_43_0.7zip build success with msvc-9.0 bjam toolset=msvc-9.0 --build-type=complete OS: Windows7 No python, no ICU, no MPI

2 1

[release][1.43] Release notes and some other things
by Daniel James 06 May '10

06 May '10

Hello all, Please can you add your release notes for 1.43. If you can't, or don't know how, then just send them to me and I'll do it for you. Sorry I'm late asking this time round. If you didn't realise, you don't have to wait for me to ask, I create the file for the release notes at the beginning of the release cycle. Also, if haven't done so already, can you check the inspect report for your library. It's not too late to fix simple inspect errors (eg. missing newlines, tabs, licenses, broken links) although it is too late to change any code (unless it's an actual bug, of course). You can find links to it on the testing page (http://www.boost.org/development/testing.html) And finally, can you have a look at your library's documentation on the beta site and let me know if it's messed up, as I've been tweaking the way the documentation is displayed. It's still displaying the 1.42 documentation, we only update that after the release. thanks, Daniel

7 12

[Inspect] More Apple issues
by John Maddock 06 May '10

06 May '10

I keep getting bug reports from users who want to compile code as Objective-C++ in order to use the Apple OS X headers... unfortunately this adds some more relatively common names that we can't use (http://developer.apple.com/mac/library/documentation/cocoa/conceptual/Objec…) id, Class, SEL, IMP, and BOOL Should we changes the inspect tool to complain about these as well? Obviously this is a pain in the &*^%, but it would stop my code from regressing (again) I guess... Cheers, John.

3 4

spoiled function declarations
by Lorenzo Caminiti 06 May '10

06 May '10

Hello all, I have been looking to which Boost libraries provide an interface that "spoils" usual C++ function declaration using macros. So far I found that both Boost.ConceptCheck and Boost.Parameter replace usual C++ function declaration using macros (see sample code below). Do you know of any other Boost library that "spoils" usual C++ function declaration? Boost.ConceptCheck: template<typename RanIter> BOOST_CONCEPT_REQUIRES( ((Mutable_RandomAccessIterator<RanIter>)) ((LessThanComparable<typename Mutable_RandomAccessIterator<RanIter>::value_type>)), (void)) // return type within macro instead that before function name stable_sort(RanIter,RanIter) { ... } Boost.Parameter (quite a bit more involved): BOOST_PARAMETER_FUNCTION( (void), // 1. parenthesized return type depth_first_search, // 2. name of the function template tag, // 3. namespace of tag types (required (graph, *) ) // 4. one required parameter, and (optional // four optional parameters, with defaults (visitor, *, boost::dfs_visitor<>()) (root_vertex, *, *vertices(graph).first) (index_map, *, get(boost::vertex_index,graph)) (in_out(color_map), *, default_color_map(num_vertices(graph), index_map) ) ) ) { // ... body of function goes here... // use graph, visitor, index_map, and color_map } Thank you very much. -- Lorenzo

6 6

[Bind] Interoperability of bind/mem_fn with transform_iterator
by Samuel Debionne 05 May '10

05 May '10

Hello all, I'm scratching my head about the correct way to use transform_iterator with bind and mem_fn. In brief, bind and mem_fn return object functions that are not Default Constructible, which means that, when used to construct a transform_iterator, the resulting transform_iterator is not even a Trivial Iterator. Most of the case, it's not a problem because the transform_iterator is never default constructed... until some libs that do concept checking on their template parameters are used. See the following code for exemple : #include <vector> #include <boost/bind.hpp> #include <boost/iterator/transform_iterator.hpp> #include <boost/iterator/iterator_concepts.hpp> #include <boost/concept/requires.hpp> struct foo { size_t id_; size_t get_id() const {return id_;} }; template <class ForwardIterator> void check(ForwardIterator _it) { using namespace boost; function_requires< boost_concepts::ForwardTraversalConcept<ForwardIterator> >(); } int main(int argc, char* argv[]) { using namespace boost; std::vector<foo> foo_vec; //Fail to compile since mem_fn is not Default Constructible check(make_transform_iterator( foo_vec.begin(), mem_fn(&foo::get_id))); //Fail to compile since mem_fn is not Default Constructible check(make_transform_iterator( foo_vec.begin(), mem_fn(&foo::id_))); return 0; } What would be the best way to handle the "problem" ? Patch the bind library to add some default constructors ? Best Regards, Samuel

5 13

[Proto] Broken on trunk
by Doug Gregor 05 May '10

05 May '10

Proto and the libraries that depend on it are broken in trunk: http://www.boost.org/development/tests/trunk/developer/proto.html It appears to be due to this change: https://svn.boost.org/trac/boost/changeset/61782 - Doug

2 1

Re: [boost] [xint] Third release is ready, requesting preliminary review
by Jürgen Hunold 05 May '10

05 May '10

On Tuesday, 4. May 2010 17:32:58 you wrote: > On 05/04/2010 05:51 AM, Jürgen Hunold wrote: > > And it make things easiser if you only have on "red" entry in the summary > > page and can just see which test file to look at. > > And smaller test cases are just current Boost standard. > > That works, then. Thanks for satisfying my curiosity. You're welcome. > > And I think the patch > > > > +#ifdef BOOST_XINT_SINGLE_TEST_PROGRAM > > + #define BOOST_TEST_DYN_LINK > > +#else > > + #define BOOST_TEST_MAIN > > +#endif > > > > is wrong. BOOST_TEST_DYN_LINK should always be defined on the command > > line when linking against a shared Boost.Test library. So, no source > > code #define is necessary. > > But removing the BOOST_TEST_MAIN from all but one of the files, when > using a single test program, is. Yes, BOOST_TEST_MAIN is needed. #if !defined(BOOST_XINT_SINGLE_TEST_PROGRAM) #define BOOST_TEST_MAIN #endif is the "correct" solution > I'm fairly new to Boost.Test, but the documentation gave me the > impression that you had to make a decision on whether to use dynamic > linking or not when you wrote the code, because static and dynamic > linking need slightly different setups. That would suggest that you > can't easily switch between them, wouldn't it? Well, I use the same code for static ansd shared linking :-)) You are using AUTO_TEST_CASEs, so there is no problem. All the needed magic is hidden in BOOST_TEST_MAIN in combination with BOOST_TEST_DYN_LINK. Using "manual registration" can be tricky. > > And this issues > > " > > test_main.cpp:95:1: warning: "BOOST_TEST_DYN_LINK" redefined > > <command-line>: warning: this is the location of the previous definition" > > > > when compiling a shared library with all Boost.Build magic enabled. > > Eh? The library code doesn't use Boost.Test, only the testing code does. > And even the testing code only includes that #define when > BOOST_XINT_SINGLE_TEST_PROGRAM is defined, which it should never be > except on my development machine, or that of someone else doing > modifications to the library. That would be me ;-) I've added the single test program locally to get the errors messages. Adding "BOOST_TEST_DYN_LINK" in source code is potentially dangerous. It should really be a commandline-option. It should be possible to set in Code::Blocks. > > By the way: > > You have deleted test/Jamroot. Should there be a "test/Jamfile" instead ? > > Yes, there should. Did it not make it into Subversion? Checking... it > appears that it's there, so I'm not sure what to tell you. Maybe check > it out manually? No, it is definetely missing. > > build/Jamfile.v2 still contains "nothrow_random.cpp" which was deleted in > > 61752 as well. > > Sorry, I didn't remember to update that. I would have caught it before a > final release though, I have an entire checklist of things to do for that. Good. > > And I think you may also check in files for other build systems, too. > > Some libraries have Makefiles as well as visual studio solutions. > > I didn't think anyone would care about my Code::Blocks or Visual Studio > projects. If there's some interest in them, I'll add them in the next > repository update. Not really. I've never used Code::Blocks ;-)) Yours, Jürgen -- * Dipl.-Math. Jürgen Hunold ! * voice: ++49 4257 300 ! Fährstraße 1 * fax : ++49 4257 300 ! 31609 Balge/Sebbenhausen * juergen.hunold(a)gmx.de ! -- * Dipl.-Math. Jürgen Hunold ! Ingenieurgesellschaft für * voice: ++49 511 262926 57 ! Verkehrs- und Eisenbahnwesen mbH * fax : ++49 511 262926 99 ! Lister Straße 15 * juergen.hunold(a)ivembh.de ! www.ivembh.de * * Geschäftsführer: ! Sitz des Unternehmens: Hannover * Prof. Dr.-Ing. Thomas Siefer ! Amtsgericht Hannover, HRB 56965 * PD Dr.-Ing. Alfons Radtke !

2 1

[xint] Boost.Move vs Copy-on-Write timings
by Chad Nelson 05 May '10

05 May '10

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I've done some further testing, eliminating the Boost.Thread locking on the random number generator as a factor, as promised earlier today. Here are the raw timings: (Debug build) Baseline: 29.4, 36.0, 32.8 (32.73) GCC move: 32.0, 35.3, 31.2 (32.83) Emulated Move: 28.4, 33.8, 28.4 (30.20) Copy-on-write: 27.3, 25.0, 26.9 (26.40) (Release build) Baseline: 10.5, 12.5, 10.6 (11.20) GCC move: 11.3, 13.0, 10.4 (11.57) Emulated move: 10.0, 10.8, 9.7 (10.17) Copy-on-write: 8.5, 8.4, 9.4 ( 8.77) Times are measured in seconds, using two sets of ten 2048-bit integers. The tests consisted of adding each of those pairs of numbers together 10,000 times, multiplying them 10,000 times, and doing a "mulmod" operation on them (with a third randomly-generated 2048-bit modulus argument) 1,000 times. Each test was run three times, under as close to identical situations as I could manage, with the raw results (rounded to the nearest tenth of a second) in the first three columns; the fourth column is the average of the three. The compiler used was GCC 4.4.3, under Ubuntu Linux 10.04. The release build used -O2 optimization; the debug build used none. Otherwise, the settings were left at their defaults, except where noted below. The baseline configuration had neither copy-on-write nor any kind of move semantics enabled. The "emulated move" rows used the baseline configuration plus Boost.Move in C++03 emulation mode, with no copy-on-write; the "GCC move" rows indicate the exact same configuration, except that I used "-std=c++0x" as well (so presumably Boost.Move would switch to compiler-supplied move semantics). The copy-on-write rows used the baseline configuration, but enabled my copy-on-write system. Using the calculation... (baseline_time - time) / baseline_time ... copy-on-write provided a 19.3% and 21.7% speed increase over the baseline settings. Boost.Move emulation provided 7.7% and 9.2%. GCC-provided move semantics were, surprisingly, the worst performers, coming in at 0.3% and 3.3% *worse* than the baseline performance. I'm assuming that that code hasn't been optimized yet, and that it will eventually be a lot faster. Conclusions: * The copy-on-write system is faster than Boost.Move emulation by a respectable amount, and an even greater one than my earlier tests indicated. * The non-thread-safe version is *not* twice the speed of the thread-safe one, as I erroneously indicated before. Much of the difference must have come from the random number locking. It's still markedly faster, as it uses copy-on-write and the thread-safe version can only use Boost.Move, but only by about 12%. Am I missing any statistics? Does anyone want the test code to reproduce this and look for errors in my test setup? It's only a small modification from the code in the sandbox and vault, plus the test function. - -- Chad Nelson Oak Circle Software, Inc. * * * -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkvd5ZwACgkQp9x9jeZ9/wTnnQCfYt1MrUNFGnYKNJImYKuuryDf HfYAoIrXeBgsT25cCwI/oiIAShSyvyh0 =nZxq -----END PGP SIGNATURE-----

7 36

[GSoC] Helping out Phoenix v3
by Joel Falcou 04 May '10

04 May '10

Joel and I pondered about getting a student from GSoC to help us complete the phoenix v3 port to proto. I currently have a few prototypes and ideas to extend it further but a few more hands are most welcome. Considering the schedule, I'll be compeltely free for mentoring this prospective student. Now, is it realistic and on topic for GSoC ?

9 33

boost atomic question
by Janek Kozicki 04 May '10

04 May '10

Hello Helge, What would it take to get this code to work? std::vector<boost::atomic<Something> > v; v.resize(100); best regards -- Janek Kozicki http://janek.kozicki.pl/ |

6 12

Re: [boost] [xint] Third release is ready, requesting preliminary review
by Jürgen Hunold 04 May '10

04 May '10

Hi Chad, Am Dienstag, 4. Mai 2010, um 01:26:42 schrieben Sie: > On 05/03/2010 08:37 AM, Juergen Hunold wrote: > > Well, I'm concentrating on Boost.Build issues. The rest looks nice. > > Please find some improvements to you current setup attached. [...] > > I'm confused... I thought you'd done something different. It seems I should submit smaller pachtes, my fault. > Why did you > split up the test program into multiple programs? What benefit does that > offer over a single executable? Well, as long as you run the tests locally, this might be better. But as soon as your lib is part of the regular regression tests, you have to deal with *lots* of possible errors. This could be: - timeout on slow machines due to too long execution time - compile and/or link errors And it make things easiser if you only have on "red" entry in the summary page and can just see which test file to look at. And smaller test cases are just current Boost standard. And I think the patch +#ifdef BOOST_XINT_SINGLE_TEST_PROGRAM + #define BOOST_TEST_DYN_LINK +#else + #define BOOST_TEST_MAIN +#endif is wrong. BOOST_TEST_DYN_LINK should always be defined on the command line when linking against a shared Boost.Test library. So, no source code #define is necessary. The code above breaks when doing "bjam link=static" with "in function main:/rmc/hunold/packages/boost/boost/test/unit_test.hpp:59: error: undefined reference to 'boost::unit_test::unit_test_main(bool (*)(), int, char**)'" because Boost.Test expects "main" to be linked into the static library. And this issues " test_main.cpp:95:1: warning: "BOOST_TEST_DYN_LINK" redefined <command-line>: warning: this is the location of the previous definition" when compiling a shared library with all Boost.Build magic enabled. By the way: You have deleted test/Jamroot. Should there be a "test/Jamfile" instead ? build/Jamfile.v2 still contains "nothrow_random.cpp" which was deleted in 61752 as well. And I think you may also check in files for other build systems, too. Some libraries have Makefiles as well as visual studio solutions. Yours, Jürgen -- * Dipl.-Math. Jürgen Hunold ! * voice: ++49 4257 300 ! Fährstraße 1 * fax : ++49 4257 300 ! 31609 Balge/Sebbenhausen * juergen.hunold(a)gmx.de ! -- * Dipl.-Math. Jürgen Hunold ! Ingenieurgesellschaft für * voice: ++49 511 262926 57 ! Verkehrs- und Eisenbahnwesen mbH * fax : ++49 511 262926 99 ! Lister Straße 15 * juergen.hunold(a)ivembh.de ! www.ivembh.de * * Geschäftsführer: ! Sitz des Unternehmens: Hannover * Prof. Dr.-Ing. Thomas Siefer ! Amtsgericht Hannover, HRB 56965 * PD Dr.-Ing. Alfons Radtke !

2 1

[xint] Boost.Move vs Copy-on-Write timings, remeasured
by Chad Nelson 04 May '10

04 May '10

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Thanks to a bug that I was blind to, and that Jeffrey Hellrung gently pointed out (for which I give him public thanks), the earlier timings weren't accurate. I've corrected the problem and remeasured the times. You can find the earlier timings, along with the details of the testing, here: <http://permalink.gmane.org/gmane.comp.lib.boost.devel/203539>. Here are the updated timings (for release builds only, I didn't see a point in doing debug builds this time): Baseline: 8.6, 8.8, 8.8 (8.73) GCC move: 8.6, 8.6, 8.8 (8.67) Emulated move: 8.8, 8.5, 8.6 (8.63) Copy-on-write: 6.5, 6.7, 6.9 (6.70) Comparing to the originals, it looks like the change benefited all four, but I guarantee that it couldn't have affected the copy-on-write score. The only way I can explain the overall reduction is that my (virtual) development machine was running slower in the old tests. The change in relative scores is more interesting. The baseline, GCC move, and emulated move scores are now within 1% of each other, strongly suggesting that the compiler's Return Value Optimization is making the inclusion of Boost.Move nearly irrelevant. Emulated move semantics still beat out the compiler-supplied ones, but the difference is so small that that could well be within the margin of error. What is surprising and somewhat baffling to me is that even though the copy-on-write code wasn't affected by the change, that version is *still* better, and by an even (slightly) larger percentage than before (23.2%, as opposed to 21.7% in the previous test). I can only come up with two possible explanations for that: either there's some other piece of code in there that's preventing move semantics from working to their full potential, or copy-on-write is benefiting something other than return values, and by a ridiculously large amount. In either case, I don't know what could be responsible, but I'll keep looking for it. The updated code is now in the sandbox, for those who might want to test it themselves. - -- Chad Nelson Oak Circle Software, Inc. * * * -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkvgNHEACgkQp9x9jeZ9/wRAOACeMf9Lvu2Zn/uduwRAVYIH11o9 swgAoKsmap30FR4MywZ1uy+ON2+gjfy7 =VoRk -----END PGP SIGNATURE-----

1 0

Re: [boost] [iterator] Help needed understanding output_iterator requirements
by Thomas Klimpel 04 May '10

04 May '10

Dear authors of Boost.Iterator, As described in <http://lists.boost.org/Archives/boost/2010/03/163133.php>, Boost.MultiArray is currently unusable with the recently released MSVC 10. This is also confirmed by many failures in the regression tests: <http://www.boost.org/development/tests/release/developer/multi_array.html>. These failures are caused by a specific behavior of iterator_facade from Boost.Iterator, introduced by Jeremy Siek with the explanation "changed iterator_facade_default_category to stop lying about output_iterator_tag": <https://svn.boost.org/trac/boost/changeset/21683>. I'm not the right person to judge (or understand) how serious the original code was a lying, but the attached patch that conditionally reintroduces the original behavior as a workaround for MSVC 10 fixes all compile failures of the regression tests of Boost.MultiArray for me (MSVC 10 does compile time checking of iterator categories when _HAS_ITERATOR_DEBUGGING is defined). However, the "resize" regression test then fails with a runtime error (assertion failure) instead of a compile error: testing.capture-output ..\..\..\bin.v2\libs\multi_array\test\resize.test\msvc-10.0\debug\threading-multi\resize.run ====== BEGIN OUTPUT ====== Assertion failed: index_bases[n] <= start && start < index_bases[n]+index(extents[n]), file C:\nobackup\boost_trunk\boost/multi_array/base.hpp, line 446 C:\nobackup\boost_trunk\boost/test/minimal.hpp(123): exception "R6010 - abort() has been called " caught in function: 'int __cdecl main(int,char *[])' **** Testing aborted. **** 1 error detected EXIT STATUS: 201 ====== END OUTPUT ====== I have no idea whether this failure is related to the reintroduced lying or not. All I know is that there have been recent request to find "some kind of proper workaround or fix" for these issues: <http://lists.boost.org/Archives/boost/2010/04/165548.php>. But from my point of view, the only responsibility I may have with respect to these issues is to notify the authors of the affected libraries, which I have done now. Regards, Thomas

2 3

[GSoC] Bonding period
by Andrew Sutton 04 May '10

04 May '10

Hi All, If your proposal was accepted for GSoC 2010, then you will need to read this email thoroughly since it outlines the basic instructions for getting started with Boost development and your Summer Work. There are a couple of things you'll have to do (detailed instructions follow). 1. Introduce yourself to your mentor 2. Request SVN sandbox access from the Boost owners 3. Get started with Boost 4. Read about bjam and Quickbook 5. Write Code = Detailed instructions = == Introducing Yourself == Send an email to your mentor from the account that you want to receive Boost GSoC-related communications from. We're collecting your contact information in case we need to get in touch. If you have other secondary email address', please forward those also. There may be some organizational overhead to interacting with your mentor. We are still determining the best way to manage some aspects of this process. == Requesting SVN Access == Email the boost owner mailing list and request SVN *sandbox* write access for your GSoC project. Be sure to state that you are a student working on a GSoC 2010 project. Detailed instructions are given here [1] under "Getting a Trac SVN Userid". Your work will ultimately be hosted in this URL [2]. * Note to owners: if you want to validate students you can email me or I can grant you access to the GSoC webapp. == Getting Started == Read this [3] carefully, and follow the instructions. If you want to build Boost's trunk, follow the instructions here [4]. == Bjam and Quickbook == Bjam is the build tool used to compile Boost libraries, test suites, examples, and applications. For information on writing Bjam project files, read the manual, here [5]. Quickbook is the preferred* tool used to document the Boost libraries. It is a frontend to the BoostBook XML schema, which is an extension of the DocBook schema. The documentation toolchain is used to build online and PDF documentation for the Boost libraries. Documentation for writing Quickbook files can be found here [6]. * I could be wrong, but it is popular and also quite nice. == Writing Code == I would suggest trying to build (and document) some small example programs using the Boost development environment before diving in to your project. For example, port some of your programming assignments to Boost -- just don't commit them to the SVN repository :) This will help familiarize you with the Boost infrastructure. Also, read the Boost Guidelines and Requirements [7] before starting your project. These determine the layout of your directory structuring, how to name your files, and basic styles used throughout the Boost C++ Libraries. Additional information on techniques for generic programming can also be found here [8]. These techniques are used throughout many Boost libraries and are definitely worth reading about and understanding. I think that's about it for now. If I missed something, hopefully one of the other contributors will be able to point it out :) Welcome to Boost, and good luck on your summer projects! Andrew Sutton andrew.n.sutton(a)gmail.com [1] https://svn.boost.org/trac/boost/#GettingaTracSVNUserid [2] http://svn.boost.org/svn/boost/sandbox/SOC/2010/ [3] http://www.boost.org/doc/libs/1_42_0/more/getting_started/index.html [4] https://svn.boost.org/trac/boost/wiki/BoostSubversion [5] http://www.boost.org/doc/tools/build/doc/html/index.html [6] http://www.boost.org/doc/libs/1_42_0/doc/html/quickbook.html [7] http://www.boost.org/development/requirements.html [8] http://www.boost.org/community/generic_programming.html

7 16

[1.43.0] Release freeze
by Beman Dawes 04 May '10

04 May '10

AFAIK, we are ready to generate the 1.43.0 release candidates. For the current state of the release branch, see http://beta.boost.org/development/tests/release/developer/summary.html Please make no further changes to branches/release. I plan to generate release candidates later today. --Beman PS: There are still a number of VC++ 10 failures, but they will have to wait until after the release. I think we need a bug fixing sprint fairly soon to address those and other accumulated issues.

1 0

Re: [boost] [repost][multiarray] Bug with boost::detail::multi_array::array_iterator on MSVC 2010RC?
by Thomas Klimpel 04 May '10

04 May '10

Jesse Perla wrote: > I have attached my test files. Any ideas or patches would be appreciated I could reproduce the problem with MSVC 2010beta2. I noticed that only the debug version fails to build. So I added the line #define _HAS_ITERATOR_DEBUGGING 0 and everything compiled fine. So the simplest solution is to add ADD_DEFINITIONS(-D_HAS_ITERATOR_DEBUGGING=0) to your CMakeLists.txt, which many people recommend in any case, because they claim that the debug version under MSVC would otherwise violate the "runtime complexity specifications" of the corresponding containers and iterators. (I don't know whether this is really true, but I really think that this workaround is not unreasonable.) But of course, you want to know whether this is a bug in boost::multi_array or a bug in MSVC 2010beta2. Before we come to that, another "workaround" would be to change multi_array/iterator.hpp:56 for , boost::random_access_traversal_tag to , std::random_access_iterator_tag This will most probably work, but would lying to the standard library, because the reference reference type of the corresponding iterator is not value_type& (but a proxy): http://lists.boost.org/boost-users/2006/11/23565.php What effectively happens it that the iterator gets the category "input_iterator", but std::copy wants to have an "output_iterator". I think I understand why the iterator doesn't satisfies the requirement of a "forward_iterator", but it's unclear to me why it didn't qualify as an "output_iterator". There is an "input_output_iterator_tag" in "boost/iterator/detail/facade_iterator_category.hpp", so it would have been possible for the iterator to be both "input_iterator" and "output_iterator". However, it seems to me that "input_output_iterator_tag" is never used in the Boost.Iterator library. I would have to read more about "output_iterator" to understand whether Boost.Iterator is correct here. With my current understanding of "output_iterator", I would say it's a bug in "boost/iterator/detail/facade_iterator_category.hpp". Perhaps somebody with more knowledge about "output_iterator" and Boost.Iterator can explain to me why an iterator using the "boost::random_access_traversal_tag" for the "CategoryOrTraversal" template parameter of "iterator_facade" will never get the category "output_iterator" (or "input_output_iterator_tag"). Regards, Thomas

4 6

sun4v compile error
by Rohit Goel 04 May '10

04 May '10

Hi, I am using the interprocess package of boost for file locks. Though the code builds fine on Windows & Linux, I get the following errors on Solaris "/etc/sw//boost/interprocess/detail/move.hpp", line 649: Error: Templates can only declare classes or functions. "/etc/sw//boost/interprocess/detail/move.hpp", line 656: Error: A declaration was expected instead of "while". "/etc/sw//boost/interprocess/detail/move.hpp", line 656: Error: No direct declarator preceding "(". "/etc/sw//boost/interprocess/detail/move.hpp", line 658: Error: Multiple declaration for f. "/etc/sw//boost/interprocess/detail/move.hpp", line 658: Error: A declaration was expected instead of "++". "/etc/sw//boost/interprocess/detail/move.hpp", line 660: Error: A declaration was expected instead of "return". "/etc/sw//boost/interprocess/detail/move.hpp", line 668: Error: Templates can only declare classes or functions. "/etc/sw//boost/interprocess/detail/move.hpp", line 672: Error: A declaration was expected instead of "}". "/etc/sw//boost/interprocess/detail/move.hpp", line 686: Error: is_movable is not defined. "/etc/sw//boost/interprocess/detail/move.hpp", line 686: Error: enable_if is not defined. "/etc/sw//boost/interprocess/detail/move.hpp", line 686: Error: type is not defined. "/etc/sw//boost/interprocess/detail/move.hpp", line 695: Error: is_movable is not defined. "/etc/sw//boost/interprocess/detail/move.hpp", line 695: Error: disable_if is not defined. "/etc/sw//boost/interprocess/detail/move.hpp", line 695: Error: type is not defined. "/etc/sw//boost/interprocess/detail/move.hpp", line 696: Error: A previously specified default argument value cannot be changed. "/etc/sw//boost/interprocess/detail/move.hpp", line 696: Error: move_detail::uninitialized_move_move_iterator<move_detail::I, move_detail::F>(move_detail::I, move_detail::I, move_detail::F, int*) already had a body defined. "/etc/sw//boost/interprocess/detail/move.hpp", line 706: Error: is_move_iterator is not a member of move_detail. "/etc/sw//boost/interprocess/detail/move.hpp", line 706: Error: Unexpected type name "I" encountered. "/etc/sw//boost/interprocess/detail/move.hpp", line 706: Error: Expression must have a constant value. "/etc/sw//boost/interprocess/detail/move.hpp", line 706: Error: enable_if is not defined. "/etc/sw//boost/interprocess/detail/move.hpp", line 706: Error: type is not defined. "/etc/sw//boost/interprocess/detail/move.hpp", line 730: Error: is_move_iterator is not a member of move_detail. "/etc/sw//boost/interprocess/detail/move.hpp", line 730: Error: Unexpected type name "I" encountered. "/etc/sw//boost/interprocess/detail/move.hpp", line 730: Error: Expression must have a constant value. "/etc/sw//boost/interprocess/detail/move.hpp", line 730: Error: disable_if is not defined. Any ideas what could be wrong ? -Rohit

1 0

[xint] granularity
by vicente.botet 03 May '10

03 May '10

Hi, N1692 talks about granularity "For the operations on the integer data, its granularity must be defined, that is how wide are the data chunks that are operated on". Which is the granularity for Xint? _____________________ Vicente Juan Botet Escribá http://viboes.blogspot.com/

2 1

[date_time] Maintainer?
by conferno 03 May '10

03 May '10

Hi, boost::date_time has a lot of bugs: https://svn.boost.org/trac/boost/report/14?page=2 Their owner is az_sw_dude, who seems to be inactive since 2007: https://svn.boost.org/trac/boost/search?q=az_sw_dude http://groups.google.com/groups/search?hl=en&q=az_sw_dude Who is the maintainer of boost::date_time and is there any hope that the bugs will be fixed ?

3 2

DotNet FileSystemWatcher like library proposal.
by Fernando Pelliccioni 03 May '10

03 May '10

Hello all, I am working on a library like DotNet FileSystemWatcher ( http://msdn.microsoft.com/en-us/library/system.io.filesystemwatcher%28VS.80…) Basically the library monitors for file system changes and notifies throwing events. First, it will support the following platforms: - Windows NT 5.0 (Windows 2000) or higher using O/I Completion Port. - Linux 2.6.13 or higher using inotify. - FreeBSD 4.1 or higher using kqueue. - NetBSD 2.0 or higher using kqueue. - OpenBSD 3.6 higher using kqueue. (Not sure which version supports it) - MacOS/X 10.4 higher using kqueue. (Not sure which version supports it) Future supported platforms: - Linux from 2.4.0-test9 2.6.12 using dnotify. - Sun OpenSolaris using FEM API. Testing: I am testing the library on FreeBSD 7.2, Linux 2.6.31, Windows XP (Windows NT 5.1). I need help to test on older versions of these operating systems. Also in NetBSD, OpenBSD and mainly on MacOSX because I do not have the necessary hardware. I would like to include this library in Boost, I think would be useful. What do you think? If so, I would like to have a mentor (like GSoC) and experienced in Boost development. Thanks and regards, Fernando Pelliccioni --- References: - O/I Completion Port: http://msdn.microsoft.com/en-us/library/aa365198%28VS.85%29.aspx http://en.wikipedia.org/wiki/Input/output_completion_port - inotify: http://en.wikipedia.org/wiki/Inotify - kqueue: http://people.freebsd.org/~jlemon/papers/kqueue.pdf http://en.wikipedia.org/wiki/Kqueue - dnotify: http://en.wikipedia.org/wiki/Dnotify

6 8

[xint] what about a DSEL?
by vicente.botet 03 May '10

03 May '10

Hi Chad, I dont know the complexity of the algorithms behind the xint operations, but instead of making eager evaluation you could do lazy evaluation. You could define a DSEL which evaluates the expression x*y + z at once. it would be great if at the end w = x*y + z; resulted in only one allocation for the result of the expression, and a move to make the assignement. If given two integers i and j using n and m bits, you know the number of bits needed by i @ j, you can know the number of bits of x*y + z, isn't it? If in addition, the rhs expression resulted on a integer needing less bits than the lsh, you could do the operation directly on the lhs, avoiding any allocation! My 2cts, _____________________ Vicente Juan Botet Escribá http://viboes.blogspot.com/

1 0

[multi_array]regression test failures on trunk
by Thomas Klimpel 02 May '10

02 May '10

Hi, the Boost.MultiArray regression test for "resize" fails on trunk (<http://www.boost.org/development/tests/trunk/developer/multi_array.html>), but passes on the release branch (<http://www.boost.org/development/tests/release/developer/multi_array.html>). This recently created some confusion for me (<http://lists.boost.org/Archives/boost/2010/05/165798.php>), because I was looking at the regression test results for the release branch, but did my local testing on trunk. The failures on trunk are caused by the changes from the commit <https://svn.boost.org/trac/boost/changeset/53789>. These changes were never merged to the release branch. The attached patch seems to fix these failures, but I take no responsibility for its correctness (as I've only tried to find the changes that caused the failure, but have not tried to understand the code). Regards, Thomas

1 0

Re: [boost] [castor] Interest in Logic Paradigm for C++ ?
by Joris IJsselmuiden 02 May '10

02 May '10

My humble opinion to the matter: I think it is a great idea to try and make Castor part of Boost. I have been using Castor in my research for a while now, and I think that it is definitely Boost-material. A logic engine can be a powerful tool, and it is a shame that C++ doesn't have one readily available. I am confident that Castor is the best choice for adding logic support to Boost. As far as I know, Boost is the most popular code-base that is not part of the C++ standard library yet. So, making Castor part of Boost would be a great way of increasing Castor's visibility. It would be nice to keep Castor available as a stand-alone library, so that you don't need Boost if you only want to use Castor. But I am sure that this issue can be solved: Castor could be a Boost "companion" library, or one could have a stand-alone version and a Boost version side-by-side. Although this last solution doesn't seem that great to me. I hope I will find the time to do some testing for Castor 1.1. Keep in touch! Joris Ijsselmuiden _________________________________________________________________ Hotmail: Powerful Free email with security by Microsoft. https://signup.live.com/signup.aspx?id=60969

3 3

Parallel Boost Algorithm
by anil khadka 02 May '10

02 May '10

I am pretty new to both boost and parallel boost. I am using Brandes Centrality algorithm, but the performance really doesn't meet my expectation. If I used Java, which is only using 1 CPU core would complete it in around 30 hrs. The parallel version which use 8 CPU cores tooks 17 hours!! I don't know why there is just around 13 hours gain if i use 8 cores against 1, unless there are lots and lots of communication between each cores. I am using just 1 machine (not a cluster), right now. Graph size is Node 80K, edges 120K I am reading edges from files. I used distributed compressed_sparse_row to represent graph. Right now, it seems like all the cpu cores are reading files on its own, I am assuming each CPU core will takes its graph part automatically (distributed algorithm do it ?). Note: I downloaded the parallel version from: http://osl.iu.edu/research/pbgl/software/ Any help/suggestions would be really appreciated. Metanil.

2 1

[Wave][1.43] Asking for permission to merge low impact bug
by Hartmut Kaiser 01 May '10

01 May '10

Hey, I would like to ask for the permission to merge a low impact bug to the release branch (patch: https://svn.boost.org/trac/boost/changeset/61723) Regards Hartmut --------------- Meet me at BoostCon www.boostcon.com

2 1

[contract] next round of development
by Lorenzo Caminiti 01 May '10

01 May '10

Hello all, FYI, I am starting the next round of development of Boost.Contract. Most of the planned modifications derive from feedback I have received from this mailing list -- thanks! My goal is to request Boost.Contract formal review after this round of development and related documentation updates. You can check the planned development items at: http://sourceforge.net/tracker/?group_id=253844&atid=1330818 Comments are always welcome. Regards, -- Lorenzo

2 2

Re: [boost] Implementation of Factorization Library (
by abhijith reddy 01 May '10

01 May '10

abhijith reddy wrote: > I am interested in implementing a module that will factor large numbers > (10^25 -10^30) .. > I think this can be added into the existing math and numerics library in > boost. > I'd be grateful if some could share their thoughts on this and comment on > it. > > Thank you > ______________________________ > > _________________ > > Unsubscribe & other changes: > http://lists.boost.org/mailman/listinfo.cgi/boost > > > Maybe you should collaborate with the GSoC student currently developing > the Bigint library? > > Adam Smith Implementation of arbitrary precision integers (BigInts) > for Boost Rene Rivera accepted > > Yours, > Stefan > Hello That may not be needed , Since the numbers here are much smaller and more importantly positive. And Hence the help of such a generic library is not be needed. Besides i have most of the code ready, i just have to port it into boost specific format. So I am looking for the community's interest in the proposal. Thank you On Fri, Apr 30, 2010 at 9:30 PM, <boost-request(a)lists.boost.org> wrote: > Send Boost mailing list submissions to > boost(a)lists.boost.org > > To subscribe or unsubscribe via the World Wide Web, visit > http://lists.boost.org/mailman/listinfo.cgi/boost > or, via email, send a message with subject or body 'help' to > boost-request(a)lists.boost.org > > You can reach the person managing the list at > boost-owner(a)lists.boost.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Boost digest..." > > > The boost archives may be found at: http://lists.boost.org/Archives/boost/ > > Today's Topics: > > 1. Implementation of Factorization Library (abhijith reddy) > 2. Re: [any] boost::get style accessors (Christoph Heindl) > 3. Re: [any] boost::get style accessors (Stewart, Robert) > 4. Re: [castor] Interest in Logic Paradigm for C++ ? > (Johannes Brunen) > 5. DotNet FileSystemWatcher like library proposal. > (Fernando Pelliccioni) > 6. Re: [castor] Interest in Logic Paradigm for C++ ? > (Joris IJsselmuiden) > 7. Re: [xint] Third release is ready, requesting preliminary > review (Chad Nelson) > 8. Re: Implementation of Factorization Library (Stefan) > 9. Re: [xint] Third release is ready, requesting preliminary > review (Chad Nelson) > 10. Re: Implementation of Factorization Library (Rene Rivera) > 11. boost atomic question (Janek Kozicki) > 12. Re: boost atomic question (Janek Kozicki) > 13. Re: boost atomic question (edouard(a)fausse.info) > 14. Re: boost atomic question (Vicente Botet Escriba) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Fri, 30 Apr 2010 18:52:41 +0530 > From: abhijith reddy <abhijith200690(a)gmail.com> > To: boost(a)lists.boost.org > Subject: [boost] Implementation of Factorization Library > Message-ID: > <u2pbb2644e11004300622g7b80a854w88986e55d76869c3(a)mail.gmail.com> > Content-Type: text/plain; charset=ISO-8859-1 > > I am interested in implementing a module that will factor large numbers > (10^25 -10^30) .. > I think this can be added into the existing math and numerics library in > boost. > I'd be grateful if some could share their thoughts on this and comment on > it. > > Thank you > > > ------------------------------ > > Message: 2 > Date: Fri, 30 Apr 2010 15:28:02 +0200 > From: Christoph Heindl <christoph.heindl(a)gmail.com> > To: boost(a)lists.boost.org > Subject: Re: [boost] [any] boost::get style accessors > Message-ID: > <k2ibac4b0ff1004300628pee41037r724711ac806ba19a(a)mail.gmail.com> > Content-Type: text/plain; charset=ISO-8859-1 > > On Fri, Apr 30, 2010 at 12:57 PM, Stewart, Robert > <Robert.Stewart(a)sig.com> wrote: > > > > +1 for having a common approach to extracting such values. ?boost::get<> > is consistent with tuples, not just variant, so I think it is the right > interface. ?any_cast is, of course, highly specific. > > > > What are the next logical steps? Should I come up with an initial > implementation and post it as patch (against the trunk) to the mailing > list, or should I remain silent until some decision is made by library > maintainers, people on the mailing list or whoever is in charge. > > -- Christoph > > > ------------------------------ > > Message: 3 > Date: Fri, 30 Apr 2010 09:35:05 -0400 > From: "Stewart, Robert" <Robert.Stewart(a)sig.com> > To: "boost(a)lists.boost.org" <boost(a)lists.boost.org> > Subject: Re: [boost] [any] boost::get style accessors > Message-ID: > <DF2E67F3D097004694C8428C70A3FD690473E80AE4(a)msgbal516.ds.susq.com> > Content-Type: text/plain; charset="iso-8859-1" > > Christoph Heindl wrote: > > On Fri, Apr 30, 2010 at 12:57 PM, Stewart, Robert > > <Robert.Stewart(a)sig.com> wrote: > > > > > > +1 for having a common approach to extracting such values. > > > boost::get<> is consistent with tuples, not just variant, so > > > I think it is the right interface. any_cast is, of course, > > > highly specific. > > > > What are the next logical steps? Should I come up with an initial > > implementation and post it as patch (against the trunk) to the mailing > > list, or should I remain silent until some decision is made by library > > maintainers, people on the mailing list or whoever is in charge. > > Submit a patch via Trac and mention the Trac ticket here. If the > maintainer (Kevlin Henney) doesn't notice the ticket after a reasonable > time, we can try other ways to get his attention. > > _____ > Rob Stewart robert.stewart(a)sig.com > Software Engineer, Core Software using std::disclaimer; > Susquehanna International Group, LLP http://www.sig.com > > IMPORTANT: The information contained in this email and/or its attachments > is confidential. If you are not the intended recipient, please notify the > sender immediately by reply and immediately delete this message and all its > attachments. Any review, use, reproduction, disclosure or dissemination of > this message or any attachment by an unintended recipient is strictly > prohibited. Neither this message nor any attachment is intended as or should > be construed as an offer, solicitation or recommendation to buy or sell any > security or other financial instrument. Neither the sender, his or her > employer nor any of their respective affiliates makes any warranties as to > the completeness or accuracy of any of the information contained herein or > that this message or any of its attachments is free of viruses. > > > ------------------------------ > > Message: 4 > Date: Fri, 30 Apr 2010 16:07:38 +0200 > From: "Johannes Brunen" <JBrunen(a)DataSolid.de> > To: boost(a)lists.boost.org > Subject: Re: [boost] [castor] Interest in Logic Paradigm for C++ ? > Message-ID: <hreo8n$6ib$1(a)dough.gmane.org> > > Count me interested a lot... > > Best, > Johannes > > "Roshan Naik" <roshan_naik(a)yahoo.com> schrieb im Newsbeitrag > news:007b01cae76b$4472eda0$cd58c8e0$@com... > > Based on suggestions from some Boost community experts, I would like to > > gauge interest to see if there is broader interest for including the > > Castor > > library into Boost. > > > > > > ------------------------------ > > Message: 5 > Date: Fri, 30 Apr 2010 00:43:22 -0300 > From: Fernando Pelliccioni <fpelliccioni(a)gmail.com> > To: boost(a)lists.boost.org > Subject: [boost] DotNet FileSystemWatcher like library proposal. > Message-ID: > <j2n69897ea01004292043hb64da836w9a731c64d92bfbc5(a)mail.gmail.com> > Content-Type: text/plain; charset=ISO-8859-1 > > Hello all, > > I am working on a library like DotNet FileSystemWatcher ( > > http://msdn.microsoft.com/en-us/library/system.io.filesystemwatcher%28VS.80… > ) > > Basically the library monitors for file system changes and notifies > throwing > events. > > First, it will support the following platforms: > - Windows NT 5.0 (Windows 2000) or higher using O/I Completion Port. > - Linux 2.6.13 or higher using inotify. > - FreeBSD 4.1 or higher using kqueue. > - NetBSD 2.0 or higher using kqueue. > - OpenBSD 3.6 higher using kqueue. (Not sure which version supports it) > - MacOS/X 10.4 higher using kqueue. (Not sure which version supports it) > > Future supported platforms: > - Linux from 2.4.0-test9 2.6.12 using dnotify. > - Sun OpenSolaris using FEM API. > > Testing: > I am testing the library on FreeBSD 7.2, Linux 2.6.31, Windows XP > (Windows NT 5.1). > I need help to test on older versions of these operating systems. > Also in NetBSD, OpenBSD and mainly on MacOSX because I do not have the > necessary hardware. > > I would like to include this library in Boost, I think would be useful. > What do you think? If so, I would like to have a mentor (like GSoC) and > experienced in Boost development. > > Thanks and regards, > Fernando Pelliccioni > > --- > > References: > > - O/I Completion Port: > > http://msdn.microsoft.com/en-us/library/aa365198%28VS.85%29.aspx > http://en.wikipedia.org/wiki/Input/output_completion_port > > - inotify: > http://en.wikipedia.org/wiki/Inotify > > - kqueue: > http://people.freebsd.org/~jlemon/papers/kqueue.pdf<http://people.freebsd.org/%7Ejlemon/papers/kqueue.pdf> > http://en.wikipedia.org/wiki/Kqueue > > - dnotify: > http://en.wikipedia.org/wiki/Dnotify > > > ------------------------------ > > Message: 6 > Date: Fri, 30 Apr 2010 10:22:42 +0000 > From: Joris IJsselmuiden <joris_imp(a)hotmail.com> > To: <boost(a)lists.boost.org> > Subject: Re: [boost] [castor] Interest in Logic Paradigm for C++ ? > Message-ID: <BAY138-W7AFA5103AA1AD2149562789000(a)phx.gbl> > Content-Type: text/plain; charset="iso-8859-1" > > > My humble opinion to the matter: > I think it is a great idea to try and make Castor part of Boost. I have > been using Castor in my research for a while now, and I think that it is > definitely Boost-material. A logic engine can be a powerful tool, and it is > a shame that C++ doesn't have one readily available. I am confident that > Castor is the best choice for adding logic support to Boost. > > As far as I know, Boost is the most popular code-base that is not part of > the C++ standard library yet. So, making Castor part of Boost would be a > great way of increasing Castor's visibility. It would be nice to keep Castor > available as a stand-alone library, so that you don't need Boost if you only > want to use Castor. But I am sure that this issue can be solved: Castor > could be a Boost "companion" library, or one could have a stand-alone > version and a Boost version side-by-side. Although this last solution > doesn't seem that great to me. > > I hope I will find the time to do some testing for Castor 1.1. Keep in > touch! > Joris Ijsselmuiden > _________________________________________________________________ > Hotmail: Powerful Free email with security by Microsoft. > https://signup.live.com/signup.aspx?id=60969 > > ------------------------------ > > Message: 7 > Date: Fri, 30 Apr 2010 10:21:01 -0400 > From: Chad Nelson <chad.thecomfychair(a)gmail.com> > To: boost(a)lists.boost.org > Subject: Re: [boost] [xint] Third release is ready, requesting > preliminary review > Message-ID: <4BDAE74D.6070803(a)gmail.com> > Content-Type: text/plain; charset=UTF-8 > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 04/30/2010 06:48 AM, Neal Becker wrote: > > > It would be good to remind us what this is > > The Extended Integer library provides arbitrary-length integers. > - -- > Chad Nelson > Oak Circle Software, Inc. > * > * > * > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.10 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > iEYEARECAAYFAkva500ACgkQp9x9jeZ9/wQZzgCgxaRkEXzJaeyHgCkWYjMEUTvy > 8LcAnjtbpUIube3pGg0pXTbhpvI49iIA > =2bMJ > -----END PGP SIGNATURE----- > > > ------------------------------ > > Message: 8 > Date: Fri, 30 Apr 2010 17:18:15 +0300 > From: Stefan <mstefanro(a)gmail.com> > To: boost(a)lists.boost.org > Subject: Re: [boost] Implementation of Factorization Library > Message-ID: <hreori$8fv$1(a)dough.gmane.org> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > abhijith reddy wrote: > > I am interested in implementing a module that will factor large numbers > > (10^25 -10^30) .. > > I think this can be added into the existing math and numerics library in > > boost. > > I'd be grateful if some could share their thoughts on this and comment on > > it. > > > > Thank you > > _______________________________________________ > > Unsubscribe & other changes: > http://lists.boost.org/mailman/listinfo.cgi/boost > > > Maybe you should collaborate with the GSoC student currently developing > the Bigint library? > > Adam Smith Implementation of arbitrary precision integers (BigInts) > for Boost Rene Rivera accepted > > Yours, > Stefan > > > > ------------------------------ > > Message: 9 > Date: Fri, 30 Apr 2010 10:23:42 -0400 > From: Chad Nelson <chad.thecomfychair(a)gmail.com> > To: boost(a)lists.boost.org > Subject: Re: [boost] [xint] Third release is ready, requesting > preliminary review > Message-ID: <4BDAE7EE.80804(a)gmail.com> > Content-Type: text/plain; charset=UTF-8 > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 04/30/2010 07:11 AM, Stewart, Robert wrote: > > Neal Becker wrote: > >> > >> It would be good to remind us what this is > > > > ...and where. > > Sorry, I thought "sandbox and Vault" would be sufficient to locate it. > The sandbox address is <https://svn.boost.org/svn/boost/sandbox/xint>; > the Vault one is > < > http://www.boostpro.com/vault/index.php?action=downloadfile&filename=xint.z… > >. > - -- > Chad Nelson > Oak Circle Software, Inc. > * > * > * > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.10 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > iEYEARECAAYFAkva5+4ACgkQp9x9jeZ9/wRCNQCeLQEf67UK0QSFtJfckuQOe6OU > vM0AoOjB1QrsuFe9xDzzGfsgGpReq66l > =5+NT > -----END PGP SIGNATURE----- > > > ------------------------------ > > Message: 10 > Date: Fri, 30 Apr 2010 09:40:34 -0500 > From: Rene Rivera <grafikrobot(a)gmail.com> > To: boost(a)lists.boost.org > Subject: Re: [boost] Implementation of Factorization Library > Message-ID: <4BDAEBE2.30502(a)gmail.com> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > On 4/30/2010 9:18 AM, Stefan wrote: > > abhijith reddy wrote: > >> I am interested in implementing a module that will factor large numbers > >> (10^25 -10^30) .. > >> I think this can be added into the existing math and numerics library in > >> boost. > >> I'd be grateful if some could share their thoughts on this and comment > on > >> it. > >> > > Maybe you should collaborate with the GSoC student currently developing > > the Bigint library? > > > > Adam Smith Implementation of arbitrary precision integers (BigInts) for > > Boost Rene Rivera accepted > > The GSoC rules don't really allow for anything but advice and critique. > > > -- > -- Grafik - Don't Assume Anything > -- Redshift Software, Inc. - http://redshift-software.com > -- rrivera/acm.org (msn) - grafik/redshift-software.com > -- 102708583/icq - grafikrobot/aim,yahoo,skype,efnet,gmail > > > ------------------------------ > > Message: 11 > Date: Fri, 30 Apr 2010 17:04:53 +0200 > From: Janek Kozicki <janek_listy(a)wp.pl> > To: boost(a)lists.boost.org, Helge Bahmann <hcb(a)chaoticmind.net> > Subject: [boost] boost atomic question > Message-ID: <20100430170453.43a9a514(a)atak.bl.pg.gda.pl> > Content-Type: text/plain; charset=US-ASCII > > Hello Helge, > > What would it take to get this code to work? > > std::vector<boost::atomic<Something> > v; > v.resize(100); > > best regards > -- > Janek Kozicki http://janek.kozicki.pl/ | > > > ------------------------------ > > Message: 12 > Date: Fri, 30 Apr 2010 17:07:28 +0200 > From: Janek Kozicki <janek_listy(a)wp.pl> > To: boost(a)lists.boost.org, Helge Bahmann <hcb(a)chaoticmind.net> > Subject: Re: [boost] boost atomic question > Message-ID: <20100430170728.2977bd23(a)atak.bl.pg.gda.pl> > Content-Type: text/plain; charset=US-ASCII > > Janek Kozicki said: (by the date of Fri, 30 Apr 2010 17:04:53 +0200) > > > What would it take to get this code to work? > > > > std::vector<boost::atomic<Something> > v; > > v.resize(100); > > Just for the question to be complete, that's my Something class: > > > class Something > { > private: > int val; > public: > Something(){}; > Something(int i):val(i){}; > void set_val(int i) {val=i;}; > int get_val() {return val;}; > }; > > > But that 'int' is just a placeholder. This class is intended to be a > bit more complex... > > > best regards > -- > Janek Kozicki http://janek.kozicki.pl/ | > > > ------------------------------ > > Message: 13 > Date: Fri, 30 Apr 2010 17:12:50 +0200 > From: <edouard(a)fausse.info> > To: <boost(a)lists.boost.org> > Subject: Re: [boost] boost atomic question > Message-ID: <08b9223f71910f920167aec540cdecc3@localhost> > Content-Type: text/plain; charset=UTF-8 > > On Fri, 30 Apr 2010 17:04:53 +0200, Janek Kozicki <janek_listy(a)wp.pl> > wrote: > > What would it take to get this code to work? > > > > std::vector<boost::atomic<Something> > v; > > v.resize(100); > > Hi Janek, > > I'd like to know what's your goal when you declare a vector of "atomic" > variables. What is the result you are looking for? > > Regards. > > -Edouard > > > ------------------------------ > > Message: 14 > Date: Fri, 30 Apr 2010 08:33:04 -0700 (PDT) > From: Vicente Botet Escriba <vicente.botet(a)wanadoo.fr> > To: boost(a)lists.boost.org > Subject: Re: [boost] boost atomic question > Message-ID: <28413638.post(a)talk.nabble.com> > Content-Type: text/plain; charset=us-ascii > > > > > Janek Kozicki wrote: > > > > Hello Helge, > > > > What would it take to get this code to work? > > > > std::vector<boost::atomic<Something> > v; > > v.resize(100); > > > > > Hi, just to understand better your concern. > > What kind of problems do you expect to have? > have you already tried it? > What do you expect from the atomic library? > > Best, > Vicente > > -- > View this message in context: > http://old.nabble.com/boost-atomic-question-tp28413326p28413638.html > Sent from the Boost - Dev mailing list archive at Nabble.com. > > > > ------------------------------ > > _______________________________________________ > Unsubscribe & other changes: > http://lists.boost.org/mailman/listinfo.cgi/boost > > End of Boost Digest, Vol 2897, Issue 3 > ************************************** >

1 0

Re: [boost] [contract] member initializers (was "diff n1962")
by Lorenzo Caminiti 30 Apr '10

30 Apr '10

On Sun, Apr 11, 2010 at 10:58 AM, vicente.botet <vicente.botet(a)wanadoo.fr> wrote: > I supose that the constructor preconditions are evaluated before the member initialization as this initialization can rely on the preconditions been satisfied. Note also that preconditions/postconditions must to be in the declaration part, and the member initialization is on the definition part. > > I understand that it is not easy for Boost.Contract to check the precondition before member initialization . To be able to do that you will need to have a first member or inherit from a 'precondition' class that do this precondition check, > > class C : C_constructor_precondition ... { > > C(T1 p1) : C_constructor_precondition(p1), ... { > // ... > } > }; > > but this seems to me a severe constraint and adds more complexity. I think that I can live with preconditions check after member initialization. Yes, "pre > base-init > member-init" will require to mess with the inheritance tree and I do not see how that can be done by the CONTRACT_CONSTRUCTOR() macro which is used at the constructor declaration level (so inside the class and after its inheritance declarations). However, special member variables could be used to implement "base-init > pre > member-init" (as indicated below). Do you think it is worth implementing "base-init > pre > member-init" instead of "base-init > member-init > pre"? For example: #define ASSERT(cond) if (!(cond)) throw std::runtime_error(# cond) struct y { y(int i) {} }; struct x: y { x(int i): y(i), x_i_pre_check_(i), num(i) {} struct x_i_pre_ { x_i_pre_() {} // Assert nothing (implicitly used by other constructors). x_i_pre_(const int& i) { ASSERT( i >= 123 ); } } x_i_pre_check_; x(double d): y(d), x_d_pre_check_(d), num(d) {} struct x_d_pre_ { x_d_pre_() {} x_d_pre_(const double& d) { ASSERT( d >= 1.23 ); } } x_d_pre_check_; int num; }; I think I can program the CONTRACT_CONSTRUCTOR() macro to do this. However, limitations are: 1) All member variables must be declared after the constructors. In this case num is declared at the bottom of the class. 2) Preconditions are NOT checked before base class construction but only after member variable construction. This might be OK because base classes will in turn implement their own preconditions if needed. However, I still think that "pre > base-init > member-init" is ideal over the "base-init > pre > member-init" implemented by this approach. That is because the derived class might have more stringent preconditions than the base classes, preconditions which could be checked to fail even before the base classes are constructed. 3) The macro syntax now needs to separate bases from members in the initializer list (this separation is not done by usual C++ syntax). This could be done using the following macro syntax: CONTRACT_CONSTRUCTOR( (x)( (double)(d) ) (y(d)) // Base class init (before pre). (precondition)( (i >= 123) ) (num(i)) // Member init (after pre). (postcondition)( (num == i) ) ({}) ) or: CONTRACT_CONSTRUCTOR( (x)( (double)(d) ) (y(d)) (members) (num(i)) // Note (members). (precondition)( (i >= 123) ) (postcondition)( (num == i) ) ({}) ) but a more natural C++-like syntax would be: CONTRACT_CONSTRUCTOR( (x)( (double)(d) ) (y(d)) (num(i)) (precondition)( (i >= 123) ) (postcondition)( (num == i) ) ({}) ) and this syntax cannot be used because I will not know how to inject the precondition check after y(d) but before num(i).

2 3

[contract] diff n1962
by Lorenzo Caminiti 30 Apr '10

30 Apr '10

Hello all, Below is a summary of the differences between Boost.Contract and the Contract Programming C++ standard proposal n1962. I know some of the authors of n1962, and also of its previous revisions, are on this mailing list -- I hope that they can provide comments at least. [n1962] Crowl and T. Ottosen, Proposal to add Contract Programming to C++ (revision 4), The C++ Standards Committee, 2006. All previous revisions of this proposal are also relevant (and related authors comments encouraged). Boost.Contract design was vastly based on n1962. However, in few places I deliberately made the different design decisions listed below. Based on your feedback, I would be happy to revisit my design decisions to align even more Boost.Contract with n1962. 1) SUBCONTRACTING n1962 allows only the base class to specify preconditions. Instead, Boost.Contract allows also derived classes to specify preconditions. Boost.Contract fully supports subcontracting as defined by substitution principles, implemented by Eiffel, and specified by prevision revisions of n1962 (n1613). However, Boost.Contract could be modified to comply with n1962. Why does n1962 allow preconditions only for the base classes? n1962 section 4.2.1: <<If the function F is virtual, we require that 1. only the base virtual function of F can have a precondition. Section 3.5 of n1613 explains how little redefinition of preconditions is used. Even though subcontracting is theoretically sound, it ends up being fairly useless in practice [3]. [3] A weaker precondition can be taken advantage of if we know the particular type of the object. If weaker preconditions should be allowed, then there exists two alternatives: to allow reuse of an existing contract or to require a complete redefinition. The former favours expressiveness, the latter favours overview.>>. 2) STATIC CLASS INVARIANTS n1962 does not support static class invariants. Instead, Boost.Contract supports static class invariants. Non-static class invariants are not checked at constructor entry, at destructor exit, and at entry/exit of static member functions (because there is no object in these cases). Static class invariants instead are always checked at entry/exit of constructors, destructor, and (static or non-static) member functions. I added static class invariants for completeness. Boost.Contract could drop static class invariants to comply with n1962 (but I find them useful). struct z { static int counter; int number; CONTRACT_CLASS( (z) (static) (invariant) ({ // Static class invariants (no object here). CONTRACT_ASSERT( counter >= 0 ); }) (invariant) ({ // Non-static class invariants (`this` present). CONTRACT_ASSERT( number <= counter ); }) ) ... }; Why does n1962 not support static class invariants? 3) ARBITRARY CODE IN CONTRACTS n1962 allows only a list of assertions, eventually guarded by if-statements, in invariants, preconditions, and postconditions. Instead, Boost.Contract allows for any C++ code in the contract. Boost.Contract documentation recommends to keep the contract code simple, limited to a list of assertions eventually guarded by if-statements (otherwise, it is more likely you have bugs in the contracts than in the actual code). However, I think it would be strange for a library to enforce such a constraint at compile-time -- I agree that language support for CP should instead enforce this constraint at compile-time. Boost.Contract could be modified to enforce this constraint by removing the CONTRACT_ASSERT() macros. Would this complicate the macro syntax even more? template<typename T> class myvector { CONTRACT_FUNCTION_DECL( (iterator) (erase)( (iterator)(first) (iterator)(last) ) (copyable) (postcondition) (result) ( // no `{` bracket ( size() == (CONTRACT_OLDOF(this)->size() - std::distance(first, last) ) ( if (empty()) (result == end()) ) // if-guarded condition ) // no `}` braket ... ) ... }; Note how the postconditions are just a preprocessor sequence of boolean expressions asserting the contract. The if-guarded conditions can AND (&&) multiple assertions plus they can list an optional 3rd element for the else block, for example: (precondition) ( (if (check) ( then1 && then2 ) else ( else1 && else 2 ) ) // endif ) If check is true then then1 and then2 conditions are asserted, else else1 and else2 conditions are asserted. 4) BODY KEYWORD n1962 does not use the body keyword. Instead, Boost.Contract macros use (body). Boost.Contract could be changed to remove the need for (body) -- the body will simply be the last element in the contract sequence. This way, and removing also the CONTRACT_ASSERT(), Boost.Contract syntax will be _exactly_ the same as n1962 with the "only" addition of the () preprocessor wrappings: template<typename T> // n1962 syntax class myvector { void push_back(const T& element) precondition { size() < max_size(); } postcondition { back() == element; size() == (oldof size() + 1); } { vector_.push_back(element); } ... }; template<typename T> // Boost.Contract syntax class myvector { CONTRACT_FUNCTION_DECL( (void) (push_back)( (const T&)(element) ) (copyable) (precondition) ( // no CONTRACT_ASSERT() ( size() < max_size() ) ) (postcondition) ( ( back() == element ) ( size() == (CONTRACT_OLDOF(this)->size() + 1) ) ) ({ // no (body) vector_.push_back(element); }) ) ... }; Is the macro syntax more readable with or without (body) and/or CONTRACT_ASSERT()? 5) CONTRACT CHECKING ORDER (policy) n1962 checks contracts as pre > inv > body > inv > post. Instead, Boost.Contract checks contracts as inv > pre > body > inv > post, where inv is static-inv > non-static-inv. Note that Boost.Contract checks class invariants before preconditions while n1962 does not. However, n1962 footnote [9] says ``Strictly speaking the invariant needs to hold before the precondition is executed because the contracts might call public functions of the class which require the invariant to be established. Currently we do not expect that to be a practical problem though, and the current specification is easier to implement.''. In addition, if invariants are checked first programmers can assert pre/postconditions assuming the class invariants are true (furthermore, non-static class invariants can be programmed assuming static class invariants are true). For example, if the class invariants were to assert a member pointer to be not null, both pre/postconditions can assert conditions on this pointer without checking for nullity first. Therefore, I concluded Boost.Contract inv > pre is a preferred approach over n1962 pre > inv. However, Boost.Contract could be changed to check preconditions before invariants to comply with n1962. 6) DISABLE ASSERTION CHECKING WITHIN ASSERTIONS CHECKING (policy) n1962 only disables assertion checking from within preconditions checking. Instead, Boost.Contract disables assertion checking from within all contract checking. I found this policy useful to prevent infinite recursion. Previous revisions of n1962 (n1613) specified the same policy implemented by Boost.Contract. Furthermore, Eiffel implements the Boost.Contract policy. Boost.Contract could be changed to comply with n1962. Why does n1962 disable assertion checking only from within preconditions? 7) NESTED FUNCTION CALLS (policy) n1962 disable nothing. Instead, Boost.Contract disables invariant checking within nested function calls. I found this policy useful to prevent infinite recursion. Previous revisions of n1962 (n1613) specified the Boost.Contract policy. Eiffel disables all checks (not just invariants). Boost.Contract could be changed to comply with n1962. Why does n1962 not disable invariants checking in nested calls? 8) CODE ORDERING Both n1962 and Boost.Contract require preconditions > postconditions > body to be specified in this order. Instead, Eiffel uses preconditions > body > postconditions. People new to CP usually ask why the order is not pre > body > post when looking at the contracts for the 1st time. However, after using the library, the same people appreciate pre > post > body more because the programming is cleaner "first program the contracts (pre and post) then the body". I think using only one ordering is better to enforce code consistency and I prefer pre > post > body over Eiffel's pre > body > post. Do you think Boost.Contract should be modified to support both n1962 and Eiffel orderings? 9) LOOP VARIANTS n1962 does not support loop variants. Instead, Boost.Contract supports loop variants with semantics similar to Eiffel's loop variants. I find loop variants not useful in practice so I do not think I would personally recommend them for language support. However, it was easy enough to add them to Boost.Contract and I would leave them in the library. 10) FAILURE HANDLERS In n1962 section 4.6: <<The precondition for all the set_XX_handler functions should be r != 0>>. Instead, Boost.Contract behaviour is undefined if a null handler function pointer `r` is specified. Boost.Contract mirrors the C++ specifications for std::set_terminate() which indicates undefined behaviour if a null terminate handler function pointer is specified. This could be changed. 11) OLDOF n1962 allows to apply oldof to *any expression* that can be copied. Instead, Boost.Contract only supports CONTRACT_OLDOF() for *object and the function parameters* that can be copied. This is a limitation of Boost.Contract because, for example, in order to get the old value of a vector size I need to copy the entire vector adding more overhead respect to copying just the vector size (which is simply an integer): oldof vector.size() // n1962: Just copy the integer size(). CONTRACT_OLDOF(vector).size() // Boost.Contract: Copy entire vector... Furthermore, if the vector object cannot be copied, I cannot not get its old size even if the size itself can be copied because it is just an integer: oldof noncopyable_vector.size() // n1962: OK, just copy the integer size(). CONTRACT_OLDOF(noncopyable_vector).size() // Boost.Contract: Cannot do this because cannot copy noncopyable_vector... Finally, the use of CONTRACT_OLDOF(variable) requires programmers to explicitly indicate that the variable type is copyable using (copyable) in the function signature adding syntactic overhead. Unfortunately, I do not know how to remove these library limitations. (All of that said, Boost.Contract old value support is very useful and it successfully covered all the uses cases and examples presented in n1962 and in a number of C++/Eiffel books/articles.) 12) CONSTANT-CORRECTNESS Block invariants are constant-correct in n1962 but not in Boost.Contract. (Class invariants and pre/postconditions are constant-correct in both n1962 and Boost.Contract.) Unfortunately, I do not know how to enforce constant-correctness of block invariants (and also of loop variants) for Boost.Contract because I cannot inject const within a code block: class z { void f() { const { // Can't do this... so f() is not const and block invariants are also not const in this context... ... // block invariant here } } }; This is a limitation of Boost.Contract. Regards, Lorenzo

5 19

Implementation of Factorization Library
by abhijith reddy 30 Apr '10

30 Apr '10

I am interested in implementing a module that will factor large numbers (10^25 -10^30) .. I think this can be added into the existing math and numerics library in boost. I'd be grateful if some could share their thoughts on this and comment on it. Thank you

3 2

[any] boost::get style accessors
by Christoph Heindl 30 Apr '10

30 Apr '10

Hi all, I couldn't find any boost::get<T> style accessors for boost::any, so I came up with an implementation that looks something along the following lines. #include <boost/any.hpp> #include <boost/call_traits.hpp> namespace boost { template<class T> typename boost::call_traits<T>::reference get(any &a) { return boost::any_cast<typename boost::call_traits<T>::reference>(a); } template<class T> typename boost::call_traits<T>::const_reference get(const any &a) { return boost::any_cast<typename boost::call_traits<T>::const_reference>(a); } } In case it cannot be converted to the desired destination type a bad_any_cast exception is thrown. The above code enables boost.any and boost.variant to be used interchangeably as far as boost::get<T> is concerned. Any thoughts? Best regards, Christoph

4 19

[1.43][statechart] Permission to merge changeset 61637 to the release branch
by Andreas Huber 30 Apr '10

30 Apr '10

Hi I'd like to merge the following trivial fixes to the release branch: <https://svn.boost.org/trac/boost/changeset/61637> The fixes were tested by >50% of the testers without incident. Ok to go ahead? Thanks, -- Andreas Huber When replying by private email, please remove the words spam and trap from the address shown in the header.

2 2

[Interprocess] Compile error with VC10
by cg 30 Apr '10

30 Apr '10

I am trying Interprocess with VS2010, and got some compile error, the error message is: 1>ClCompile: 1>boost/interprocess/detail/move.hpp(358): error C2440: 'return' : cannot convert from 'boost::interprocess::mapped_region' to 'boost::interprocess::mapped_region &&' 1> You cannot bind an lvalue to an rvalue reference Any quick fix for it?

4 11

[spirit] VC10 ICE when defining a Karma/Qi rule in a 0x lambda
by Lars Viklund 29 Apr '10

29 Apr '10

Hi list, I encountered a rather amusing/horrible compiler error today when trying to wrap my head around the new Spirit. Apparently, VC++10 experiences a fatal internal compiler error when defining a Karma or Qi rule inside a lambda expression, as shown in the attached source at the bottom of this mail (and in the bug report). I reported a spirit bug [1] and a kind soul on the #boost channel linked me a similar Microsoft Connect bug [2], which seems to have sadly been ignored. I've got no idea in what edge of Spirit to start investigating this, as there's deep magic going on inside it, and would appreciate advice on what might be at fault, and whether there are any knobs I can twiddle. Could it be related to the recent thread on incomplete decltypes and odd rvalue references that VC10 has? [1] https://svn.boost.org/trac/boost/ticket/4160 [2] http://connect.microsoft.com/VisualStudio/feedback/details/541534/internal-… //---8<--- #include <boost/spirit/include/karma.hpp> int main() { []() { boost::spirit::karma::rule<char*> r; }; } //---8<--- -- Lars Viklund | zao(a)acc.umu.se

5 7

VC10 config - some regressions in several libraries
by John Maddock 29 Apr '10

29 Apr '10

Just a note that the recent changes to the VC10 config has produced several regressions in a number of libraries - I think these are all related to the use the rvalue references and move semantics. At present I can't say whether these are caused by bugs in VC10 rendering it's rvalue refs unusable (in which case we need a better test case in Boost.Config), or whether our library code isn't mature/portable enough yet given that this is a new and relatively untried feature. Can library authors making use of this feature investigate so we can decide what should be done here? Thanks! John.

13 27

[range][1.43] is boost::get or boost::at missing?
by vicente.botet 29 Apr '10

29 Apr '10

Hi, I'm wondering if a checked element access via at() is missing for Random Access ranges. Best, _____________________ Vicente Juan Botet Escribá http://viboes.blogspot.com/

2 2

[uuid] Confusing uuid_class example in documentation
by Sylvester-Bradley, Gareth 29 Apr '10

29 Apr '10

http://beta.boost.org/doc/libs/1_42_0/libs/uuid/uuid.html#POD%20Efficien cies includes some example code for making a uuid_class from the struct uuid POD. I was confused to see the example uuid_class both derives from boost::uuids::uuid *and* provides operator boost::uuids::uuid() [const]. Aren't the conversion operators unnecessary, as a conversion function is never called to convert an object to a base class of that type (by 12.3.2 [class.conv.fct])? In fact the source file that the documentation references (e.g. at https://svn.boost.org/trac/boost/browser/tags/release/Boost_1_43_0_beta1 /libs/uuid/test/test_uuid_class.cpp) doesn't include the conversion operators. I think the documentation should be updated to match. Cheers, Gareth ************************************************************************ The information contained in this message or any of its attachments may be confidential and is intended for the exclusive use of the addressee(s). Any disclosure, reproduction, distribution or other dissemination or use of this communication is strictly prohibited without the express permission of the sender. The views expressed in this email are those of the individual and not necessarily those of Sony or Sony affiliated companies. Sony email is for business use only. This email and any response may be monitored by Sony to be in compliance with Sony's global policies and standards

2 1

[function] function_template.hpp has ambiguous mem_fn calls on compilers with std::mem_fn (VC10); simple 2-line fix
by Conrad Poelman 29 Apr '10

29 Apr '10

*Summary*: It seems that function_template.hpp needs "boost::" in front of mem_fn in two spots so as not to be ambiguous with std::mem_fn on compilers that have std::mem_fn. (mem_fn appears in that file 4 times; two spots already use fully-qualified "boost::mem_fn".) I entered this at https://svn.boost.org/trac/boost/ticket/4073, but just wondered what the process is for having this fix committed to boost repository. **Example**: Here's a reproducible example that won't compile in Visual Studio 2010 (produces an "ambiguous call to overloaded function" error regarding mem_fn - could be boost::mem_fn or could be std::mem_fn) but that compiles fine in other compilers that don't have an std::mem_fn: #include<boost/function.hpp> #include<string> class PrimitiveBuilder { public: bool someFunction( std::string& token ); void registerSomeFunction() { mPrimitiveFunctor =&PrimitiveBuilder::someFunction; // ambiguity error is here } private: typedef boost::function<bool (PrimitiveBuilder*, std::string& token)> PrimitiveFunctor; PrimitiveFunctor mPrimitiveFunctor; }; The above code compiles and works fine in VS 2010 once "boost::" is added to mem_fn in function_template.hpp. I look forward to hearing your thoughts. Thanks! -- Conrad

1 0

running the regression tests with SunCC 5.9
by Frank Meerkötter 29 Apr '10

29 Apr '10

Hello, I am trying to run the regression tests for boost on a SunSparc machine with the SunCC 5.9. As i am trying to evaluate a certain version of boost i provide a local tarball. python run.py --runner meerkoetter --toolsets=sun --user= --local=../boost/boost_1_42_0.tar.bz2 The tests sits for a few minutes at this line. Before it fails. # Starting tests ("/home/meerkoef/boost_regression/tools_bjam/bin.solarissparc/bjam" "-sBOOST_BUILD_PATH=/home/meerkoef/boost_regression:/home/meerkoef/boost_regression/tools_bb" "-sBOOST_ROOT=/home/meerkoef/boost_regression/boost" "--boost=/home/meerkoef/boost_regression/boost" "--boost-build=/home/meerkoef/boost_regression/tools_bb" "--debug-configuration" -l300 sun -d2 preserve-test-targets=off --dump-tests "--build-dir=/home/meerkoef/boost_regression/results" >>"/home/meerkoef/boost_regression/results/bjam.log" 2>&1)... # Running Boost.Build tests Traceback (most recent call last): File "run.py", line 60, in ? runner(root) File "/home/meerkoef/boost_regression/tools_regression_src/regression.py", line 193, in __init__ self.main() File "/home/meerkoef/boost_regression/tools_regression_src/regression.py", line 551, in main getattr(self,action_m)() File "/home/meerkoef/boost_regression/tools_regression_src/regression.py", line 516, in command_regression self.command_test() File "/home/meerkoef/boost_regression/tools_regression_src/regression.py", line 317, in command_test self.command_test_boost_build() File "/home/meerkoef/boost_regression/tools_regression_src/regression.py", line 354, in command_test_boost_build "boost/bin.v2/libs/any/test/any_test.test")); OSError: [Errno 2] No such file or directory: '/home/meerkoef/boost_regression/results/boost/bin.v2/libs/any/test/any_test.test' The last few lines in bjam.log show: [...] boost-test(RUN) "config/no_void_returns_pass" : "libs/config/test/no_void_returns_pass.cpp" boost-test(COMPILE_FAIL) "config/no_void_returns_fail" : "libs/config/test/no_void_returns_fail.cpp" boost-test(RUN) "config/no_wchar_t_pass" : "libs/config/test/no_wchar_t_pass.cpp" boost-test(COMPILE_FAIL) "config/no_wchar_t_fail" : "libs/config/test/no_wchar_t_fail.cpp" don't know how to make <e>sun ...found 1 target... ...can't find 1 target... Any ideas how i can fix this? btw. i noticed that the tools are build using the gcc and not the sun compiler. Is this correct? In the end i don't care what compiler is used to create the regression testing tools but still it makes me wonder if the tests are compiled with the right compiler? Here is the complete log: # Running regressions in /home/meerkoef/boost_regression... # Creating regression scripts at /home/meerkoef/boost_regression/tools_regression_src... # Dowloading regression scripts from http://svn.boost.org/svn/boost/trunk/tools/regression/src... # Getting Boost.Build v2... # Downloading "http://beta.boost.org/development/snapshot.php/trunk/tools/build/v2" to "/home/meerkoef/boost_regression"... # Looking for old unpacked archives... # Unpacking boost tarball ("/home/meerkoef/boost_regression/tools_bb.tar.bz2")... # Unpacked into directory "/home/meerkoef/boost_regression/boost-trunk-2010-04-26-09-02-11-EDT" # Deleting "tools_bb" directory... # Renaming "/home/meerkoef/boost_regression/boost-trunk-2010-04-26-09-02-11-EDT" into "tools_bb" # Getting Boost.Jam... # Downloading "http://beta.boost.org/development/snapshot.php/tags/tools/jam/Boost_Jam_3_1…" to "/home/meerkoef/boost_regression"... # Looking for old unpacked archives... # Unpacking boost tarball ("/home/meerkoef/boost_regression/tools_bjam.tar.bz2")... # Unpacked into directory "/home/meerkoef/boost_regression/boost-tags-2010-04-26-09-02-30-EDT" # Deleting "tools_bjam" directory... # Renaming "/home/meerkoef/boost_regression/boost-tags-2010-04-26-09-02-30-EDT" into "tools_bjam" # Getting regression tools an utilities... # Downloading "http://beta.boost.org/development/snapshot.php/trunk/tools/regression" to "/home/meerkoef/boost_regression"... # Looking for old unpacked archives... # Unpacking boost tarball ("/home/meerkoef/boost_regression/tools_regression.tar.bz2")... # Unpacked into directory "/home/meerkoef/boost_regression/boost-trunk-2010-04-26-09-02-51-EDT" # Deleting "tools_regression" directory... # Renaming "/home/meerkoef/boost_regression/boost-trunk-2010-04-26-09-02-51-EDT" into "tools_regression" # Getting boost-build.jam... # Using local file "../boost/boost_1_42_0.tar.bz2" # Tag: "boost_1_42_0" # Looking for old unpacked archives... # Unpacking boost tarball ("../boost/boost_1_42_0.tar.bz2")... # Unpacked into directory "/home/meerkoef/boost_regression/boost_1_42_0" # Deleting "/home/meerkoef/boost_regression/boost" directory... # Renaming "/home/meerkoef/boost_regression/boost_1_42_0" into "/home/meerkoef/boost_regression/boost" # Preinstalled "/home/meerkoef/boost_regression/bjam" is not found; building one... # Found "bjam" source directory "/home/meerkoef/boost_regression/tools_bjam" # Building "bjam" (./build.sh )... ### ### Using 'gcc' toolset. ### rm -rf bootstrap mkdir bootstrap gcc -o bootstrap/jam0 command.c compile.c debug.c expand.c glob.c hash.c hdrmacro.c headers.c jam.c jambase.c jamgram.c lists.c make.c make1.c newstr.c option.c output.c parse.c pathunix.c pathvms.c regexp.c rules.c scan.c search.c subst.c timestamp.c variable.c modules.c strings.c filesys.c builtins.c pwd.c class.c native.c md5.c w32_getreg.c modules/set.c modules/path.c modules/regex.c modules/property-set.c modules/sequence.c modules/order.c execunix.c fileunix.c ./bootstrap/jam0 -f build.jam --toolset=gcc --toolset-root= clean ...found 1 target... ...updating 1 target... ...updated 1 target... ./bootstrap/jam0 -f build.jam --toolset=gcc --toolset-root= ...found 48 targets... ...updating 2 targets... [MKDIR] bin.solarissparc [COMPILE] bin.solarissparc/bjam ...updated 2 targets... # Searching for "bjam" in "/home/meerkoef/boost_regression/tools_bjam"... # bjam succesfully built in "/home/meerkoef/boost_regression/tools_bjam/bin.solarissparc/bjam" location # Preinstalled "/home/meerkoef/boost_regression/process_jam_log" is not found; building one... # Found "process_jam_log" source directory "/home/meerkoef/boost_regression/tools_regression/build" # Building "process_jam_log" ("/home/meerkoef/boost_regression/tools_bjam/bin.solarissparc/bjam" "-sBOOST_BUILD_PATH=/home/meerkoef/boost_regression:/home/meerkoef/boost_regression/tools_bb" "-sBOOST_ROOT=/home/meerkoef/boost_regression/boost" "--boost=/home/meerkoef/boost_regression/boost" "--boost-build=/home/meerkoef/boost_regression/tools_bb" "--debug-configuration" process_jam_log -d2 -l300)... notice: found boost-build.jam at /home/meerkoef/boost_regression/boost-build.jam notice: loading Boost.Build from /home/meerkoef/boost_regression/tools_bb notice: Searching /etc /home/meerkoef /home/meerkoef/boost_regression/tools_bb /home/meerkoef/boost_regression /home/meerkoef/boost_regression/tools_bb /home/meerkoef/boost_regression/tools_bb/kernel /home/meerkoef/boost_regression/tools_bb/util /home/meerkoef/boost_regression/tools_bb/build /home/meerkoef/boost_regression/tools_bb/tools /home/meerkoef/boost_regression/tools_bb/contrib /home/meerkoef/boost_regression/tools_bb/. for site-config configuration file site-config.jam . notice: Loading site-config configuration file site-config.jam from /home/meerkoef/boost_regression/tools_bb/site-config.jam . notice: Searching /home/meerkoef /home/meerkoef/boost_regression/tools_bb /home/meerkoef/boost_regression /home/meerkoef/boost_regression/tools_bb /home/meerkoef/boost_regression/tools_bb/kernel /home/meerkoef/boost_regression/tools_bb/util /home/meerkoef/boost_regression/tools_bb/build /home/meerkoef/boost_regression/tools_bb/tools /home/meerkoef/boost_regression/tools_bb/contrib /home/meerkoef/boost_regression/tools_bb/. for user-config configuration file user-config.jam . notice: Loading user-config configuration file user-config.jam from /home/meerkoef/boost_regression/tools_bb/user-config.jam . notice: iostreams: using prebuilt zlib notice: iostreams: using prebuilt bzip2 notice: [python-cfg] Configuring python... notice: [python-cfg] Checking interpreter command "python"... notice: [python-cfg] running command '"python" -c "from sys import *; print('version=%d.%d\nplatform=%s\nprefix=%s\nexec_prefix=%s\nexecutable=%s' % (version_info[0],version_info[1],platform,prefix,exec_prefix,executable))" 2>&1' notice: [python-cfg] ...requested configuration matched! notice: [python-cfg] Details of this Python configuration: notice: [python-cfg] interpreter command: "python" notice: [python-cfg] include path: "/usr/include/python2.4" notice: [python-cfg] library path: "/usr/lib/python2.4/config" "/usr/lib" warning: No toolsets are configured. warning: Configuring default toolset "gcc". warning: If the default is wrong, your build may not work correctly. warning: Use the "toolset=xxxxx" option to override our guess. warning: For more configuration options, please consult warning: http://boost.org/boost-build2/doc/html/bbv2/advanced/configuration.html notice: will use 'g++' for gcc, condition <toolset>gcc-3.4.3 notice: using gcc libraries :: <toolset>gcc-3.4.3 :: /usr/sfw/bin /usr/sfw/lib /usr/sfw/lib32 /usr/sfw/lib64 notice: using gcc archiver :: <toolset>gcc-3.4.3 :: /usr/sfw/sparc-sun-solaris2.10/bin/ar notice: using gcc ranlib :: <toolset>gcc-3.4.3 :: /usr/sfw/sparc-sun-solaris2.10/bin/ranlib warning: toolset gcc initialization: can not find tool windres warning: initialized from notice: using rc compiler :: <toolset>gcc-3.4.3 :: as ...patience... ...found 487 targets... ...updating 27 targets... common.mkdir bin mkdir -p "bin" common.mkdir bin/gcc-3.4.3 mkdir -p "bin/gcc-3.4.3" common.mkdir bin/gcc-3.4.3/release mkdir -p "bin/gcc-3.4.3/release" gcc.compile.c++ bin/gcc-3.4.3/release/process_jam_log.o "g++" -ftemplate-depth-128 -O3 -finline-functions -Wno-inline -Wall -fPIC -DBOOST_ALL_NO_LIB=1 -DBOOST_FILESYSTEM_STATIC_LINK=1 -DBOOST_SYSTEM_STATIC_LINK=1 -DNDEBUG -D_CRT_SECURE_NO_WARNINGS -I"/home/meerkoef/boost_regression/boost" -c -o "bin/gcc-3.4.3/release/process_jam_log.o" "../src/process_jam_log.cpp" ../src/process_jam_log.cpp: In function `int main(int, char**)': ../src/process_jam_log.cpp:692: warning: comparison between signed and unsigned integer expressions gcc.compile.c++ bin/gcc-3.4.3/release/tiny_xml.o "g++" -ftemplate-depth-128 -O3 -finline-functions -Wno-inline -Wall -fPIC -DBOOST_ALL_NO_LIB=1 -DNDEBUG -D_CRT_SECURE_NO_WARNINGS -I"/home/meerkoef/boost_regression/boost" -c -o "bin/gcc-3.4.3/release/tiny_xml.o" "../src/detail/tiny_xml.cpp" common.mkdir /home/meerkoef/boost_regression/boost/bin.v2 mkdir -p "/home/meerkoef/boost_regression/boost/bin.v2" common.mkdir /home/meerkoef/boost_regression/boost/bin.v2/libs mkdir -p "/home/meerkoef/boost_regression/boost/bin.v2/libs" common.mkdir /home/meerkoef/boost_regression/boost/bin.v2/libs/filesystem mkdir -p "/home/meerkoef/boost_regression/boost/bin.v2/libs/filesystem" common.mkdir /home/meerkoef/boost_regression/boost/bin.v2/libs/filesystem/build mkdir -p "/home/meerkoef/boost_regression/boost/bin.v2/libs/filesystem/build" common.mkdir /home/meerkoef/boost_regression/boost/bin.v2/libs/filesystem/build/gcc-3.4.3 mkdir -p "/home/meerkoef/boost_regression/boost/bin.v2/libs/filesystem/build/gcc-3.4.3" common.mkdir /home/meerkoef/boost_regression/boost/bin.v2/libs/filesystem/build/gcc-3.4.3/release mkdir -p "/home/meerkoef/boost_regression/boost/bin.v2/libs/filesystem/build/gcc-3.4.3/release" common.mkdir /home/meerkoef/boost_regression/boost/bin.v2/libs/filesystem/build/gcc-3.4.3/release/link-static mkdir -p "/home/meerkoef/boost_regression/boost/bin.v2/libs/filesystem/build/gcc-3.4.3/release/link-static" gcc.compile.c++ /home/meerkoef/boost_regression/boost/bin.v2/libs/filesystem/build/gcc-3.4.3/release/link-static/operations.o "g++" -ftemplate-depth-128 -O3 -finline-functions -Wno-inline -Wall -DBOOST_ALL_NO_LIB=1 -DBOOST_All_STATIC_LINK=1 -DBOOST_SYSTEM_STATIC_LINK=1 -DNDEBUG -I"/home/meerkoef/boost_regression/boost" -c -o "/home/meerkoef/boost_regression/boost/bin.v2/libs/filesystem/build/gcc-3.4.3/release/link-static/operations.o" "/home/meerkoef/boost_regression/boost/libs/filesystem/src/operations.cpp" gcc.compile.c++ /home/meerkoef/boost_regression/boost/bin.v2/libs/filesystem/build/gcc-3.4.3/release/link-static/path.o "g++" -ftemplate-depth-128 -O3 -finline-functions -Wno-inline -Wall -DBOOST_ALL_NO_LIB=1 -DBOOST_All_STATIC_LINK=1 -DBOOST_SYSTEM_STATIC_LINK=1 -DNDEBUG -I"/home/meerkoef/boost_regression/boost" -c -o "/home/meerkoef/boost_regression/boost/bin.v2/libs/filesystem/build/gcc-3.4.3/release/link-static/path.o" "/home/meerkoef/boost_regression/boost/libs/filesystem/src/path.cpp" gcc.compile.c++ /home/meerkoef/boost_regression/boost/bin.v2/libs/filesystem/build/gcc-3.4.3/release/link-static/portability.o "g++" -ftemplate-depth-128 -O3 -finline-functions -Wno-inline -Wall -DBOOST_ALL_NO_LIB=1 -DBOOST_All_STATIC_LINK=1 -DBOOST_SYSTEM_STATIC_LINK=1 -DNDEBUG -I"/home/meerkoef/boost_regression/boost" -c -o "/home/meerkoef/boost_regression/boost/bin.v2/libs/filesystem/build/gcc-3.4.3/release/link-static/portability.o" "/home/meerkoef/boost_regression/boost/libs/filesystem/src/portability.cpp" gcc.compile.c++ /home/meerkoef/boost_regression/boost/bin.v2/libs/filesystem/build/gcc-3.4.3/release/link-static/utf8_codecvt_facet.o "g++" -ftemplate-depth-128 -O3 -finline-functions -Wno-inline -Wall -DBOOST_ALL_NO_LIB=1 -DBOOST_All_STATIC_LINK=1 -DBOOST_SYSTEM_STATIC_LINK=1 -DNDEBUG -I"/home/meerkoef/boost_regression/boost" -c -o "/home/meerkoef/boost_regression/boost/bin.v2/libs/filesystem/build/gcc-3.4.3/release/link-static/utf8_codecvt_facet.o" "/home/meerkoef/boost_regression/boost/libs/filesystem/src/utf8_codecvt_facet.cpp" RmTemps /home/meerkoef/boost_regression/boost/bin.v2/libs/filesystem/build/gcc-3.4.3/release/link-static/libboost_filesystem.a(clean) rm -f "/home/meerkoef/boost_regression/boost/bin.v2/libs/filesystem/build/gcc-3.4.3/release/link-static/libboost_filesystem.a" gcc.archive /home/meerkoef/boost_regression/boost/bin.v2/libs/filesystem/build/gcc-3.4.3/release/link-static/libboost_filesystem.a "/usr/sfw/sparc-sun-solaris2.10/bin/ar" rc "/home/meerkoef/boost_regression/boost/bin.v2/libs/filesystem/build/gcc-3.4.3/release/link-static/libboost_filesystem.a" "/home/meerkoef/boost_regression/boost/bin.v2/libs/filesystem/build/gcc-3.4.3/release/link-static/operations.o" "/home/meerkoef/boost_regression/boost/bin.v2/libs/filesystem/build/gcc-3.4.3/release/link-static/path.o" "/home/meerkoef/boost_regression/boost/bin.v2/libs/filesystem/build/gcc-3.4.3/release/link-static/portability.o" "/home/meerkoef/boost_regression/boost/bin.v2/libs/filesystem/build/gcc-3.4.3/release/link-static/utf8_codecvt_facet.o" "/usr/sfw/sparc-sun-solaris2.10/bin/ranlib" "/home/meerkoef/boost_regression/boost/bin.v2/libs/filesystem/build/gcc-3.4.3/release/link-static/libboost_filesystem.a" common.mkdir /home/meerkoef/boost_regression/boost/bin.v2/libs/system mkdir -p "/home/meerkoef/boost_regression/boost/bin.v2/libs/system" common.mkdir /home/meerkoef/boost_regression/boost/bin.v2/libs/system/build mkdir -p "/home/meerkoef/boost_regression/boost/bin.v2/libs/system/build" common.mkdir /home/meerkoef/boost_regression/boost/bin.v2/libs/system/build/gcc-3.4.3 mkdir -p "/home/meerkoef/boost_regression/boost/bin.v2/libs/system/build/gcc-3.4.3" common.mkdir /home/meerkoef/boost_regression/boost/bin.v2/libs/system/build/gcc-3.4.3/release mkdir -p "/home/meerkoef/boost_regression/boost/bin.v2/libs/system/build/gcc-3.4.3/release" common.mkdir /home/meerkoef/boost_regression/boost/bin.v2/libs/system/build/gcc-3.4.3/release/link-static mkdir -p "/home/meerkoef/boost_regression/boost/bin.v2/libs/system/build/gcc-3.4.3/release/link-static" gcc.compile.c++ /home/meerkoef/boost_regression/boost/bin.v2/libs/system/build/gcc-3.4.3/release/link-static/error_code.o "g++" -ftemplate-depth-128 -O3 -finline-functions -Wno-inline -Wall -DBOOST_ALL_NO_LIB=1 -DBOOST_SYSTEM_STATIC_LINK=1 -DNDEBUG -I"/home/meerkoef/boost_regression/boost" -c -o "/home/meerkoef/boost_regression/boost/bin.v2/libs/system/build/gcc-3.4.3/release/link-static/error_code.o" "/home/meerkoef/boost_regression/boost/libs/system/src/error_code.cpp" RmTemps /home/meerkoef/boost_regression/boost/bin.v2/libs/system/build/gcc-3.4.3/release/link-static/libboost_system.a(clean) rm -f "/home/meerkoef/boost_regression/boost/bin.v2/libs/system/build/gcc-3.4.3/release/link-static/libboost_system.a" gcc.archive /home/meerkoef/boost_regression/boost/bin.v2/libs/system/build/gcc-3.4.3/release/link-static/libboost_system.a "/usr/sfw/sparc-sun-solaris2.10/bin/ar" rc "/home/meerkoef/boost_regression/boost/bin.v2/libs/system/build/gcc-3.4.3/release/link-static/libboost_system.a" "/home/meerkoef/boost_regression/boost/bin.v2/libs/system/build/gcc-3.4.3/release/link-static/error_code.o" "/usr/sfw/sparc-sun-solaris2.10/bin/ranlib" "/home/meerkoef/boost_regression/boost/bin.v2/libs/system/build/gcc-3.4.3/release/link-static/libboost_system.a" gcc.link bin/gcc-3.4.3/release/process_jam_log "g++" -o "bin/gcc-3.4.3/release/process_jam_log" "bin/gcc-3.4.3/release/process_jam_log.o" "bin/gcc-3.4.3/release/tiny_xml.o" "/home/meerkoef/boost_regression/boost/bin.v2/libs/filesystem/build/gcc-3.4.3/release/link-static/libboost_filesystem.a" "/home/meerkoef/boost_regression/boost/bin.v2/libs/system/build/gcc-3.4.3/release/link-static/libboost_system.a" -mimpure-text ...updated 27 targets... # Searching for "process_jam_log" in "/home/meerkoef/boost_regression/tools_regression/build"... # process_jam_log succesfully built in "/home/meerkoef/boost_regression/tools_regression/build/bin/gcc-3.4.3/release/process_jam_log" location # Making "/home/meerkoef/boost_regression/results" directory... # Starting tests ("/home/meerkoef/boost_regression/tools_bjam/bin.solarissparc/bjam" "-sBOOST_BUILD_PATH=/home/meerkoef/boost_regression:/home/meerkoef/boost_regression/tools_bb" "-sBOOST_ROOT=/home/meerkoef/boost_regression/boost" "--boost=/home/meerkoef/boost_regression/boost" "--boost-build=/home/meerkoef/boost_regression/tools_bb" "--debug-configuration" -l300 sun -d2 preserve-test-targets=off --dump-tests "--build-dir=/home/meerkoef/boost_regression/results" >>"/home/meerkoef/boost_regression/results/bjam.log" 2>&1)... # Running Boost.Build tests Traceback (most recent call last): File "run.py", line 60, in ? runner(root) File "/home/meerkoef/boost_regression/tools_regression_src/regression.py", line 193, in __init__ self.main() File "/home/meerkoef/boost_regression/tools_regression_src/regression.py", line 551, in main getattr(self,action_m)() File "/home/meerkoef/boost_regression/tools_regression_src/regression.py", line 516, in command_regression self.command_test() File "/home/meerkoef/boost_regression/tools_regression_src/regression.py", line 317, in command_test self.command_test_boost_build() File "/home/meerkoef/boost_regression/tools_regression_src/regression.py", line 354, in command_test_boost_build "boost/bin.v2/libs/any/test/any_test.test")); OSError: [Errno 2] No such file or directory: '/home/meerkoef/boost_regression/results/boost/bin.v2/libs/any/test/any_test.test'

3 3

[Review] [ITL] ITL formal review results
by Hartmut Kaiser 29 Apr '10

29 Apr '10

Hi all, The formal review of the Interval Template Library (ITL) written by Joachim Faulhaber started February 18th and ended March 7th, 2010. We saw a lively discussion resulting in 14 votes: 10 people voted unconditionally YES, 3 voted conditionally YES, and 1 reviewer voted NO. The overwhelming majority of the votes was YES which reflects the overall discussion and the general consensus of this library being worth to be included into Boost. Based on this result and the discussions we saw the Interval Template Library is now formally accepted into Boost. Detailed results ---------------- Pros: Almost all reviewers highlighted the general usefulness of the library. The more experience the reviewers had with the library in real world applications the more they emphasized its usefulness. Here are some quotes: - "ITL solved this problem for me, in a way that honestly freed me from having to think about a lot of the unsavory low-level details." - " Until now, we only used the library for intervals of date-times (coded as integers), but I'm sure, that its usefulness goes far beyond." - " Very useful. I mentioned two projects where the library would have helped me if it had been into Boost earlier, and I'm considering rewriting them such that the problems make use of the library, and simplify them in that way." The comments on the quality of the documentation are unanimous: "impressive and quite complete", "I couldn't ask for more". It seemed to be generally helpful to understand the concepts of the library and to get started. Some people asked to add more simple quick-start examples to the documentation and the distribution. Overall, the library is mature and easy to use. All reviewers actually utilizing the ITL library for real world use cases reported they were able to start quickly and without problems. All reviewers using ITL in real world applications stated that no performance problems were encountered. This is important to note as the NO vote was based on the current lack of a interval tree implementation, which was considered to result in suboptimal performance for certain use cases. Cons: Some aspects of the design have been criticized: "OO-type design decisions", "fat 'one size fits all'-interval class template", and "incomplete extraction of global functions" are the major points of critique. These points have real merit. In order to make the design and interface more flexible and more durable these have to be rectified before the final inclusion of the library into Boost's code base. Joachim already agreed to a list of things to change addressing those problems. For certain use cases, specifically for interval map of collections, the current implementation has suboptimal complexity characteristics that leads to O(n^2) space usage in the worst case. OTOH, for the majority of applications of the library the worst case scenario seems to be (reportedly) irrelevant. This issue has been discussed at length and Joachim plans to add an implementation with a better worst case performance of the affected class templates as later optimizations. This is not considered to be a precondition to full inclusion into Boost's code base as it is not anticipated to cause any interface changes. Last but not least people suggested to change the name of the library as having the word template in the name does not carry any useful information. Joachim already agreed to this. Regards Hartmut Review Manager --------------- Meet me at BoostCon www.boostcon.com

3 3

About command line parameters parsing again...
by Denis Shevchenko 29 Apr '10

29 Apr '10

Hi all! Sorry for my English... During last two months I develop simple library for command line parameters parsing. Although there is many such libraries (e.g. on sf.net) I cannot find library with _realy_ simple using. Command line parameters parsing is simple, trivial task, so (imho) library for this task must be easy-to-learn and easy-to-use. Boost.Program_options is good and flexible library, but (imho) work with command line parameters must be easier. My library _not_ parse config file, because I like rule "one task - one library". My question: is it need in Boost another library for command line parameters parsing? P.S. Library: https://sourceforge.net/projects/clp-parser/ Denis

1 0

[range] irange is not very eloquent
by vicente.botet 29 Apr '10

29 Apr '10

Hi, I have find the function 'irange' in the section "Provided Ranges". template<class Integer> integer_range< range_detail::integer_iterator<Integer> > irange(Integer first, Integer last); I will expect in this section ranges and not functions. This function allows to treat integers as a model of the Random Access Range Concept. I find the name not very eloquent. What about make_integer_range, for example? BTW, I don't find the documentation of the the class integer_range. Where it is documented? Best, _____________________ Vicente Juan Botet Escribá http://viboes.blogspot.com/

3 10

[range] Permission to merge extensive documentation work from trunk.
by Neil Groves 29 Apr '10

29 Apr '10

Please may I merge just the documentation changes that have been performed on the trunk? These include: 1. corrections to documentation errors 2. complete documentation of the header files 3. acknowledgements for the Boost.RangeEx work. Regards, Neil Groves

3 6

[GSoC][boost.process] Blog
by Felipe Tanus 29 Apr '10

29 Apr '10

Hi, My project for Google Summer of Code was accepted, as many of you already know. I would like to give my thanks to anyone that supported me. I'll give my best in this project. Writing with my mentor, we decided that would be a good idea to keep an track from our actions, project decisions and have a place where interested people could help us without the need of we ask. Then, I created a blog that I'll write whenever I have something significant to tell. If you are interested in this project, I invite you to follow the updates from this blog[1] and comment whenever you like. This way, we might post in this mailing list only when it's strictly needed about the project. Thank you. [1] http://gsoc2010.fotanus.com -- Felipe de Oliveira Tanus E-mail: fotanus(a)gmail.com Blog: http://www.itlife.com.br Site: http://www.inf.ufrgs.br/~fotanus/ ----- "All we have to decide is what to do with the time that is given us." - Gandalf

1 0

[ANN] CodeSynthesis XSD 3.3.0 released
by Boris Kolpackov 29 Apr '10

29 Apr '10

Hi, I am pleased to announce the availability of CodeSynthesis XSD 3.3.0. CodeSynthesis XSD is an open-source (GPL2 + proprietary license), cross- platform W3C XML Schema to C++ data binding compiler. Provided with a schema, it generates C++ classes that represent the given vocabulary as well as parsing and serialization code. You can then access the data stored in XML using types and functions that semantically correspond to your application domain rather than dealing with elements, attributes, and text in a direct representation of XML such as DOM or SAX. The XSD compiler uses several Boost libraries (filesystem and regex) in its implementation. The generated code can also map XML Schema date/time built- in types to Boost date_time types. The C++ classes can also be serialized into various binary formats besides XML. Boost serialization library is supported as one of the representations. Major new features in this release: * Support for uniform parsing and serialization of XML documents with varying root elements. * Configurable application character encoding (UTF-8, ISO-8859-1, etc). * Support for stream-oriented, partially in-memory/partially event- driven XML parsing and serialization. * Support for embedding the binary representation of the schema grammar into the application. * Generation of the detach functions that allow moving object model sub-trees without copying. * Support for XML compression. * Smaller and faster generated code for polymorphic XML Schemas (xsi:type and substitution groups). The release also adds support for a range of new operating system and C++ compiler versions, including: * AIX 6.x * Mac OS X 10.6 * Windows 7, * Windows Server 2008 * Visual Studio 2010 (10.0) * GNU g++ 4.5.0 * Intel C++ 11 * Sun Studio 12.1 * IBM XL C++ 11 Visual Studio 2010 project and solution files are provided for all the examples. For the complete list of new features in this release see: http://www.codesynthesis.com/pipermail/xsd-announcements/2010/000038.html CodeSynthesis XSD is available on IBM AIX, GNU/Linux, HP-UX, Mac OS X, Solaris, Windows, OpenVMS, and z/OS. Supported C++ compilers include: GNU g++, HP aCC, IBM XL C++, Intel C++, Sun C++, and MS Visual C++. More information, documentation, source code, and precompiled binaries for all the supported platforms are available from: http://www.codesynthesis.com/products/xsd/ Boris -- Boris Kolpackov, Code Synthesis http://codesynthesis.com/~boris/blog Open-source XML data binding for C++ http://codesynthesis.com/products/xsd XML data binding for embedded systems http://codesynthesis.com/products/xsde Command line interface to C++ compiler http://codesynthesis.com/projects/cli

3 4

People in charge for the Boost-CMake mailing list
by Isidor Zeuner 29 Apr '10

29 Apr '10

Hello fellow Boosters, a couple of days ago I posted a message to the Boost-CMake mailing list and received a notification about the message awaiting moderator approval. Since then it was neither posted, nor did I receive a rejection notice. So I'm wondering if there is currently someone in charge of moderating this list, and if the message will expire at some point. Best regards, Isidor Zeuner

2 3

Request to merge r61263 into release branch
by Jeremiah Willcock 28 Apr '10

28 Apr '10

It's another begin/end disambiguation patch to fix VC++ 10 issues. -- Jeremiah Willcock

3 5

Concept check and __LINE__
by Matthew L. Creech 28 Apr '10

28 Apr '10

I made some trivial changes in a header file today, and suddenly it refused to compile, throwing out boost::concept_check errors. Here's an example error: In file included from /home/mlcreech/work/PCM-tk/etn_export/include/translator++.hpp:193, from ../../common/source/main.cpp:8: /home/mlcreech/work/PCM-tk/etn_export/include/translator/handle.hpp:119: error: conflicting declaration ‘typedef struct boost::concept::detail::instantiate<boost::concept::requirement<Model>::failed [with Model = toolkit::translator::Callable<toolkit::translator::CHandle<toolkit::translator::CValArray<toolkit::translator::CSimpleVal<double> > > >]> toolkit::translator::boost_concept_check119’ /home/mlcreech/work/PCM-tk/etn_export/include/translator/concept/translatable_archetype.hpp:119: error: ‘toolkit::translator::boost_concept_check119’ has a previous declaration as ‘typedef struct boost::concept::detail::instantiate<boost::concept::requirement<Model>::failed [with Model = toolkit::translator::Translatable<toolkit::translator::translatable_archetype<boost::null_archetype<int> > >]> toolkit::translator::boost_concept_check119’ make[3]: *** [translate++] Error 1 I had no idea what this was about, but then I went to look up where the supposed conflicts were and noticed that they were both on line 119. As it turns out, I have 2 different header files which have BOOST_CONCEPT_ASSERT() for different concepts at line 119. It seems that Boost internally generates some global names based on the line number, so it creates 2 identially-named enum definitions. From "boost/concept_check/general.hpp": # define BOOST_CONCEPT_ASSERT( ModelInParens ) \ enum { BOOST_PP_CAT(boost_concept_check,__LINE__) = \ ::boost::concept_check_<void(*) ModelInParens>::instantiate \ } Off-hand I'm not sure how to fix this in Boost (maybe some preprocessor tricks based on __FILE__?), but it seems like it should at least be documented as a limitation. Or maybe there's some other way of using BOOST_CONCEPT_ASSERT() that works around this? Obviously the immediate fix is trivial - add a few blank lines. I just thought I'd bring it up in case others hit the same problem. Thanks -- Matthew L. Creech

4 3

[handling mini-reviews] do we need formal scheduling for this?
by Thorsten Ottosen 28 Apr '10

28 Apr '10

Dar Boosters, Erwann has implemented some cool extensions to Boost.Assign that we would like to include. For example, his work allows code like A list of references (to temporaries, in this example): boost::array<int,9> a = cref_csv( 1,5,3,4,2,9,0,7 ) Chained ranges: vector<int> v = vector<int>( 3,1 ) && vector<int>( 3,2 ) && vector<int>( 3,3 ); See https://svn.boost.org/svn/boost/sandbox/statistics/support/boost/assign/ and https://svn.boost.org/svn/boost/sandbox/statistics/support/libs/assign/ for more info. I think the right thing to do is to make a mini-review. Do we need a special schedule for such reviews or should we just proceed with an announcement on the user and dev list? -Thorsten

2 1

[1.43.0] Release schedule
by Beman Dawes 28 Apr '10

28 Apr '10

The question came up as to whether 1.43.0 is still open for bug fixes. The answer is, yes, with permission from one of the release managers. My rationale is that there are still an uncomfortable number for test failures, and so taking a few more days to clear more failures is well worthwhile. The release is currently scheduled for next Monday, but I'm guessing release may run a few days later than that. --Beman

4 3

[async] withdrawn
by Scott Woods 28 Apr '10

28 Apr '10

Hi Boost, To prevent any further related effort, the library previously offered for review is withdrawn. Vicente explained why my work would need re-licensing and conversion to Boost componentry. Robert explained why the library is not a proper candidate for acceptance into Boost. I respect both of these positions. However, re-licensing and conversion then has little purpose. Regards, Scott

1 0

Library proposal: odeint
by Karsten Ahnert 28 Apr '10

28 Apr '10

Hi, some months ago, I proposed a library for solving ordinary differential equations, which can be found at http://svn.boost.org/svn/boost/sandbox/odeint/ Is it possible to add odeint to the Libraries Under Construction page? Best regards, Karsten

2 3

[range][1.43] Range Algorithms clasification
by vicente.botet 27 Apr '10

27 Apr '10

Hi, The documentation of the range library contains the following sections for Range Algorithms: * Introduction and motivation * Mutating algorithms * Non-mutating algorithms * Set algorithms * Heap algorithms * Permutation algorithms * New algorithms * Numeric algorithms I don't find the clasification enough clear in particular we can find a New algorithms section with the following algorithms * erase * for_each * insert * iota * overwrite * push_back * push_front * remove_erase * remove_erase_if Shouldn't these algorithms be included on the other cathegories? Best, _____________________ Vicente Juan Botet Escribá http://viboes.blogspot.com/

2 1

[range][1.43] mismatch doc
by vicente.botet 27 Apr '10

27 Apr '10

The documentation of the mistmatch function contains several errors. The prototypes return a pair of iterators, but the description talk about The versions of mismatch that return an iterator or a range_return. Could this be improved for 1.43 release or it is better I make a ticket? "Description The versions of mismatch that return an iterator, return an iterator to the first position where rng1 and rng2 differ. Equality is determined by operator== for non-predicate versions of mismatch, and by satisfying pred in the predicate versions. The versions of mismatch that return a range_return, defines found in the same manner as the returned iterator described above." Best, _____________________ Vicente Juan Botet Escribá http://viboes.blogspot.com/

2 1

[range] Check if one sequence is a rotation of other sequence.
by vicente.botet 27 Apr '10

27 Apr '10

Hi I want to define a function is_rotation that check if a sequence is a rotation of another using the following algorithm: a.. First make sure s1 and s2 are of the same length. b.. Check to see if s2 is a substring of s1 concatenated with s1. I have started to implement this using boost range, using the join view to avoid the phisical concatenation but I'm not sure that testing 'boost::search(boost::join(s1,s1), s2) != end(boost::join(s1,s1))' is the best way to do with Boost.Range. bool is_rotation(std::string const &s1,std::string const &s2) { return (boost::size(s1) == boost::size(s2)) && boost::search(boost::join(s1,s1), s2) != end(boost::join(s1,s1))); } Sugestion for improvement? Best regards, _____________________ Vicente Juan Botet Escribá http://viboes.blogspot.com/

1 0

[System] Non-standard code in error_code_user_test
by Doug Gregor 27 Apr '10

27 Apr '10

The code in lib/system/test/error_code_user_test.cpp attempts to default-initialize a const-qualified variable non-POD class type that does not have a user-declared default constructor, which is ill-formed per C++03 [dcl.init]p9 (C++0x [dcl.init]p6). The attached patch fixes the problem be introducing a user-declared default constructor for two of the types we're testing with. - Doug

1 0

[fiber] With MSVC71
by Chard 27 Apr '10

27 Apr '10

I was hoping to try the latest fiber library from the vault, but it currently does not compile successfully with MSVC71. Is it the intention to support this compiler? There are two compilation failures: fiber/strategy.hpp, lines 77-8 template< typename Callable > friend void this_fiber::at_fiber_exit( Callable); I believe this is a VC71 compiler bug; the forward declaration of a template function that is subsequently given friend access to a class does not seem to work. I don't know the workaround. The other can be trivially fixed, and should not cause any issues on other compilers. Here's the patch: --- X:/Old/boost/libs/fiber/src/fiber.cpp Fri Apr 09 19:33:08 2010 +++ X:/New/boost/libs/fiber/src/fiber.cpp Fri Apr 23 11:41:58 2010 @@ -90,7 +90,7 @@ return * this; } -fiber::operator unspecified_bool_type() const +fiber::operator fiber::unspecified_bool_type() const { return info_; } bool

1 0

Re: [boost] VC10 config - some regressions in several libraries
by Brian Wood 27 Apr '10

27 Apr '10

> I've made a note to myself to request that /Za be removed or at least deprecated in VC11 > (our command-line deprecation warnings aren't silenceable, so they're pretty effective). [ snip] Please don't top post and please trim quotes to make things less cumbersome. Regards, Brian Wood Ebenezer Enterprises http://webEbenezer.net

2 1

Color of nodes in Edmonds & Karps max flow algorithms.
by Dan Jiang 27 Apr '10

27 Apr '10

Hi All, I have a question: What is the color(s) of nodes that can still be labeled after max flow is found in the Edmonds and Karp's algorithm? Are they black AND grey or just black? I know black nodes can still be labeled, what about nodes with grey color? -Thanks, Dan _________________________________________________________________ Videos that have everyone talking! Now also in HD! http://go.microsoft.com/?linkid=9724465

2 1

Boost.thread compile error with SunCC 5.9
by Frank Meerkötter 27 Apr '10

27 Apr '10

Hi, I am trying to use boost.thread with the version 5.9 of the sun compiler. I encountered an error during compilation which already has been reported by Urs Stotz some weeks ago. He also supplied a patch for this issue. http://lists.boost.org/Archives/boost/2010/02/161801.php The patch works for me. I wonder if it could be applied for 1.43? Kind Regards, Frank

3 3

[GSoC] Student Proposals
by Andrew Sutton 27 Apr '10

27 Apr '10

Hi All, I'd like to start by thanking all of the students who are interested in working on the Boost C++ Libraries and submitted proposals. Unfortunately, we can't fund every proposal we received (about 85), and the competition for available funding slots (only 10) is very competitive. We carefully reviewed every proposal based on the merits and feasibility of the work described. If your proposal was not accepted, that does not mean that it was without merit. We encourage all students to continue participating with the Boost community as users and developers, regardless of the results of this program, and look forward to seeing new proposals next year. If you are interested in feedback about your proposal's review and how you can improve the competitiveness of your submissions, feel free to contact me directly. Having said that, congratulations to the students whose projects were accepted. I will be sending out instructions soon on getting started and up to speed with the Boost development infrastructure, Subversion, mailing lists, etc. I'm will be posting the instructions to the Boost developers mailing list (not users!). If you are a student whose project was accepted, you need to subscribe to the Boost developer's mailing list [1]. I'd also like to thank all of the mentors for helping with the ranking and assignment of student projects. Thanks again and best regards, Andrew Sutton andrew.n.sutton(a)gmail.com [1] http://lists.boost.org/mailman/listinfo.cgi/boost

1 0

[GSoC] Implementation of arbitrary precision integers (BigInts)
by Adam Smith 27 Apr '10

27 Apr '10

Hi, First of all, I'd like to extend thank you to whoever chose my proposal - it's a great honour, and I'm very excited to contribute to Boost. Just a few questions to start with; these are primarily for my mentor (Rene Rivera), I guess, but of course others could chime in. Will most communication happen on the mailing lists or on #boost or #boost-soc? If the latter, roughly what time of day should I be online? Alternatively, would direct e-mail communication be preferred? Are there any particular documents I should read? Any preliminary tasks that I should do? Thanks again for accepting my proposal! Adam

2 1

[1.43] regex build files
by Richard Hazlewood 27 Apr '10

27 Apr '10

Reminder; you might want to update the stand-alone makefiles in /branches/release/libs/regex/build Is it worth continuing with these? Seems like an unnecessary maintenance overhead, especially given that bjam seems to do it all. Chard.

2 1

fixing the compilation of the math lib on HPUX
by Frank Meerkötter 27 Apr '10

27 Apr '10

Hello, I am currently trying to build boost with the HP aCC (aCC: HP C/aC++ B3910B A.06.12 [Nov 03 2006]). The build fails for the tr1 math lib. [...] acc.compile.c++ bin.v2/libs/math/build/acc/release/threading-multi/copysign.o "libs/math/build/../src/tr1/copysign.cpp", line 16: error #2247: function "copysign(double, double) C" has already been defined extern "C" double BOOST_MATH_TR1_DECL copysign BOOST_PREVENT_MACRO_SUBSTITUTION(double x, double y) ^ 1 error detected in the compilation of "libs/math/build/../src/tr1/copysign.cpp". [...] acc.compile.c++ bin.v2/libs/math/build/acc/release/threading-multi/copysignf.o "libs/math/build/../src/tr1/copysignf.cpp", line 16: error #2247: function "copysignf" has already been defined extern "C" float BOOST_MATH_TR1_DECL copysignf BOOST_PREVENT_MACRO_SUBSTITUTION(float x, float y) 1 error detected in the compilation of "libs/math/build/../src/tr1/copysignf.cpp". [...] "libs/math/build/../src/tr1/fmaxf.cpp", line 16: error #2247: function "fmaxf" has already been defined extern "C" float BOOST_MATH_TR1_DECL fmaxf BOOST_PREVENT_MACRO_SUBSTITUTION(float x, float y) ^ 1 error detected in the compilation of "libs/math/build/../src/tr1/fmaxf.cpp". acc.compile.c++ bin.v2/libs/math/build/acc/release/threading-multi/fminf.o "libs/math/build/../src/tr1/fminf.cpp", line 16: error #2247: function "fminf" has already been defined extern "C" float BOOST_MATH_TR1_DECL fminf BOOST_PREVENT_MACRO_SUBSTITUTION(float x, float y) ^ 1 error detected in the compilation of "libs/math/build/../src/tr1/fminf.cpp". In all cases the code causing the problems looks somewhat like this: #if !(defined(__HP_aCC) && (__HP_aCC >= 61400)) extern "C" float BOOST_MATH_TR1_DECL fminf BOOST_PREVENT_MACRO_SUBSTITUTION(float x, float y) #endif [...] So it looks like someone already took some precautions against this problem. My compiler is slightly older (61200 vs. 61400). When i replace the 61400 at these four places with a 61000 my build completes just fine. ./libs/math/src/tr1/copysign.cpp:#if !(defined(__HP_aCC) && (__HP_aCC >= 61400)) ./libs/math/src/tr1/copysignf.cpp:#if !(defined(__HP_aCC) && (__HP_aCC >= 61400)) ./libs/math/src/tr1/fmaxf.cpp:#if !(defined(__HP_aCC) && (__HP_aCC >= 61400)) ./libs/math/src/tr1/fminf.cpp:#if !(defined(__HP_aCC) && (__HP_aCC >= 61400)) Can anybody more experienced with the aCC tell me if such a change would be a good idea? Would you accept a patch? Frank

2 3

Re: [boost] [1.43][Serialization] Serialization library seriosly broken
by Hartmut Kaiser 27 Apr '10

27 Apr '10

> Hartmut Kaiser wrote: > >> I've just made a change in void_cast.cpp. I tested it here and > >> checked > > into > >> the trunk(61546). > >> > >> Could you test this change ASAP? > > > > I will be able to test tomorrow evening only, but I definitely will > > test. > > > > Regards Hartmut > > You might want to check the change I made as well. The assert exists in 1.42 > - the only difference in the file - void_cast.cpp is a small change I made to fix > a memory leak. I'm not confident that my fix actually fixed it - but of course > everything passes here. I'm sorry to say I recompiled everything against Boost trunk (rev. 61561), but the problem still persists. I don't understand what's going on, but I doubt it's a problem directly in void_cast.cpp. For some reason the type I described gets registered more than once (definitely from different modules, although dynamically loaded, none gets unloaded before the assertion). Did you change anything related to auto-type registration? Regards Hartmut --------------- Meet me at BoostCon www.boostcon.com

4 8

[1.43] Beta build of PDF docs available.
by John Maddock 27 Apr '10

27 Apr '10

A PDF build of the docs for Boost-1.43-beta is now available from https://sourceforge.net/projects/boost/files/boost-docs/1.43.0/boost_pdf_1_… If library authors with quickbook/boostbook docs could take a look and check for SNAFU's that would be great. Enjoy, John.

2 2