- Boost - lists.boost.org

Boost Build Experiences
by Dan Weber 17 May '07

17 May '07

Hi there, Last night I had a great experience for the first time with bjam and boost-build. Installation was the most difficult part, but after that writing the Jamroot was done in under 30 minutes for a library I'm working with that has a really lousy existing build system. I needed full install support (missing in the library's build) that worked consistently across operating systems. Overall, it was a great success and I'll be moving my development projects to boost-build. The only thing I couldn't figure out how to do was be able to set OS specific settings without having to rewrite the entire lib $LIBRARYNAME for that variant. Although, come to think of it, aliases would have worked well. Thanks, Dan

3 3

[1.34] tuple's documentation
by Christian Henning 17 May '07

17 May '07

Hi there, just browsed through the tuple's doc and I think we need to update the Portability section: This is what it's now: Portability The library code is(?) standard C++ and thus the library works with a standard conforming compiler. Below is a list of compilers and known problems with each compiler: Compiler Problems gcc 2.95 - edg 2.44 - Borland 5.5 Can't use function pointers or member pointers as tuple elements Metrowerks 6.2 Can't use ref and cref wrappers MS Visual C++ No reference elements (tie still works). Can't use ref and cref wrappers I'm using the MS VC 7.1 compiler and for this the statement is simply not true anymore. I hope not too many people got turned off by this message. Christian

1 0

string_algo find/split
by Shams 17 May '07

17 May '07

Hi Pavol, For upcoming 1.34.1 Any chance of making iter_find, iter_split documented. If no chance then can you consider allowing passing the FinderT Finder in iter_join(..., FinderT Finder) and iter_split(FinderT Finder) as parameters to find_all and split. or should we always just use find_iterator/split_iterator (bit more coding :-) and write our own wrappers around them... Thanks Shams --

2 3

Re: [boost] Boost building with CMake
by Boris Gubenko 17 May '07

17 May '07

Johan Nilsson wrote: > While I'm at that point (cross-platform) - does anyone know if CMake is > available for OpenVMS? I'm well aware that Boost.Build isn't compatible > with OpenVMS currently, but I also believe that porting the current > system would not be impossible as most of the Jam stuff is VMS-capable. I don't know if Cmake is available VMS. From http://www.vtk.org/Bug/bug.php?op=show&bugid=3974&pos=6 it looks like the only problem with Cmake on VMS is that it does not generate MMS rules (as you, probably, know, MMS is VMS native make, it is close to Posix make. Since VMS has gmake (on the Freeware CD) and Cmake can generate rules for gmake, I'm not sure what's the point in adding support for MMS to Cmake. Anyway, I'll try to find out if Cmake was ported to VMS and will get back to you. Thanks, Boris

2 1

[math toolkit] Review results
by Matthias Schabel 17 May '07

17 May '07

