March 2010 - Boost - lists.preview.boost.org

[program_options]
by Thorsten Ottosen 08 Mar '10

08 Mar '10

Hi, I tried using bpo::options_description desc("Allowed options"); desc.add_options() (HELP, "produce help message"); but this fails to compile because HELP is an std::string. Isn't that a bit too restrictive? -Thorsten

9 14

is review system in place is extremely slow? (was Re: [rfc] rcpp)
by vicente.botet 08 Mar '10

08 Mar '10

Hi, ----- Original Message ----- From: "Mathias Gaunard" <mathias.gaunard(a)ens-lyon.org> To: <boost(a)lists.boost.org> Sent: Tuesday, February 23, 2010 12:47 PM Subject: Re: [boost] [rfc] rcpp > > Ivan Sorokin wrote: >> 3 When will Boost.Move become a part of boost? > > When it gets reviewed. > It could be said, however, that the review system in place is extremely > slow and that it's going to take years (literally). Why do you think the review system in place is extremely slow? Currently there are a lot of libraries to review, but no review managers. That means that the user community don't want to spend a little bit of their time to manage a review. In addition, the last review didn't had too much of reviewers (I'm also concerned by this point) I'm the review manager of Boost.Task but the library is not ready for review, because now Boost.Task depends on Boost.Move, Boost.Fiber and Boost.Atomic (which is not yet on the review queue). Maybe the review withards could add this on the schedule page. What do you propose to improve it? Best, _____________________ Vicente Juan Botet Escribá

32 87

Cooperative Multi-Tasking
by Daniel Larimer 08 Mar '10

08 Mar '10

I am curious whether anyone here has experience with any cross-platform cooperative multi-tasking libraries? I am familiar with the Boost.Coroutine library, but it only provides the "primitives" or "threads". What I am looking for is something much higher level that hides all of the coroutine details behind a asynchronous function call / future API. Something along the line of ASIO for coroutines. I am guessing that Boost.Asio would benefit from such a library. It seems obvious to me now that coroutines / cooperative multi-tasking is the superior approach to solving problems with a large number of actors and "locks" where heavy weight preemptive scheduling would bog down the system. Considering that cooperative multitasking is a very old concept, are there any reasons why there are no obvious libraries / scheduling systems in place? Does everyone "roll their own" or do they avoid it for some other reason? Dan

9 20

[Tokenmap] A (perfect) hash container library chcked-in to sandbox (RFC)
by Slawomir Lisznianski 08 Mar '10

08 Mar '10

http://svn.boost.org/svn/boost/sandbox/tokenmap/libs/tokenmap/doc/html/inde… A tokenmap is a data structure that uniquely maps pseudo-random generated keys with elements of the collection. Boost.Tokenmap is a (perfect) hash container library for C++. An important distinction between tokenmap and other dictionary-like containers, such as std::map or Boost.Unordered, is that tokenmap generates keys internally (referred to as "tokens") rather than relying on user to provide them. Specifically, when a new element is inserted into the tokenmap, an apparently random key is returned back to the caller which uniquely maps to the stored element. The returned key can later be used in a very efficient lookup. Although the code and documentation are far from complete, the implementation in the repo is functional and hopefully serves as a basis for further work. Slawomir

9 27

[Itl] Review
by Phil Endecott 08 Mar '10

08 Mar '10

My review of the proposed Interval Template Library follows. This is based only on studying the documentation, and previous discussion of the library on the Boost mailing list (e.g. http://lists.boost.org/Archives/boost/2009/03/149396.php ). Joachim has clearly put a lot of work into what is a substantial and well-documented library. Unfortunately, it seems to me that it is built on a weak foundation. One of the most well-known problems involving intervals is to determine which of a given set of intervals contains a particular point. How to store a set of intervals in such a way as to make this problem efficient has been extensively studied. If an "interval tree" (See e.g. Wikipedia: http://en.wikipedia.org/wiki/Interval_tree) is used, then the problem can be answered in logarithmic time and linear space. (More precisely: if there are N intervals in the container and M overlap the point of interest, finding them should take O(M + log N) time and the data structure should take O(N) space.) I was hoping to find that this library was an implementation of an interval tree. But it is not: it is built on top of normal standard-library containers. The implementation used can find the intervals that overlap a point in O(M + log N) time, but to do so it needs worst-case O(N^2) space and I think it needs O(N^2 log N) time to build that structure. Presumably this complexity is not an issue in Joachim's application. Unfortunately, library code will be used in many different applications including those where optimal complexity is required. For example, consider trying to store the lifespans of people in a genealogy program: recording a few thousand people living over a few hundred years would approach the worse-case space complexity and need megabytes of storage. Perhaps other reviewers will feel that there are sufficient applications where this library is suitable to justify its inclusion in Boost. My feeling is that since the interval tree data structure is so well known and its performance is so much better, we should not accept this library. Ideally it would be possible for Joachim to replace ITL's current standard containers with an interval tree implementation. Could an interval tree be implemented with an interval sufficiently similar to a std::set/map to make that possible, without losing the complexity benefits? Once again, I believe that apart from this weak foundation this looks like an excellent submission that is comprehensive and well-documented. Regards, Phil.

3 9

[Review] ITL review starts today, February 18th
by Hartmut Kaiser 07 Mar '10

07 Mar '10

Hi all, The formal review of the Interval Template Library (ITL) starts today, February 18th, 2010 and will end February 27th, 2010. ITL is being developed by Joachim Faulhaber. ------------------------------------------------ About the library: The Interval Template Library (ITL) is a library of interval containers that facilitates computations on collections of intervals and associated values. Use cases of such computations typically occur in the date and time problem domain, when collections of time intervals with associated data are analyzed, combined and aggregated. But the scope of applications for interval containers is more general and not limited to date and time problems. Interval containers allow to access and manipulate collections of intervals on an abstract level as sets and maps (of elements), but also to exploit segmental information that is given by the interval borders. Interval containers are fairly generic. They can be instantiated with discrete domain (or key) types like integral numeric types or boost::date or time types. But they also work with continuous domain types like double, rational or string. Using the latter allows to represent infinite sets and maps. The interface of the interval containers strives to be very intuitive and in line with the stl and other boost libraries. * The set theoretic operations union, difference, intersection and symmetric difference are available as operators for all interval containers and for many useful overloads between them. * There is iterator support on the level of segments and interval containers can be combined with stl containers of intervals via stl algorithms. * For discrete domain types, element iterators are available which makes interval sets and maps models of SortedAssociative Containers so they can be used with many stl algorithms. All interval containers are addable and subtractable. The addability and subtractability concept of the ITL leads to a general mechanism of aggregation on interval_maps which is called 'aggregate on overlap'. Exploiting 'aggregate on overlap' allows to compute many useful aggregation results in a simple and abstract manner. The ITL's Set and Map concepts are defined by a signature and collections of laws or axioms. Those semantical constraints have been validated using automatic law based tests. This gives the library both a well founded formal specification and an unusual thorough test base. The ITL emerged out of real world use cases and is successfully used at Cortex Software GmbH since a couple of years in the production code of various applications. On the boost developer's list it has been proposed in four previews and a review request since May 2008 and has been refactored and refined according to boost standards and suggestions from the list. The ITL is available from the boost vault: http://www.boostpro.com/vault/index.php?action=downloadfile&filename=itl_3_2 _0.zip&directory=Containers Documentation is online available at: http://www.herold-faulhaber.de/boost_itl/doc/libs/itl/doc/html/index.html The current sources are in the sandbox: https://svn.boost.org/svn/boost/sandbox/itl/ ------------------------------------------------ Everybody on this list is invited to participate in this formal review. I hope to see your review of this library, including your vote, and I welcome your participation in the discussions on the Boost mailing list. Please always state in your review, whether you think the library should be accepted as a Boost library. Additionally, please consider giving feedback on the following general topics: - What is your evaluation of the design? - What is your evaluation of the implementation? - What is your evaluation of the documentation? - What is your evaluation of the potential usefulness of the library? - Did you try to use the library? With what compiler? Did you have any problems? - How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? - Are you knowledgeable about the problem domain? Regards Hartmut Review Manager --------------- Meet me at BoostCon www.boostcon.com

9 29

[Boost][Test] Small issue with explicit function initialization
by Sylvain Bougerel 07 Mar '10

07 Mar '10

Hi, I'm not sure if it's an issue or not. But I noticed that the given code does not compile: #define BOOST_TEST_MAIN #include <boost/test/included/unit_test.hpp> template <typename Tp1, typename Tp2> inline Tp2 stupid_cast (const Tp1& arg) { return static_cast<Tp2>(arg); } BOOST_AUTO_TEST_CASE( test_details_key ) { BOOST_CHECK(stupid_cast<float, int>(1.0) == 1); } It give the following error with g++ (GCC) 4.4.3: try.cpp:40:48: error: macro "BOOST_CHECK" passed 2 arguments, but takes just 1 try.cpp: In member function 'void test_details_key::test_method()': try.cpp:40: error: 'BOOST_CHECK' was not declared in this scope While the following does compile (and runs well): #define BOOST_TEST_MAIN #include <boost/test/included/unit_test.hpp> template <typename Tp1, typename Tp2> inline Tp2 stupid_cast (const Tp1& arg) { return static_cast<Tp2>(arg); } BOOST_AUTO_TEST_CASE( test_details_key ) { BOOST_CHECK((stupid_cast<float, int>(1.0) == 1)); // <----- I wrapped it in parenthesis } So I was wondering whether the BOOST_<level> macro (I did check that the others suffer the same problem) are expected to behave in this way, or they are just missing an extra layer of parenthesis around the arguments, or even GCC is at fault, or I'm missing something definitely... Regards, Sylvain

2 1

Re: [boost] [Review] ITL review starts today, February 18th
by Brian Wood 07 Mar '10

07 Mar '10

Joachim Faulhaber writes: > Let me put it this way: > std::set : could be model of itl::Set, if operators were implemented > itl::set : is model of itl::Set > itl::interval_set : is model of itl::Set but implemented via intervals > boost::dynamic_bitset : is almost model of itl::Set but implemented > via arrays of machine words. Joachim and I have previously discussed the names of some of the classes in his library in the context of serialization: *http://preview.tinyurl.com/y86phqg* I don't have plans yet to add support for this library to the C++ Middleware Writer, but I would suggest that you consider where you will be able to come up with serialization support for the library. I believe your options will be to add it yourself with Boost Serialization or go without it. If you stick with the names of some of the classes that you have today, at the very least, I'll put off developing marshalling support for the library. Brian Wood http://webEbenezer.net (651) 251-9384 "Then Samuel took a rock and set it up between Mizpah and Shen. He named it Ebenezer [Rock of Help] and said, 'Until now the L-RD has helped us.'"

2 1

[transact] Handling with user exceptions
by vicente.botet 07 Mar '10

07 Mar '10

Hi, I would like to initiate a discussion on how to manage with user exceptions. Here follows some thougth I'm implementing in Boost.STM. There are two main ways to manage with user exceptions: * exceptions commit transactions - corresponds to the current C++ behavior * exceptions abort on exit - corresponds to rollback The behavior associated to the curent language-like macros is to throw the catched exception. In this case, the exception shouldn't contain references to transaction specific objects. I was wondering if we cannot add a second family of macros that before a user exception leaves the transaction block the transaction is commited. BOOST_TRANSACT_A_ family will abort the transaction on user exception BOOST_TRANSACT_C_ family will commit the transaction on user exception This will allows to explore which both approaches, and see which approach is more usable, or if there is an approach that is better adapted to some particuler contexts. * Exceptions Commit Transactions - How to get this? While trying to commit on destruction we have catched any exception to release the commit_on_destruction variable. commit_on_destruction __comm( __txn ) ; t ry { i f ( false ) ; else / / to for ce a sentence / / t r a n s a c t i o n sentence } catch ( . . . ) { __comm. release ( ) ; throw ; } To make exception commit transactions by default, we should not release the committer. However, we need to avoid exception throw by commit when the transaction has been set as forced to abort or during unwinding exception. commit_on_destruction __comm( __txn ) ; t ry { <sentence > } catch ( . . . ) { i f ( __txn_.forced_to_abort ( ) ) __comm.release ( ) ; else __comm.commit ( ) ; throw ; } We need how to override the default behavior. If we have Exceptions Commit Transactions - we can abort the transaction in two ways: * Explicit try-block to Abort Transactions * Explicitly abort before throw - Explicit try-block to Abort Transactions The user may want the exception abort the transaction while leaving the transaction block. The user must explicitly state that this is the desired behavior by adding a try-catch block as shown below: BOOST_STM_C_TRANSACTION t ry { / / t r a n s a c t i o n block } catch (Ex&) { BOOST_STM_ABORT( ) ; throw ; } BOOST_STM_C_END_TRANSACTION; - Explicitly abort before throw The user may want the transaction to be aborted before throwing an exception. The user may explicitly state that this is the desired either by setting the current transaction as forced to abort, BOOST_STM_ABORT( ) ; throw except ( ) ; or by throwing the exception using the macro : / / . . . BOOST_STM_ABORT_AND_THROW( except ( ) ) ; / / . . . If we have Exceptions Abort on Exit we can commit the transaction as follows: - Explicit try-block to Commit Transactions The user must explicitly state that this is the desired behavior by adding a try-catch block as shown below: BOOST_STM_TRANSACTION t ry { / / t r a n s a c t i o n block } catch (Ex &ex ) { BOOST_STM_COMMIT( ) ; throw ; } BOOST_STM_END_TRANSACTION; boost::exception_ptr error; BOOST_STM_TRANSACTION t ry { / / t r a n s a c t i o n block } catch (Ex &) { error=boost::current_exception(); } BOOST_STM_END_TRANSACTION; if( error) boost::rethrow_exception(error); } Please let me know what do you think? Do you find this useful? Should we provide two families of macros? Best regards, _____________________ Vicente Juan Botet Escribá

