January 2011 - Boost - lists.preview.boost.org

compiling Boost boost_1_45_0 regex with icu (redhat).
by Candid Shot 05 Jan '11

05 Jan '11

Greetings. I am trying to compile boost regex with icu. The icu library is placed in a non-standard place, so I have set the appropriate environment variable. However everytime I run bjam, console output (amongst many thing) says - has_icu builds : no I have invoked bjam with -sBOOST_HAS_ICU=1. No luck picking icu. I have invoked bjam with -sICU_PATH=/home/xxx/yyy, and no luck either. OTOH, if I go to the subdirectory : libs/regex/build and do 'make -f gcc.mak' It builds with -DBOOST_HAVE_ICU=1 and with the right icu include directory in the compile line. I am new to compiling boost, and would love to find out what is going on. And how can I rectify it. Thanks, CD.

3 6

[ratio] Test failing on trunk
by vicente.botet 04 Jan '11

04 Jan '11

Hi, Boost.ratio is failing with compiler option -pedantic Test output: Sandia-darwin-4.0.1 - ratio - ratio_pass / darwin-4.0.1 Rev 67644 / Tue, 4 Jan 2011 01:50:26 +0000 ... ../libs/ratio/test/ratio_ratio/ratio_pass.cpp:24: error: ISO C++ does not support 'long long' Do you know a compiler macro that states if the -pedantic option is set. Otherwise I see two options: A- Don't test Boost.ratio with this option and add to the documentation the limitation. B Add a explicit macro BOOST_DONT_USE_LONG_LONG The definition of boost::intmax_t should relay on another type in this case. I think the best is option A, as Boost.Ratio could not respect the requirements if the type is not long long. What other think? Best, _____________________ Vicente Juan Botet Escribá http://viboes.blogspot.com/

5 7

[Range] begin/end ADL issues in C++0x range-based for
by Michel MORIN 04 Jan '11

04 Jan '11

