- Boost - lists.boost.org

[tr1] Help needed with Darwin port
by John Maddock 14 Jan '09

14 Jan '09

Can someone with access to various flavours of gcc-4.x on Darwin let me know what directory the glibc++ std lib headers are in? Currently Boost.TR1 is using #include <../c++/header_name> which is taken from STLPort's configuration, but is apparently causing regressions in the boost code, Thanks, John.

4 10

[scope_exit] Doesn't included in Boost yet?
by Dmitriy Maksimov 14 Jan '09

14 Jan '09

Hi, I didn't found boost::scope_exit library in Boost 1.37 althougth the library approved in May 2008. Why? Kind regards, Dmitriy

6 15

Re: [boost] [lexical_cast] A suggestion
by Andrew Troschinetz 14 Jan '09

14 Jan '09

Alexander Nasonov <alnsn <at> yandex.ru> writes: > This looks interesting but boost::optional<T> is already > InputStreamable: > #include <boost/optional/optional_io.hpp> This sounded really cool to me so I attempted a cursory hack to get this working. The only way I could figure out how to provide an override for optional<T> that never throws was to change detail::lexical_cast from a function to a struct to get partial template specialization. Maybe there is a better way, I'm new at this. It seems like there must be because I wound up with lots of almost- duplicated code. Here's the old familiar detail::lexical_cast, structified: And here's the optional<T> specialization: Initially this didn't work however. I traced it to what might be a bug in optional_io.hpp's insertion operator: if ( in.good() ) { int d = in.get(); if ( d == ' ' ) /* assuming a space in stream, what if there's not? */ { T x ; in >> x; v = x ; } else v = optional<T>() ; } return in; With the above insertion operator code, this would fail: istringstream si ("test"); optional<string> o; si >> o; assert (o); /* fails, would work if si were constructed with " test" instead */ That seems wrong to my thinking, but maybe there's a reason for the if (d == ' ') test? If the intent was to simply eat up spare white space, how about this instead: if (in) { T x; if (in >> std::ws >> x) v = x; else v = optional<T>(); } return in; Using that code in optional_io.hpp, and with the above changes, things work out just fine: int invalid_as_uint = -1; int valid_as_uint = 5; unsigned default_uint = 6; // Normal form, throws. try { unsigned i = lexical_cast<unsigned> (invalid_as_uint); cout << i << endl; } catch (const bad_lexical_cast&) { cout << "bad lexical cast error" << endl; } // Overload for lexical_cast<optional<T>>, does not throw. optional<unsigned> i = lexical_cast<optional<unsigned> > (invalid_as_uint); if (i) cout << *i << endl; else cout << "invalid return value" << endl; i = lexical_cast<optional<unsigned> > (valid_as_uint); if (i) cout << *i << endl; else cout << "invalid return value" << endl; Also, I would love to see a fallback style lexical_cast for the same reasons Neil already mentioned. -- Andrew Troschinetz

1 0

MSVC9 SFINAE quirks?
by Simonson, Lucanus J 14 Jan '09

14 Jan '09

Is there some gotcha about metaprogramming with MSVC9? I recently finished my geometry library rewrite and found that I couldn't port it to windows because the SFINAE overloading of generic functions is viewed as ambiguous in the more complex cases, but was readily accepted by gcc and icc in linux. The following code compiles in recent versions of gcc, but fails in MSVC9 //simple SFINAE overload of foo works in both template <typename T> typename gtl_if<typename is_mutable_polygon_90_type<T>::type>::type foo(const T& t) { return gtl_yes(); } template <typename T> typename gtl_if<typename is_mutable_polygon_45_type<T>::type>::type foo(const T& t) { return gtl_yes(); } //metafunction wrapper around SFINAE to supply return type works in both template <typename T> typename requires_1<typename gtl_if<typename is_mutable_polygon_90_type<T>::type>::type, void>::type foo2(const T& t) { } template <typename T> typename requires_1<typename gtl_if<typename is_mutable_polygon_45_type<T>::type>::type, void>::type foo2(const T& t) { } //meta function wrapper around two checks works in gcc but not msvc9 // error C2668: 'gtl::foo4' : ambiguous call to overloaded function template <typename polygon_type, typename polygon_type_2> typename requires_1< typename gtl_if< typename gtl_and< typename is_mutable_polygon_90_type<polygon_type>::type, typename is_mutable_polygon_90_type<polygon_type_2>::type >::type>::type, polygon_type>::type foo4(polygon_type& polygon, const polygon_type_2& point) {return point;} template <typename polygon_type, typename polygon_type_2> typename requires_1< typename gtl_if< typename gtl_and< typename is_mutable_polygon_45_type<polygon_type>::type, typename is_mutable_polygon_45_type<polygon_type_2>::type >::type>::type, polygon_type>::type foo4(polygon_type& polygon, const polygon_type_2& point) {return point;} int main() { using namespace gtl; polygon_45_data<int> p45; foo(p45); foo2(p45); foo4(p45, p45); //error here //this works as expected and has no syntax error in msvc9 gtl_if<gtl_and< is_mutable_polygon_45_type<polygon_45_data<int> >::type, is_mutable_polygon_45_type<polygon_45_data<int> >::type >::type>::type a; //this works as expected, generating syntax error in msvc9 // error C2039: 'type' : is not a member of 'gtl::gtl_if<gtl::gtl_no> gtl_if<gtl_and< is_mutable_polygon_90_type<polygon_45_data<int> >::type, is_mutable_polygon_90_type<polygon_45_data<int> >::type >::type>::type b; Does someone like Steve Wanatabe with more experience with MS compilers know what I have inadvertently run afoul of and how to get myself out of this jam? Thanks, Luke

