- Boost - lists.boost.org

Coverity Static Code Analysis
by Michael Fawcett 05 Feb '09

05 Feb '09

Purely out of curiosity, how come Boost isn't at Rung 1 in the Coverity Scan Ladder? http://scan.coverity.com/ Boost and Boost.Build are both listed in Rung 0, so it appears that the only step left is selecting a Boost/Coverity liaison. http://scan.coverity.com/newproj.html --Michael Fawcett

14 25

[svn] sandbox access
by Kasra 05 Feb '09

05 Feb '09

Hi, I have requested a svn access to the sandbox for my crypto library. However, I haven't received my e-mail's reply yet. How long should I expect to wait?? With Best Regards Mr. Kasra Nassiri Department of Mathematics & Computer Science Imperial College London

1 0

[build] Using 'distcc' with bjam
by Dean Michael Berris 04 Feb '09

04 Feb '09

Hi Everyone, Has anybody tried using distcc instead of GCC with Boost.Build and Boost.Jam? Thanks in advance. -- Dean Michael C. Berris Software Engineer, Friendster, Inc.

2 1

[python] Expose a struct with a std::vector<std::string> member
by Tiago Coutinho 04 Feb '09

04 Feb '09

Hello all, I am new to boost::python. I have access to a C++ library which I want to expose to python using boost. One of the structs I want to expose is something like: #include <vector> struct ExampleStruct { std::vector<std::string> elements; }; I would like to expose this class but I like to avoid having to write a wrapper that would inefficiently have to copy the vector contents to a boost::python::list member. Is there a way to do this? Thank you very much in advance Cheers Tiago

2 4

[mpl]iter_fold_if use of apply1 instead of iter_apply1 maybe bug?
by Larry Evans 04 Feb '09

04 Feb '09

The following code line: https://svn.boost.org/trac/boost/browser/trunk/boost/mpl/iter_fold_if.hpp#L… shows apply1<Predicate,Iterator>; however, shouldn't this be iter_apply1<Predicate,Iterators> because, just from the name, Iterator is an iterator and needs to be deref'ed. Also, the previous line: not_< is_same<Iterator,LastIterator> > further suggests that Iterator is actually an iterator. I know it works presently; however, I really don't understand why.

2 1

Any real-world need for static_cast_iterator, const_cast_iterator, dynamic_cast_iterator?
by Nigel Stewart 04 Feb '09

04 Feb '09

In addition to the specialised adaptors in the boost iterator library, does it make any sense to add: static_cast_iterator const_cast_iterator dynamic_cast_iterator ...iterator adaptors providing embedded static_cast<>, const_cast<> or dynamic_cast<> when dereferencing? (Rather than just throwing them straight on the scrap heap...) - Nigel ---------------------------------------------- template<typename T, typename I> class static_cast_iterator : public boost::transform_iterator < T (*)(const typename I::reference), I > { private: typedef typename I::reference F; typedef typename boost::transform_iterator< T (*)(const F), I> B; public: static_cast_iterator() {} static_cast_iterator(const I &i) : B(i,&doCast) {} operator const I &() const { return B::base(); } static_cast_iterator &operator++() { B::operator++(); return *this; } static_cast_iterator &operator--() { B::operator--(); return *this; } private: static T doCast(const F val) { return static_cast<T>(val); } }; template<typename I> class const_cast_iterator : public boost::transform_iterator < typename boost::remove_const<typename I::reference>::type (*)(const typename I::reference), I > { private: typedef typename I::reference F; typedef typename boost::remove_const<F>::type T; typedef typename boost::transform_iterator< T (*)(const F), I> B; BOOST_STATIC_ASSERT(boost::is_const<F>::value); BOOST_STATIC_ASSERT(!boost::is_const<T>::value); public: const_cast_iterator() {} const_cast_iterator(const I &i) : B(i,&doCast) {} operator const I &() const { return B::base(); } const_cast_iterator &operator++() { B::operator++(); return *this; } const_cast_iterator &operator--() { B::operator--(); return *this; } private: static T doCast(const F val) { return const_cast<T>(val); } }; template<typename T, typename I> class dynamic_cast_iterator : public boost::transform_iterator < T (*)(const typename I::reference), I > { private: typedef typename I::reference F; typedef typename boost::transform_iterator< T (*)(const F), I> B; BOOST_STATIC_ASSERT(boost::is_pointer<F>::value || boost::is_reference<F>::value); BOOST_STATIC_ASSERT(boost::is_pointer<T>::value || boost::is_reference<T>::value); public: dynamic_cast_iterator() {} dynamic_cast_iterator(const I &i) : B(i,&doCast) {} operator const I &() const { return B::base(); } dynamic_cast_iterator &operator++() { B::operator++(); return *this; } dynamic_cast_iterator &operator--() { B::operator--(); return *this; } private: static T doCast(const F val) { return dynamic_cast<T>(val); } };

