October 2005 - Boost - lists.boost.org

[test] --catch_system_errors=no doesn't work with minimal test
by David Abrahams 07 Nov '05

07 Nov '05

When using boost/test/minimal.hpp, it doesn't respond to the presence of --catch_system_errors=no, which makes it unreasonably difficult to debug problems on Windows. All I get is an exception caught by the test library, with all of the info about the real cause of the error lost, which is absolutely unhelpful. It seems to me that the minimal configuration ought to at least be useful for writing and debugging simple test cases. -- Dave Abrahams Boost Consulting www.boost-consulting.com

3 8

Report from Mont Tremblant C++ Committee meeting
by Beman Dawes 07 Nov '05

07 Nov '05

The C++ Standards Committee met this past week in Mont Tremblant, Quebec, Canada. Many Boosters were present, and Boost continues to get praise and encouragement from non-Boost committee members. The Library Working Group (LWG) is starting serious work on TR2. Initial proposals for several Boost libraries were evaluated: Filesystem : Interested? Yes 17, No 0 Date-Time : Interested? Yes 9, No 0 Range : Want a C++03 version aimed at TR2, but still interested in a version based on new language features (Concepts perhaps?). String-algo : Interested, but concern over interface and choice of functions, generic vs basic_string.5.3 separate proposal numeric_cast<> : Interested? Yes 10, No 0 Interval : Interested? Yes 7, No 4. Concerns about sufficiently large user base to justify standardizing. Optional : Interested? Strong yes 9, weak yes 2, weak no 3, strong no 0 Significant concerns about the interface: Pointer interface. Two ways of doing the same thing. Depends on nullptr - is there a backup plan. Dubious of use of references. "Boost style" Threads : Pursue? Strong yes 9, weak yes 5, weak no 0, strong no 1 Also: minmax and / or algorithm std::minmax_element In favor 13, Not in favor 0 TR2 0 2 1 0 C++0X 1 8 0 0 Kevlin Henney Threads : Ask for fleshed-out proposal? Strong yes 3, weak yes 6, weak no 2, strong no 1 The next C++ Committee meeting will be in Berlin, Germany, the first week of April 2006. The meeting after that will be in Portland, Oregon, US, in October 2006. --Beman

34 139

Boost's position/work on a Standard GUI Library for C++0x
by David Wehite 06 Nov '05

06 Nov '05

In his article "The Design of C++0x", published in C/C++ Users Journal, May 2005, the author of C++ Bjarne Stroustrup wrote, "The most commonly requested new feature for C++ is a standard GUI". I am new to Boost and will appreciate if some folks here would give me a summary of Boost organization's standing on such a standard GUI library. If and how was it addressed and pointers to work on the subject if such has been done. I just want to clarify, that when I say "standard", I mean that as long as my application source code adheres to that standard, if I take it and walk into any machine that has a C++ compiler (at least one that deserves that title), compilation would at least not fail for syntax reasons, w/o me changing a single character in the source (not even changing the case of a character), no matter how complex and/or large that source is. I don't know how to avoid a sea of answers with this mailing list arrangement (not that I think that my 2.6GB gmail box would soon fill up...), may be the few answers can be posted on the newsgroup forum? Thanks in advance for the education, David

33 162

autoconf-like configure on RC_1_33_0 branch
by Doug Gregor 05 Nov '05

05 Nov '05

I've placed an autoconf-like "configure" script on the RC_1_33_0 branch. If you're a *nix user and would like an alternative to directly using bjam, give it a try and send me some bug reports :) Typically one would just use: ./configure --prefix=/where/to/install make make install Run "./configure --help" for more options. Cheers, Doug

9 13

Documentation Wizard
by Rob Stewart 05 Nov '05

05 Nov '05

