- Boost - lists.boost.org

[tasklet] micro-tasks with cooperative scheduler
by Oliver Kowalke 19 Mar '11

19 Mar '11

Hi, I've uploaded version 0.2.0 of boost.tasklet: http://www.boostpro.com/vault/index.php?action=downloadfile&filename=boost.… boost.tasklet provides a framework for cooperatively scheduling micro-tasks (some kind of user-level threads). It comes with an scheduler, synchronisation primitives - mutex, condition, barrier, event-variables (auto- and manual-reset and count-down variable), future and channel. boost::tasklets::packaged_task< std::string > pt( helloworld_fn); boost::tasklets::unique_future< std::string > fu = pt.get_future(); boost::tasklet t( boost::move( pt), boost::tasklet::default_stacksize); boost::scheduler::schedule( t); boost::scheduler::schedule( my_function, 1, "abc"); for (;;) { while ( boost::scheduler::run() ); if ( boost::scheduler::empty() ) break; } std::cout << fu.get() << std::endl; In order to let functions/actions be executed in a separate thread boost.tasklet provides a scheduler_thread: boost::scheduler_thread st; boost::shared_future< void > f1( st.schedule( some_fn ) ); boost::shared_future< std::string > f2( st.schedule( other_fn) ); f1.wait(); std::cout << "future 2 result: " << f2.get() << std::endl; regards, Oliver

2 5

lambda compile error
by Andy Venikov 18 Mar '11

18 Mar '11

Hi, I thought that lambda expressions of the form: (var(actual_var) = _1)(new_value) are supposed to work. Here's a small code that does not compile with boost 1.42 and gcc4.5: #include <map> #include <boost/lambda/lambda.hpp> using namespace std; void foo() { using namespace boost::lambda; typedef multimap<int, int> MP; MP mp1; MP mp2; (var(mp1) = _1)(mp2); //compile-time error here } Are standard maps special in that regard? Thanks, Andy.

2 4

Re: [boost] [Review] Boost.Type Traits Extension by Frederic Bron
by Jeffrey Lee Hellrung, Jr. 18 Mar '11

18 Mar '11

