- Boost - lists.boost.org

[1.37.0] Release schedule added to Development page
by Beman Dawes 09 Oct '08

09 Oct '08

The calendar with the release schedule appears on the web site's Community page, but that isn't the first place a developer is likely to look. So I've added a copy on the Development page. See http://www.boost.org/development/index.html. The "Month" or "Agenda" tabs provide useful views. The time zone shown is US Central Time. I guess that's because its Rene's time zone, and he created the calendar. It might be better if it were UTC, but I'll leave that up to Rene. --Beman

2 1

1.37: Boost.Pool fixes to be merged to release?
by Chris Newbold 08 Oct '08

08 Oct '08

I've fixed a couple of minor issues in Boost.Pool over the course of the last week and submitted to trunk. Can/should I go ahead and merge these to release? -Chris

2 1

Known 1.36 bugs
by Johan Torp 08 Oct '08

08 Oct '08

Is there a list of known 1.36 bugs? Or can someone please point me to the most serious ones? Best Regards, Johan Torp www.johantorp.com -- View this message in context: http://www.nabble.com/Known-1.36-bugs-tp19878713p19878713.html Sent from the Boost - Dev mailing list archive at Nabble.com.

3 2

[multi_array] Finding array bounds.
by Robert Jones 08 Oct '08

08 Oct '08

I'm trying to write this piece of code struct Cell { .... }; typedef boost :: multi_array< Cell, 2 > Grid; void f( Grid & grid ) { for ( Grid::index i=grid.?????(); i!=grid.????(); ++i ) { ..... } } where the intention is to iterate over the first subscript of the multi_array. I can see that index_range has start() and finish() methods, but I can't see how to extract the first index_range from the multi_array. Thanks - Rob.

1 0

[phoenix] Phoenix & 1.37
by Robert Jones 08 Oct '08

08 Oct '08

I see the 1.37 release is gathering momentum. We will see any development of Phoenix in 1.37, following on from all the input of the recent review? - Rob.

2 1

config.hpp
by Joel Falcou 08 Oct '08

08 Oct '08

I'm digging up a previous topic of mine : http://article.gmane.org/gmane.comp.lib.boost.user/39236/match=config Basically, is it possible to consolidate the boost/config headers so they provide a macro usable in #ifdef and such so we can use Boost comprehensive platform/compiler tests in library ? I know some are already usable (like testing for BOOST_MSVC and such) but it lacks in some area like platform. My proposal is the following : For platform, stdlib and compiler config flag, add a macro called respectively : BOOST_ACTIVE_PLATFORM_CONFIG BOOST_ACTIVE_STDLIB_CONFIG BOOST_ACTIVE_COMPILER_CONFIG That contains a numeric value that identify the current chosen configuration. For each type of configuration, files called boost/config/platform_list.hpp,boost/config/stdlib_list.hpp and boost/config/compiler_list.hpp are provided. Those files contains the global list of possible active configuration and give them proper usable symbol. eg : platform_list.hpp #ifndef __BOOST_CONFIG_PLATFORM_LIST_HPP__INCLUDED__ #define __BOOST_CONFIG_PLATFORM_LIST_HPP__INCLUDED__ #define BOOST_AIX_PLATFORM_CONFIG 100 #define BOOST_AMIGAOS_PLATFORM_CONFIG 101 /// and so on ... #define BOOST_WIN32_PLATFORM_CONFIG 111 #define BOOST_UNKNOWN_PLATFORM_CONFIG 999 #endif Then in win32.hpp, the following definition is provided : #define BOOST_ACTIVE_PLATFORM_CONFIG BOOST_WIN32_PLATFORM_CONFIG In user code, it can be checked like this : #if (BOOST_ACTIVE_PLATFORM_CONFIG == BOOST_WIN32_PLATFORM_CONFIG) // Some Win32 code #else // some other code for non-win32 #endif Does this sound useful or am I overlooking some already existing boost system that may already do this ?

1 0

[serialization] disabling msvc warnings
by Jürgen Hunold 08 Oct '08

08 Oct '08

Hi ! Please find a patch attached which disables MS "secure" STL and C-Runtime warnings when build Boost.Serialization with msvc-8.0 and above. Yours, Jürgen -- * Dipl.-Math. Jürgen Hunold ! Ingenieurgesellschaft für * voice: ++49 511 262926 57 ! Verkehrs- und Eisenbahnwesen mbH * fax : ++49 511 262926 99 ! Lister Straße 15 * juergen.hunold(a)ivembh.de ! www.ivembh.de * * Geschäftsführer: ! Sitz des Unternehmens: Hannover * Prof. Dr.-Ing. Thomas Siefer ! Amtsgericht Hannover, HRB 56965 * PD Dr.-Ing. Alfons Radtke !

1 0

[serialization] extended_type_info_typeid doesn't work with objects with non public destructors
by Rodolfo Lima 07 Oct '08

07 Oct '08

Hi, it seems that in boost::serialization-1.36 the extended_type_info_typeid and extended_type_info_no_rtti doesn't use boost::serialization::access to delete the object, hence there are compile failures when it's used with an object whose destructor isn't public. Is there any chances that this will be fixed in boost-1.37? Regards, Rodolfo Lima

2 2

[property_tree] Conversion constructor missing?
by Boris 07 Oct '08

07 Oct '08

Imagine you have this XML structure (copied from the documentation and shortened): <debug> <modules> <module>Finance</module> <module>Admin</module> <module>HR</module> </modules> </debug> Now imagine you have this function which you want to call three times to pass the <module>...</module> nodes to: void foo(boost::property_tree::ptree pt); You can use get_child("debug.modules") to retrieve a property tree containing all module nodes. However if you iterate over the property tree the iterator refers to std::pair<const key_type, basic_ptree<Tr>> - and there is no simple way to convert this pair to a new property tree. You must create an empty property tree followed by a call to push_back() to insert the pair. Either there is a conversion constructor missing or I miss something and there is a simpler way of what I'm trying to do? Boris

1 0

type_with_alignment.hpp / alignment_of.hpp too heavy
by Emil Dotchevski 07 Oct '08

07 Oct '08

I need to allocate an object of type T, but I also need to bundle it in a single memory allocation with an object of class U. Something like "new std::pair<T,U>" would work, except that U is a rather heavy type and I want to pimpl it away into a cpp. This means that the cpp needs to deal with the alignment of T and U when allocating the memory. For that purpose, I could use type_traits/type_with_alignment.hpp in my header, but when I looked at it, I was blown away by how much crap it includes (remember, I want my header to be very very light.) Then I thought that I could probably build my system by just using type_traits/alignment_of.hpp. It sure would be very light, right? Wrong, it also includes mpl and whatnot. I hope someone shares my frustration. Shouldn't at least alignment_of.hpp be much, much lighter? I'd think that all it should contain is whatever compiler-specific hacks are needed and that's it. What is the justification for including stuff like <boost/mpl/aux_/lambda_support.hpp> in alignment_of.hpp? Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode

8 9