September 2012 - Boost - lists.boost.org

[coroutine] new location
by Oliver Kowalke 05 Sep '12

05 Sep '12

Hi, because some of the community members have had some problems to access the archive I've uploaded the library to a new location. docu: http://ok73.ok.funpic.de/boost/libs/coroutine/doc/html/ src: http://ok73.ok.funpic.de/boost.coroutine.zip I'd like to remember that the review starts at September 3, 2012. The library contains one example using boost.asio together with a stream reading from a socket (without blocking the application if newline was not received). regards, Oliver

7 15

[context] Why does boost::ctx::minimum_stacksize() on Windows return 65536
by Hartmut Kaiser 05 Sep '12

05 Sep '12

Hey all, Why is the minimally possible stack size in Boost.Context on Windows set to be 64k? This seems to be way too high for applications where only a minimal amount of stack is required. I assume, that since Boost.Context allocates the stack using VirtualAlloc the minimum possible value should be equal to the page size (see http://msdn.microsoft.com/en-us/library/windows/desktop/aa366887(v=vs.85).as px). Regards Hartmut --------------- http://boost-spirit.com http://stellar.cct.lsu.edu

4 18

Mail moderated?
by Klaim - Joël Lamotte 05 Sep '12

05 Sep '12

Hi I sent an email to this list this morning that apparently got into moderation because it contained some text files with logs. I'm just not sure it's been noticed by moderators, as it might have been marked spam or something? Joel Lamotte

2 1

Re: [boost] [Review.Coroutine] Some comments
by Oliver Kowalke 05 Sep '12

05 Sep '12

> * I don't know if showing the signature in the documentation will be > more informative. OK > * Could you add the following noexcept specifier? OK > * As the template class Allocator is not used to allocate internal > memory of the coroutine class. Could the Allocator parameter be renamed > StackAllocator? OK > * Could you add an standard Allocator parameter as e.g. the one of > packaged_task? > > 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. You mean coroutine would have two allocators - one for allocating internal memory and one for allocating the stack? Removing the StackAllocator from the template arguments of coroutine should not that problem (would require an internal pointer to an internal interface - maybe detail::context_exec is a candidate). I've some concerns about having two allocator objects in coroutine's ctor . > * Parameters and move semantics. Could the signature parameters be > rvalue references? > > R operator()(A0 a0, ..., A9 a9); Hmmm - this would require a second version of opertor() and all arguments are moveable?! R operator()(BOOST_RV_REF( A0) a0, ..., BOOST_RV_REF( A)) a9); > I'm asking this because I think that Boost.Tuple has not implemented yet > move semantics. don't know - would that be an issue > * 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, instead of passing those threee params as args to coroutine ctor? good point > * Usually (at least in the C++ standard) a function doesn't throws > because of its preconditions are not satisfied. then assert? pre-conditions should be checked but how should I react if I get garbage from the user? > This should be coherent with > > > |Result operator()()| > > Preconditions: > > |*this| is not a /not-a-generator/, |! is_complete()|. > > which doesn't throws any specific exception if the preconditions are not > satisfied. does an assert - OK the I'll replace throwing excpetions be assertions > Documentation > ========= > > coroutine.html > > s/it can migrated between threads/it can migrate between threads/ OK > 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() ); OK I think it will be easy to incorporate your suggestions - but during the boost.context review I was told not to modify the reviewd library (if the review is still on-going). regards, Oliver

2 1

[rational] Over/underflow checked update ready for comments
by Dan Searles 05 Sep '12

05 Sep '12

>>> Quick overview of the update: the original usage and >>> code of the template class remains mostly as before, ie >>> boost::rational<int> RationalVar; should work as >>> in the original version. Adding 'true' as a second >>> template parameter, however, allows an exception to >>> be raised if an operation with a class variable results >>> in a value that can't accurately be represented >>I haven't looked at anything else, but I dislike using true/false as the template argument. I'd prefer meaningful names. _____ >>Rob Stewart robert.stewart(a)sig.com >>Software Engineer using std::disclaimer; >>Dev Tools & Components >>Susquehanna International Group, LLP http://www.sig.com >Replaced the bool template parameter with an enum: >enum RationalChecktype {RationalNoChecking, RationalCheckforOverflow}; For those interested in the rational number class, see: https://svn.boost.org/svn/boost/sandbox/rational Requesting comments on the code, and review for inclusion in the next release. Dan Searles

2 1