3 5

warnings from gcc-4.3.3 -Wall
by John Salmon 04 Feb '09

04 Feb '09

I recently upgraded to gcc/4.3 and started seeing warnings from gcc-4.3.3 -Wall suggesting parentheses around && within ||. It would be great if boost/1.38 could repair these by adding a few pairs of parentheses before the final release. N.B. I did not do an exhaustive compilation of everything in boost with gcc -Wall. The three cases below are the ones that my code base just happens to hit. Thanks, John Salmon /proj/desres/root/Linux/x86_64/boost/1_37_0-14/Release/include/boost/tuple/tuple_comparison.hpp:73: warning: suggest parentheses around && within || /proj/desres/root/Linux/x86_64/boost/1_37_0-14/Release/include/boost/iostreams/filter/symmetric.hpp:126: warning: suggest parentheses around && within || /proj/desres/root/Linux/x86_64/boost/1_37_0-14/Release/include/boost/iostreams/detail/streambuf/indirect_streambuf.hpp:285: warning: suggest parentheses around && within ||

2 1

[mpl] holder class for types with external linkage (similar to integral contants)
by klaus triendl 04 Feb '09

04 Feb '09

Recently, I've been in need of a holder class for strings with external linkage but I didn't find an mpl datatype that could wrap an externally defined entity. Instead of creating a quick solution working for my needs I thought the mpl library could benefit from a generic holder class similar to the integral constant holders. <code> template<typename T, T N> struct external_c { // make it a nullary metafunction typedef external_c type; typedef T value_type; // correct? requirements? typedef integral_c_tag tag; // can't make a static compile time constant but only a static // function static value_type value() { return N; } // implicitly convertible to its runtime type value operator value_type() const { return this->value(); } }; // e.g. extern const char string1[]; const char string1[] = "string1"; extern const std::string string2; const std::string string2("string2"); int main() { external_c<const char* const, string1> x1; external_c<const std::string&, string2> x2; std::cout << x1 << "\n"; std::cout << x2.value() << "\n"; return 0; } </code> The name 'external_c' is just a quick idea and would have to be changed anyway with c++09's possibility to use types with internal linkage in template programming. Would it be reasonable to integrate this into the mpl? Any comments? Klaus Triendl

1 0

[Serialization] Need help with binary archive deserialization error
by George van Venrooij 04 Feb '09

04 Feb '09

Hi, I just ran into an issue with serialization which is very peculiar. When serializing a complex class structure to an archive all goes well without errors. However, when trying to read back the data it works with all xml and text archive types, but when using binary archives I get an archive exception while loading. The exception occurs while loading an array of 3 doubles. From what I can make up out of the code, the archive says there are 20 bytes to load, while the library expects 24. Apparently I'm doing something that has no effect for text-based serialization, but does for binary. Since I didn't find any posts or tickets for this issue I assume I have made a mistake somewhere, only I have been looking for hours and cannot seem to find it. So any suggestions on where to look would be welcome, even the obvious ones ;-) Regards, George van Venrooij

4 4

[interprocess] Severe bug in sp_counted_impl.hpp!
by Lars Hagström 04 Feb '09

04 Feb '09

Hi, I believe that there is a bug in sp_counted_impl_pd::destroy(). Currently the method looks like this: void destroy() // nothrow { //Self destruction, so get a copy of the allocator //(in the future we could move it) this_allocator a_copy(*this); BOOST_ASSERT(a_copy == *this); this_pointer this_ptr (this); //Do it now! scoped_ptr<this_type, scoped_ptr_dealloc_functor<this_allocator> > (this_ptr, a_copy); typedef typename this_allocator::value_type value_type; detail::get_pointer(this_ptr)->~value_type(); } What I think is wrong is on the deallocator functor line. I believe that it should read scoped_ptr<this_type, scoped_ptr_dealloc_functor<this_allocator> > DEALLOCATOR(this_ptr, a_copy); The missing thing is the name for the scoped_ptr instance (the one I called DEALLOCATOR, to make it stand out). And since the name is missing it will become an anonymous instance, which will be destroyed *before* the destructor is called on this_ptr. The upshot is that with the bug we deallocate the memory and then call the destructor, rather than the opposite. If you're unlucky some other thread/process has allocated that memory for some other use, and you will then be running the destructor on that instead... I'm writing a ticket on this as well, just so it doesn't get overlooked. (If I'm wrong about all this my face will be red for a while...) Cheers Lars

4 6