Quite some time ago, Dave Abrahams announced that I was the new Boost Documentation Wizard. I said I'd write something on the subject and that is long overdue. Herewith, I describe what I think the DocWiz should do and what is needed from volunteers to make it happen. That is, I'm trying to document the new DocWiz role and solicit your help. Please have a look and comment on what I'm proposing. If you don't like the direction I'm planning, say so. If you think I've missed something, let me know. If you think you can help in some way, please let me know; I can't do the job alone. The DocWiz's purpose is to try to foster better documentation for Boost. Since this is something new at Boost, some measures will be grandfathered* of necessity, while others will likely be retrofitted to existing documentation. Some things will be purely stylistic, but most will be substantive. A significant problem with writing library documentation is that English is often not the library author's primary language.* It is all too common that those who can write C++ fluently cannot write English well. Thus, we need a means to ensure that the library author's ideas are well communicated. Another problem with writing library documentation is knowing what to write. How much detail is sufficient? How many code examples should there be? How much material should be relegated to a reference section and how much should be presented in a tutorial? What is a sufficient rationale for the library? Many of these issues can be addressed by seeking insight from what has been written well already and by seeking advice from those expert on the tasks. From that information we can capture best practices to assist new documentation authors. Still another problem is consistency. As Boost grows, having a reasonably consistent look and feel to our documentation becomes increasingly important. Naming and organizing sections in our documentation must be consistent across libraries to simplify locating desired information in each library. Given the rate at which new libraries are proposed, I cannot do this task alone. I'm the father of eight (yes, 8!) children (so far, at least), I have a full time job, etc. Like everyone else, I'm quite busy. Thus, I need help. I intend to be the manager of a group of folks who can divide the workload to make it manageable. To that end, I propose the following positions to assist in improving the state of Boost documentation: Editors - Folks with demonstrably good English skills who can assist library authors by clarifying and correcting the documentation at various times, as determined by the author, so the meaning is clear. Editors also advice the author on structural changes necessary to conform to Boost guidelines. Editors are not so much concerned with content as with clear communication of what is included. Domain Experts*** - Folks with special skills in writing certain types of documentation such as concepts or tutorials; when a library author is struggling to write a portion of the library's documentation, the author can call upon the appropriate domain expert for assistance. Mentors - Folks with skills and desire to write good documentation who can come alongside a new library author to ghost write, share writing tasks, suggest content, etc. The output from author/mentor collaboration must still be approved by an editor. The workload of an editor will be varied since the number of authors writing documentation varies and based upon their update schedules. The workload of a domain expert should be quite low as folks writing concept descriptions, for example, should not need a domain expert's input often or long. The workload of a mentor likely will be as high as the mentor wishes. Initially, anyone acting as an editor will need to prove his/her skills by relying on trusted editors to proof the results. Once proven, a new editor can act autonomously. The expected result of this group of folks is documentation that is acceptable to Boost. I propose that a library cannot be fully accepted by Boost without the DocWiz's approval. IOW, a library can be conditionally accepted pending documentation approval. (That approval may be given based solely upon the word of a trusted editor; the DocWiz needn't read every document to give approval, but the responsibility does lie with the DocWiz for deficient approved documentation.) Note that the DocWiz is not the final authority on what is acceptable documentation. Users of that documentation are. An author will likely need to update documentation based upon user experience. Such changes should be subject to an editorial review, too, in order to maintain high standards. -------- * That means that existing documentation needn't be changed to conform to new policies, but may be if the author chooses. ** Another problem is that English *is* the library author's primary language. :) *** The name "domain expert" smacks too much of someone who is expert in the domain of the library rather than of a particular aspect of library documentation. Please suggest a better name. -- Rob Stewart stewart(a)sig.com Software Engineer http://www.sig.com Susquehanna International Group, LLP using std::disclaimer;

6 6

Active objects?
by Jason Hise 04 Nov '05

04 Nov '05

