September 2012 - Boost - lists.boost.org

Sizes, signed and unsigned integers, MPL and Fusion
by Mathias Gaunard 10 Sep '12

10 Sep '12

Hi folks, I am writing this message to bring to your attention ticket #7304 <https://svn.boost.org/trac/boost/ticket/7304> Sizes of fusion sequences are of type 'int', because it mimics MPL. However, sizes of standard containers, some of which are fusion sequences, are of type std::size_t, which is unsigned. This seems a bit inconsistent, and can lead to unexpected signed/unsigned mismatch warnings in certain scenarios. Should both MPL and Fusion be modified to use unsigned size types? I think it is best to discuss this with the whole of Boost.

2 1

Making use of extern template
by Jens Auer 10 Sep '12

10 Sep '12

Hi, I tried to use C++11 extern template mechanism to reduce the turn-around time for our main project, but it turns out that the way people write template code in libraries is not suited well for that purpose. I tried to explicitly instantiate the template base class of boost::posix_time_ptime, date_time::base_time<ptime, posix_time_system>, because ptime is a value class which is used quite often in our project. The base class is then instantiated in every translation unit and later removed by the linker (we use MS Visual C++ 2010. The linker is single threaded and dead slow). The problem with extern template and the boost library is that inline template code is still instantiated in every translation unit even when using extern template, so it basically has no effect with the current boost code: $14.7.2.10: "Except for inline functions and class template specializations, explicit instantiation declarations have the effect of suppressing the implicit instantiation of the entity to which they refer." I would like to have a discussion of how boost could support extern template to reduce built times, maybe by changing the coding style to not write template code inline and use extern template in the library to automatically suppress instantiation of library instantiations such as the base class of ptime. Best regards, Jens

1 0

[atomic, 1.52] adoption & merge request
by Tim Blechmann 09 Sep '12

09 Sep '12

hi all, boost.atomic has been accepted as boost library and has been in trunk for a few months. however there are some issues and pending patches and helge bahmann, the original author, did not comment on any of them. therefore, hartmut and me would like to adopt the library temporarily to support helge, and merge these pending patches. we also like to add the library into the release branch, so that it will make it into 1.52. any objections? thanks, tim

3 2

[atomic] ia32/cmpxchg8b fix
by Tim Blechmann 09 Sep '12

09 Sep '12

one of my users reported an issue with atomic on gcc/ia32, related to const-correctness. ok to commit this fix? thanks, tim Index: boost/atomic/detail/gcc-x86.hpp =================================================================== --- boost/atomic/detail/gcc-x86.hpp (revision 80433) +++ boost/atomic/detail/gcc-x86.hpp (working copy) @@ -1556,11 +1556,11 @@ template<typename T> T -platform_load64(volatile T * ptr) +platform_load64(const volatile T * ptr) { T expected = *ptr; do { - } while (!platform_cmpxchg64_strong(expected, expected, ptr)); + } while (!platform_cmpxchg64_strong(expected, expected, const_cast<volatile T*>(ptr))); return expected; }

2 1

Re: [boost] C++ Boost library - passing Shared pointer to a function
by abhishek goswami 09 Sep '12

09 Sep '12

I am looking for a project which is converting c malloc/realloc to shared_ptr. During my Analysis, I found the issue Can anyone provide me some input how to fix below issue typedef boost::shared_ptr<Employee_t> srdpointer; srdpointer ptr((Employee_t*)malloc(sizeof(Employee_t)),std::ptr_fun(free)); I need to pass the shared pointer which will allocate memory Pointed by the ptr. Something like this. void allocateBlocks(int **ptr, int *cnt) { *ptr = (int*)malloc(sizeof(int) * 10); *cnt = 10; /*do something*/ } int main() { int *p = NULL; int count = 0; allocateBlocks(&p, &count); /*do something*/ free(p); } How can I achieve the similar functionality using shared ptr as shown in above code

2 1

[intrusive] patch to resolve compiler error for WinCE
by David Deakins 09 Sep '12

09 Sep '12

Hi Ion, I had a little bit of time to look into the compile error mentioned in ticket 6841 and determine a patch from detail/mpl.hpp that I think should resolve it. The patch is attached to that Trac ticket, although I could also just go ahead and apply it if you like. Thanks, -Dave

2 1

[Review.Coroutine] Some comments
by Vicente J. Botet Escriba 09 Sep '12

09 Sep '12