2 6

[Review] The review of the ITL library ends today, March 7th
by Hartmut Kaiser 07 Mar '10

07 Mar '10

Hey all, The review of Joachim Faulhabers ITL library ends today, March 7th 2010. Please get your reviews in today or get in contact with me to agree on some offline schedule. Regards Hartmut Review Manager --------------- Meet me at BoostCon www.boostcon.com

1 0

Re: [boost] [transact] transaction language macros (was: Re: [transact] code in sandbox)
by vicente.botet 07 Mar '10

07 Mar '10

Hi, ----- Original Message ----- From: <strasser(a)uni-bremen.de> To: "vicente.botet" <vicente.botet(a)wanadoo.fr> Sent: Saturday, March 06, 2010 3:55 PM Subject: Re: [boost] [transact] transaction language macros (was: Re: [transact] code in sandbox) > > hi again, > > another thing, are you experienced with the various parsing libraries > of boost? No, I have made only some toy examples with Spirit long time ago. > I know that they're not capable of analyzing C++ code, but it seems to > me that the code transformation required for our little language > extension is fairly simple. > > boost has compliant preprocessor, so macros aren't a problem. > the most complicated thing would be to detect if a transaction is in a > user-loop or not, so the grammar would have to be able to read > for/while/... loops and correctly parse c++ scopes. > does anything like that already exist? To do something like that I will use LLVM that gives already this possibility. Of course starting to use LLVM will be not easy, but will open much more possibilities than a specific parsing. Best, Vicente

1 0

Re: [boost] [Boost-users] [Review] ITL review starts today, February 18th
by Joachim Faulhaber 06 Mar '10

06 Mar '10

Hi John, thank you for reviewing the ITL library! 2010/3/3 John Reid <j.reid(a)mail.cryst.bbk.ac.uk>: > Hartmut Kaiser wrote: >> >> The ITL is available from the boost vault: >> >> http://www.boostpro.com/vault/index.php?action=downloadfile&filename=itl_3_2 >> _0.zip&directory=Containers > > I have to say first I have been evaluating the version of ITL called > itl_plus_3_2_1 rather than the version in the boost vault. Perhaps someone > can tell me whether that is a big mistake or not. Using itl_plus_3_2_1 is completely ok. It is a later release than the review version itl_3_2_0. But the differences are marginal. Also itl_plus_3_2_1 contains more than the core library that is submitted for review. But you did not refer to these parts. So everything is fine. >> Please always state in your review, whether you think the library should >> be >> accepted as a Boost library. > > I think it should be accepted subject to the inclusion of an interval tree > implementation. > >> >> - What is your evaluation of the design? > > I suspect that making the open/closedness of an interval a template > parameter would suit more users although I don't have a strong opinion on > this one. There has been a discussion on this point already. http://permalink.gmane.org/gmane.comp.lib.boost.devel/199905 For continuous data types it seems like interval bounds are needed as data member. For intervals of integral types the bound_type can be a static property. I will adapt the design in this point. >> - What is your evaluation of the implementation? > > I would have liked to see interval trees in the implementation. For what > I've needed the library for so far this has not been a problem as most of > the intervals don't overlap. In the future I can see use cases where the > lack of interval trees would make the library impractical. I don't know how > much impact adding an interval tree implementation would have on the > existing interface. I think the current implementation has its value and application. It should not and can not completely be replaced by an implementation based on an interval_tree. This would improve certain use cases but lead to problems in others. I will report on this in more detail. An interval_tree based split_interval_map will be a valuable optimization that should be done as an additional class template. The current implementation is fully functional, correct, useful and efficient in most cases of application. >> - What is your evaluation of the documentation? > > Good. A tutorial would be a welcome addition. Some functions were > undocumented, I'm assuming they're documented in the review version. The "handcrafted" documentation relates to the major interface of overloaded functions and function templates. In order to keep that short, more specific functions are only documented in the part of the documentation that is generated from doxygen comments: http://www.joachim-faulhaber.de/boost_itl/doc/libs/itl/doc/html/interval_te… And yes, there may be few that have been forgotten. Please tell me, which ones you missed specifically. >> - What is your evaluation of the potential usefulness of the library? > > Very useful. It seems to have many applications in several different > domains. > >> - Did you try to use the library? With what compiler? Did you have any >> problems? > > I used gcc 4.4.1 and boost.python to make a python module for most of the > main elements of the library. I used this module successfully in an > application in genomics. However so far I have only had use for the > SplitIntervalMap so I have not used most of the library. > >> - How much effort did you put into your evaluation? A glance? A quick >> reading? In-depth study? > > A reasonable amount - enough to get up to speed and use the library. > >> - Are you knowledgeable about the problem domain? > > Not especially. > Thank you again. Best regards, Joachim