I watched the talk Herb Sutter gave recently regarding concurrency, and I have to say I find the ideas of active objects and future variables to be very exciting. (A link to the talk is provided below, which must be viewed with Internet Explorer). I noticed that Boost already has a futures library in the sandbox under development, which from what I can tell looks well designed. Are there any plans to add the functionality of active objects to boost as well? I would be interested in hearing how you think the problem would be best approached. From what I can tell, it should ideally be possible to use 'active' as a modifier like 'const' or 'volatile' in front of a specific object instance, and have all member function calls automatically add themselves to a queue when called, instead of actually being called. Because this syntax is probably impossible to pull off, I think the next best thing would look something like the following: struct MyClass { int foo ( int arg1, const char * arg2 ); }; void test ( ) { active < MyClass > object; future < int > i = object.request ( MyClass::foo, 42, "blah" ); } 'request' could also be spelled 'enqueue', 'invoke', or 'operator ()', although I'm not sure if the terseness of the latter would be sensible. 'active' would probably use CRTP to derive privately from 'MyClass', enforcing that member functions of MyClass are not called directly. Thoughts? Herb Sutter's video: http://microsoft.sitestream.com/PDC05/TLN/TLN309_files/Default.htm#nopreloa… -Jason

13 29

Alternative solution to intermediate results problem of expression templates.
by Korcan Hussein 01 Nov '05

01 Nov '05

Hi I'm not sure if this has already been explored or even in current use but I think I may have come up with an alternative solution to the type deduction of intermediate results from expression templates. Instead of using automatic type erasing technique, take the compile-time parse tree of an intermediate expression and create an exact runtime replica of the expression tree using recursive variant types (using Boost.Variant in C++). The creation of the expression tree can be completely automated. I have tried this myself with promising results. The only (minor) downside is in order to avoid redundant copies of operands the types of the operands must be given but not the structure of the compile-time expression tree itself. Leaf nodes of the recursive variant hold constant references to there elements. I've done quick profile of this against the traditional eager evaluation of overloaded operators and it still is more efficient but tree creation does cost in time slightly. If people are interested I can post code the code for this.

4 20

[serialization] fast array serialization (10x speedup)
by Matthias Troyer 01 Nov '05

01 Nov '05

Hi Robert, Over the past week I got around to doing what I wanted to do for a long time, and implemented an improved serialization of contiguous arrays of fundamental types. The motivation was two-fold: i) to speed up the serialization of large data sets by factors of up to 10 ii) to allow implementation of serialization by MPI The problem with the serialization of large contiguous arrays of fundamental types (be it a C-array, a std::vector, a std::valarray, boost::multi_array, ...) is that the serialization function is called for each (of possible billions) elements, instead of only once for the whole array. I have attached a suite of three benchmark programs and timings I ran on a PowerbookG4 using Apple's version of the gcc-4 compiler. The benchmarks are a) vectortime: reading and writing a std::vector<double> with 10^7 elements to/from a file b) arraytime: reading and writing 1000 arrays double[10000] to/ from a file c) vectortime_memory: reading and writing a std::vector<double> with 10^7 elements to/from a memory buffer The short summary of the benchmarks is that Boost.Serialization is 5-10 times slower than direct reading or writing! With the fast array serialization modifications, discussed below, this slowdown is removed. Note that the codes were compiled with -O2. Without -O2 I have observed another factor of 10 in slowdown in some cases In order to implement the fast array serialization, I made the following changes to the serialization library: i) a new traits class template <class Archive, class Type> has_fast_array_serialization<Archive,Type>; which specifies whether an Archive has fast array serialization for a Type. The default implementation for this traits class is false, so that no change is needed for existing archives. ii) output archives supporting fast array serialization for a given Type T provide an additional member function save_array(T const * address, std:;size_t length); to save a contiguous array of Ts, containing length elements starting at the given address, and a similar function load_array(T * address, std:;size_t length); for input archives iii) serialization of C-arrays and std::vector<T> was changed to use fast array serialization for those archives and types where it is supported. I'm still working on serialization for std::valarray and boost::multi_array using the same features. iv) in addition, to support an MPI serialization archive (which is essentially done but still being tested), and to improve portability of archives, I introduced a new "strong" type BOOST_STRONG_TYPEDEF(std::size_t, container_size_type) for the serialization of the size of a container. The current implementation uses an unsigned int to store the size, which is problematic on machines with 32-bit int but 64 bit size_type . To stay compatible with old archives, the serialization into binary archives converts the size to an unsigned int, but this should be changed to another type, and the file version number bumped up to allow containers with more than 2^32 elements. The second motivation was MPI serialization, for which I need the size type of containers to be a type distinct from any other integer. The explanation is lengthy and I will provide the reason once the MPI archives are finished. v) also the polymporphic archives were changed, by adding save_array and load_array functions. Even for archives not supporting fast array serialization per se this should improve performance, since now only a single virtual function call is required for arrays, instead of one per element. The modifications are on the branch tagged "fast_array_serialization", and I have attached the diffs with respect to the main trunk. I have performed regression tests under darwin, using Apple's version of gcc-4. None of the changes should lead to any incompatibility with archives written with the current version of the serialization library, nor should it break any existing archive implementation. Regarding compatibility with non-conforming compilers the only issue I see is that I have used boost::enable_if to dispatch to either the standard or fast array serialization. We should discuss what to do for compilers that do not support SFINAE. My preferred solution would be to just disable fast array serialization for these compilers, to keep the changed to the code minimal. The other option would be to add another level of indirection and implement the dispatch without using SFINAE. Robert, could you take a look at the modifications, and would it be possibly the merge these modifications with the main trunk once you have finished your work for the 1.33.1 release? Best regards Matthias

