- Boost - lists.boost.org

Any Tutorial?
by mistus 20 Aug '04

20 Aug '04

Do you know where to find a good tutorial on how to implement an STL-like container?

1 0

Metacom toolsets broken?
by John Maddock 20 Aug '04

20 Aug '04

The Metacom toolsets that use STLport in the current regression test results appear not to be finding the STLport binaries, which is basically causing these toolsets to fail all the tests :-( Any ideas? John.

2 1

Missing copyright in Format library
by John Maddock 20 Aug '04

20 Aug '04

The following file have no copyright, can the owner please fix? libs/format/example/sample_userType.cpp boost/format/detail/unset_macros.hpp Many thanks, John Maddock

2 2

[MPL] BOOST_MPL_METAFUNCTION_MAX_ARITY in template_arity
by Daniel Wallin 20 Aug '04

20 Aug '04

I think there's a mismatch in the use of BOOST_MPL_METAFUNCTION_MAX_ARITY. mpl::bind<> and aux::template_arity<> both make use of the BOOST_MPL_METAFUNCTION_MAX_ARITY when generating code. However, bind<> has an additional leading argument which increases it's arity by one. This means template_arity<> will return the wrong arity. This demonstrates the bug: #include <boost/mpl/bind.hpp> #include <boost/mpl/lambda.hpp> using namespace boost::mpl; template<int N, class T> void f() { T x[-1]; } int main() { f< aux::template_arity<bind<int> >::value , bind<int> >(); } With gcc3.3 this results in: arity.cpp: In function `void f() [with int N = 5, T = boost::mpl::bind< int , boost::mpl::void_ , boost::mpl::void_ , boost::mpl::void_ , boost::mpl::void_ , boost::mpl::void_ > ]': Where N should actually be 6. -- Daniel Wallin

2 1

irritation in ublas/lu.hpp
by troy d. straszheim 20 Aug '04

20 Aug '04

Real quick: numeric/ublas/lu.hpp will not compile on its own, it requires at least operation.hpp for the symbol axpy_prod<>. In the absence of examples, one of my users included matrix.hpp , vector.hpp, and lu.hpp intending to do some lu-decompositions, and was stymied when the headers wouldn't compile. As lu.hpp is not included from anywhere else, it appears that it is *not* a header that is designed not to be used directly... I asked on #boost, can't come up with an explanation, therefore submit as bug^-2 -t

2 1

vc7 lib name mangling broken
by John Maddock 20 Aug '04

20 Aug '04

Rene, The vc7 toolset is currently appending the suffix "vc" rather than "vc7" to lib names, which is breaking the auto-link code, do you have any idea what may have broken this? Thanks! John.

1 0

31 character limit for filenames
by Doug Gregor 20 Aug '04

20 Aug '04

Okay, it's time to ask again: do we still need to enforce the 31-character limit on filenames? AFAIK, we have this for MacOS 9, only. Is that platform still significant for Boost users? Doug

8 11

[mpl] Iterator categories for sequence views
by Daniel James 20 Aug '04

20 Aug '04

I'm not sure about this, but I think the iterator categories for joint_view, transform_view and filter_view are wrong. At the moment they are set to the category of their base iterator, but I think that they should be set to forward_iterator_tag (or maybe input_iterator_tag?) because they don't implement prior, advance or distance. I think this is the reason that the attached file fails to compile. Of course, this might not be the case in the new version? Daniel

2 1

Links to regression tests are broken
by Jeff Garland 20 Aug '04

20 Aug '04

Go to http://www.boost.org/regression-logs/ The developer and and user reports links are broken. I assume these now need to point to meta-comm? Jeff

2 1

shared_ptr feature request: void_pointer_cast
by Joe Gottman 20 Aug '04

20 Aug '04

I know this isn't the best time to request a new feature, but I just had an idea for an extremely useful new function for shared_ptr. It is common to use a shared_ptr<void> in places where a void * would otherwise be used. While a void * can point to anything, there is no safe way to determine at run-time what type it originally pointed to. Casting it to the wrong type can result in undefined behavior. Although there's no way to avoid this problem with a plain void *, except by passing type information along with it, it should be possible to improve on this situation for shared_ptr<void>, using the template function void_pointer_cast. template<class X> shared_ptr<X> void_pointer_cast(shared_ptr<void> pv); (and similarly for shared_ptr<const void>, shared_ptr<volatile void> and shared_ptr<const volatile void>) void_pointer_cast should have the following semantics: if (pv.get() && pv owns an object of type X) { return shared_pointer_cast<X>(pv); } else { return shared_ptr<X>(); } This would allow code like the following shared_ptr<void> pv = getNextObject(); if (shared_ptr<int> pInt = void_pointer_cast<int>(pv)) { // Do something with pInt; } else if (shared_ptr<string> pString = void_pointer_cast<string>(pv)) { // Do something with pString; } Note that while this code is very similar to code using dynamic_pointer_cast, void_pointer_cast would be usable even when the target type is not a class with virtual functions. On the other hand, given code like shared_ptr<void> pv(new Derived); shared_ptr<Base> pb = void_pointer_cast<Base>(pv); pb.get() would equal 0, even if Base were a public base class of Derived and had a virtual destructor. void_pointer_cast should be easy to implement, using the same techniques as were used in get_deleter, and I think it would be of great use to many programmers. Joe Gottman

1 0