2 11

[mp_int] Incorrect comparison with native types
by Nathan Kitchen 13 Jan '09

13 Jan '09

When I create an negative mp_int outside the range of a native type and compare it to a number of that type, I get incorrect results. Here is an example to reproduce the behavior: #include <iostream> #include <limits> #include <boost/cstdint.hpp> #include <boost/mp_math/mp_int.hpp> using namespace boost::mp_math; using namespace std; int main() { int32_t MIN = numeric_limits<int32_t>::min(); mp_int<> a = MIN; cout << a << endl; a -= 1; // Should print "-2147483649 1" but prints "-2147483649 0" instead cout << a << ' ' << (a < MIN) << endl; return 0; }

2 7

1.38 release schedule
by John Maddock 13 Jan '09

13 Jan '09

Since there haven't been any announcements, do I correctly assume that the 1.38 schedule is likely to slip by a couple of weeks? Cheers, John.

2 1

Pondering Futures
by Tom Brinkman 13 Jan '09

13 Jan '09

Ponderings on the Futures Library: What is the status of Anthony Williams' submission of the futures library to the c++ standards committee? Is it more prudent to wait to find out what the c++ standards committe is going to do first, before adding a possibly incompatible version of the futures library to boost? One could ask, if Anthony's submission is approved by the c++ standards committe, what is the point of adding a "futures" library to boost as well? Is a seperate library needed? What is the advantage of having a root level library called boost::futures? Why would it not be perferable to just extend boost::thread with the additional capabiltity to handle "futures"? Futures are a very useful concept, and I have used them personally. The c++ commitee is correctly considering adding them to the standard. I would be interested in hearing the authors views on their "grand" vision for parallel programming in general and how their "futures" library submissions fit into this vision. tom brinkman

8 12

[fusion] mpl::is_sequence<fusion::vector<> >::type::value should work right?
by Dean Michael Berris 13 Jan '09

13 Jan '09

Hi Guys, I've tried the following minimal test with the latest in trunk and I get an error with GCC 4.2. #include <boost/fusion/container/vector.hpp> #include <boost/static_assert.hpp> int main(int argc, char *argv[]) { BOOST_STATIC_ASSERT((boost::mpl::is_sequence<boost::fusion::vector<> >::type::value)); return EXIT_SUCCESS; } The error is pasted below: /home/dean/boost_trunk/boost/mpl/begin_end.hpp: In instantiation of 'boost::mpl::begin<boost::fusion::vector<boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_> >': /home/dean/boost_trunk/boost/mpl/is_sequence.hpp:95: instantiated from 'boost::mpl::is_sequence<boost::fusion::vector<boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_> >' fusion_is_sequence_test.cpp:5: instantiated from here /home/dean/boost_trunk/boost/mpl/begin_end.hpp:35: error: invalid use of incomplete type 'struct boost::mpl::begin_impl<boost::fusion::fusion_sequence_tag>' /home/dean/boost_trunk/boost/mpl/begin_end_fwd.hpp:19: error: declaration of 'struct boost::mpl::begin_impl<boost::fusion::fusion_sequence_tag>' fusion_is_sequence_test.cpp: In function 'int main(int, char**)': fusion_is_sequence_test.cpp:5: error: 'type' is not a member of 'boost::mpl::is_sequence<boost::fusion::vector<boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_> >' fusion_is_sequence_test.cpp:5: error: template argument 1 is invalid fusion_is_sequence_test.cpp:5: error: template argument 1 is invalid Is this a bug? HTH -- Dean Michael C. Berris Software Engineer, Friendster, Inc.

2 2

[Signals] Early exit on call
by Kisso Bajslovski 12 Jan '09

12 Jan '09

Hi, I wonder if there's any way to end a call early. For example, if we have 4 connections to a signal, and when the first 2nd is called it wants to abort and avoid the calls to the last 2 connections.

3 2

[PhD] todo: use sum() consistently all places ... make it easy to switch to kahanSum() or to optomize
by Thorsten Ottosen 12 Jan '09

12 Jan '09

-Thorsten

1 1