June 2011 - Boost - lists.boost.org

[1.47.0] Regression test failures
by Beman Dawes 01 Jul '11

01 Jul '11

The following libraries are failing release regression tests on most or all platforms: accumulators build config spirit/repository spirit/test tr1 The following are failing on critical platforms (Darwin/Linux/Windows with recent GCC or VC++ releases): assign conversion multi_array optional python regex type_traits wave See http://beta.boost.org/development/tests/release/developer/summary.html My personal opinion is that we can't ship 1.47.0 until the number of failures is dramatically reduced. --Beman

9 25

BJam optional settings with Visual Studio 2010
by George Urakhchin 01 Jul '11

01 Jul '11

Hello, I'm new to Boost, and I searched for this problem, but could not find. When I first built Boost for Visual Studio 2010 (64-bit), I simply ran bjam.exe. I added the include and library paths as instructed and my simple test program, (the regex one on the Getting Started page) using Boost.Regex worked perfectly (Built and Ran). However, then when I ran bjam.exe with the following settings: Link=static,shared runtime-link=shared variant=debug,release threading=multi address-model=64 -a -q, it built successfully, but when I Built my VS2010 project, I started getting "unresolved external symbol" errors. Does anyone have a clue to why this is? Perhaps I need to change some settings in my Visual Studio mode? Maybe the first time, it just used static libraries without any problems, but this time it's having problems with the shared libraries? Any help would be appreciated! ________________________________ CONFIDENTIALITY WARNING: This email including any attachments may contain privileged or confidential information and is for the sole use of the intended recipient(s). Any unauthorized use or disclosure of this communication is prohibited. This e-mail may also be subject to specific non-disclosure and confidentiality provisions. The information contained herein is the property of Chopper Trading, LLC. If you believe that you have received this email in error, please notify the sender immediately and delete it from your system.

2 1

Re: [boost] Is there interest in an alternative to the Singleton anti-pattern?
by Ben Robinson 01 Jul '11

01 Jul '11

> > I would like to see the updated source code. Even if boost vault is > deprecated and moved to github, it is still a good place to post > files. > I have posted the files to: http://www.mediafire.com/?d8kn5fx2n5d22 > > Two more remarks: > 1) it would be great to use auto_ptr for instance_ptr_type. It will > make sure that the resource is deleted and the constructor called. > The purpose of auto_ptr is to clean up the instance automatically. It was a design goal to make destruction of the Singularity explicit, especially in multi-threaded contexts. However, users can create custom ThreadingModel policies which use any kind of smart pointer they desires. I thought to provide the only a primitive pointer for the included policies. > 2) > 2011/6/25 Ben Robinson <icaretaker(a)gmail.com>: > > Singularity, I feel I still must make "instance_ptr" volatile for thread > > safety. ?If I do not, the compiler can store the pointer in a register, > and > > other threads of execution will not see changes to its value. ?The linked > > article seems mostly concerned with fencing access to the variable, which > I > > am achieving by using a mutex object. ?I only need volatile to > > prevent effectively reading a "cached" value for the pointer. ?I found > the > > following article by Andrei Alexandrescu especially interesting: > > http://drdobbs.com/cpp/184403766 > > It is not thread safe. Consider the article > http://www.aristeia.com/Papers/DDJ_Jul_Aug_2004_revised.pdf by Scott > Meyers and Andrei Alexandrescu. In the article by Andrei Alexandrescu > at http://drdobbs.com/cpp/184403766 there is no construction of object > in LockingPtr, and that makes a big difference! > Singularity does not using the Double-Checked Locking Pattern. When using the multi_threaded policy, it always acquire the mutex before accessing the volatile instance pointer. Therefore, it is thread safe, although it is certainly not as efficient as possible. The recommended usage of Singularity is without a globally accessible get() function, so the performance of create() and destroy() should not be an issue. If global_access is enabled, it would be advisable to minimize calls to get(), such as calling get() once per thread, storing the result in thread-local storage. > Best regards, > Antony Polukhin I greatly appreciate the feedback you are providing. In addition, the linked article was a fascinating read. Thank you, Ben Robinson, Ph.D.

5 6

[msm]mismatch document and code
by kondo＠t.email.ne.jp 01 Jul '11

01 Jul '11