6 42

[MPL.Math] rational_part or fractional_part?
by Cromwell Enage 01 Nov '05

01 Nov '05

--- Daryle Walker wrote: > Is BOOST_MPL_MATH_RATIONAL_PART_OF_RATIONAL a > re-statement of the rational number itself? No. > Or is it supposed to be the remainder after taking > out the "whole" part? Yes. > If the latter, then the name should have "FRACTIONAL" > replacing the first "RATIONAL", since "fractional" > and not "rational" better describes a left-over bit. For consistency this part of the macro name is lexically the same as the template name whose specialization the macro creates, i.e. rational_part. > (Rational numbers are a generalization of fractions > that include values with absolute values greater than > one, i.e. a numerator larger than its denominator [in > absolute value].) I have no qualms about changing the name, as long as all interested parties agree. Andy Little? Cromwell D. Enage __________________________________ Yahoo! Mail - PC Magazine Editors' Choice 2005 http://mail.yahoo.com

5 8

[MPL.Math] numeric concepts
by Cromwell Enage 01 Nov '05

01 Nov '05

--- Andy Little wrote: > BTW, I have found that the ability to convert a > rational to an integral_constant if possible is a > useful utility too, though I'm not quite sure > what purists would make of it as the resulting > ::type may be an integral_constant or maybe a > rational constant. I currently call it > "simplify_rational_or_numeric". The resulting ::type > works ok if accessed using the numerator and > denominator functions, and this allows me to make > lists of dimensions using both integral_constants and > rationals. Maybe there is room for such a concept as > an "mpl rational or numeric concept"? In my yet-to-be-submitted documentation, I have the following numeric metatype hierarchy: Numeric Constant | +--Real Numeric Constant | | | +--Discrete Constant--Bitwise Constant | | | | | | +--Integral Constant------+ | | | | | | +--Big Integral Constant--+ | | | +--Continuous Constant | | | +--Rational Constant | | | +--Mixed Numeric Constant | +--Complex Numeric Constant Each concept is defined in terms of the metafunctions that can operate on it, and their semantics. In this scheme, both Integral Constants and Rational Constants are Real Numeric Constants. Not only do the arithmetic metafunctions (negate, plus, minus, times, divides), a few comparison metafunctions (equal_to, not_equal_to), and a few numeric metafunctions (is_zero, zero, real_part, imaginary_part) work on them as they do on other Numeric Constants; but all the other comparison metafunctions (less, greater, less_equal, greater_equal) and all the other numeric metafunctions (is_negative, abs, numerator, denominator, whole_part, fractional_part) work on them as well. A few metafunctions have different semantics for Discrete Constants; e.g. the numerator or whole_part of an Integral Constant is itself, its denominator is always one, and its fractional_part is always zero. To obtain the corresponding run-time values, use the runtime_value facility, which is required to operate on all Numeric Constants. Let me know of any details that need to be fleshed out for you. Cromwell D. Enage __________________________________ Yahoo! FareChase: Search multiple travel sites in one click. http://farechase.yahoo.com

2 2