- Boost - lists.boost.org

[Report] 0 regressions on RC_1_34_0 (2007-05-17)
by Douglas Gregor 17 May '07

17 May '07

Boost Regression test failures Report time: 2007-05-14T23:41:53Z This report lists all regression test failures on release platforms. Detailed report: http://engineering.meta-comm.com/boost-regression/CVS-RC_1_34_0/developer/i… No failures! Yay!

1 0

Re: [boost] Boost 1.34 Unit test suite - BOOST_PARAM_TEST_CASE
by Chad Maron 17 May '07

17 May '07

I know the error has nothing to do with BOOST_PARAM_TEST_CASE, just like I mentioned in the sentence immediately following the error. I mention BOOST_PARAM_TEST_CASE because that is the where I found code to use to prevent the parameters from being destroyed until the test case is run. I also know the reason for the error, my question is what is the new technique for 1.34. "The user should make sure that parameters list will not be destroyed until the test case is run. That's why it not recommended to create a parameters list as local variable in init_unit_test_suite. A simple way to handle a parameters list lifetime is to place it into a user defined test suite class." - http://www.boost.org/libs/test/doc/components/utf/components/test_case/para… Again, I know this won't work in 1.34... but what will? *IS* there a new simple method for this in 1.34? How much code will I have to modify to get my tests to work with the new version? Here is an example code modeled after the examples from http://www.boost.org/libs/test/doc/components/utf/components/test_case/para… and http://www.boost.org/libs/test/doc/components/utf/components/test_case/para… ----- #include <iostream> #include <map> #include <string> #include <boost/shared_ptr.hpp> #include <boost/test/unit_test.hpp> #include <boost/test/parameterized_test.hpp> #include <boost/test/included/unit_test_framework.hpp> using boost::unit_test::test_suite; void parse_test(std::string str) { BOOST_CHECK(1); } struct sub_test_suite : public boost::unit_test::test_suite { sub_test_suite() { while(std::cin) { getline(std::cin, input_line); if(input_line.size() > 0) { queries.push_back(input_line); } } add( BOOST_PARAM_TEST_CASE( &parse_test, queries.begin(), queries.end() ), 0 ); } std::string input_line; std::vector<std::string> queries; }; test_suite* init_unit_test_suite( int, char* [] ) { test_suite* test= BOOST_TEST_SUITE( "Spirit SQL parser" ); test->add(new sub_test_suite()); return test; } -----Original Message----- From: boost-bounces(a)lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Gennadiy Rozental Sent: Wednesday, May 16, 2007 2:44 AM To: boost(a)lists.boost.org Subject: Re: [boost] Boost 1.34 Unit test suite - BOOST_PARAM_TEST_CASE "Chad Maron" <cmaron(a)logicworks.net> wrote in message news:82DA1BC8E3377840AAC2B22ACFAB1EE437FD4CF5@exchange3.corp.logicworks.net... > Hey all, > > I have some code that is essentially doing what is suggested on the > Parameterized free function based test case page > (http://www.boost.org/libs/test/doc/components/utf/components/test_case/para…) > > This technique worked fine in 1.33.1 but in 1.34 I get the following error > when I try to compile my test: > > Test.cpp: In constructor > 'sub_test_suite::sub_test_suite(boost::shared_ptr<Tester>)': > Test.cpp:98: error: no matching function for call to > 'boost::unit_test::test_suite::test_suite()' > /usr/local/include/boost-1_34/boost/test/impl/unit_test_suite.ipp:110: > note: candidates are: > boost::unit_test::test_suite::test_suite(boost::unit_test::const_string) > /usr/local/include/boost-1_34/boost/test/unit_test_suite_impl.hpp:116: > note: boost::unit_test::test_suite::test_suite(const > boost::unit_test::test_suite&) Above error has nothing to do with BOOST_PARAM_TEST_CASE > I understand the reason for the error but I am not sure about what to do The reason is that test_suite is not default constractible. > . Is there a new technique for using BOOST_PARAM_TEST_CASE to ensure the > parameters are not destroyed until the test case is run? Please provide a simple examples that fails. Genandiy _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

1 0

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