On 3/14/2011 12:48 AM, Joel Falcou wrote: > Dear All, > > This is the first day of the fast track review of Frédéric Bron's > extensions to the Type Traits Library.This reviews will last until March > 18th, 2011 under my management. All comments and reviews are > very welcome. [...] I vote for inclusion, pending resolution of my comments below (that is, I'm hoping the community will reach some consensus, not necessarily that all my suggestions will be adopted). I've perused a few pages of the documentation and a good chunk of the implementation source. As far as the naming, I'm fine with the has_operator_xxx convention. In my own implementation of such traits, I use names such as is_pre_incrementable, is_left_shiftable, etc., which I find equally good, but as John Maddock pointed out, the has_operator_xxx names are conveniently grouped in the alphabetical reference. Perhaps an additional section of the documentation under "Type Traits by Category" should be added called "Operator Traits" which can section out these new operator traits, and then the fact that all the operator traits are nicely grouped together in the alphabetical reference would be less of an issue. For the arithmetic operators, I prefer "plus" and "minus" to "add" and "subtract", respectively, and likewise "plus_equal" to "add_assign", but it's not a strong preference, and perhaps consistency with other Boost libraries should dictate these, I don't know. I do more strongly prefer "post_decrement" to "postfix_decrement", and to have "increment" and "decrement" spelled out. "bit_op" versus "bitwise_op" is another one that I have no strong preference either way, so I would probably look at other Boost libraries for precedent. One could provide aliases for the more contentious trait names...? There is precedent for this in Boost.Fusion with accumulate and fold... At least one example in the documentation utilizing one of these operator traits would be useful. I like the idea posited earlier of a generic streaming function, maybe for debugging purposes, which uses << if available, else streams out some default string containing the type of the argument. It is implicit in the documentation, and likewise verified from looking at the implementation, that all arguments are assumed to be lvalues. That is, a reference qualifier is automatically added to the argument types given to an operator trait. Thus, the only way to query if an operator is applicable to an rvalue is to query using a const-qualified type, and even then I think you could get back false negatives in C++0x and even C++03 with Boost.Move rvalue-reference emulation (consider only operator_xxx(T&&) available). Further, rvalueness and lvalueness does enter into overload resolution (rvalues can't bind to T& when T is deduced), hence it does influence the result type of the operation. For these reasons, I believe the traits should strive to differentiate between lvalue and rvalue argument types. In either case, whether arguments are treated as presently or as propositioned above, this treatment of the arguments should be spelled out explicitly. As Vicente pointed out, the use of make in the implementation can be replaced with the declval that common_type uses. I don't have strong feelings on whether to use "void" to signify that one "doesn't care" about the result type or to use some "dont_care" type. I've personally used "void" in my operator traits implementation. If the latter solution is settled upon, I believe it should be a documented part of the interface, and not in a detail namespace, to allow users to explicitly supply it. I still believe an extra template parameter representing a Boost.MPL metafunction to apply to the result type would be useful, relatively easy to add, and will not change the existing interface. It seems, however, that I'm the only one that likes this idea, and it's use cases are relatively limited. I've mostly used such a feature to further constrain the result beyond just "convertible". For example, one may want to prevent returning references to locals from functions. That is, the function's return type is fixed to be T const &, and the function logically returns the result of an operator applied to a local variable. If the operator returns U which is implicitly convertible to T, then everything compiles fine but it's probably asking for a crash, as the function's return value is a dangling reference. You'd hope you'd get a compiler warning, but better to either create a hard error in such cases or provide an alternate implementation of the function. I think that covers everything. Well done Frederic! - Jeff

2 1

[Review] Boost.Type Traits Extension by Frederic Bron
by Joel Falcou 18 Mar '11

18 Mar '11

Dear All, This is the first day of the fast track review of Frédéric Bron's extensions to the Type Traits Library.This reviews will last until March 18th, 2011 under my management. All comments and reviews are very welcome. =========== What is it? =========== This extension adds 37 new traits corresponding to the following 37 operators: - binary: ==, !=,<,<=,>,>=, , +, -, *, /, %, +=, -=, *=, /=, %=, , &&, ||, ,&, |, ^,<<,>>,&=, |=, ^=,<<=,>>= - prefix: ++, --, +, -, !, ~, * - postfix: ++, -- Each trait can detect if the operator can be used with particular types and if needed, if the return type is convertible to some type. =================== Getting the library =================== The latest version can be downloaded by different ways: - from the vault with unix line ending: http://www.boostpro.com/vault/index.php?action=downloadfile&filename=type_t… - from the vault with dos line ending: http://www.boostpro.com/vault/index.php?action=downloadfile&filename=type_t… - from the sandbox:http://svn.boost.org/svn/boost/sandbox/type_traits/ The entry point of the documentation is type_traits/libs/type_traits/doc/html/boost_typetraits/category/value_traits/operators.html The library has been tested with: - MSVC 8, 9, 10 on Windows, - g++ 4.4.5 on Linux, - intel 10.0 and 11.1 on Linux. To test the library, the simplest is to untar the headers in your boost include directory. For this, you can download the header part of the extension: - from the vault with unix line ending: http://www.boostpro.com/vault/index.php?action=downloadfile&filename=type_t… - from the vault with dos line ending: http://www.boostpro.com/vault/index.php?action=downloadfile&filename=type_t…

12 63

bcp (and config.hpp, user.hpp, shared_ptr.hpp) problem
by Michael Matthews 18 Mar '11

18 Mar '11

I am trying to compile (with VS2008) using a few boost tools pulled out using bcp. I've used bcp before without trouble, but I just upgraded to boost_1_46_1, and now I'm having trouble. I pulled the boost subset out with: C:\Program Files\boost\boost_1_46_1>bcp filesystem.hpp foreach.hpp property_tree shared_ptr.hpp fromBoost\ During compile, the problem is with shared_ptr. The shared_ptr.hpp file includes this line at the top: #include <boost/config.hpp> // for broken compiler workarounds which causes config.hpp to be used (and it is correctly pulled by bcp), which then causes this compile error (because user.hpp is not pulled, though other files in boost/config/ are): \fromboost\boost\config.hpp(26) : fatal error C1083: Cannot open include file: 'boost/config/user.hpp': No such file or directory which is from these lines in the config.hpp file: // if we don't have a user config, then use the default location: #if !defined(BOOST_USER_CONFIG) && !defined(BOOST_NO_USER_CONFIG) # define BOOST_USER_CONFIG <boost/config/user.hpp> #endif // include it first: #ifdef BOOST_USER_CONFIG # include BOOST_USER_CONFIG #endif What is the source of the problem, and what can I do to fix it? I am not familiar with config.hpp or what it's used for, but a quick look at the documentation makes me think that I shouldn't have to worry about it as a library user. Should I manually being #defining BOOST_NO_USER_CONFIG? That seems like a hack. Thanks, Michael

2 3

Deprecation guidelines?
by Daniel Herring 18 Mar '11

18 Mar '11

I was trying to figure out how Boost handles deprecated classes, functions, headers, macros, etc. The following command finds several approaches within boost $ grep -ir deprecate boost-1.44.0/include/boost/* \ | grep -v "This header is deprecated" \ | grep -v BOOST_SPIRIT_DEPRECATED Surprisingly, none of these use compiler support. e.g. http://stackoverflow.com/questions/295120/c-mark-as-deprecated Where can one find guidelines on how to deprecate things in Boost? What is the proper way to check that code using Boost is clean? Thanks, Daniel

6 6

Boost Trunk LKGR
by Joshua Boyce 18 Mar '11

18 Mar '11

Hey all, I was wondering if there was any way to query for the Last Known Good Revision of the Boost trunk? It would be great if there was a file or something on the website that had the revision number of the latest build to compile cleanly and pass all tests, either for all platforms, or one file for each platform. For an example of this in practice elsewhere, see the Chromium project: https://sites.google.com/a/chromium.org/dev/developers/how-tos/get-the-code… <https://sites.google.com/a/chromium.org/dev/developers/how-tos/get-the-code…> Thanks.

3 3

Deprecation of compilers and libraries
by Jeroen Habraken 18 Mar '11

18 Mar '11

Hi, It seems the acceptance of Phoenix V3 has raised the question on how to handle the deprecation of compilers and libraries again. I believe it is important to reach a consensus and to make an official statement regarding it, as it's important for both users and developers. Below I've assembled a set of questions I would like to see answered: Compilers: 1. What minimum of compilers should a library support for it to be considered for review? 2. What is necessary for a compiler previously supported to be removed from this list? Libraries: 3. Should library X be marked as preferred over library Y, since multiple solutions to a similar problem are becoming more common and the right choice might not be obvious to a user? 4. Can an existing library be marked "deprecated"? 5. Once deprecated will a library be removed from boost after X releases? 6. Should a backwards compatible solution exist for a library to be removed? Personally I believe dead branches should, in due time, be cut from the tree for boost to remain at the forefront of C++ development. Especially now the number of libraries is growing, we should aim for clarity. Regards, Jeroen Habraken

3 2

[phoenix] Upcoming release - What about the rest?
by Thomas Heller 18 Mar '11

18 Mar '11

Hi all, The next boost release is nearing and I want to include Phoenix. However, there are some questions that needs to be solved. How to deal with Boost.Bind and Boost.Lambda? First of all, I don't think its a good idea to remove either of those. However, should Phoenix deprecate Boost.Bind and Boost.Lambda? If yes, how should this deprecation be handled? My main concern is that most users will just continue to use BB and BLL just because of their names. What about Phoenix V2? For V2 I have a clearer vision. I would like to have three phases: 1) Have V2 and V3 coexist in the tree, have a macro that decides which version should be included. will default to V2 2) deprecate V2, change the default of the macro introduced in 1) to V3 Alternatives: 3 a) remove phoenix v2 3 b) move phoenix v2 to another namespace so that V3 and V2 don't interfere anymore Best regards, Thomas

2 2

[valid_ptr] proposing a new type of pointer object that allows validity tracking without memory management and object ownership
by Dan Walters 17 Mar '11

17 Mar '11

Dear all, I am posting to propose a new light weight pointer object library (boost.valid_ptr) that provides safe validity checking without having to take ownership or the the responsibility of memory management of the object pointed to. The intention is to develop a useful pointer object that is easy to use and handles validity in a simple and invisible manner, to be used just like a normal pointer and in a way that a programmer would be familiar with, to produce cleaner and more intuitive code than other pointer libraries for its problem domain. The library would be best used when it is difficult to determine when an object will be released, for example, when pointing to objects higher on the stack, objects that are members of other objects or objects contained within a boost.ptr_container. The library is to be practically useful and most useful where boost.smart_ptr and boost.ptr_container libraries are not appropriate (for example, due to memory management or ownership not being required). The valid_ptr library is to be optimized for access rather than fast assignment / de-assignment. Detailed proposal: https://docs.google.com/document/pub?id=1wod4CbeL9x8rLJ2S8815akMAGmYj-fCq90… I am posting here in the hope it will generate suitable interest that it may be worth developing as a full library for submission. Best wishes, Dan

6 12