Hi, thanks Oliver to move the Coroutine library to a Boost review ready proposal. Before doing a formal review, I have some comments, suggestions and questions after a quick reading. Design ==== * I don't know if showing the signature in the documentation will be more informative. This will avoid, in particular, the be forced to explain what T and R and in the the current declaration. Could you replace template< typename Signature, typename Allocator = ctx::stack_allocator > class coroutine { public: class self_t { public: T yield( R); void yield_break(); }; by template< typename Signature, typename Allocator = ctx::stack_allocator >class coroutine; template< typename R, typename ...ArgTypes, typename Allocator > class coroutine<R(ArgTypes...)> { public: class self_t { public: tuple<ArgTypes...>yield( R); void yield_break(); }; * Could you add the following noexcept specifier? class coroutine { // ... coroutine() BOOST_NOEXCEPT; coroutine( coroutine && other) BOOST_NOEXCEPT; coroutine & operator=( coroutine && other) BOOST_NOEXCEPT; explicitoperator bool() const BOOST_NOEXCEPT; bool is_complete() const BOOST_NOEXCEPT; //... }; void swap( coroutine & l, coroutine & r) BOOST_NOEXCEPT; The same applies to generator. * As the template class Allocator is not used to allocate internal memory of the coroutine class. Could the Allocator parameter be renamed StackAllocator? * Could you add an standard Allocator parameter as e.g. the one of packaged_task? 0. template <class F, class Allocator> explicit packaged_task(allocator_arg_t, const Allocator& a, F&& f); C++ International Standard * I understand that the Boost.Context Allocator parameter is part od the class, as context is a low-level class, but coroutine is more high level. Is there a possibility to type erase the StackAllocator (and preceding Allocator) template parameter, as packaged_task do? This will allow to store coroutines (and generators) with the same signature in a container even if they don't share the Allocator. template<typename>class coroutine; template< typename R, typename ...ArgTypes > class coroutine<R(ArgTypes...)> { public: //... template< typename Fn,typename Allocator> generator( Fn fn, std::size_t size = ctx::default_stacksize(), flag_unwind_t do_unwind = stack_unwind, bool preserve_fpu = true, Allocator alloc = Allocator() ); //... }; * Parameters and move semantics. Could the signature parameters be rvalue references? R operator()(A0 a0, ..., A9 a9); I'm asking this because I think that Boost.Tuple has not implemented yet move semantics. * What about moving some of the coroutine/generator optional parameters to a coro::attributes class std::size_t size = ctx::default_stacksize(), flag_unwind_t do_unwind = stack_unwind, bool preserve_fpu = true, * Usually (at least in the C++ standard) a function doesn't throws because of its preconditions are not satisfied. Preconditions: |size| > ctx::minimum_stacksize(), |size| < ctx::maximum_stacksize() when ! ctx::is_stack_unbound(). Effects: Creates a generator which will execute |fn|. If |do_unwind| is |stack_unwind| the destructor of |*this| unwinds the stack before destructing it. If |preserve_fpu| is |true| the floating-point registers are preserved between context switches. Throws: /invalid_argument/ if a precondition is not satisfied. Should the function throw in this case? This should be coherent with |Result operator()()| <http://ok73.ok.funpic.de/boost/libs/coroutine/doc/html/coroutine/generator/…> Preconditions: |*this| is not a /not-a-generator/, |! is_complete()|. which doesn't throws any specific exception if the preconditions are not satisfied. . Documentation ========= coroutine.html s/it can migrated between threads/it can migrate between threads/ s/yield_return/yield_break/ * documentation for the following constructor is missing in the reference template< typename Fn > coroutine( Fn && fn, std::size_t size = ctx::default_stacksize(), flag_unwind_t do_unwind = stack_unwind, bool preserve_fpu = true, Allocator alloc = Allocator() ); Best, Vicente

4 12

Re: [boost] [Boost-users] boost 1.51.0 bz2 archive observations
by Daniel James 09 Sep '12

09 Sep '12

>From the user list: On 31 August 2012 16:39, Aras Vaichas <aras.vaichas(a)gmail.com> wrote: > > There is a slight difference between the 1.51.0 and 1.50.0 boost bz2 files. > > e.g. > \boost_1_50_0.tar.bz2\boost_1_50_0.tar\boost_1_50_0\ > \boost_1_51_0.tar.bz2\boost_1_51_0.tar\.\boost_1_51_0\ This is causing problems for some people's build scripts. The attached patch should fix this.

2 1

boost::assign::map_list_of and references?
by David Hagood 08 Sep '12

08 Sep '12

I was trying to initialize a map using map_list_of, and ran into what I consider an undesirable behavior: class stooge { public: stooge(); stooge(const stooge &); stooge &operator =(const stooge &); }; typedef std::map<std::string,const stooge &> MyMap_t; extern const stooge larry,moe,curly; MyMap_t mymap = boost::assign::map_list_of ("larry",larry) ("moe",moe) ("curly",curly); The above leaves mymap full of bogus references - it seems map_list_of is creating temporary copies of the objects, rather than taking their references, and then the map takes references to those temporaries, and blooley! Changing the assignment to: MyMap_t mymap = boost::assign::map_list_of<std::string, const stooge &> doesn't change anything. (and for various reasons, making stooge noncopyable is not an option). This is under gcc 4.5 i686 target. Am I "doing it wrong" or is this an issue with map_list_of?

1 0

[config] [result_of] Now VC++11 selects decltype-based result_of by default
by Michel Morin 08 Sep '12

08 Sep '12

On VC++11, result_of (on trunk) uses decltype-based implementation by default from r80453: https://svn.boost.org/trac/boost/changeset/80453 Note that VC++11 does not have a C++03/C++11 compiler switch and it always runs in a C++11 mode. Regards, Michel

1 0