April 2007 - Boost - lists.preview.boost.org

[math toolkit]
by Leopoldo Peralta 02 Jul '07

02 Jul '07

This Fatal Error occurs when trying to compile a MSVC 2003 (SP1) project using the proposed Math Toolkit: C:\boost_1_34_0_beta\boost_1_34_0\boost\math\special_functions\log1p.hpp(195 ): error C2785: 'tools::promote_args<T>::type boost::math::log1p(T)' and 'double boost::math::log1p(double)' have different return types Any fix to this error? Leopoldo Peralta

2 8

proto::tag naming convention
by Maurizio Vitale 22 Jun '07

22 Jun '07

What is the rationale for not having proto::tags match the corresponding mpl metafunctions? For instance mpl has plus and proto has add (but unary_plus). Since people will often mix the two, it would be nice to have the same name. (I basically have to look them up everytime I use one of them) If the intention was to make them different so that they can be mixed without namespace qualification I think they're not different enough. Given divide and divides, which is proto's and which is mpl's? Clearly one gets used to these things, but maybe it is something to consider before finalizing proto for inclusion in boost. regards Maurizio

7 25

[soc 07] SoC 2007 Projects
by Jeff Garland 04 Jun '07

04 Jun '07

Hi All - I'm happy to announce that Boost will be mentoring 9 Google SoC projects this year. They are: Title Student Mentor ----------------------------------------------------------------------------- User-friendly graphs and their measures Andrew Sutton Jeremy Siek FastCGi and SCGI-compatible CGI library Darren Garvey Christopher M Kohlhoff Boost 'Big Integer' proposal Arseny Kapoulkine Jeff Garland Signal Network library Stjepan Rajko Douglas Gregor Evolutionary Computation Library Aaron Garrett Jaakko Järvi Application to extend Boost regex with recursive matching, named sub-expressions, and automata-based matching Hugh Wimberly John Maddock Visualization Of Arrays And STL Containers Jacob R>Voytko Joaquín L. Muñoz Boost.Extension and Reflection Mariano G. Consoni Hartmut Kaiser A Generic Geometric Library Huseyin Akcan Herve Bronnimann You can find the abstracts of these projects online here: http://code.google.com/soc/boost/about.html As with last year, there were many worthy students and projects that ultimately were not selected. So, for all the students that were not selected realize that the competition for a very few slots was immense. My main advice for students that might want to try again next year is to start participating now -- it really helps to hang out on the list, submit patches, and work on ideas well in advance of SoC. I'd like to thank the mentoring team that evaluated the ~220 applications we received this year. It takes a huge effort to go thru these, read, rank, clarify and give feedback. Note that in addition to the mentors above Andreas Huber, Rene Rivera, and Daniel Wallin all helped with evaluations. For those coming to BoostCon I'll be giving a presentation on Friday about Boost and SoC: http://www.boostcon.com/program/sessions#garland-summer-of-code And, if you aren't coming to BoostCon, well, you should ;-) http://www.boostcon.com/registration Jeff

5 5

Some follow-up on my fixed point code, and safe integers
by Phil Endecott 17 May '07

17 May '07

Dear All, Last week I posted some fixed-point arithmetic code for potential boostification. Thanks for all your comments. The most common suggestion was that it ought to offer overflow detection, so I have just thrown together some proof-of-concept code to do this. I have added a third template parameter to the fixed<> class which allows you to specify an integer implementation type; it defaults to boost::int_t<>::least as before giving you no checking an no overhead. If you want to check for overflow you need to supply a checking integer type, and I've implemented a simple safe_int<N> class that can be used for this: http://svn.chezphil.org/libpbe/trunk/include/safe_int.hh This is just a proof of concept with some obvious holes, but I think it shows what's possible. It should also be usable on its own in integer applications. The other main issues that were raised were: - The alternative approach of using proto to provide something more sophisticated. I would be very interested to see what can be achieved by this approach (and at what cost) compared to my simplistic version. - The need for <cmath>-like functions. This is rather beyond my ability. - What implicit and/or explicit conversions should be included? - My concerns about how to do, for example, a 32x32->64-bit multiply efficiently without actually doing a 64x64->64-bit multiply. I look forward to hearing your comments. I'm keen to maintain momentum; if people think that something not too different in scope from what I am currently proposing would be acceptable then I will start thinking about the other things that are needed (docs, tests etc). The fixed<> class itself can be found at: http://svn.chezphil.org/libpbe/trunk/include/fixed.hh Regards, Phil.