4 24

[BGL] Testing a graph for bipartiteness
by Matthias Walter 06 Mar '10

06 Mar '10

Hi, I'm working on a project where I need to determine whether a given graph is bipartite (possible yielding certificates for the two cases). As such a test can be perfectly implemented via BFS and visitor patterns, I wondered why there is no implementation in the BGL. Is there any reason or am I just to blind to find it? If I'm forced to write my own one, how about submitting it to BGL? best regards Matthias Walter

4 29

[numeric][ublas] trunk testing broken
by K. Noel Belcourt 06 Mar '10

06 Mar '10

Hi, Trunk testing broke with this commit: https://svn.boost.org/trac/boost/changeset/60156 Here's the error message. error: Unable to find file or target named error: 'test_coordinate_matrix_sort.cpp' error: referred from project at error: '../libs/numeric/ublas/test' Could someone please add this missing file or revert the commit? Thanks. -- Noel

3 3

[propertytree] Own storage
by Adam Badura 06 Mar '10

06 Mar '10

Are end users allowed to provide own parsers to populate property tree? For example for the (not yet available) Windows Registry? Or is this discouraged? If not then maybe adding a simple example to the documentation would be a good idea? Adam Badura

2 3

[log] init methods and named parameters
by Michael Caisse 05 Mar '10

05 Mar '10

I've gotten a head start looking at the boost.log library that will be reviewed in a couple weeks. The utility methods utilize boost.parameter's named parameters. For example, boost::log::init_log_to_file. I would like to decide at runtime (via a config file) which set of parameters will listed. For example, rotation_size or rotation_interval or both. It is my first real use of boost.parameter so I may be missing something that is common knowledge. I don't see an easy way to do this. I thought maybe building a fusion sequence of parameters or something like that was the way to go... Looking for guidance. Thanks. michael -- ---------------------------------- Michael Caisse Object Modeling Designs www.objectmodelingdesigns.com

3 8

filesystem utf-8 support?
by Jochen Wilhelmy 05 Mar '10

05 Mar '10

Hi! I wonder if boost::filesystem has support for utf-8. especially for windows this means that all path names have to be converted from utf-16 to utf-8 and back internally by boost::filesystem. for unix-like systems this may not be necessary as the locale can be set to utf-8 but auto-conversion for non-utf-8 locales would still be good. -Jochen

1 0

[boost.atomic] linker error with gcc 4.1.2
by Jamie Allsop 05 Mar '10

05 Mar '10

With gcc 4.1.2 (gcc 4.3.x is fine) I am seeing this linker error: .build/debug/working/SourceOne.o: In function `void boost::detail::atomic::platform_atomic_thread_fence<boost::memory_order>(boost::memory_order)': /thirdparty/boost/boost_1_42/boost/smart_ptr/detail/shared_count.hpp:229: multiple definition of `void boost::detail::atomic::platform_atomic_thread_fence<boost::memory_order>(boost::memory_order)' .build/debug/working/SourceTwo.o: /thirdparty/boost/boost_1_42/boost/atomic/detail/gcc-x86.hpp:63: first defined here Which doesn't make a lot of sense at first glance, but on closer inspection I see that: boost/atomic/detail/base.hpp defines platform_atomic_thread_fence as: template<typename T> static inline void platform_atomic_thread_fence(T order) { /* FIXME: this does not provide sequential consistency, need one global variable for that... */ platform_atomic<int> a; a.exchange(0, order); } and then it is defined as a specialisation in: boost/atomic/detail/gcc-x86.hpp as: template<> void platform_atomic_thread_fence(memory_order order) { switch(order) { case memory_order_seq_cst: full_fence(); case memory_order_acquire: case memory_order_consume: case memory_order_acq_rel: case memory_order_release: __asm__ __volatile__ ("" ::: "memory"); default:; } } Is this a compiler error or should the specialisation be declared as: template<> inline void platform_atomic_thread_fence(memory_order order) (which will work) Suggestions? Jamie

3 4

[type traits] add a set of templates to propagate const etc from one type to another?
by Vasilis Vasaitis 04 Mar '10

04 Mar '10

Hello, I've been looking at the Type Traits library recently, and it looks wonderful overall. However, it's lacking a use case that I end up needing quite often, so I thought I'd suggest it in case the authors and/or other users of the library find it useful. Allow me to explain. So Type Traits has the add_const / remove_const / is_const triplet (and similar for a few other type properties). add_const is great when you always know that you want to add the const, but sometimes you only want to do it conditionally to another type being const. So recently I've ended up using something like this from quite a few places in my code: template<class Source, class Target> struct propagate_const { typedef Target type; }; template<class Source, class Target> struct propagate_const<const Source, Target> { typedef const Target type; }; That is, propagate_const<Source, Target> will only add const to Target if Source is const too. What are the use cases for this? Well, for example recently I was writing an iterator class, and I wanted to avoid duplicating the code for the const_iterator case. Not a big deal, as it turned out, as I could just pass a const type as the template argument and have it behave as the const iterator. The only problem was that I was doing some pointer arithmetic with reinterpret_casts from T* to char* and back (where T is the template argument), so the compiler would complain if T was const. So instead of char I defined this: typedef typename propagate_const<T, char>::type char_type; Of course I could also have done this with a combination of is_const and add_const, but this would probably require more code than the propagate_const definition above. So what do people think? Would it be a useful addition alongside add_* and remove_*? Thanks, Vasilis P.S. Please CC me in your replies, as I've set the mailing lists to not send me emails (similar to not being subscribed). -- Vasilis Vasaitis "A man is well or woe as he thinks himself so."

10 18

command line parameters parser
by Denis Shevchenko 04 Mar '10

04 Mar '10