[Range] begin/end ADL issues in C++0x range-based for Hi, I recently played around with C++0x range-based for (available on GCC 4.6 Pre-Release). It turned out that some codes using Boost libraries do not compile. Compiler errors (ambiguous calls to begin/end) are generated, when ADL finds both std::begin/end and boost::begin/end in range-based for and there is no single best match. Remarkably, boost::iterator_range (and adapted ranges in Boost.Range) cannot be used in range-based for. First let us recall range-based for. A range-based for for (auto x : range_expr) { // do something } is equivalent to { // Special rule: namespace std is added to rng's associated namespaces auto&& rng = range_expr; for ( auto it = begin(rng), it_end = end(rng); it != it_end; ++it ) { auto x = *it; // do something } } Note that rng has namespace std as its associated namespaces and the unqualified begin/end function call triggers ADL. In C++0x, there are std::begin functions (for simplicity, let's ignore end): template <typename Range> auto begin(Range& r) -> decltype(r.begin()); template <typename Range> auto begin(Range const& r) -> decltype(r.begin()); And Boost.Range has boost::begin functions: template <typename Range> inline typename boost::range_iterator<Range >::type begin(Range& r); template <typename Range> inline typename boost::range_iterator<Range const>::type begin(Range const& r); So, if - rng has namespace boost as its associated namespaces, - the header file boost/range/begin.hpp is included, and - there is no single best match between std::begin and boost::begin, then unqualified begin function call becomes ambiguous. For example, all the following codes fail to be compiled: // code 1 #include <boost/range/iterator_range.hpp> for (auto x : boost::iterator_range<int*>(nullptr, nullptr)) {} // error // code 2 #include <boost/ptr_container/ptr_vector.hpp> for (auto x : boost::ptr_vector<int>()) {} // error // code 3 #include <vector> #include <boost/range/adaptor/reversed.hpp> for (auto x : std::vector<int>() | boost::adaptors::reversed) {} // error // code 4 #include <boost/algorithm/string.hpp> #include <boost/array.hpp> for (auto x : boost::array<int, 2>()) {} // error // code 5 #include <vector> #include <boost/shared_ptr.hpp> #include <boost/range/algorithm.hpp> for (auto x : std::vector<boost::shared_ptr<int> >()) {} // error These errors can be resolved by fixing boost/range/begin.hpp. The fix uses a using-declaration ("using std::begin;") and SFINAE (disable_if with "has_begin" metafunction). A summary of range-based-for-compatible <boost/range/begin.hpp> is the following: #ifndef BOOST_NO_RANGE_BASED_FOR namespace boost { using std::begin; // has_begin metafunction... template <typename Range> inline typename boost::range_iterator<Range>::type begin(Range& rng, typename disable_if<range_detail::has_begin<Range>>::type* = 0) { return range_begin(rng); } // const version ... } #else // existing code... For details, see the attached. I also attach a patch for Boost.Config to add BOOST_NO_RANGE_BASED_FOR. Any comments or thoughs? Regards, Michel

4 7

Fwd: Boost Digest, Vol 3137, Issue 2
by Brent Spillner 04 Jan '11

04 Jan '11

> On 24/12/2010 18:14, Thomas Heller wrote: (My apologies for the delay in responding; I've been travelling for the holidays and had irregular access to email.) >I think this comprehension syntax would be a wonderful addition to phoenix. >In fact i was thinking of adding it to phoenix V3 myself. >By basing your work on phoenix v3 you would introduce a kind of big >dependency, true. However, that dependency is imho not a bad thing, it would >provide you with a powerful basis for your work. The only thing that needed >to be done is to code the logic for the list comprehension... everything >else is already done for you. I managed to make a little time to acquaint myself with Phoenix (v2) and discovered that it wasn't that hard to add Phoenix support to the comprehension library-- a couple of traits specializations to derive the return types, a special case to treat void values as 'true' for the purpose of continuing the comprehension (applies in all cases, not just when using Phoenix expressions), and a mechanism to limit ambiguous operator overloads. I just uploaded a new version of the comprehension library (0.02) to the Vault that includes all of the above, along with the ability to nest comprehensions, support for increment/decrement and assignment operators, general code cleanup, a couple of compiler workarounds, reorganized example programs, and most importantly some preliminary documentation in the README file. As always, I'd appreciate reports of any compilation environments or use cases that cause problems. As far as integrating the comprehension syntax directly into Phoenix goes, it certainly looks feasible but I wonder how much there really is to be gained. Since Phoenix already overloads the <<= (and every other) operator, you'd either have to introduce a wordier sequential-assignment syntax or a special sequentially-assignable type, in which case the comprehension engine might as well be a separate component. One thing that would be handy in v3, though, would be control flow operators that return a value type (e.g. the value of the last expression in the statement list) rather than void. Right now if you need a comprehension to depend on some value computed within the body of a complex Phoenix statement, you have to assign that value to a temporary variable and reference the variable later in the comprehension. I think that this capability would be more generally useful outside the comprehension context, and it would mirror the semantics of many functional languages. I'm still not familiar enough with the Phoenix internals to recognize whether there's some other constraint that makes this impractical. On a more technical note, does anyone know of a safe compile-time way to detect whether the -std=c++0x (or /Qstd=c++0x) command-line option has been passed to the Intel C++ compiler? http://stackoverflow.com/questions/3744023/detecting-c0x-mode-on-intel-c suggests that the the constant __GXX_EXPERIMENTAL_CXX0X__ will be defined (as it is in g++), but that doesn't seem to be true, at least in version 12 under Linux. boost/config/compiler/intel.hpp doesn't seem to have any tricks for this either, which is unfortunate because it never enables BOOST_HAS_DECLTYPE, and the compiler chokes on parts of Boost.Typeof when -std=c++0x is /not/ defined (i.e. when you actually need it most.) Brent

1 0

[smart_ptr] enable_shared_from_this and multiple inheritance solution
by Philippe Cayouette 03 Jan '11

03 Jan '11

Fellow boosters, A little while ago I found a pernicious problem with enable_shared_from_this when used with multiple inheritance. Here is an example: #include <boost/smart_ptr.hpp> #include <boost/enable_shared_from_this.hpp> class Base1 : public boost::enable_shared_from_this< Base1 > { public: Base1() {} virtual ~Base1() {} boost::shared_ptr< Base1 > GetBase1() { return shared_from_this(); } }; class Base2 : public boost::enable_shared_from_this< Base2 > { public: Base2() {} virtual ~Base2() {} boost::shared_ptr< Base2 > GetBase2() { return shared_from_this(); } }; class Derived : public Base1, public Base2 { }; int main() { boost::shared_ptr< Derived > wDerived(new Derived()); // Either of the following lines crashes with GCC, but the first one // passes on VS2005 boost::shared_ptr< Base1 > wBase1 = wDerived->GetBase1(); boost::shared_ptr< Base2 > wBase2 = wDerived->GetBase2(); return 0; } Since Derived inherits from two bases that each inherits from enable_shared_from_this, it has two internal weak_ptr. These weak_ptr are usualy initialised in the constructor of the shared_ptr and I have observed two different behavior with the above code depending if I build it with VS2005 or GCC. With VS2005, the first base class in the inheritance list of Derived (here Base1) get its internal weak_ptr initialized, but not the second one, thus it crashes when we try to access the Base2 weak_ptr via shared_from_this. On GCC, neither base classes get their internal weak_ptr initialized and both base classes access to their internal weak_ptr provokes a crash. To prevent that kind of problem, I created a SmartPtrBuilder and a (very) slightly modified EnabledSharedFromThis (only one assert was removed). Here is the same program with the modifications: #include <boost/smart_ptr.hpp> #include "EnableSharedFromThis.h" #include "SmartPtrBuilder.h" class Base1 : public Generic::EnableSharedFromThis< Base1 > { public: Base1() {} virtual ~Base1() {} boost::shared_ptr< Base1 > GetBase1() { return SharedFromThis(); } }; class Base2 : public Generic::EnableSharedFromThis< Base2 > { public: Base2() {} virtual ~Base2() {} boost::shared_ptr< Base2 > GetBase2() { return SharedFromThis(); } }; class Derived : public Base1, public Base2 { public: // Factory method static boost::shared_ptr< Derived > Create() { return Generic::SmartPtrBuilder::CreateSharedPtr< Base1, Base2 >(new Derived()); } private: Derived() {} }; int main() { boost::shared_ptr< Derived > wDerived = Derived::Create(); // No more crashes boost::shared_ptr< Base1 > wBase1 = wDerived->GetBase1(); boost::shared_ptr< Base2 > wBase2 = wDerived->GetBase2(); return 0; } As you can see, Derived has now a factory method that uses the SmartPtrBuilder to create the shared_ptr. Two template arguments are used on CreateSharedPtr, allowing it to initialize the internal weak_ptr of each base classes. The SmartPtrBuilder I did can support up to 10 base classes as template arguments and I also did a variadic template version which has no limit. By using the factory method, the users of Derived don't need to know which of its base classes need its internal weak_ptr need to be initialized. Source code for the SmartPtrBuilder and the modified EnableSharedFromThis: http://spoluck.ca:8000/boost/EnableSharedFromThis.h http://spoluck.ca:8000/boost/SmartPtrBuilder.h That builder might be incorporated to the boost smart pointer library so that anyone could use its facilities to prevent the problem mentioned earlier. No modification to the mighty shared_ptr class required, only the addition of a builder. What do you think? Philippe

3 7

[units] inconvent printing of composite scaled units
by Matthias Schabel 03 Jan '11

03 Jan '11

> great, it works, using the CGS example, if I define: > > namespace boost{namespace unit{ > namespace si{ > typedef scaled_base_unit<boost::units::si::second_base_unit, > scale<10, static_rational<-15> > > femtosecond_base_unit; > typedef femtosecond_base_unit::unit_type femtosecond_unit; > static const femtosecond_unit femtosecond, femtoseconds; > } > }} > > then > > cout << 3.*si::meter/si::femtosecond << endl; // prints 3 m fs^-1 > > while > > cout << 3.*si::meter/(si::femto*si::second) << endl; //print 3 P(m > s^-1), notice the ugly P (for Peta) > > this gives better control on the intended output (at least). > > (Unfortunately this operation doesn't work 3.*si::femtosecond + > 2.*(si::femto*si::second) ) I'm guessing that this is an issue of mixing scaled and unscaled quantities... It should probably work, though, since si::femto*si::second should really return the scaled unit you define manually above. I'll look into it, though it may be a while. Matthias

1 0

[GCC 4.6] Problems catching exceptions
by Beman Dawes 03 Jan '11

03 Jan '11

Although GCC 4.6 isn't released yet, I've been getting good results on a non-Boost project with the weekly MinGW build. See http://www.equation.com/servlet/equation.cmd?call=fortran for the prebuilt MinGW binaries. When I try to run the Boost Filesystem V3 regression tests against this build, however, all the tests fail that involve catching an exception. These tests pass for numerous other compilers, and for other versions of GCC. Since 4.6 is getting close to release, I'd like to see the problem fixed. But I don't have enough knowledge of GCC and MinGW to know where the problem is, or whether this is already a reported bug. Is there anyone out there who knows enough about GCC and MinGW to tell if this bug is already known? --Beman

5 8

[inspect] Tag a directory to be ignored?
by Beman Dawes 03 Jan '11

03 Jan '11

The Boost inspection tool that generates the inspection reports has a hardwired list of directories not to recurse into. "CVS", ".svn", ".git", etc. While those particular cases make sense, some of the hardwired names are so specialized ("doc/xml", "tools/build/v2/engine", etc.) that a better approach might be to tag directories as not to be inspected. That way the inspect.cpp code wouldn't have to be changed to accommodate yet another directory to be avoided. One simple way to do this would be for inspect.cpp to ignore any directories with some special file. For example, "no_boost_inspect". Comments? --Beman

3 5

[SoC] BGL project idea
by Gautam Sewani 03 Jan '11

03 Jan '11

Hi, I am a Computer Science student hoping to contribute to Boost for this year's summer of code. I had a few questions regarding the BGL project idea (https://svn.boost.org/trac/boost/wiki/SoC2010#Boost.Graph) for SOC 2010. 1. I can think of only a few places where the suggested algorithms will be used. Does the community think that these algorithms are used frequently enough to put them in a library? How important does the community consider this project? 2. Will the project proposal be expected to include the API design? Thanks and Regards Gautam

5 29

[BGL] Get properties from an out_edge_iterator efficiently
by Shaun Jackman 03 Jan '11

03 Jan '11

Hi, I have a graph implementation where get(tag, graph, out_edge_iterator) is much more efficient than get(tag, graph, edge_descriptor) which is probably not an usual case. Would it make sense for BGL to provide a default implementation of the former that dereferences the iterator and calls the latter? Graphs for which the former is more efficient could then specialize this function template. Cheers, Shaun

2 3