- Boost - lists.boost.org

[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

[lockfree] Review
by Grund, Holger 09 Aug '11

09 Aug '11

Hi everyone, I'm sorry for the late review -- things have been busy as usual. I've briefly gone over the code and think Tim's Lockfree library would make an excellent addition to Boost and should be accepted, provided some points are addressed. First and foremost, I don't think the library can be called ready when it doesn't support Visual C++/x86 in a meaningful way -- which I believe it doesn't right now. What is your evaluation of the design? -------------------------------------- The library seems well-designed. As I believe has been discussed in a separate thread, naming is somewhat inconsistent. The failure modes are not clear to me (e.g. does enqueue/push return false or throw an exception when there is no more memory), but overall I think Tim did an excellent job. What is your evaluation of the implementation? ---------------------------------------------- As mentioned, it would appear that bundled atomic implementation has a lot of shortcomings, but one is particularly bad: atomic<tagged_ptr> is not actually lock-free for Visual C++. The DCAS implementation should be straightforward, but seems to be absent . in case you wonder I did an initial implementation of <(cstd)atomic> and added all required intrinsics for a simple implementation to the compiler. These made it all into VC++2010 RTM (IIRC, there was only one 64-bit, most where 8 & 16-bit variants) There are a few points that make me a bit nervous. Specifically, the alignment story is a bit weak. It seems there is only one use of BOOST_LOCKFREE_CACHELINE_ALIGNMENT and that's for fifo<>::node. Older compilers (GCCs and VC at least) don't dynamically align the stack with __declspec(align)/__attribute__((aligned). Other classes do not use alignment at all. It seems somewhat inconsequent to add internal padding to move members to different cachelines, but at the same time not ensuring alignment (which means potential cacheline overlaps at back and front of the object). Also the code seems to assume that compilers will use an empty base class optimization for noncopyable -- I guess, that's fine for most major compilers. Also it is not clear how it is ensured that nodes allocated are actually aligned. Allocators can and usually do ignore alignment requirements greater than intmax_t types. Some may just fail to instantiate. likely/unlikely are often defined as macros as in the Linux kernel. People probably shouldn't do that for C++, but I have seen it quite a bit. It probably doesn't help that many compilers' inlining oracles don't do very well for modern code. The name freelist_t is somewhat confusing for a template parameter and while I'm not sure what harm it could do it should probably follow the general convention of CamelCase. What is your evaluation of the documentation? --------------------------------------------- This is a bit of a weak point right now. There isn't much documentation to begin with. The definition of wait-free and lock-free is a bit weird. Specifically, the term concurrent operations is a bit vague. I think it's easier to grasp if you say something along the lines of at least one thread makes forward progress at any given point in time. With the current definition in the docs (and most others I know of), it may not be immediately clear why a mutex-based implementation wouldn't be lock-free. There's a paragraph: > The synchronization is done completely in user-space with no interaction without any direct interaction with the operating system [1] . > This implies that they are not prone to issues like priority inversion (a low-priority thread needs to wait for a high-priority thread). I think there's some duplication in the first sentence. I'm not sure what lock-free has to do with priority inversion and I would think that priority inversion means priorities are -- well, inverted. I.e. a high-priority thread is not scheduled, because a lower priority thread owns a resource needed by the high-priority thread. This also makes it sound a bit like lock-free is superior to OS mechanisms, but that really depends. A standard lock-free list is not fair for writers, but an implementation making use of OS facilities can be. On the other hand ticket lockets can provide some fairness. fifo<> and ringbuffer::empty says it is not thread-safe. I would assume that means the value returned is potentially stale, but it can't break class invariants, or can it? What is your evaluation of the potential usefulness of the library? ------------------------------------------------------------------- I think the library addresses a very important use-case and could therefore be a very useful addition to Boost. But to reiterate, I would expect Lockfree to actually be lock-free on all mainstream platforms. Did you try to use the library? With what compiler? Did you have any problems? ------------------------------------------------------------------------------ I don't have Boost libs built here, so only tried some simple tests with VC++ 10 SP1. No problems. I'm planning to run some perf tests with GCC 4.1 on AS5 x86_64. How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? -------------------------------------------------------------------------------------------- I spent about four hours mostly going over the code and the docs. Are you knowledgeable about the problem domain? ----------------------------------------------- I have done quite a lot of lock-free work over the last the last 8 years. I did an initial implementation of <atomic> for Microsoft and my current job involves a lot of tweaking of very low latency code, where we very much care about upper limits for execution time (but also about throughput). While I'm still constantly surprised by modern CPUs, I do consider myself to be quite knowledgeable about this area. -hg Holger Grund, Vice President Morgan Stanley | MS Strats and Modeling 25 Cabot Square | Canary Wharf | Floor 03 London, E14 4QA Phone: +44 20 7677-4095 Holger.Grund(a)morganstanley.com -------------------------------------------------------------------------- NOTICE: Morgan Stanley is not acting as a municipal advisor and the opinions or views contained herein are not intended to be, and do not constitute, advice within the meaning of Section 975 of the Dodd-Frank Wall Street Reform and Consumer Protection Act. If you have received this communication in error, please destroy all electronic and paper copies and notify the sender immediately. Mistransmission is not intended to waive confidentiality or privilege. Morgan Stanley reserves the right, to the extent permitted under applicable law, to monitor electronic communications. This message is subject to terms available at the following link: http://www.morganstanley.com/disclaimers. If you cannot access these links, please notify us by reply message and we will send the contents to you. By messaging with Morgan Stanley you consent to the foregoing.

5 16

Re: [boost] [math][accumulators] Empirical distribution function
by Denis Arnaud 09 Aug '11

09 Aug '11

On 8/8/11, er wrote: > Thanks, but it was just, I quote, a "basis for a conversation" at the > request of a user (Denis Arnaud), but it failed to go anywhere at the time. Note that I am still interested in using such a component/library. The difficulty I had was the integration with the rest of Boost and, therefore, the build of that component. Indeed, I use CMake (from the Ryppl initiative) rather than bjam, for the Boost sandbox components, and the integration is therefore a little bit different. AFAIU, Daniel Pfeifer is now close to have a CMake-ified Boost able to integrate Boost sandbox libraries. One of the first such use case would be to integrate and to test your Empirical CDF component. Nevertheless, thanks for having proposed a solution, even though I understand it is still not perfect. Best Denis

1 0

[tti] Write access to Boost
by Edward Diener 09 Aug '11

09 Aug '11

For my TTI library I need write access to the Boost repository si I can check the library into the trunk and maintain it there. Eddie Diener

2 2

[function][bind] Crash with g++ 4.5.0 -O[23]
by Daniel Larimer 08 Aug '11

08 Aug '11

I recently wrote some code that only crashes with g++ 4.5.0 -O[23] and am not sure whether it is a g++, boost::bind, or boost::function bug. I have prepared a minimum test case that crashes every time: 0 test 0x00000001000016ba Private::method_name(std::string const&) + 26 1 test 0x0000000100001348 boost::detail::function::function_obj_invoker1<boost::_bi::bind_t<void_t, boost::_mfi::mf1<void_t, Private, std::string const&>, boost::_bi::list2<boost::_bi::value<Private*>, boost::arg<1> > >, void_t, std::string const&>::invoke(boost::detail::function::function_buffer&, std::string const&) + 24 2 test 0x00000001000027bb boost::detail::function::void_function_obj_invoker2<functor<std::string, boost::function<void_t ()(std::string const&)> >, void, std::string const&, std::string&>::invoke(boost::detail::function::function_buffer&, std::string const&, std::string&) + 59 3 test 0x0000000100003893 Private::test() + 2723 4 test 0x00000001000012d8 main + 56 5 test 0x0000000100001250 start + 52 Mac OS X 10.6 Snow Leopard g++-4.5.0 -O3 or -02 crashes g++-4.5.0 -O1 works. g++-4.2 -O3 works. g++-4.0 -O3 works llvm-g++-4.2 -O3 works The odd thing is that if I replace boost::bind() with my own custom functor then it does not crash. If I include both working and non-working functors (uncomment code) then they both work. Because older versions of g++ work (pre C++0x support) it could be a bug in how boost::function or boost::bind use rvalue references. Because replacing boost::bind() with my own custom functor also fixes it, I suspect that the problem, if not g++, lies in boost::bind. If I remove boost::function from the equation by creating functor<Seq,Functor> with Functor = TYPEOF( boost::bind( ... ) ) via the use of a helper method, then it also does not crash. Thus some combination of creating a boost::function<...> from a boost::bind() functor on g++4.5 causes the crash.

2 2