Hi! Sorry for my English, I am from Russia. Is there any interest in a library which parse command line parameters and call correspond functions/functors? Features: - check type of parameter, - check "value semantic" of parameter, - set necessity of parameter, - maybe set default value for parameter, - some other settings. Example: void help() { std::cout << "This is my help info!" << std::endl; ::exit( 0 ); // Exit after printing help info. } struct config_file { void operator()( const std::string& file ) { // Some work with obtaining file path. } }; void limit( const std::string& some_limit_value ) { // int limit = boost::lexical_cast< int >( some_limit_value ); // ... } int main( int argc, char* argv[] ) { typedef command_line_parameter_parser clp_parser; clp_parser parser; parser.add_parameter( "-h", "--help", help ); // Short and full names, in Unix tradition. // In this case we define parameter with one name and value (it is must be valid path); // Without check_value() obtaining path will not be checked. parser.add_parameter( "--config", config_file, clp_parser::with_value ).check_value( clp_parser::path ); parser.add_parameter( "-l", "--limit", limit ).check_type( clp_parser::integer ); // Is integer? parser.set_value_separator( ':' ); // "--config:/home/file.conf" instead default "--config=/home/file.conf" try { parser.parse( argc, argv ); } catch ( const std::exception& exc ) { std::cerr << exc.what() << std::endl; } ... return 0; } Denis

3 7

[1.39][preprocessor] "preprocessor/wstringize.hpp" not included by "preprocessor.hpp"
by Adam Badura 04 Mar '10

04 Mar '10

It seems that "preprocessor.hpp" includes (through "preprocessor/library.hpp") "preprocessor/stringize.hpp" but not "preprocessor/wstringize.hpp". I don't know whether this occurs in 1.42 as well but I guess it may. Adam Badura

1 0

boost::optional<A,B,...>
by Daniel Larimer 04 Mar '10

04 Mar '10

I have a situation where I have a class that stores two mutually exclusive optional values. This results in double overhead of two bools and twice the "reserved" space. I could opt for a boost::optional<boost::variant<A,B> >, but this would incur extra costs associated with the implementation of boost::variant. Considering the fact that boost::variant<> explicitly guarantees to be always "valid", it seems like it would be reasonable to have boost::optional<A,...> that behaves like boost::variant<>, yet is optimized specifically for allowing "empty" states as well. The boolean could then become the type index where 0 is empty, 1 is A, 2 is B etc. Thoughts? Dan

4 3

[rfc] rcpp
by Ivan Sorokin 04 Mar '10

04 Mar '10

Hello! I have a small library that is intended for convenient and declarative resource wrappers creation. Read Documentation: http://rain.ifmo.ru/~sorokin/rcpp/doc/index.html Main Page: http://rain.ifmo.ru/~sorokin/rcpp/ Although this library is small I think it is useful. I think it is possible to use it in implementations of asio, filesystem and thread. **-- Ivan Sorokin

6 16

Re: [boost] [mpl] Basic mpl sequence question
by Martim Nascimento 04 Mar '10

04 Mar '10

Maybe you forget to add the mpl::find include. #include<boost/mpl/vector.hpp> //here #include <boost/mpl/find.hpp> using namespace boost; typedef mpl::vector<char,short,int,long,float,double> types; typedef mpl::find<types,long>::type long_pos; int main() { }

1 0

Another implementation of properties.
by Germán Diago 04 Mar '10

04 Mar '10

Hello. I've been trying to implement properties for c++0x, for now. I've come up with this solution for now. You need g++ svn to test it. It's a partial implementation, since not every operator is overloaded. Space overhead: - one pointer to the object per property instance. - the pointer to the member functions is shared among every instance of the class, so it's a per-class and not per-instance overhead, which is negligible. Usage: class Person { int getAge() const { .... }; void setAge(int age) { ... }; PROPS_RWPROPERTY(Age); Person() : Age(this) {} }; You can: - declare getters/setters const or nonconst. - getters must have one parameter. - setters must return void. - it has some operators overloaded, but the idea is to overload all of them if the implementation is all right. - the property returns whatever you put in your getter and gets as a parameter what you put in the setter. If you declare the getters and setters to be VIRTUAL, you get virtual behaviour, so you can use virtual properties, even with pure virtual functions, and it will work. Caveats: - Needs c++0x compiler for now. - Not enforced the read-only access for properties for now. I need extended friend declarations for that, and the operator= would be made private with friend class. But for now it's not reinforced. I think this implementation is pretty usable as-is. It's just a matter of extending it. I don't use the offset trick because I think it does not work with classes with virtual members, but I'm not sure. The implementation contains Trivial properties as well, which for now, are the same as fields I think. Implementation: #include <functional> #include <type_traits> #include <iostream> #ifndef _PROPS_PROPERTY_HPP_ #define _PROPS_PROPERTY_HPP_ namespace props { template <class GetterAddress, class SetterAddress> class RWProperty; template <class GetterAddress, class SetterAddress> class ROProperty; template <class PropType> class TROProperty; template <class PropType> class TRWProperty; namespace detail { struct unused {}; template <bool cond, class T = void> struct EnableIf { typedef T type; }; template <class T> struct EnableIf<false, T> {}; template <bool cond, class T = void> struct DisableIf {}; template <class T> struct DisableIf<false, T> { typedef T type; }; template <class ObjectType, class Ret, Ret (ObjectType::*Getter)()> struct WrapperGetter { typedef ObjectType object_t; typedef Ret result_type; Ret (ObjectType::*getter)(); WrapperGetter() : getter(Getter) {} }; template <class ObjectType, class Ret, Ret (ObjectType::*Getter)() const> struct WrapperGetterConst { typedef ObjectType object_t; typedef Ret result_type; Ret (ObjectType::*getter)() const; WrapperGetterConst() : getter(Getter) {} }; template <class ObjectType, class Arg, void (ObjectType::*Setter)(Arg)> struct WrapperSetter { typedef ObjectType object_t; typedef void result_type; typedef Arg argument_type; void (ObjectType::*setter)(Arg); WrapperSetter() : setter(Setter) {} }; template <class ObjectType, class Arg, void (ObjectType::*Setter)(Arg) const> struct WrapperSetterConst { typedef ObjectType object_t; typedef void result_type; typedef Arg argument_type; void (ObjectType::*setter)(Arg) const; WrapperSetterConst() : setter(Setter) {} }; template <class T> struct IsProperty : public std::false_type {}; template <class GetterAddress, class SetterAddress> struct IsProperty<RWProperty<GetterAddress, SetterAddress> > : public std::true_type {}; template <class GetterAddress, class SetterAddress> struct IsProperty<ROProperty<GetterAddress, SetterAddress> > : public std::true_type {}; template <class PropType> struct IsProperty<TRWProperty<PropType> > : public std::true_type {}; template <class PropType> struct IsProperty<TROProperty<PropType> > : public std::true_type {}; template <class T> struct IsConstMemberGetter : public std::false_type {}; template <class Ret, class Object> struct IsConstMemberGetter<Ret (Object::*)() const> : public std::true_type {}; template <class T> struct IsConstMemberSetter : public std::false_type {}; template <class ObjectType, class Arg> struct IsConstMemberSetter<void (ObjectType::*)(Arg) const> : public std::true_type {}; template <class ObjectType, class Ret, Ret (ObjectType::*Getter)()> WrapperGetter<ObjectType, Ret, Getter> deduceWrapperForGetter(); template <class ObjectType, class Ret, Ret (ObjectType::*Getter)() const> WrapperGetterConst<ObjectType, Ret, Getter> deduceWrapperForGetter(); template <class ObjectType, class Arg, void (ObjectType::*Setter)(Arg)> WrapperSetter<ObjectType, Arg, Setter> deduceWrapperForSetter(); template <class ObjectType, class Arg, void (ObjectType::*Setter)(Arg) const> WrapperSetterConst<ObjectType, Arg, Setter> deduceWrapperForSetter(); template <class ObjectType, class Arg> Arg deduceSetterArg(void (ObjectType::*Setter)(Arg) const); template <class ObjectType, class Arg> Arg deduceSetterArg(void (ObjectType::*Setter)(Arg)); template <class ObjectType, class PropType> auto deduceGetterRet(PropType (ObjectType::*Getter)() const, const ObjectType * obj = 0) -> typename EnableIf<IsConstMemberGetter<PropType (ObjectType::*)() const>::value, decltype((obj->*Getter)())>::type; template <class ObjectType, class PropType> auto deduceGetterRet(PropType (ObjectType::*Getter)(), ObjectType * obj = 0) -> typename EnableIf<!IsConstMemberGetter<PropType (ObjectType::*)()>::value, decltype((obj->*Getter)()) >::type; } //namespace detail template <class PropType> class TRWProperty { static_assert(!std::is_reference<PropType>::value, "Property types must not be reference types"); PropType value_; public: typedef typename std::remove_cv<PropType>::type value_type; typedef PropType & GetterReturnType; typedef const PropType & ConstGetterReturnType; /************************Constructors*************************************/ ///Default constructor TRWProperty() = default; ///Construct from other property (rvalue) template <class OtherProp> TRWProperty(OtherProp && other, typename detail::EnableIf<detail::IsProperty<OtherProp>::value>::type * = 0) : value_(std::move(other())) {} ///Construct from other value (rvalue) template <class PropVal> TRWProperty(PropVal && val, typename detail::EnableIf<!detail::IsProperty<PropVal>::value>::type * = 0) : value_(std::move(val)) {} ///Construct from other value (lvalue) template <class PropVal> TRWProperty(const PropVal & value, typename detail::EnableIf<!detail::IsProperty<PropVal>::value>::type * = 0) : value_(value) {} ///Construct from other property (lvalue) template <class OtherProp> TRWProperty(const OtherProp & prop, typename detail::EnableIf<detail::IsProperty<OtherProp>::value>::type * = 0) : value_(prop()) {} //***************************Assignment operators*****************************/ ///Assign from other property (rvalue) template <class OtherProp> typename detail::EnableIf<detail::IsProperty<OtherProp>::value, TRWProperty &>::type operator=(OtherProp && other) { value_ = std::move(other()); return *this; } ///Assign from other value (rvalue) template <class PropValue> typename detail::EnableIf<!detail::IsProperty<PropValue>::value, TRWProperty &>::type operator=(PropValue && val) { value_ = std::move(val); return *this; } ///Assign from other property (lvalue) template <class OtherProp> typename detail::EnableIf<detail::IsProperty<OtherProp>::value, TRWProperty &>::type operator=(const OtherProp & other) { value_ = other(); return *this; } ///Assign from other value (lvalue) template <class PropValue> typename detail::EnableIf<!detail::IsProperty<PropValue>::value, TRWProperty &>::type operator=(const PropValue & val) { value_ = val; return *this; } /***************************Obtain value operators*****************************/ ConstGetterReturnType operator()() const { return value_; } GetterReturnType operator()() { return value_; } /****************************Implicit conversions******************************/ operator ConstGetterReturnType() const { return value_; } operator GetterReturnType() { return value_; } /******************************Arithmetic Operators**********************************/ template <class Prop> typename detail::EnableIf<detail::IsProperty<Prop>::value, TRWProperty&>::type operator+=(const Prop & other) { (*this)() += other(); return *this; } template <class PropValue> typename detail::EnableIf<!detail::IsProperty<PropValue>::value, TRWProperty&>::type operator+=(const PropValue & value) { (*this)() += value; return *this; } TRWProperty & operator++() { ++((*this)()); return *this; } TRWProperty & operator++(int) { ((*this)())++; return *this; } TRWProperty & operator--() { --((*this)()); return *this; } TRWProperty & operator--(int) { ((*this)())--; return *this; } /*****************************Relational operators**************************************/ template <class Prop> typename detail::EnableIf<detail::IsProperty<Prop>::value, bool>::type operator<(const Prop & other) const { return (*this)() < other(); } template <class PropValue> typename detail::EnableIf<!detail::IsProperty<PropValue>::value, bool>::type operator<(const PropValue & value) const { return (*this)() < value; } template <class Prop> typename detail::EnableIf<detail::IsProperty<Prop>::value, bool>::type operator==(const Prop & other) const { return (*this)() == other(); } template <class PropValue> typename detail::EnableIf<!detail::IsProperty<PropValue>::value, bool>::type operator==(const PropValue & value) const { return (*this)() == value; } //******************************Swap*************************** template <class OtherProp> void swap(OtherProp & other) { TRWProperty tmp(std::move(other)); other = std::move(*this); *this = std::move(tmp); } }; template <class PropType> class TROProperty { //FIXME: Make private operator= and friend class the class containing the property static_assert(!std::is_reference<PropType>::value, "Property types must not be reference types"); PropType value_; public: typedef typename std::remove_cv<PropType>::type value_type; typedef PropType & GetterReturnType; typedef const PropType & ConstGetterReturnType; /************************Constructors*************************************/ ///Default constructor TROProperty() = default; ///Construct from other property (rvalue) template <class OtherProp> TROProperty(OtherProp && other, typename detail::EnableIf<detail::IsProperty<OtherProp>::value>::type * = 0) : value_(std::move(other())) {} ///Construct from other value (rvalue) template <class PropVal> TROProperty(PropVal && val, typename detail::EnableIf<!detail::IsProperty<PropVal>::value>::type * = 0) : value_(std::move(val)) {} ///Construct from other value (lvalue) template <class PropVal> TROProperty(const PropVal & value, typename detail::EnableIf<!detail::IsProperty<PropVal>::value>::type * = 0) : value_(value) {} ///Construct from other property (lvalue) template <class OtherProp> TROProperty(const OtherProp & prop, typename detail::EnableIf<detail::IsProperty<OtherProp>::value>::type * = 0) : value_(prop()) {} //***************************Assignment operators*****************************/ ///Assign from other property (rvalue) template <class OtherProp> typename detail::EnableIf<detail::IsProperty<OtherProp>::value, TROProperty &>::type operator=(OtherProp && other) { value_ = std::move(other()); return *this; } ///Assign from other value (rvalue) template <class PropValue> typename detail::EnableIf<!detail::IsProperty<PropValue>::value, TROProperty &>::type operator=(PropValue && val) { value_ = std::move(val); return *this; } ///Assign from other property (lvalue) template <class OtherProp> typename detail::EnableIf<detail::IsProperty<OtherProp>::value, TROProperty &>::type operator=(const OtherProp & other) { value_ = other(); return *this; } ///Assign from other value (lvalue) template <class PropValue> typename detail::EnableIf<!detail::IsProperty<PropValue>::value, TROProperty &>::type operator=(const PropValue & val) { value_ = val; return *this; } /***************************Obtain value operators*****************************/ ConstGetterReturnType operator()() const { return value_; } GetterReturnType operator()() { return value_; } /****************************Implicit conversions******************************/ operator ConstGetterReturnType() const { return value_; } operator GetterReturnType() { return value_; } /******************************Arithmetic Operators**********************************/ template <class Prop> typename detail::EnableIf<detail::IsProperty<Prop>::value, TROProperty&>::type operator+=(const Prop & other) { (*this)() += other(); return *this; } template <class PropValue> typename detail::EnableIf<!detail::IsProperty<PropValue>::value, TROProperty&>::type operator+=(const PropValue & value) { (*this)() += value; return *this; } TROProperty & operator++() { ++((*this)()); return *this; } TROProperty & operator++(int) { ((*this)())++; return *this; } TROProperty & operator--() { --((*this)()); return *this; } TROProperty & operator--(int) { ((*this)())--; return *this; } /*****************************Relational operators**************************************/ template <class Prop> typename detail::EnableIf<detail::IsProperty<Prop>::value, bool>::type operator<(const Prop & other) const { return (*this)() < other(); } template <class PropValue> typename detail::EnableIf<!detail::IsProperty<PropValue>::value, bool>::type operator<(const PropValue & value) const { return (*this)() < value; } template <class Prop> typename detail::EnableIf<detail::IsProperty<Prop>::value, bool>::type operator==(const Prop & other) const { return (*this)() == other(); } template <class PropValue> typename detail::EnableIf<!detail::IsProperty<PropValue>::value, bool>::type operator==(const PropValue & value) const { return (*this)() == value; } //******************************Swap*************************** template <class OtherProp> void swap(OtherProp & other) { TROProperty tmp(std::move(other)); other = std::move(*this); *this = std::move(tmp); } }; //***********************************************Elaborated properties******************************************* template <class GetterAddress, class SetterAddress> class RWProperty { typedef typename GetterAddress::object_t ObjectType; ObjectType * object_; static SetterAddress setter_; static GetterAddress getter_; typedef decltype((object_->*GetterAddress::getter)()) GetterReturnType; typedef const decltype((object_->*GetterAddress::getter)()) ConstGetterReturnType; typedef typename std::remove_cv<GetterReturnType>::type value_type; public: //Constructor without value RWProperty(ObjectType * object) : object_(object) { } //Constructor with value (lvalue) template <class PropValue> RWProperty(ObjectType * object, const PropValue & val, typename detail::EnableIf<!detail::IsProperty<PropValue>::value>::type * = 0) : object_(object) { (object_->*setter_.setter)(val); } //Constructor with other property (lvalue) template <class OtherProp> RWProperty(ObjectType * object, const OtherProp & other, typename detail::EnableIf<detail::IsProperty<OtherProp>::value>::type * = 0) : object_(object) { (object_->*setter_.setter)(other()); } //Constructor with value (rvalue) template <class PropValue> RWProperty(ObjectType * object, PropValue && val, typename detail::EnableIf<!detail::IsProperty<PropValue>::value>::type * = 0) : object_(object) { (object_->*setter_.setter)(std::move(val)); } //Constructor with other property (rvalue) template <class OtherProp> RWProperty(ObjectType * object, OtherProp && other, typename detail::EnableIf<detail::IsProperty<OtherProp>::value>::type * = 0) : object_(object) { (object_->*setter_.setter)(std::move(other())); } ConstGetterReturnType operator()() const { return (object_->*getter_.getter)(); } GetterReturnType operator()() { return (object_->*getter_.getter)(); } operator ConstGetterReturnType() const { (object_->*getter_.getter)(); } operator GetterReturnType() { return (object_->*getter_.getter)(); } ///Assign from other property (rvalue) template <class OtherProp> typename detail::EnableIf<detail::IsProperty<OtherProp>::value, RWProperty &>::type operator=(OtherProp && other) { (object_->*setter_.setter)(std::move(other())); return *this; } ///Assign from other value (rvalue) template <class PropValue> typename detail::EnableIf<!detail::IsProperty<PropValue>::value, RWProperty &>::type operator=(PropValue && val) { (object_->*setter_.setter)(std::move(val)); return *this; } ///Assign from other property (lvalue) template <class OtherProp> typename detail::EnableIf<detail::IsProperty<OtherProp>::value, RWProperty &>::type operator=(const OtherProp & other) { (object_->*setter_.setter)(other()); return *this; } ///Assign from other value (lvalue) template <class PropValue> typename detail::EnableIf<!detail::IsProperty<PropValue>::value, RWProperty &>::type operator=(const PropValue & val) { (object_->*setter_.setter)(val); return *this; } /******************************Arithmetic Operators**********************************/ template <class Prop> typename detail::EnableIf<detail::IsProperty<Prop>::value, RWProperty&>::type operator+=(const Prop & other) { auto res = (*this)() + other(); (object_->*setter_.setter)(res); return *this; } template <class PropValue> typename detail::EnableIf<!detail::IsProperty<PropValue>::value, RWProperty&>::type operator+=(const PropValue & value) { auto res = (*this)() + value; (object_->*setter_.setter)(res); return *this; } RWProperty & operator++() { auto val = (*this)() + 1; (object_->*setter_.setter)(val); return *this; } RWProperty & operator++(int) { ++(*this); return *this; } RWProperty & operator--() { auto val = (*this)() - 1; (object_->*setter_.setter)(val); return *this; } RWProperty & operator--(int) { --(*this); return *this; } /*****************************Relational operators**************************************/ template <class Prop> typename detail::EnableIf<detail::IsProperty<Prop>::value, bool>::type operator<(const Prop & other) const { return (*this)() < other(); } template <class PropValue> typename detail::EnableIf<!detail::IsProperty<PropValue>::value, bool>::type operator<(const PropValue & value) const { return (*this)() < value; } template <class Prop> typename detail::EnableIf<detail::IsProperty<Prop>::value, bool>::type operator==(const Prop & other) const { return (*this)() == other(); } template <class PropValue> typename detail::EnableIf<!detail::IsProperty<PropValue>::value, bool>::type operator==(const PropValue & value) const { return (*this)() == value; } //******************************Swap*************************** template <class OtherProp> void swap(OtherProp & other) { value_type tmp(std::move(other())); other = std::move(*this); *this = std::move(tmp); } }; template <class GetterAddress, class SetterAddress> GetterAddress RWProperty<GetterAddress, SetterAddress>::getter_; template <class GetterAddress, class SetterAddress> SetterAddress RWProperty<GetterAddress, SetterAddress>::setter_; //***********************************************Elaborated properties******************************************* template <class GetterAddress, class SetterAddress> class ROProperty { typedef typename GetterAddress::object_t ObjectType; ObjectType * object_; static SetterAddress setter_; static GetterAddress getter_; typedef decltype((object_->*GetterAddress::getter)()) GetterReturnType; typedef const decltype((object_->*GetterAddress::getter)()) ConstGetterReturnType; typedef typename std::remove_cv<GetterReturnType>::type value_type; public: //Constructor without value ROProperty(ObjectType * object) : object_(object) { } //Constructor with value (lvalue) template <class PropValue> ROProperty(ObjectType * object, const PropValue & val, typename detail::EnableIf<!detail::IsProperty<PropValue>::value>::type * = 0) : object_(object) { (object_->*setter_.setter)(val); } //Constructor with other property (lvalue) template <class OtherProp> ROProperty(ObjectType * object, const OtherProp & other, typename detail::EnableIf<detail::IsProperty<OtherProp>::value>::type * = 0) : object_(object) { (object_->*setter_.setter)(other()); } //Constructor with value (rvalue) template <class PropValue> ROProperty(ObjectType * object, PropValue && val, typename detail::EnableIf<!detail::IsProperty<PropValue>::value>::type * = 0) : object_(object) { (object_->*setter_.setter)(std::move(val)); } //Constructor with other property (rvalue) template <class OtherProp> ROProperty(ObjectType * object, OtherProp && other, typename detail::EnableIf<detail::IsProperty<OtherProp>::value>::type * = 0) : object_(object) { (object_->*setter_.setter)(std::move(other())); } ConstGetterReturnType operator()() const { return (object_->*getter_.getter)(); } GetterReturnType operator()() { return (object_->*getter_.getter)(); } operator ConstGetterReturnType() const { (object_->*getter_.getter)(); } operator GetterReturnType() { return (object_->*getter_.getter)(); } ///Assign from other property (rvalue) template <class OtherProp> typename detail::EnableIf<detail::IsProperty<OtherProp>::value, ROProperty &>::type operator=(OtherProp && other) { (object_->*setter_.setter)(std::move(other())); return *this; } ///Assign from other value (rvalue) template <class PropValue> typename detail::EnableIf<!detail::IsProperty<PropValue>::value, ROProperty &>::type operator=(PropValue && val) { (object_->*setter_.setter)(std::move(val)); return *this; } ///Assign from other property (lvalue) template <class OtherProp> typename detail::EnableIf<detail::IsProperty<OtherProp>::value, ROProperty &>::type operator=(const OtherProp & other) { (object_->*setter_.setter)(other()); return *this; } ///Assign from other value (lvalue) template <class PropValue> typename detail::EnableIf<!detail::IsProperty<PropValue>::value, ROProperty &>::type operator=(const PropValue & val) { (object_->*setter_.setter)(val); return *this; } /******************************Arithmetic Operators**********************************/ template <class Prop> typename detail::EnableIf<detail::IsProperty<Prop>::value, ROProperty&>::type operator+=(const Prop & other) { auto res = (*this)() + other(); (object_->*setter_.setter)(res); return *this; } template <class PropValue> typename detail::EnableIf<!detail::IsProperty<PropValue>::value, ROProperty&>::type operator+=(const PropValue & value) { auto res = (*this)() + value; (object_->*setter_.setter)(res); return *this; } ROProperty & operator++() { auto val = (*this)() + 1; (object_->*setter_.setter)(val); return *this; } ROProperty & operator++(int) { ++(*this); return *this; } ROProperty & operator--() { auto val = (*this)() - 1; (object_->*setter_.setter)(val); return *this; } ROProperty & operator--(int) { --(*this); return *this; } /*****************************Relational operators**************************************/ template <class Prop> typename detail::EnableIf<detail::IsProperty<Prop>::value, bool>::type operator<(const Prop & other) const { return (*this)() < other(); } template <class PropValue> typename detail::EnableIf<!detail::IsProperty<PropValue>::value, bool>::type operator<(const PropValue & value) const { return (*this)() < value; } template <class Prop> typename detail::EnableIf<detail::IsProperty<Prop>::value, bool>::type operator==(const Prop & other) const { return (*this)() == other(); } template <class PropValue> typename detail::EnableIf<!detail::IsProperty<PropValue>::value, bool>::type operator==(const PropValue & value) const { return (*this)() == value; } //******************************Swap*************************** template <class OtherProp> void swap(OtherProp & other) { value_type tmp(std::move(other())); other = std::move(*this); *this = std::move(tmp); } }; template <class GetterAddress, class SetterAddress> GetterAddress ROProperty<GetterAddress, SetterAddress>::getter_; template <class GetterAddress, class SetterAddress> SetterAddress ROProperty<GetterAddress, SetterAddress>::setter_; } //namespace props #define PROPS_RWPROPERTY(propname) \ ::props::RWProperty< \ decltype(::props::detail::deduceWrapperForGetter<ClassName, \ decltype(::props::detail::deduceGetterRet(&ClassName::get##propname)), \ &ClassName::get##propname>()), \ decltype(::props::detail::deduceWrapperForSetter<ClassName, \ decltype(::props::detail::deduceSetterArg(&ClassName::set##propname)), \ &ClassName::set##propname>())> propname #define PROPS_ROPROPERTY(propname) \ ::props::ROProperty< \ decltype(::props::detail::deduceWrapperForGetter<ClassName, \ decltype(::props::detail::deduceGetterRet(&ClassName::get##propname)), \ &ClassName::get##propname>()), \ decltype(::props::detail::deduceWrapperForSetter<ClassName, \ decltype(::props::detail::deduceSetterArg(&ClassName::set##propname)), \ &ClassName::set##propname>())> propname #endif

6 6

[mpl] Basic mpl sequence question
by Michael Robinson 04 Mar '10

04 Mar '10

Hi, I'm a newbie with mpl and I'm trying to execute some example code from the book "C++ Template Metaprogramming", by Abrahams and Gurtovoy: >From section 5.2, p. 78, Sequences and Algorithms: I wrote this code: // // mpltest.C // #include<boost/mpl/vector.hpp> using namespace boost; typedef mpl::vector<char,short,int,long,float,double> types; typedef mpl::find<types,long>::type long_pos; int main() { } And I get this compiler error on the mpl::find line: $ g++ mpltest.C -ompltest mpltest.C:10: error: expected initializer before ‘<’ token Can you tell me what I'm doing wrong? Thank you, Mike FYI/IYC: $ g++ --version g++ (GCC) 4.4.1 20090725 (Red Hat 4.4.1-2) Copyright (C) 2009 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. ____________________________________________________________ Get Free Email with Video Mail & Video Chat! http://www.netzero.net/freeemail?refcd=NZTAGOUT1FREM0210

2 1

[Filesystem V3] Filesystem Version 3 beta 1 available for download and comment
by Beman Dawes 03 Mar '10

03 Mar '10

The first beta release of Boost.Filesystem Version 3 is now available. The documentation can be viewed at http://mysite.verizon.net/beman/v3/index.htm Important differences from the prior version: http://mysite.verizon.net/beman/v3/v3.html The beta can be downloaded from the Boost vault. See http://www.boostpro.com/vault/index.php?&direction=0&order=&directory=Files… Installing the beta is described at http://mysite.verizon.net/beman/v3/install_distro.html I'm concerned about breaking existing code. While some workarounds have been provided already, I'd open to further suggestions as to how to mitigate code breakage. The tentative plan for integrating V3 into the boost release cycle involves several steps: * For the first boost release cycle, ship V2 as the default, but V3 is present and can be activated by users. * For an additional boost release cycle, ship V3 as the default, but V2 is present (but deprecated) and can be activated by users. * For the following boost release cycle, V2 is removed and no longer supported. The plan is to go through as many beta cycles as needed to reach stability. Although quite a bit of testing has already been done, this is definitely beta software that isn't ready yet for production use. Any comments appreciated. --Beman

10 23

[range] resulting range type
by Andrey Torba 03 Mar '10

03 Mar '10

Hi All, When i implement range based algorithms i always have to write `boost::iterator_range<typename boost::range_iterator<R>::type>'. It is pretty annoying. i.e.: template<class R> boost::iterator_range<typename boost::range_iterator<R>::type> Algo(R& r); I would like to have special metafunction in Boost.Range for such cases to make code more cleaner: template<class R> typename boost::make_range<R>::type Algo(R& r); What do you think? -- Regards, Andrey

3 3

[graph] gcc 3.4 & 4.0 currently broken
by Ralf W. Grosse-Kunstleve 03 Mar '10

03 Mar '10

boost svn trunk rev 60079 broke our gcc 3.4 and 4.0 builds (various platforms). The problem is line 52 in boost/graph/two_bit_color_map.hpp BOOST_STATIC_ASSERT(elements_per_char > 0); It fails with (gcc 3.4 in this case): % g++ -o boost/libs/python/src/object/inheritance.o -c -DBOOST_PYTHON_MAX_BASES=2 -DBOOST_PYTHON_SOURCE -DBOOST_PYTHON_BOOL_INT_STRICT -fPIC -fno-strict-aliasing -w -DNDEBUG -O3 -ffast-math -ftrapping-math -DBOOST_ALL_NO_LIB -DBOOST_DISABLE_THREADS -I/net/chevy/raid1/rwgk/hot/boost -I/usr/include/python2.3 /net/chevy/raid1/rwgk/hot/boost/libs/python/src/object/inheritance.cpp In file included from /net/chevy/raid1/rwgk/hot/boost/boost/graph/breadth_first_search.hpp:26, from /net/chevy/raid1/rwgk/hot/boost/libs/python/src/object/inheritance.cpp:7: /net/chevy/raid1/rwgk/hot/boost/boost/graph/two_bit_color_map.hpp:52: error: non-constant `(((int)boost::two_bit_color_map<IndexMap>::elements_per_char) > 0)' cannot be used as template argument /net/chevy/raid1/rwgk/hot/boost/boost/graph/two_bit_color_map.hpp:52: error: `value' is not a member of `<declaration error>' Commenting out line 52 resolves the error. I printed the value of elements_per_char and it appears to be correct (4). There is no problem with gcc 3.2 and gcc 4.1 through 4.4. Maybe a BOOST_WORKAROUND to disable the static assert for 3.4 and 4.0? Ralf

2 3

[uuid] basic_random_generator doesn't produce a fully randomized uuid when sizeof(unsigned long) == 4
by Sylvester-Bradley, Gareth 03 Mar '10

03 Mar '10

Hi Andy, I wonder if the following is a flaw in basic_random_generator<> (boost/uuid/uuid_generators.hpp, line 366-374)? On many platforms sizeof(unsigned long) == 4. This means that the first 8 bytes of the uuid are populated with random data, but in my tests the remaining 8 bytes are populated with repeated data, and then only by relying on the undefined behaviour of >> when its "right operand is greater than or equal to the length in bits of the promoted left operand." For example, try the following test program with a Win32 build by Visual C++ 9.0 - #include <iostreams> #include <boost/uuid/uuid_generators.hpp> #include <boost/uuid/uuid_io.hpp> int main( int, char*[] ) { std::cout << boost::uuids::random_generator()() << std::endl; return 0; } This produced for me: f1633d75-ee94-47b9-ae94-37b9ee9437b9 Or wrapped to show the problem: f1633d75- ee94-47b9- ae94-37b9 ee94 37b9 Is 8 bytes of randomness enough, or is this a mistake? Best regards, Gareth ************************************************************************ The information contained in this message or any of its attachments may be confidential and is intended for the exclusive use of the addressee(s). Any disclosure, reproduction, distribution or other dissemination or use of this communication is strictly prohibited without the express permission of the sender. The views expressed in this email are those of the individual and not necessarily those of Sony or Sony affiliated companies. Sony email is for business use only. This email and any response may be monitored by Sony to be in compliance with Sony's global policies and standards

4 4

Boost.Log formal review upcoming
by Vladimir Prus 03 Mar '10

03 Mar '10

Boosters, the formal review of the Boost.Log library, written by Andrey Semashev, will start in a week from now, on March 8, 2010 and will run through March 17, 2010. The documentation for the current version is available at: http://boost-log.sourceforge.net The downloads at at: http://sourceforge.net/projects/boost-log Because the library is relatively big and important, you might want to take a look in advance, without waiting for the formal review. Please note that reports of real-world usage will be particularly appreciated -- even if you don't have the time to to do everything formal review checklist requires please still report your experiences. To clarify timelines, the formal reviews are accepted from 23:59, March 7, PST = 2:59, March 8, EST = 7:59 March 8, GMT = 10:59, March 8 MSK until 23:59, March 17, PST = 2:59, March 18, EST = 7:59 March 18, GMT = 10:59, March 18 MSK Reviews submitted outside of this frame are not guaranteed to be processed. Thanks, Volodya

9 21

Boost.Coroutine
by Daniel Larimer 03 Mar '10

03 Mar '10

I am attempting to use boost.coroutine; however, it is not behaving for me. Perhaps someone could shed some light? Here is what happens: 1 start coroutine A 2 do some work.... 3 my_wait_for_value() 4 future<R> f(self); 5 callback = make_callback(f); 6 r = do_wait( f ) 7 boost::coroutines::wait( f ) // blocks and the coroutine exits , goto A 8 return *f; 9 print( "here" ) 10 return r; 11 do some more work A start coroutine B B do some work C callback_from_coroutine_A ( R ) // goto line 8 D .... back to line 8 8 r = *f; // got the right future value 9 print("here") 10 return r; 11 ????? After returning r on line 10, I should end up back on line 11, but instead end up on line D. I clearly setup the future, waited, started another coroutine, set the value of the future, returned 2 levels of the stack, but the 3rd level dumped me off back in a different coroutine. Running on Mac OS X 10.6. Single threaded code. Dan

1 1

the best possible c++ properties (implementation).
by Germán Diago 02 Mar '10

02 Mar '10

Hello. I've been trying hard to implement the best possible properties sytem in c++ (version 0x). For now, I'm quite satisfied with the result, but it can be improved a little. The properties are implemented in a header called (surprisingly!) Property.hpp Classes: template TROProperty and TRWProperty for trivial properties, which are those which you can use very straightforward without defining setters or getters and it stores the property value inside. templates RWProperty and ROProperty, for which you need to define a storage (if needed) and getters and setters. FEATURES: - You can define a getter as a function that returns *ANYTHING* and it will deduce parameters, constness and everything it needs. - You can define a setter as a function that returns void and takes one parameter. The deduction machinery will do the rest. So, for trivial properties there is little to explain: class Person { public: TROProperty<unsigned int> Age; Person(int age) : Age(age) {} }; int main(int argc, char * argv[]) { Person p(26); cout << p.Age << endl; } For elaborated properties, you have freedom in defining the get and set functions, as long as the get function gets just one parameter and the set function sets one parameter and returns void. The usage of elaborated properties is done through a macro: class Agenda { typedef Agenda ClassName; //Needed for elaborated properties. vector<Person> persons_; Person * getCurrentPerson() { return persons_[Position]; } public: TrivialProperty<int> Position; PROP_ROPROPERTY(CurrentPerson); .... Agenda() : PROP_PROPERTY_INIT(CurrentPerson) {}; }; And now it's ready to be used. For now the features are: -Implicit conversion to the underlying type. -Operator overloading (just a sample of the possible operators, just implemented operator++ and some others) -Comparison operators... -Construction assignment, etc from any other property that has a convertible type or from a data type that makes sense. - Move and copy construction where it makes sense. - Compare, for example, a Property<int> to an int or another property with a convertible value to a Property<int>. If it makes sense, it must work. The same for any other operator. - You can obtain the underlying type for a property through operator(), which makes sense in some contexts. For example, suppose you have a class Person with properties Name, SurName and Age and a class Agenda with a property CurrentPerson which returns a pointer to a Person. You can do like this: string name = agenda.CurrentPerson().Name; you can assign Name to a string or any other property that accepts a string (untested but you could). But you don't need operator() when implicit conversion takes place. personsbyage_[aperson.Age] //No need for operator(), implicit conversion Caveats: ROProperty TROProperty I cannot enforce a private operator= because for that I need a workaround I don't know of or extended friend declarations, which are part of c++0x. So for now, these properties are exactly the same as their writeable counterparts without read-only enforcement. In the implementation part, for elaborated properties I have a template like this: template <class Getter, class Setter> class RWProperty; The same goes for ROProperty. Just with that and the macro to ease the writing of properties, you can get a property. These properties must be constructed with the this pointer AND the pointer to member functions. I'm experimenting (but I can't find a way to do it) with something like this: template <class Getter, class Setter, Getter, Setter> class RWProperty; so that the construction of properties wouldn't need the pointers, because they would be passed as template parameters. But inside the template I have an ambiguity problem. Getter and Setter are pointer to member function types and Getter and Setter parameters are the addresses. For now I've found the properties very usable. The only caveats are the enforcement of operator= and the passing of pointer to members as part of initialization. If I can solve those, we can get a good properties implementation of properties and the initialization of elaborated properties would be just with the this pointer (and a value if you want to initialize with a value). This is a work in progress. For now I've used c++0x, but I think I can use BOOST_TYPEOF (maybe) and some other things in order to translate it to current c++. The code is attached. It's an (unfinished) miniapplication of an Agenda made in gtkmm compiled under g++ 4.5 svn. Take a look at the Property.hpp and the application and tell me what you think. I would like to be able to pass pointer to member functions as template arguments in order to avoid initialization of pointers as parameters. compile with: g++ -std=c++0x `pkg-config gtkmm-2.4 --libs --cflags` Person.cpp Agenda.cpp Window.cpp main.cpp -o Agenda You can just add people with "Añadir" Button and traverse with < and > button. It does not do anything special, it's just to test properties.

9 14

Boost
by Enrique Nieloud 02 Mar '10

02 Mar '10

Hi, I just wanted to report that the following two links are broken: boost/gil/extension/numeric/sampler.hpp boost/gil/extension/numeric/resample.hpp In the file: http://www.boost.org/doc/libs/1_42_0/libs/gil/example/resize.cpp thanks, - Enrique

3 2

[iostreams][patch] position_to_offset() is broken for Microsoft Visual C++/Dinkumware
by Sylvester-Bradley, Gareth 02 Mar '10

02 Mar '10

The recent work on Boost.Iostreams by Richard Smith and Daniel James has really improved this library. Thanks guys; this kind of maintenance is really appreciated. I have found a bug in position_to_offset() on Microsoft Visual C++/Dinkumware demonstrated by the following test app - #include <iostream> #include <boost/iostreams/positioning.hpp> int main( int, char*[] ) { const boost::int64_t twoGB = 2 << 30; std::streampos pos = boost::iostreams::offset_to_position( twoGB ); pos -= 2; if ( twoGB - 2 != boost::iostreams::position_to_offset( pos ) ) { std::cout << "Failed!" << std::endl; return -1; } return 0; } This has the potential to affect many parts of Boost.Iostreams but in particular it means the "small seeks optimization" in indirect_streambuf.hpp is broken. I believe this is resolved by the following patch to boost/iostreams/positioning.hpp. 105,106c105,106 < static_cast<stream_offset>(static_cast<std::streamoff>(pos)) - < static_cast<stream_offset>(_FPOSOFF(streampos_to_fpos_t(pos))); --- > static_cast<stream_offset>(static_cast<std::streamoff>(pos) - > _FPOSOFF(streampos_to_fpos_t(pos))); Raised on Trac: https://svn.boost.org/trac/boost/ticket/3969 Best regards, Gareth ************************************************************************ The information contained in this message or any of its attachments may be confidential and is intended for the exclusive use of the addressee(s). Any disclosure, reproduction, distribution or other dissemination or use of this communication is strictly prohibited without the express permission of the sender. The views expressed in this email are those of the individual and not necessarily those of Sony or Sony affiliated companies. Sony email is for business use only. This email and any response may be monitored by Sony to be in compliance with Sony's global policies and standards

1 0

Boost_Test: Initialize fixture only once
by Dmytro Ovdiienko 02 Mar '10

02 Mar '10

Hello All, I have a question about boost test. Please help. I have set of test_suites. Every test_suite consists of a bunch of test_cases. Every test case should be initialized before execution. So, I created Fixture for every test_suite. The problem is Fixture initialization takes a lot of time and boost creates it for every test_case (not for every test_suite) How to solve this? Best regards. Dima

3 5

[iostreams] array and gzip_decompressor
by Nikolay Mladenov 01 Mar '10

01 Mar '10

Recently I came back to a source written some time ago, that was running then but it is not compiling now. the failing snippet is: typedef boost::iostreams::composite<boost::iostreams::gzip_decompressor, boost::iostreams::array_source> array_gzip_decompressor; boost::iostreams::gzip_decompressor filter; boost::iostreams::array_source source(&_storage[0], _storage.size()); array_gzip_decompressor dev(filter,source); boost::iostreams::stream_buffer<array_gzip_decompressor> ibuf(dev); the error is: > boost\iostreams\read.hpp(191) : error C2039: 'putback' : is not a member of 'boost::iostreams::detail::direct_adapter<Direct>' > with [ Direct=boost::iostreams::array_source ] It seems to me that gzip_decompressor requires peekable source, but array_source is not peekable. Is there another way I should be creating gzipped stream into memory? Or maybe the arrays could be made peekable? Thanks in advance, Nikolay Mladenov

3 5

boost::optional<void>
by Daniel Larimer 01 Mar '10

01 Mar '10

I am writing some generic code and would like to handle "all values" the same way; however, I keep running into the problem of return void return types that need "special treatment". There is nothing I can do about it most of the time except template specialization. That said, it would be helpful if boost::optional<void> could have some sensible default implementation where it acts more or less like a boolean. As it is, I will probably provide my own specialization of boost::optional to simplify my templates. Any thoughts on this? Dan

4 4

[ITL][Review] A late mini review
by Thomas Klimpel 01 Mar '10

01 Mar '10

> Please always state in your review, whether you think the > library should be accepted as a Boost library. ITL should be accepted as a Boost library. > - What is your evaluation of the design? I haven't spend sufficient time reviewing the library to be able to judge the design. At least, I haven't seen any obvious flaws during my short review. > - What is your evaluation of the implementation? I took a cursory look at all source (header) files, and they look nicely written. I took a cursory look at the directory structure, to verify that it follows boost conventions. It does so in general, but I was surprised to find a "libs/itl/build" folder, since I "know" that ITL is a headers only library. The content of the build folder also didn't make me happy (it's extremely "unportable"), but this is a completely different topic that has nothing to do with this specific library. The template meta programming in boost/itl/type_traits/* could follow MPL conventions more closely. > - What is your evaluation of the documentation? The documentation is nicely written. However, please don't invent new words like "aggrovering" or "unon". Please also try to avoid changing the meaning of existing words like "neutron". > - What is your evaluation of the potential usefulness of the library? The need to work with "interval sets" arises sufficiently frequently in "time based" and "geometry based" problem domains to warrant a library dedicated especially to this problem domain. (In my review of Boost.Polygon, I pointed out that interval set concepts were missing.) I have to admit that I haven't spend sufficient time evaluating ITL to be able to judge whether ITL is able to handle all these needs. > - Did you try to use the library? With what compiler? Did you have any problems? No, I didn't try to use the library. > - How much effort did you put into your evaluation? > A glance? A quick reading? In-depth study? Some month ago, I read through the documentation just for the pleasure it gave me, pondered a bit about the concept and looked at the BoostCon2009 slide show. I was certainly planning to do a proper review during the review period, but I was (and still am) occupied with other things. What I've done now while writing this review was just a glance. > - Are you knowledgeable about the problem domain? This is not important in this case, since I haven't spend enough time for the review anyway. Regards, Thomas P.S.: As I guessed from recent experience, the review period has just been extended. However, I decided to submit this mini review nevertheless. I may have a look at "I have to admit that I haven't spend sufficient time evaluating ITL to be able to judge whether ITL is able to handle all these needs." with respect to the issue raised by Phil Endecott in http://lists.boost.org/Archives/boost/2010/02/162198.php (and write about it in case I can make up my own opinion), because this seems to be an interesting question. Even so I want to thank Phil Endecott for his courage to bring up this issue, and I guess that he is right (in a certain sense), I think it is wiser to base my review only on my personal experiences and not on my judgment of whether Phil is right or wrong with respect to this issue.

2 1

[numeric][intervall] msvc_rounding_control.hpp broken in 64 bit build.
by Juergen Hunold 01 Mar '10

01 Mar '10

Hi ! boost/numeric/interval/detail/msvc_rounding_control.hpp does not compile in x64 (64bit) build with (at least) msvc-9 The offending commit is: ------------------------------------------------------------------------ r59350 | marshall | 2010-01-29 19:01:34 +0100 (Fri, 29 Jan 2010) | 1 line Applied patches to fix #2512 and #2513 ------------------------------------------------------------------------ This does not show up in regression test because we don't have a test runner running a 64bit version of msvc. The compiler bails out on the x86 inline assembler introduced in that commit when running in 64bit mode. The simple patch is to fall back to the old behaviour using "rint" for target "x64": Index: msvc_rounding_control.hpp =================================================================== --- msvc_rounding_control.hpp (revision 59697) +++ msvc_rounding_control.hpp (working copy) @@ -25,7 +25,7 @@ namespace interval_lib { namespace detail { -#if BOOST_MSVC < 1400 +#if BOOST_MSVC < 1400 || defined(WIN64) extern "C" { double rint(double); } #else inline double rint(double x) I can apply this if necessary. Tested with msvc-9.0 I have not looked into the referenced tickets. Any (better) ideas ? 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 !

2 1

ptr_container move support
by Zachary Turner 01 Mar '10

01 Mar '10

The collections in ptr_container don't seem to support move constructors. All the recent compilers support r-value refs, has there been any discussion of adding support for this? Zach

2 1

[Serialization] extended_type_info.hpp
by fab 01 Mar '10

01 Mar '10

Hi, With boost 1.42.0, when I use BOOST_CLASS_EXPORT, I always need to include extended_type_info.hpp to resolve this error : xxx.hpp:153: error: 'guid_defined' is not a template xxx.hpp:153: error: explicit specialization of non-template 'boost::serialization::guid_defined' xxx.hpp:153: error: expected initializer before '<' token xxx.hpp:153: warning: 'boost::archive::detail::<unnamed>::init_guid<MyClass>::g' defined but not used Maybe extended_type_info.hpp can be included in export.hpp ? Fabien Castan

4 5