Hello, I'm reading the Boost.Msm document. I found some mismatches between the document and the code. Here is the document. http://www.boost.org/doc/libs/1_46_1/libs/msm/doc/HTML/ch03s02.html Section:Explicit entry / entry and exit pseudo-state / fork State machine diagram "stm Fsm". I believe that the diagram should correspond to an example code below. http://www.boost.org/doc/libs/1_46_1/libs/msm/doc/HTML/examples/DirectEntry… ==1== In the diggram, there are two transitions that are triggered with event5. But outer one is event6 in the code. 168: _row < SubFsm2::exit_pt 169: <SubFsm2_::PseudoExit1>, event6 , State2 > ==2== There is no transition in the diagram correspond to the code below. 167: _row < SubFsm2 , event1 , State1 >, ==3== There is no transition in the diagram correspond to the code below. 136: _row < SubState2 , event6 , SubState1 >, I'm not sure which is correct the code or the diagram. It's depends on what the author want to describe. Christophe, could you check that? Thanks, Takatoshi

3 2

[iterator] [iterator_facade] operator-> question
by Jeffrey Lee Hellrung, Jr. 01 Jul '11

01 Jul '11

I'm looking at boost::iterator_facade's implementation of operator->, and I'm not convinced it is correct when using proxy references. I ran into this problem while using iterator_facade as (sketch only) struct derived_iterator : boost::iterator_facade< derived_iterator, pair< Index, Value >, // value_type CategoryOrTraversal, pair< Index, Value& >, // reference Difference > { /*...*/ }; where pair here is similar to std::pair, but also handles reference types. Thus, the reference type of derived_iterator is a proxy reference. Indeed, this might be the basic structure of an iterator to an associative container, particularly when the keys can be generated "on the fly". The problem (at least as I see it) is in lines 295 - 329 in boost/iterator/iterator_facade.hpp (as of Boost version 1.46.1), copied below for convenience: ---------------- // operator->() needs special support for input iterators to strictly meet the // standard's requirements. If *i is not a reference type, we must still // produce a lvalue to which a pointer can be formed. We do that by // returning an instantiation of this special proxy class template. template <class T> struct operator_arrow_proxy { operator_arrow_proxy(T const* px) : m_value(*px) {} T* operator->() const { return &m_value; } // This function is needed for MWCW and BCC, which won't call operator-> // again automatically per 13.3.1.2 para 8 operator T*() const { return &m_value; } mutable T m_value; }; // A metafunction that gets the result type for operator->. Also // has a static function make() which builds the result from a // Reference template <class ValueType, class Reference, class Pointer> struct operator_arrow_result { // CWPro8.3 won't accept "operator_arrow_result::type", and we // need that type below, so metafunction forwarding would be a // losing proposition here. typedef typename mpl::if_< is_reference<Reference> , Pointer , operator_arrow_proxy<ValueType> >::type type; static type make(Reference x) { return boost::implicit_cast<type>(&x); } }; ---------------- Now, iterator_facade< /*...*/ >::operator->'s return type is operator_arrow_result< /*...*/ >::type, which, for proxy references, according to the logic above in operator_arrow_result, is operator_arrow_proxy<T>, where T, in this case, is pair< Index, Value >. The error occurs when operator_arrow_proxy<T> is constructed from &x within operator_arrow_result< /*...*/ >::make, as it tries to convert a pair< Index, Value& >* to a pair< Index, Value >*, which is a no-go. It seems to me that a more correct implementation of operator_arrow_result would use operator_arrow_proxy< Reference > rather than operator_arrow_proxy< ValueType >. I would further rename and change operator_arrow_proxy's member variable to be stored as const T m_ref, rather than mutable T m_value. What are others' opinions on this? Am I doing something wrong? Thanks, - Jeff

2 2

[1.47][Random][Serialization] Undocumented changes
by Ruediger Berlich 01 Jul '11

01 Jul '11

Hi there, just a short note to say that there seem to be two changes that to me appear to be important enough to be documented in the changes section of 1.47: - In Boost.Random: There seems to be a new requirement for a static std::size_t URNG::precision() function in uniform random number generators. Since I roll my own, I ran into the missing function when trying out the Beta 1 of 1.47 - In Boost.Serialization: A very annoying bug seems to have been fixed: https://svn.boost.org/trac/boost/ticket/4842 . This one prevented me from recommending any Boost version newer than 1.43 to our users, so it is pretty important for me that it has been fixed. Otherwise 1.47 beta 1 looks fine to me (Ubuntu 11.04 64 bit, g++ 4.5.2 . Best Regards, Ruediger

2 1

Re: [boost] How to use BCP
by Denis Arnaud 30 Jun '11

30 Jun '11

> > Date: Thu, 30 Jun 2011 16:57:49 +0200 > From: Daniel Pfeifer <daniel(a)pfeifer-mail.de> > To: <boost(a)lists.boost.org> > Subject: Re: [boost] How to use BCP > > As part of the Ryppl <http://ryppl.org/> initiative, Daniel Pfeifer > > has implemented an (awful!) CMake-based Boost modularisation framework. I hope 'awful' is a translation error. Otherwise, I am open for suggestions > to make it better. > cheers, Daniel Ooops, you are absolutely right! I'm sorry about that. I had awesome and wonderful in mind, instead! Sorry again. Cheers denis

