- Boost - lists.boost.org

[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 08 Sep '12

08 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

[result_of] Usage guidelines
by Andrey Semashev 08 Sep '12

08 Sep '12

Hi, I wonder what is the correct way of declaring polymorphic function object result types and how to use result_of template with regard to argument types. If a function object receives arguments by reference, should its member result<> template be specialized for reference types as well? Also, should result_of<> for this function be instantiated with reference argument types? struct my_foo { template< typename > struct result; // Is this correct? template< typename ArgT > struct result< my_foo(ArgT) > { typedef ArgT type; }; // Or is this correct? template< typename ArgT > struct result< my_foo(ArgT const&) > { typedef ArgT type; }; template< typename ArgT > ArgT operator() (ArgT const& arg) const { return arg; } }; I realize that I can provide both result<> specializations and it will work either way. But when there are more than one argument the specializations begin to pile quickly. Consider also rvalue references and const and non-const qualified my_foo. Another question I have is how to use result_of<> when my_foo is external (i.e. provided by a third party library)? // Which one is the right way? typedef result_of< my_foo(int) >::type result_type1; typedef result_of< my_foo(int const&) >::type result_type2; I cannot know what result<> specializations are provided by my_foo, so probably there isn't an ultimate answer. But perhaps there are some guidelines or best practices? I've looked at result_of docs but there are no recommendations on this.

5 11

Interest in UDL suffixes for built-in and some standard library types?
by Peter Sommerlad 08 Sep '12

08 Sep '12

Dear boost members, I am preparing a paper for the next C++ standardization meeting for providing user-defined-literals for some standard types. b (and a variety of derivations lik bULL) for binary integer literals as in 101b s for std::string as "hello, world!"s s, h, min, etc. for std::chrono::duration literals such as 0xfh for 15 hours i, r for creating std::complex literals see http://wiki.hsr.ch/PeterSommerlad/wiki.cgi?LiteralsForBinaryStringComplexDu… for the paper draft. It also includes machinery to parse integers using the template version of a user-defined literal, because using constexpr operator"" foo(unsigned long long bar); overload loses the ability to treat the number bar as a compile-time constant, e.g., to use as template argument further on. Some people told me, such a facility would be nice in its own way, to be used by other authors of UDL constexpr overloads. I wonder if there is interest to provide standard conforming versions of my implementation (including the required _ prefix) for boost (which would require to clean up things a bit beforehand). Such a boost.suffixes library would only work with C++11 capable compilers that actually implement UDL and constexpr in combination (for some uses the constexpr is not required). gcc4.7.1 is fine, for example, my version of clang didn't do constexpr yet (that might have changed). Feedback, encouragement and thoughts are welcome. TIA and Best Regards Peter. -- Prof. Peter Sommerlad Institut für Software: Bessere Software - Einfach, Schneller! HSR Hochschule für Technik Rapperswil Oberseestr 10, Postfach 1475, CH-8640 Rapperswil http://ifs.hsr.ch http://cute-test.com http://linticator.com http://includator.com tel:+41 55 222 49 84 == mobile:+41 79 432 23 32 fax:+41 55 222 46 29 == mailto:peter.sommerlad@hsr.ch

2 1