8 17

Boost Logging library - first draft
by JD 16 May '07

16 May '07

Hello, So here is the question: "Is there any interest in a logging library for boost?" John Torjo did not answer my mail, beside I looked at pantheios. it seems a little bit complex... My idea is that a logging library should be _simple_ to use. Here is a small example: // snippet on #include <fstream> #include <boost/logging.hpp> int main(int argc, char **argv) { BOOST_LOG_INIT(("[" >> boost::logging::level >> "]," >> boost::logging::filename >> "(" >> boost::logging::line >> ")," >> boost::logging::time >> "," >> boost::logging::trace >> boost::logging::eol), // log format 2); // log level BOOST_LOG_ADD_OUTPUT_STREAM(new std::ofstream("./output.log")); BOOST_LOG_ADD_OUTPUT_STREAM(&std::cout); BOOST_LOG(1, "something"); BOOST_LOG(2, "something else"); BOOST_LOG(3, "doesn't matter"); char you_want[256] = "you want"; BOOST_LOG(1, "Let's say " << you_want << " to display " << 2); return 0; } // snippet off You can find the first draft of a logging library in the boost Sandbox vault. It consists of a header files, some examples and documentation. Put the file at your boost root folder and unzip it. It compiles with msvc and vc-8_0. I'll try with gcc asap. So let me know if you think it worth something or not. JD

15 34

[mpl] arithmetic feature request
by Matthias Schabel 12 May '07

12 May '07

It would be nice if we could represent all compile-time algebraic operations in Boost.Units using MPL arithmetic. At present, MPL supports negate, adds, subtracts, times, divides. Boost.Units additionally would require : 1) unary_plus - the compile-time equivalent of operator+(T) 2) unary_minus - the compile-time equivalent of operator-(T); this is identical to current mpl::negate, but it would be nice to have it for notational consistency with unary_plus 3) power<T,U> (or pow<T,U>) - the compile-time equivalent of pow(T,U) 4) root<T,U> - the compile-time equivalent of pow(T,1/U); can be implemented with power<T,U>, but this is a nicer syntax to eliminate its remaining compile-time algebra operators. Any thoughts on whether this would be a worthwhile addition to MPL? Matthias

4 6

[bind][tr1] patch for more compliant placeholders
by Daniel Walker 10 May '07

10 May '07

Hello, TR1 section 3.6.4 says that placeholders should be default and copy constructible. However, on gcc and borland boost::bind placeholders are not copy constructible. I tried the following C++0x test. #include <boost/tr1/functional.hpp> #include <boost/concept_check.hpp> int main() { boost::function_requires< boost::DefaultConstructible< typeof(std::tr1::placeholders::_1) > >(); boost::function_requires< boost::CopyConstructible< typeof(std::tr1::placeholders::_1) > >(); } This works on gcc 4.1 with GNU's TR1 implementation, but when using Boost.TR1 the second concept check fails to compile. On gcc and borland the placeholders are defined as inline functions. On all other compilers they are objects with internal linkage. From reading the cvs logs for placeholders.hpp, inline function placeholders are useful in order to avoid having data in headers. (Also, apparently gcc may require placeholders to be inline functions to workaround limitations in precompiled headers.) TR1 gets around the data-in-headers issue by specifying that the placeholder declarations in <functional> are extern. So, should Boost.Bind deviate from TR1 bind in terms of the linkage of placeholders or in terms of the set of valid, TR1-compliant programs it can support based on concept requirements? I don't like the idea of requiring Boost.Bind users to link to a library, so neither of these options are particularly attractive. As a compromise, why not allow the user to choose whether placeholders are internal objects or inline functions depending on their needs? The attached patch does this by introducing a macro BOOST_BIND_ENABLE_INLINE_PLACEHOLDERS. When it is defined placeholders are not objects with internal linkage, and their types do not meet the TR1 concept requirements; i.e. they're inline functions. When the macro is not defined placeholders are objects with internal linkage, and their types are both default and copy constructible. The macro is undefined by default. If a user needs inline placeholders for precompiled headers or whatever reason, they can make the trade off and define the macro. The patch also includes user documentation. The patch allows the code above to compile on gcc 4.1 with Boost.TR1, and there are no errors detected when I run the bind test suite under gcc 3.3/4.1 or msvc 7.1/8.0 with and without inline placeholders enabled. Apply with 'patch -p0 < djw_bind_placeholders.patch' from the boost root directory. I hope this is acceptable. Let me know if I'm over looking something. Thanks, Daniel Walker