I'd like to congratulate John Maddock, Paul Bristow, and their contributors on putting together an outstanding submission to Boost. It is rare to have complete unanimity among votes, but in this case there were no dissenters to accepting either the special functions or the statistical distributions portions of the library, so I'm glad to announce that it has been accepted for inclusion in Boost. Thanks to the many participants in the review : Gottlob Frege, Guillaume Melquiond, Johan Råde, Arnaldur Gylfason, John Phillips, Mark Van De Vyver, Stephan Tolksdorf, Hubert Holin, Seweryn Habdank-Wojewodski, Kevin Lynch, Leonaldo Peralta, Jeff Garland, and Stefan Seefeld (apologies for anyone I might have missed in this list). Here is a brief summary of the relatively few major issues that were raised during the course of the review : 1) Error handling is an issue that arises because this library is at the frontier between traditional numerical libraries and a (hopefully) new breed of such libraries that utilize modern programming techniques and facilities. Jeff Garland suggested that the default behavior should be to throw an exception, with errno being an option enabled by macro. It would also be nice to have more granular control over which instances throw exceptions and which do not (so, for example, a user could choose to ignore denormals). It was also suggested that additional, more transparent exceptions be provided for cases such as failure to converge rather than reusing tools::logic_error. 2) Jeff Garland also pointed out, rightly in my opinion, that attempts to use statistical functions that do not exist for a distribution should fail to compile rather than leading to a runtime error (e.g. mean of a Cauchy distribution). A reasonable method of implementing this should be devised or a strong argument for why it is not feasible/desirable provided. 3) Arnaldur Gylfason did some nice accuracy and performance testing vs. R. It was noted that the performance of quantile functions in this library was significantly worse than R, unlike non-quantile functions. He also pointed out that, for discrete distributions, the current behavior of returning fractional results for quantiles may not be the expected one. These issues should be addressed and documented. 4) Hubert Holin suggested the possibility of use of a policy parameter to choose between speed and accuracy. Another interesting possibility would be to allow the user to specify the desired precision either at compile or runtime. 5) It appears that this library will actually become two "sublibraries" within the Boost.Math library. Currently all code lives in the boost::math namespace; I would like to at least see a discussion of the possibility of having boost::math::special_functions, boost::math::statistics, and, perhaps, boost::math::statistics::distributions namespaces - as more functionality gets added to boost::math, collisions will become more likely, so some thought given now to logical partitioning may save pain later. During the review a number of typos and minor issues of documentation were raised, which the authors will need to address if they haven't already. In particular, John Phillips noted that the rationale behind using rational (vs. polynomial) approximations be clarified, the derivation of coefficients be documented, and the list of special functions in the documentation be expanded to encompass all functions actually implemented in the library. Stephan Tolksdorf requested a table listing standard statistical tests and the corresponding library implementations and enumerated a number of other documentation issues. Overall, the library was very well received, and the authors are to be commended on the tremendous amount of care and effort devoted to its preparation. Matthias Schabel Review Manager

4 5

[random] lognormal_distribution fix
by Tim Blechmann 17 May '07

17 May '07

hi all, i just figured out, that the problem, that was discussed in this thread: http://lists.boost.org/Archives/boost/2003/02/44916.php somehow hasn't been fixed ... i've attached a small regression test, showing the problem ... the fix is rather trivial, though: --- boost/random/lognormal_distribution.hpp (revision 681) +++ boost/random/lognormal_distribution.hpp (working copy) @@ -60,8 +60,8 @@ // compiler-generated copy ctor and assignment operator are fine - RealType& mean() const { return _mean; } - RealType& sigma() const { return _sigma; } + RealType mean() const { return _mean; } + RealType sigma() const { return _sigma; } void reset() { _normal.reset(); } template<class Engine> would be great to see this fixed ... cheers, tim -- tim(a)klingt.org ICQ: 96771783 http://tim.klingt.org The aim of education is the knowledge, not of facts, but of values William S. Burroughs

2 2

[GSoC 07] Visualizing STL
by Jake Voytko 17 May '07

17 May '07

I'm working on the Summer of Code project "Visualization of STL Containers", the goal of which is to create 2D graphs of data stored in STL containers. (For more details, see the Trac link at the bottom of the email) The basic organization of the code is a "svg" class for working directly in the SVG format, and a "svg_graph" class that inherits from "svg" that the user uses as an interface. My current predicament is the design of the "svg" class itself. My personal view of the "svg" class was simply that it separates the handling of the svg document from the handling of the graphing logic. This was the way I designed the rapid prototype, and ostensibly, it worked. In my head, the "svg" class could technically be implemented without any external interface for users, and exist as a worker class. However, this doesn't seem at all ideal from a long-term planning perspective. I want to know if people would want me to spend some of the time of this project making the "svg" class act as a stand-alone (yet not fully implemented, obviously) SVG solution. Should it have a proper user interface? Should it be extensible to a full-blown SVG solution in the future? More specifically, are people looking for both a SVG manipulating class *AND* a way to graph STL data? There were suggestions of even treating the "svg" class as manipulating a document as per the DOM standard, which is indeed possible, but would require a complete overhaul of my current design, which I set up my current design in order to make optimizations on space and speed in the future. I see the obvious long term benefits of this method, but I question the benefit to the current project. I only have a finite amount of time in which to complete this, and it seems like it would take away from the stated goal. However, I'd be more than glad to implement a DOM if there were clamorous demand for this feature! Thank you for your time Jake Voytko Link to wiki on the project: http://svn.boost.org/trac/boost/wiki/soc/2007/VisualizationOfContainers