very simple implementation of Andrei Alexandrescu's ScopeGuard idiom
by Sergey Radionov 04 Sep '12

04 Sep '12

https://github.com/RSATom/finally_execute/blob/master/finally_execute.h based on http://www.drdobbs.com/cpp/generic-change-the-way-you-write-excepti/1844037… I know about http://sourceforge.net/projects/loki-lib/ but with boost::bind this can be much simpler: https://github.com/RSATom/finally_execute/blob/master/README I've used this in many of my projects, and found it very usefull.... don't understand, why this simple solution does not contributed already to Boost by someone else... :)

7 19

[graph] property_value no longer valid for bgl_named_parameters
by Alex Hagen-Zanker 04 Sep '12

04 Sep '12

The transition from Boost 1.49 to 1.51 gave me a breaking change in the graph library: Originally I used the property_value struct to get the type of a named parameter, like this: property_value<bgl_params, Tag>::type; This no longer works and the current use seems to be: get_param_type<Tag, bgl_params>::type; Is this a regression? Or was I just using the library in the wrong way? Thanks, Alex

2 1

Enum Conversion
by Roland Bock 04 Sep '12

04 Sep '12

Hi, In a lot of projects in the company I work for we use Ice middleware which allows to define nice interfaces for services. The IDL also allows to define enums, but I cannot set specific values for the enum items. We also need to store some of these values in databases. We use int to represent the enumerations. Since we might feel the need to add more items to an enum or delete an unused one, we cannot just cast enum to int and vice versa when writing to or reading from the database. We need methods that translate enum to int and back in a stable way that won't change for an individual enum item, even if its position in the enum changes. I found a way to do this, which provides enum<->int and enum<->string. It is used like this: typedef enum { Alpha, Beta, Gamma, Delta, Epsilon } Greek; CREATE_CONVERTER_METHODS(Greek, (Alpha, 5), (Beta, 3), (Gamma, 7), (Delta, 1), (Epsilon, 6)); std::cout << GreekToString(IntToGreek(1)) << std::endl; std::cout << GreekToString(IntToGreek(6)) << std::endl; std::cout << GreekToInt(Alpha) << std::endl; std::cout << GreekToString(Alpha) << std::endl; std::cout << IntToGreek(17) << std::endl; ------ $ ./a.out Delta Epsilon 5 Alpha terminate called after throwing an instance of 'std::invalid_argument' what(): unexpected Greek value My questions are: a) Is this something that might be interesting for others as well? (Or does boost even offer something like that already?) b) I'd really like to be able to write this instead: CREATE_CONVERTER_METHODS(Greek, Alpha = 5, Beta = 3, Gamma = 7, Delta = 1, Epsilon = 6); Obviously, if I could use the preprocessor to translate Alpha = 5 -> (Alpha, 5) I'd be done. But I have no idea how to do that. Any suggestions? Thanks and regards, Roland

4 11

[Contract] noexcept and custom contract violation handlers
by Andrzej Krzemienski 04 Sep '12

04 Sep '12

Hi, I have just realized that there is an interesting interaction between "noexcept" and Contract Programming framework. Not only Lorenzo's library, but even if contracts were a language feature. N3248 ("noexcept prevents library validation", http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2011/n3248.pdf) recommends that functions with any preconditions should not be declared noexcept(true) in case someone wants to report precondition failures via exceptions. If preconditions become part of declaration syntax, declaring both precondition and noexcept(true) could (and should?) be recognized as compile-time error. But now also invariants and postconditions come into play: if a function declares a postcondition, or our class defines an invariant, should we be allowed to declare our function noexcept? What if someone wants to report an invariant or postcondition failure via special exception? (I do not have a good answer for it.) Regards, &rzej

4 5

[contract] invariant checking after destructor throw
by Andrzej Krzemienski 04 Sep '12

04 Sep '12

I have found a potential issue while reading the documentation. (The documentation is very good BTW). It says that the non-static invariant is still checked if object's destructor throws an exception. Am I reading it right? If so, I believe this is not correct. I have two problems with it: 1. According to the standard, an object is considered destroyed (its life-time has ended) when its destructor *starts*. Even if it throws an exception, it is considered destroyed, so accessing its members (in order to check for the invariant) may be illegal (an undefined behavior). 2. Why such an object (that threw on destruction) would need to preserve the invariant? You cannot access it or use it or even destroy it the second time, because it has already been destroyed. No-one will notice it anyway. Or am I missing something? Regards, &rzej

3 4