5 44

GCC C++0x regression testing online
by Doug Gregor 08 May '07

08 May '07

Hello fellow Boosters, GCC 4.3 will have an experimental C++0x mode containing several of the new features coming into the language. I have started nightly regression testing of Boost CVS HEAD on the current version of GCC 4.3 using this experimental mode. The "OSL5" tester will run nightly, and allow us to try out these new features within Boost. Of course, please use the new BOOST_HAS_* feature macros (described in the config library documentation for CVS HEAD) to test for specific features when using them in your Boost library. The compiler running these tests supports the following C++0x features: - Rvalue references - Right angle brackets - Default template arguments for function templates - Delegating constructors - decltype - Static assertions - C99 preprocessor - Variadic templates The version of GCC used in this tester is a patched version of the FSF GCC from their mainline (4.3) compiler, which I update periodically. For more information about the specific patches I have applied, see the OSL5 summary in the regression tests. For more information about the experimental C++0x mode in the upcoming GCC 4.3, see http://gcc.gnu.org/gcc-4.3/changes.html. Have fun! Cheers, Doug

5 17

[1.34.0] make check fails on Linux
by Thomas Witt 07 May '07

07 May '07

Begin forwarded message: > From: "Tarjei Knapstad" <tarjei.knapstad(a)gmail.com> > Date: April 26, 2007 8:16:14 AM PDT > To: "Thomas Witt" <witt(a)acm.org> > Subject: Re: [boost] [1.34.0] Volunteers needed to check tarballs > > On 4/26/07, Thomas Witt <witt(a)acm.org> wrote: >> >> On Apr 26, 2007, at 6:55 AM, Tarjei Knapstad wrote: >> >> > >> > Thanks, I've downloaded and started a build. Will check that it >> > builds, that the tests work, examples work, docs are OK and >> anything >> > else I can think of and get back to you as soon as possible. (I'm >> > doing this on a Core 2 Duo laptop running CentOS 4.4 btw). >> > >> > > My experiences so far... :) > <snip/> > > ==== Unit tests ==== > > 'make check' fails: > > user-config.jam: No such file or directory > warning: No toolsets are configured. > warning: Configuring default toolset "gcc". > warning: If the default is wrong, you may not be able to build C++ > programs. > 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: could not find main target test > notice: assuming it's a name of file to create > don't know how to make <e>test > ...found 1 target... > ...can't find 1 target... > > If I manually copy boost_1_34_0/user-config.jam to the status/ > directory it can find the toolset and the warnings disappear, but it > still doesn't find any targets. > > Am I supposed to build and run the tests some other way? (I couldn't > find any docs) > > <snip/> > > Except for not being able to run the unit tests it looks good to me. > > Regards, > -- > Tarjei -- Thomas Witt witt(a)acm.org

2 1

[1.34.0] Deadline
by Thomas Witt 07 May '07

07 May '07

Hi, I will not accept any changes to 1.34.0 whatsoever starting Thursday May 3. Please make sure you report all problems/fixes/doc changes till then. Only real show stoppers (i.e. build might start thermonuclear war) will be considered after that date. That notwithstanding please DO NOT SUBMIT to RC_1_34_0 without prior approval. Thanks Thomas

18 69