March 2004 - Boost - lists.boost.org

[math constants] a new approach (perhaps)
by Thorsten Ottosen 12 Mar '04

12 Mar '04

Dear boosters, I discovered something that at least was new to me. It's a simple way of coding floating point constants s.t. 1. no overhead at all 2. no order dependencies occur 3. the context in which the constant appears decides the precision of the constants [important in template code] 4. whenever a narrowing or widening conversion is required, explicit action must be taken by the programmer to determine what he wants 5. all precisions of the constants co-exist, so there is no need for several headers Example: #include "math_constant.hpp" #include <iostream> #include <cmath> #include <iomanip> using namespace std; template< typename T > void test(); int main() { cout << setprecision( 10 ); test<float>(); test<double>(); test<long double>(); // cout << pi; // ambiguous cout << float( pi ) << " " << double( pi ) << " " << (long double)( pi ); // ok // int i = pi; // ambiguous int i = float( pi ); // ok cout << sqrt( float( pi ) ); } template< typename T > void test() { T two_pi = T(2) * pi; two_pi = T(pi) + pi; // note: pi operator X() pi is ambiguous T plus = T(1) + pi; T minus = pi - T(1); T divide = pi / T(2); T all = pi + T(3) - T(pi) * pi / T(3); // also ambiguous cout << T( pi ) << " "; } Any comments are more than welcome. I know there are several proposals for defining math constants, but I don't see what the big problems are (so please help me understand them :-) ) br Thorsten

8 35

Re: [boost] Re: Boost 2 - development in long term
by JOAQUIN LOPEZ MU?Z 12 Mar '04

12 Mar '04

----- Mensaje original ----- De: David Abrahams <dave(a)boost-consulting.com> Fecha: Jueves, Marzo 11, 2004 9:19 pm Asunto: [boost] Re: Boost 2 - development in long term > Robert Geiman <rgeiman(a)buckeye-express.com> writes: > > > My point is, there will be a point in time where most compilers > > support template partial specialization, etc, and all that extra > code> that adds support to outdated compilers is way more trouble > than it'll > > be worth. We obviously aren't at that point right now, but at some > > point we will be. > > > > I don't think having Boost 2.x contain NO compiler hacks is a good > > thing, but it would be nice if there was a Boost feature list of all > > C++ features compilers must support to use Boost. These features > > could be added to the list when it's generally accepted that most > > compilers support these features, so then library writers can stop > > writing hacks to support those outdates compilers and even remove > > hacks to make the code smaller, cleaner, and easier to > understand and > > maintain. > Not that I love the idea of Boost 2 (B2 in the following), but maybe there's a reasonably manageable way to automate some of the process of converting Boost libraries into B2 form: * Identify the few compilers/stdlibs qualifying as B2 * Take the set of BOOST_NO_XXX macros in Boost.Config applying to any of the B2 compilers/stdlibs. Let us call these B2 defects. * Create an automatic tool that takes the source code of a B1 library and: - remove all #ifdef BOOST_NO_XXX sections where BOOST_NO_XXX is *not* a B2 defect. - remove all BOOST_WORKAROUND sections where the compiler/stdlib is not B2. This tool hopefully would give a compilable B2 source code, or at least something simple to get correct by manual postprocessing. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

1 0

bind vs. mem_fn with data members
by David Abrahams 11 Mar '04

11 Mar '04

This surprised me; should it have? #include <boost/bind.hpp> #include <boost/mem_fn.hpp> struct X { int y; }; int main() { boost::mem_fn(&X::y); // OK boost::bind(&X::y); // Error! } -- Dave Abrahams Boost Consulting www.boost-consulting.com

2 2

Re: [boost] Re: BOOST_TRY like macros: time to add them?
by JOAQUIN LOPEZ MU?Z 11 Mar '04

11 Mar '04

----- Mensaje original ----- De: Gennaro Prota <gennaro_prota(a)yahoo.com> Fecha: Jueves, Marzo 11, 2004 8:36 pm Asunto: [boost] Re: BOOST_TRY like macros: time to add them? > On Thu, 11 Mar 2004 12:21:09 -0500, David Abrahams > <dave(a)boost-consulting.com> wrote: > > >I think if you review this thread you'll see that there's no > argument. > No argument in favor of the macros? Yes, I see that. [...] Now I'm lost. Are you saying try-catch-rethrow macros for coping with BOOST_NO_EXCEPTIONS along the line proposed by Pavel are not good? Why not? Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

1 0

[indexed_set] volunteers wanted for testing
by Joaquín Mª López Muñoz 11 Mar '04

11 Mar '04

Review for indexed_set will take place in a couple of weeks; I'd like to ask for volunteers who want to try the tests on their compilers/platforms to make sure it works on a reasonable number of them. Current version has been tested for MSVC++ 6.0 SP5, ICC++ 7.1 and GCC 3.3.1 (cygwin). In particular, I'm interested in ICC+ 8.0 and MSVC 7.1, where prior versions of the library were tested without problems. Last version of the library (9.2) available at http://groups.yahoo.com/group/boost/files/indexed_set.zip Thank you in advance. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

6 10

[filesystem] create_directory() & create_directories() return bool
by Beman Dawes 11 Mar '04

11 Mar '04

create_directory() no longer throws if the directory already exists. create_directory() and create_directories() now return a bool indicating if a directory was actually created. Both throw if the path argument exists and is not a directory. Docs and test cases updated accordingly. --Beman

1 0

[Signals] Added disconnect() based on function object equivalence
by Douglas Gregor 11 Mar '04

11 Mar '04

Since we're discussing the issue, I've added an experimental disconnect() member function to signals that allows one to disconnect equivalent slots, e.g., void foo(); void bar(); signal<void()> sig; sig.connect(&foo); sig.connect(&bar); sig.disconnect(&foo); // disconnects foo, but not bar We could also reconsider the += and -= syntax, since support for -= now makes some sense. Doug

2 1

iterator adaptors problem
by Pavol Droba 10 Mar '04

10 Mar '04

Hi, I have a problem with iterator_facade usage. Error is reported by Comeau and MIPSPro compilers: An error output can be found in regression tables: http://tinyurl.com/37mxz The compiler is reporting, that iterator_core_access cannot access the private equal() function, althought it has been marked as friend. My iterator class is publicaly derived from iterator_facade and privately from another templated class. Is it possible, that multiple inheritance creates the problem? Thanks for any help. Pavol

3 6

lambda BLL question
by Neal D. Becker 10 Mar '04

10 Mar '04

I was just trying out lambda and I have a question. I have a template class Ave template<typename in_t, typename Scale> struct Ave {...} It takes a function type argument "Scale". Here's a test: typedef typeof (_1 * 0.1) some_type; some_type func (_1 * 0.1); // Ave<double, typeof (_1 * 0.1)> ave (_1 * 0.1); << this will work Ave<double, some_type> ave (func); << this will also What is the preferred way to do this without "typeof"? How do I get the type returned by the lambda expression to feed to the template Ave?

2 1

[filesystem] create_directories not thread-safe?
by Vladimir Prus 10 Mar '04

10 Mar '04

I have an application which sometimes fails saying that it can't create a directory, because it already exists. The directory is created by fs::create_directories("run"); and the application is multi-threaded. It seems there's a race condition: if (ph.empty() || exists(ph)) return; // First create branch, by calling ourself recursively create_directories(ph.branch_path()); // Now that parent's path exists, create the directory create_directory(ph); After one thread checks that 'ph' does not exist, another one creates the same directory, so call to 'create_directory' fails. What can be done? Basically, adding a mutex for MT build and adding a warning to docs are the variants. Opinions? - Volodya

7 11