- Boost - lists.boost.org

[proto] RValue reference support?
by John Maddock 12 Aug '11

12 Aug '11

Does proto have any support for rvalue references in terminals? I'm thinking that if you know that you're assigning an expression involving an rvalue-reference as a terminal, then there are some optimizations that can be performed that aren't otherwise possible. Thanks, John.

5 11

[interprocess] detail/move.hpp macros conflict with boost/move/move.hpp
by Daniel Larimer 11 Aug '11

11 Aug '11

I am attempting to include my own <boost/move/move.hpp> header, but the macros conflict with <boost/interprocess/detail/move.hpp>. It would seem to me that boost interprocess should 'namespace' the macros like it did the types so that when boost/move is included there are no conflicts. When will Boost.Move be included in an official release? Dan

1 0

[tti] Changes will go on Boost trunk
by Edward Diener 11 Aug '11

11 Aug '11

For interested parties, I have put TTI on the Boost trunk and will be making changes there in getting TTI ready for a Boost release. I will keep the reviewed copy in the sandbox until TTI is officially part of a Boost release, after which I will remove the sandbox version.

1 0

[tti] compiler error: shadows template param `class T`
by Lorenzo Caminiti 11 Aug '11

11 Aug '11

Hello, The TTI library macros expand to code that uses naive template parameter names like "T", "F", "U", etc. The library implementation should be changed to use library reserved names to avoid clashing with user template parameter names. For example, the library use a name like boost_tti_aux_T (or even better BOOST_PP_CAT(boost_tti_aux_T_, __LINE__)) instead of T and state in the documentation that any name prefixed by boost_tti_aux (in any namespace) is reserved for the library implementation. The same should be done for any other implementation symbol defined by the TTI library. This is an issue if the macros are expanded for example within a class (which is and should be possible after changing them not to expand in the boost::tti namespace). For example, assuming BOOST_TTI_HAS_COMP_MEMBER_FUNCTION is fixed not to expand in boost::tti then the following: template< typename T > struct myvector { BOOST_TTI_HAS_COMP_MEMBER_FUNCTION_TRAIT(has_push_back, push_back) // expand to code using a template parameter naively named T ... }; Will generate a compiler error on GCC "error: shadows template param class T". --Lorenzo

3 3

[containers review] A reminder that the containers review ends tomorrow
by John Maddock 11 Aug '11

11 Aug '11

Just a quick reminder that the containers lib review ends tomorrow - there have been lots of good comments, but not so many reviews - so now's your chance ;-) If there are any reviews pending that are likely to be late please let me know so we can extend the review period. Documentation from the library may be viewed online here: http://svn.boost.org/svn/boost/sandbox/move/libs/container/doc/html/index.h… The source may be accessed from the "move" directory of the sandbox SVN or downloaded from http://www.drivehq.com/web/igaztanaga/boost_container.zip. Note that this download contains a copy of the accepted, but not yet release, Boost.Move library - extract the zip over a copy of Boost-1.47 to get a full working copy. Regards, John.

1 0

[Autosave] Re: [math][accumulators] Empirical distribution function
by Simon West 11 Aug '11

11 Aug '11

Hi, On Sun, June 19, 2011 22:36, er wrote: > Hope this can serve as a basis for a conversation: > > > https://svn.boost.org/svn/boost/sandbox/acc_ecdf/ > I'm assisting Eric with the maintenance of Accumulators. I've had a look through the code at the above link, and would like to offer the following comments (if I have misunderstood anything, please let me know). My basic concern with the code is that a map is used to store the counts of data-points that have been added (the map keys are the data-points, the map values are the counts). In real-world floating point data it is rare for two data-points to be exactly the same, so in practice the map would have a single key-value pair for each data-point q_i, of the form (key=q_i,value=1). This is inefficient, because all the key values will be 1. Also, the memory usage will grow linearly with the number of data-points accumulated, which doesn't seem to be in keeping with the spirit of the Accumulators library. For these reasons, I'm not convinced that the code should be added to the library in its current state. Simon.

3 2

[tti] getting write access to Boost trunk
by Edward Diener 11 Aug '11

11 Aug '11

I sent a message a few days ago to the Boost moderators at boost-owner(a)lists.boost.org to get write access to the Boost trunk so I could work on my TTI library there, since it has been accepted into Boost, but I have not received any response. Is anybody at home ? Edward Diener

2 1

[move] [variant] Some problems with VC++10
by Antony Polukhin 10 Aug '11

10 Aug '11

There are some problems with VC10 libraries and move implementations in Boost,Variant and Boost.Move. The problem is that VC10 uses move() in it's STL implementation without directly specifying namespace. That leads to ambiguity, when VC10 containers are used with boost classes. I can not exactly reproduce the bug, because I have no VC at home, but thats how it looked like: std::vector< my_variant > vec; vec.push_back( my_variant(some_data) ); // ERROR: Leads to ambiguity. Compiler can not choose between std::move that is defined in the same namespace and boost::variant::detail::move(), which is found via ADL. I think, that the same thing can happen with Boost.Move library, if some class defined in namespace boost will be used in VC++ STL containers. Most generic way to get rid of such ambiguity, is to import std::move in namespace boost (if we have std::move). Best regards, Antony Polukhin

4 5

[move] Pathscale and Sun
by Daniel James 09 Aug '11

09 Aug '11

Hi Ion, Boost.Move seems to work okay with Pathscale (at least the unordered container tests pass), but you've marked it as not supported. IIRC it used to have some configuration problems which were fixed a little while ago. Have you got any plans to fix the issue with 'boost::rv' on Sun C++ or should I work around it? Daniel

2 2

[containers] reviewette
by Gregory Crosswhite 09 Aug '11

09 Aug '11

Hey everyone, I don't know if I will get the chance to perform a full review within the review window, but I just wanted to share my limited experience with the library. Back in February I wrote (or more precisely, rewrote in C++) a production numerical simulation code [1] that makes extensive use of Boost.Move because move-but-not-copy semantics were the most natural fit for most of my data objects. (The rationale for this was that in nearly all cases I only wanted one entity to hold a given data object, and in the remaining cases few I could just wrap the data object in a shared_ptr.) Since I wanted to have vectors containing these objects, I made use of the containers::vector class that was bundled with Boost.Move, so the headers for Boost.Move and at least the vector class of the proposed Boost.Containers library have lived in my code for a few months now. Being able to return a vector without having to worry about whether it would be copied was so nice that I eventually just started using boost::containers::vector everywhere I would normally have used std::vector; it was also very nice to be able to use the .emplace* methods to construct elements in place because this saved both some overhead *and* additional typing on my part. (Of course, I will eventually get these things by default in std::vector as soon as C++0x is available everywhere, but it is really nice to have them now! :-) ) The code has been stable enough that I never encounter any problems using it. Now, I don't know what has changed since I coped the Boost.Move+Boost.Container headers into my tree in Febrary so hopefully nothing has been broken, but based on my personal experience using the library I can say that it at least boost::containers::vector seems to work just fine in production code and I would really like to see it be a part of Boost. Cheers, Greg [1] Nutcracker, a matrix product state based quantum simulation code, available at: http://github.com/gcross/Nutcracker

2 1