2 1

Re: [boost] How to use BCP
by Denis Arnaud 30 Jun '11

30 Jun '11

Hi Will, From: William Voorhees wrote, on 2011-06-27 21:17:50: > I [...] decided to give the program_options module a try. > Since the utility is small and I don't have any current plans for > other boost functionality it doesn't make sense to include the full > BOOST library, so I tried to use bcp to get only the files I'm > interested in. I was able to get a subset of boost code that I should > be able to use with bcp, however I don't know how to compile the > program_options library for linking in my code. > >From a bit of googling it looks like bjam is the build tool, but it > doesn't seem to be included with the subset of files I have. > How would I go about incorporating boost so that all of the necessary > source and associated utilities are included for an end user to build > from. I should be able to issue a series of simple commands (looks > like ./bootstrap.sh and make) to build and install my library with > statically linked in boost. > -Will Voorhees As part of the Ryppl <http://ryppl.org/> initiative, Daniel Pfeifer has implemented an (awful!) CMake-based Boost modularisation framework. Your question is answered on this Ryppl's group thread: http://groups.google.com/group/ryppl-dev/browse_thread/thread/34b94548fb80b… What you would need to do, then, is quite simple: git clone git://github.com/ryppl/rypplite.git git clone git://github.com/boost-lib/program_options.git mkdir build cd build cmake -DBoost_DIR=/absolute/path/to/rypplite ../program_options make Note: replace "git://" by "https://" if you are behind a firewall filtering out the Git protocol (you will have to manually edit the rypplite/boost-config.cmake file as well). Discussions are still on-going about header forwarding, but it answer your needs. Do not hesitate to subscribe to the Ryppl's discussion group for further assistance and discussions. Best denis

2 1

More boostcon videos
by Marshall Clow 30 Jun '11

30 Jun '11

Bartoz (Tuesday): http://blip.tv/boostcon/haskell-the-pseudocode-language-for-c-template-meta… Tony (Wednesday): http://blip.tv/boostcon/lockfree-programming-part-2-data-structures-5258064 Cliff (Wednesday); http://blip.tv/boostcon/design-journeys-with-skoot-a-peer-oriented-generic-… I'm hoping to get about half of the videos up before I go on holidays next week. -- Marshall -- Marshall Marshall Clow Idio Software <mailto:mclow.lists@gmail.com> A.D. 1517: Martin Luther nails his 95 Theses to the church door and is promptly moderated down to (-1, Flamebait). -- Yu Suzuki

5 5

[phoenix] Implementing phoenix::make_shared<T>(...)
by Pyry Jahkola 30 Jun '11

30 Jun '11

Hi, Thomas and other Boosters! I promised on #boost yesterday to try implementing make_shared<T>(...) for Boost.Phoenix. Well, I got the first version working, it was mostly a find-and-replace task to the existing phoenix::new_<T>(...) implementation. I put the modifications to the current Phoenix trunk version here: https://github.com/pyrtsa/boost-svn/commit/b37cb155ff157199a88e59e44f1d8ede… First, the questions, then some remarks and ideas for improvement: 1) If I've understood correctly, you and Hartmut used Wave to generate the preprocessed headers. What command did you use for them? (Currently, I just added a false condition to the preprocessor #if's to fallback to the Boost.Preprocessor iteration.) 2) Where would you put the new make_shared stuff? The first implementation resides below boost/phoenix/object, but I think we should use another directory for all the smart pointer stuff - especially if we're trying to support all of (boost|std::tr1|std)! How about the following pattern? boost/phoenix/smart_ptr/... for all Boost.SmartPtr support stuff boost/phoenix/tr1/... for TR1 support (alternatively, boost/phoenix/std/tr1) boost/phoenix/std/... for C++0x (with #ifdef guards checking against std version) 3) To my pleasant surprise, I didn't need any hacks to create a functor of type function<shared_ptr<Parent>()> using a Phoenix construct like phx::make_shared<Child>(args), where Child inherits Parent. You'll find a working example in https://gist.github.com/1051564. Nevertheless, I think there's also a need for implementing the Phoenix versions of static_pointer_cast etc. 4) Another feature worth implementing might be phoenix::make_unique<T>(...). 5) We also discussed about an API that allows you to make "deep" copies of pointed objects in Phoenix. I think it might already work using something like phoenix::make_shared<T>(ref(x)) if x is of type T, or phoenix::make_shared<T>(*ref(p)) if p points to T. 6) When we get this far, I'll promise help in the documentation effort too. ;-) -- Pyry Jahkola (pyrtsa @ IRC, Twitter, etc.) pyry.jahkola(a)iki.fi +358 40 7529128

3 2