5 5

Trac milestones
by Vladimir Prus 17 May '07

17 May '07

Is it possible for somebody with enough karma to create "1.34.1" milestone in trac, so that bugs can be assigned to that milestone? - Volodya

4 4

[algorithm][string] example fails to compile with bjam.v2
by JD 17 May '07

17 May '07

Hi, bjam on 1_34_0 and on HEAD fails to compile algorithm/string/example: *********************************************************************** bjam --toolset=msvc-8.0 warning: Graph library does not contain optional GraphML reader. note: to enable GraphML support, set EXPAT_INCLUDE and EXPAT_LIBPATH to the note: directories containing the Expat headers and libraries, respectively. warning: skipping optional Message Passing Interface (MPI) library. note: to enable MPI support, add "using mpi ;" to user-config.jam. note: to suppress this message, pass "--without-mpi" to bjam. note: otherwise, you can safely ignore this message. warning: Python location is not configured warning: the Boost.Python library won't be built Building Boost.Regex with the optional Unicode/ICU support disabled. Please refer to the Boost.Regex documentation for more information (don't panic: this is a strictly optional feature). Jamfile:10: in modules.load rule subproject unknown in module Jamfile</G:/Program Files/boost-cvs/boost/libs /algorithm/string/example>. G:/Program Files/boost-cvs/boost/tools/build/v2/build\project.jam:312: in load-j amfile G:/Program Files/boost-cvs/boost/tools/build/v2/build\project.jam:68: in load G:/Program Files/boost-cvs/boost/tools/build/v2/build\project.jam:170: in projec t.find G:/Program Files/boost-cvs/boost/tools/build/v2\build-system.jam:237: in load G:\Program Files\boost-cvs\boost\tools\build\v2/kernel\modules.jam:261: in impor t G:\Program Files\boost-cvs\boost\tools\build\v2/kernel/bootstrap.jam:132: in boo st-build G:\Program Files\boost-cvs\boost\boost-build.jam:9: in module scope *********************************************************************** Seems that the jamfile has not been updated for the new build system. I'm no expert in bjam and I don't find the documentation very helpful but the Jamfile attached can at least compile most of the example (apart regex_example). Thanks. JD # Boost string_algo library examples Jamfile --------------------------------- # # Copyright Pavol Droba 2002-2003. Use, modification and # distribution is subject to the Boost Software License, Version # 1.0. (See accompanying file LICENSE_1_0.txt or copy at # http://www.boost.org/LICENSE_1_0.txt) # # See http://www.boost.org for updates, documentation, and revision history. exe conv_example : conv_example.cpp : <include>$(BOOST_ROOT) : ; exe predicate_example : predicate_example.cpp : <include>$(BOOST_ROOT) : ; exe find_example : find_example.cpp : <include>$(BOOST_ROOT) : ; exe replace_example : replace_example.cpp : <include>$(BOOST_ROOT) : ; exe rle_example : rle_example.cpp : <include>$(BOOST_ROOT) : ; exe trim_example : trim_example.cpp : <include>$(BOOST_ROOT) : ; exe regex_example : regex_example.cpp : <include>$(BOOST_ROOT) : ; exe split_example : split_example.cpp : <include>$(BOOST_ROOT) : ;

3 2

bjam FAQ
by Michael Walter 17 May '07

17 May '07

Hi, I've stumbled on that "Duplicate name of actual target" error; unfortunately the FAQ doesn't seem to solve my problem, since I'm trying to compile two different files which happen to have the same basename, i.e. something like this: lib foo : bar/test.cpp baz/test.cpp ; What's the proper way to handle this situation, except for manually specifying the object file name? Regards, Michael

5 4