April 2010 - Boost - lists.preview.boost.org

[type_traits] optimized std::copy example wrong?
by Thorsten Ottosen 25 Apr '10

25 Apr '10

Hi John & co, IIRC, std::copy() cannot use memcpy(), since the memory is allowed to overlap. Therefore it can only use memmove(). regards -Thorsten

5 5

[1.43][Serialization] Serialization library seriosly broken
by Hartmut Kaiser 25 Apr '10

25 Apr '10

As I alluded to in my mail yesterday, the serialization library seems to be utterly broken in the current trunk, and unfortunately in the current release branch as well. We're seeing assertions at application initialization time during serialization registration in the file void_cast.hpp, line 225. That is in debug builds. In release builds we're seeing aborts later on. These problems seem to be caused by registering the same type more than once but from different shared libraries. We do not intentionally register the types more than once, even more, we have no control over this. Here is the simplified code causing the multiple registrations from different modules: struct Parameter_impl : ::Par // ::Par is a C-struct { private: friend class boost::serialization::access; template<class Archive> void serialize(Archive &ar, const unsigned int version) { ar & lambda; ar & allowedl; // more serialization going on } }; struct Parameter { boost::shared_ptr< Parameter_impl > p; // ... private: friend class boost::serialization::access; template<class Archive> void serialize(Archive &ar, const unsigned int version) { ar & p; } }; Note: no BOOST_..._EXPORT or other serialization macros are utilized in this file. This code is included by several files from different shared library modules as it is passed around. It is just including this file into compilation units from different shared libraries what causes the problems described above. All code worked before and still does with V1.42. If this error stays in the release branch the whole Boost release will be unusable for us, causing endless grief in the future. Regards Hartmut --------------- Meet me at BoostCon www.boostcon.com

6 13

[tokenmap] updated perfect hash container in sandbox
by Slawomir Lisznianski 25 Apr '10

25 Apr '10

Changes: * To eliminate a possibility of the algo for finding free slots becoming slower as the load factor increases, the container now keeps track of open slots in unused nodes. This guarantees constant time insertion of new elements at a slight bookkeeping overhead. Consequently, the load-factor has been removed. Pointed by Daniel James. * More STL compliant (iterators, size(), empty(), etc)

4 9

Help with VeecoFTC - exception - cloning_test / msvc-9.0~wm5~stlport5.2
by Emil Dotchevski 24 Apr '10

24 Apr '10

Can someone help me figure out what's going on here: http://tinyurl.com/ybpbsp4 Thanks! Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode

3 5

callback or file based construction of CSR graph
by Dan Jiang 24 Apr '10

24 Apr '10

Is there any way for CSR graph to provide a constructor that takes a file stream pointer or a callback functor? If not, how hard is it to add it? I am using edges_are_sorted CSR constuctor. It doubles memory I passed in during constructor calls. My graph is huge (>30 million arcs) and It took >8gb ram to construct my CSR. If I can have callback or file-based construction, I could cut down the memory usage by half. Dan _________________________________________________________________ Hotmail & Messenger. Get them on your phone now. http://go.microsoft.com/?linkid=9724463

2 2

(no subject)
by Dan Jiang 24 Apr '10

24 Apr '10

Is there any way for CSR graph to provide a constructor that takes a file stream pointer or a callback functor? If not, how hard is it to add it? I am using edges_are_sorted CSR constuctor. It doubles memory I passed in during constructor calls. My graph is huge (>30 million arcs) and It took >8gb ram to construct my CSR. If I can have callback or file-based construction, I could cut down the memory usage by half. Dan _________________________________________________________________ Videos that have everyone talking! Now also in HD! http://go.microsoft.com/?linkid=9724465

1 0

[1.43.0] File version.hpp in release branch still says V1.42
by Hartmut Kaiser 24 Apr '10

24 Apr '10

Go figure ... Regards Hartmut --------------- Meet me at BoostCon www.boostcon.com

2 1

[1.43.0] Beta 1 now available from SourceForge
by Beman Dawes 24 Apr '10

24 Apr '10

Boost release 1.43.0 beta 1 is now available from SourceForge See http://sourceforge.net/projects/boost/files/ For details of what's in the release, see http://beta.boost.org/users/news/version_1_43_0. Note that the links to files on this web page are for the final release - use the SourceForge link above to get the beta files. There are known issues with GCC 4.5 and VC++ 2010. These compilers were released a few weeks ago so support is still rough around the edges. Some fixes will make it into the final 1.43.0 release, but full support will not be available until 1.44.0. Please download the beta, give it a try, and report any problems you encounter here. -- The Boost Release Team

3 4

[type_traits] what a about a trait that allows memcpy provided that destructors are not called?
by Thorsten Ottosen 24 Apr '10

24 Apr '10

Hi All, I'm looking into writing a boost::malloc_allocator<T> class. This allocator can also reallocate memory in-place via call's to realloc() which can be a benefit for vector-implementation and all it's functions that grow or shrink the vector. However, it is normally only safe to call memcpy() for objects with a trivial assignment operator. But we may also safely relocate a much larger set of classes, e.g. boost::shared_ptr<T> or std::vector<T>. At first I thought a trait like has_trivial_move_constructor<T> would be enough, but that seems to rule out e.g. smart pointers. The compiler can probably not detect this property, so what about a trait like template< class T > struct is_reallocable; Thoughts? -Thorsten

1 0

[1.43][beta] Fix for MPL under gcc 4.5
by joel falcou 24 Apr '10

24 Apr '10

Can : https://svn.boost.org/trac/boost/ticket/4061 be fixed by merging the attached trivial patch ? gcc 4.5 borks up on a deep MPL internals that prevent some other component to not compile. Thanks -- ___________________________________________ Joel Falcou - Assistant Professor PARALL Team - LRI - Universite Paris Sud XI Tel : (+33)1 69 15 66 35

16 30