January 2011 - Boost - lists.preview.boost.org

Boost.Filesystem v3 as default in Boost 1.46.0?
by Jeremiah Willcock 12 Jan '11

12 Jan '11

Will the default version of Boost.Filesystem be v3 in the Boost 1.46.0 release? The current release branch still has v2 as the default (at least in <boost/filesystem.hpp>). Also, if I want to write code that works for both v2 and v3, should I test the BOOST_FILESYSTEM_VERSION macro directly? -- Jeremiah Willcock

4 3

[spirit] semantic action for mismatches?
by caustik 12 Jan '11

12 Jan '11

I've come to notice that there seems to be a missing bit of symmetry in spirit with regards to semantic actions. If a rule matches, and thus executes it's semantic action(s), but a rule which includes that rule mismatches, there seems to be no way to "unwind" the code executed down the chain. For example, if one of your semantic actions allocates memory or increments a reference count, how do you free / release that reference in the mismatch scenario? I've thought about using something like a shared_ptr, but it seems like that gets pretty sloppy and unnatural. Is there something you can think of that would work? caustik

5 25

[move] abiguious ctor (msvc-10.0)
by Oliver Kowalke 11 Jan '11

11 Jan '11

I get error C2668 with msvc-10.0 - (gcc.4.x works). Any ideas? 1>test.cpp(44): error C2668: 'X::X': Mehrdeutiger Aufruf einer überladenen Funktion 1> test.cpp(19): kann 'X::X<boost::_bi::bind_t<R,F,L>>(Fn &&,size_t)' sein 1> with 1> [ 1> R=void, 1> F=void (__cdecl *)(int), 1> L=boost::_bi::list1<boost::_bi::value<int>>, 1> Fn=boost::_bi::bind_t<void,void (__cdecl *)(int),boost::_bi::list1<boost::_bi::value<int>>> 1> ] 1> test.cpp(16): oder "X::X<boost::_bi::bind_t<R,F,L>>(Fn,size_t)" 1> with 1> [ 1> R=void, 1> F=void (__cdecl *)(int), 1> L=boost::_bi::list1<boost::_bi::value<int>>, 1> Fn=boost::_bi::bind_t<void,void (__cdecl *)(int),boost::_bi::list1<boost::_bi::value<int>>> 1> ] 1> bei Anpassung der Argumentliste '(boost::_bi::bind_t<R,F,L>, int)' 1> with 1> [ 1> R=void, 1> F=void (__cdecl *)(int), 1> L=boost::_bi::list1<boost::_bi::value<int>> 1> ] test app: #include <cstdlib> #include <iostream> #include <boost/bind.hpp> #include <boost/move/move.hpp> class X { private: BOOST_COPYABLE_AND_MOVABLE( X); public: X() {} template< typename Fn > X( Fn fn, std::size_t i) {} template< typename Fn > X( BOOST_RV_REF( Fn) fn, std::size_t i) {} X( X const& other) {} X & operator=( BOOST_COPY_ASSIGN_REF( X) other) { X tmp( other); return * this; } X( BOOST_RV_REF( X) other) {} X & operator=( BOOST_RV_REF( X) other) { X tmp( boost::move( other) ); return * this; } }; void f( int) {} int main() { try { X x( boost::bind( f, 1), 1); return EXIT_SUCCESS; } catch ( std::exception const& e) { std::cerr << "exception: " << e.what() << std::endl; } catch (...) { std::cerr << "unhandled exception" << std::endl; } return EXIT_FAILURE; } -- Neu: GMX De-Mail - Einfach wie E-Mail, sicher wie ein Brief! Jetzt De-Mail-Adresse reservieren: http://portal.gmx.net/de/go/demail

2 3

[local] local functions ready for review
by Lorenzo Caminiti 11 Jan '11

11 Jan '11

Hello all, A few months ago, I probed for interest in a library for local functions with Boost.ScopeExit's variable binding. Based on that discussion, I have now implemented the Boost.Local library. I have uploaded the source files boost-local_0_1_0-818.zip in the Boost Vault under Function Objects: http://www.boostpro.com/vault/index.php?&direction=0&order=&directory=Funct… The documentation on the web: http://contractpp.sourceforge.net/boost-local_0_1_0-818/libs/local/doc/html… Any comment? As far as I can tell, Boost.Local is ready for a formal review so I am looking for a review manager. Any volunteer? Thanks, Lorenzo ________________________________________________ P.S. A preview from Boost.Local's documentation: The Boost Local library implements local functions, local blocks, and local exits for the C++ programming language. INTRODUCTION Local functions are a form of information hiding and are useful for dividing procedural tasks into subtasks which are only meaningful locally, avoiding cluttering other parts of the program with functions, variables, etc unrelated to those parts. Local functions therefore complement other structuring possibilities such as namespaces and classes. Local functions are a feature of many programming languages, notably Pascal and Ada, yet lacking from C++ (see also [N2511]). This library supports the following features for local functions (see the Alternatives section for a comparison between this library and features offered by C++ local class members, C++0x lambda functions, Boost.Lambda, Boost.Phoenix, and Boost.ScopeExit): * Local functions can access, or better bind, any of the variables from the enclosing scope. Furthermore, local functions defined within a member function can bind the enclosing object this. * The local function body is programmed using the usual C++ syntax. * Local functions can be passed as template parameters (so they can be conveniently passed to STL algorithms, etc). * However, local functions must be defined within a declarative context (e.g., at a point in the code where local variables can be declared) thus they cannot be defined within an expression. In addition to local functions, this library also supports the following features: * Local blocks which define blocks of code that bind variables from the enclosing scope. Local blocks allow programmers to bind variables as constants (constant binding) so to prevent local chunks of code from modifying selected variables. * Local exits which define blocks of code that are executed when the enclosing scope is exited (again with support for constant binding and binding of the object this). AN EXAMPLE The following example illustrates a simple use of this library and it starts introducing the library API (see the Tutorial section for more details on how to use this library): * A local function is passed to the STL std::for_each() algorithm to add together the values of an array. Variables in scope are bound to the local function by both constant value and non-constant reference. * A local exit is used to automatically release the array's memory at scope exit. * A local block is used to assert the correct final value of the summation in a constant-correct context (therefore preventing the assertion from mistakenly changing any of the variables in scope). #include <boost/local/function.hpp> #include <boost/local/block.hpp> #include <boost/local/exit.hpp> #include <algorithm> #include <iostream> #include <cassert> int main() { double sum = 0.0; int factor = 10; BOOST_LOCAL_FUNCTION( (void) (add)( (double)(num) (const bind)((factor)) (bind)((&sum)) ) ) { sum += factor * num; std::clog << "Summed: " << sum << std::endl; } BOOST_LOCAL_FUNCTION_END(add) add(100.0); size_t size = 2; double* nums = new double[size]; BOOST_LOCAL_EXIT( (const bind)((&size)) (bind)((nums)) ) { if (size && nums) delete[] nums; std::clog << "Freed array: " << nums << std::endl; } BOOST_LOCAL_EXIT_END nums[0] = 90.5; nums[1] = 7.0; std::for_each(nums, nums + size, add); BOOST_LOCAL_BLOCK( (const bind)((&sum)) ) { // So far: sum = 10 * 100.0 + 10 * 90.5 + 10 * 7.0 = 1975.0 assert(sum == 1975.0); std::clog << "Asserted summation: " << sum << std::endl; } BOOST_LOCAL_BLOCK_END return 0; }

2 5

[geometry] Excessive inspection report errors
by Beman Dawes 10 Jan '11

10 Jan '11

See http://boost.cowic.de/rc/inspect-trunk.html#geometry A bunch of these problems are related to documentation - Daniel James and some of the other Boost doc folks have dealt with similar problems in other libraries, so can probably help. Thanks, --Beman

2 3

[QuickBook] missing prev/next
by Lorenzo Caminiti 10 Jan '11

10 Jan '11

Hello all, I have generate the Boost.Units documentatiom using Boost.QuickBook from the latest Boost release 1.45.0 but the HTML pages are missing the prev and next page links. I only have the up and home links in the navbar. How can I get the prev and next links to show? Do I need to enable some XLS configuration in the Jamfile? Thank you very much. -- Sent from my mobile device Lorenzo

4 21

cygwin API: posix or windows
by vicente.botet 09 Jan '11

09 Jan '11

Hi, while trying to make Boost.System and Boost.Chrono configurable header only libs we need to include windows.h on some include files. To avoid the inclusion of this intrusive file, we decided sometime ago to include some files in detail/win that will present just the needed interfaces. In my humble opinion cygwin is a wrapper of posix intefaces under windows OS. So, boost libraries shouldn't use Windows interfaces when working under cygwin. What's the experience of others? Best, Vicente

10 10

[tasklets] new lib
by Oliver Kowalke 09 Jan '11

09 Jan '11

boost.tasklet is a split-up from old boost.fiber. The lib allow to execute micro-tasks (tasklets) in a thread and assigns each small task with a micro-thread/fiber - so tasklets are cooperativly scheduled. The API contains classes and functions to manage and synchronize tasklets (even if the tasklets are running on different threads). boost.tasklet is an example how boost.fiber could be used for cooperative scheduling ansd will be used by the threadpool from boost.task. Oliver

2 3

Workaround for clang-linux + GNU stdlib + Boost.Iostreams
by Bryce Lelbach 09 Jan '11

09 Jan '11

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 There's a discrepancy in the definition of wint_t between GCC and some later versions of clang (clang defines it as an int, GCC an unsigned int). This ends breaking Boost.Iostreams with a GNU GCC compiled version of the GNU stdlib and clang (I'll restrain myself from giving the lengthy technical explaination - if you have link-time errors with clang + GCC compiled stdlib + Boost.Iostreams, this is probably the issue). Unfortunately, I cannot patch this issue with a workaround in Boost easily. The right combination of clang flags can work around this by not using the clang intrinsic/builtin headers, but this has a good chance of causing other problems. The simplest solution here is to rebuild clang (building the GNU stdlib with clang is tricky at best). I think newer version of the mainstream clang trunk may have fixed this, but if not, you need to change the assignment to WIntType in the clang::TargetInfo ctor ($CLANG_ROOT/lib/Basic/TargetInfo.cpp, line 40-50ish). It should be UnsignedInt. You also need to hack $CLANG_ROOT/lib/Headers/stdint.h, around 630 - the macro definition of WINT_MIN and WINT_MAX need to be changed to: #define WINT_MIN 0u #define WINT_MAX __UINTN_MAX(__WINT_WIDTH__) If you'd rather not recompile clang, you can try hacking your clang intrinsic headers (not advisable, might break more stuff). Find the resource/intrinsic header directory (usually something like /usr/local/clang/2.9/include/), and make the change specified above to the stdint.h header there. In the stddef.h header, around like 60, you can change the wint_t typedef. - -- Bryce Lelbach aka wash boost-spirit.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAk0fnjQACgkQO/fqqIuE2t7NVQCgowl7TqnCRgWyjRGN+/u3fh2R NywAoK59zWsZiB7vVvtKU0IehHiMIVdz =COrS -----END PGP SIGNATURE-----

4 5

[wiki] Warning Guidelines for VC
by Michael Caisse 08 Jan '11

08 Jan '11

A question just came up on IRC concerning the use of the /Za ("disable language extensions") and it not working. While searching for a previous post from STL on the subject [1] Google offered this link: <https://svn.boost.org/trac/boost/wiki/Guidelines/WarningsGuidelines> STL's (Stephan Lavavej's) advice on the subject was to *not* use /Za because it has "an extremely nasty bug". Unfortunately our guidelines suggest it should be used. I began to edit the wiki page but considering the amount of text and an example on the subject I thought it might be best to ask permission first. Should I edit the page to be in-line with STL's suggestion or just leave it as-is? [1] <http://lists.boost.org/Archives/boost/2010/04/165531.php > michael -- Michael Caisse Object Modeling Designs www.objectmodelingdesigns.com

5 13

Boost.Bind and boost.ref propagation
by Felipe Magno de Almeida 07 Jan '11

07 Jan '11

Hi, Why this code asserts? struct foo { typedef void result_type; template <typename T> void operator()(T obj) const { BOOST_MPL_ASSERT ((boost::mpl::or_ < typename boost::mpl::not_ < typename boost::is_same<typename boost::unwrap_reference<T>::type, T>::type >::type , typename boost::is_reference<T>::type >)); } }; int main() { int i = 0; boost::bind(::foo(), boost::ref(i))(); } I would expect the T type to be boost::reference_wrapper<int>, but it is actually int. It is not int& as well. How do I get to propagate the boost::reference_wrapper through boost.bind to a template? I don't want to use T& for the parameter, because the algorithm accepts objects-by-value correctly, but I would like to be able to use boost.bind as I would call this algorithm with boost.ref for some data-types. foo()(boost::ref(i)); // Calls with boost::reference_wrapper<int> Thanks in advance, -- Felipe Magno de Almeida

2 1

serialization linking issue - mac os x 10.6 + boost 1.45
by John Clayton 07 Jan '11

07 Jan '11

Hi i've got a new problem with my code, now that I'm compiling and linking against the 1.45 boost libraries. When I compile and link, I now get these errors at the link stage: "boost::serialization::version<Model::KeyValue<QPointF> >::value", referenced from: __ZN5boost13serialization7versionIN5Model8KeyValueI7QPointFEEE5valueE$non_lazy_ptr in libDataModel.a(Project.o) __ZN5boost13serialization7versionIN5Model8KeyValueI7QPointFEEE5valueE$non_lazy_ptr in libRendering.a(EditorDocument.o) __ZN5boost13serialization7versionIN5Model8KeyValueI7QPointFEEE5valueE$non_lazy_ptr in libDataModel.a(Serialization.o) (maybe you meant: __ZN5boost13serialization7versionIN5Model8KeyValueI7QPointFEEE5valueE$non_lazy_ptr) I have version definitions for the template types using boost serialization, along the form of: namespace boost { namespace serialization { template<typename T, int scale, int defaultCurveType> struct version< Model::PropertyArrayT<T, scale, defaultCurveType> > { typedef mpl::int_<1> type; typedef mpl::integral_c_tag tag; BOOST_STATIC_CONSTANT(unsigned int, value = version::type::value); }; template<typename T> struct version< Model::KeyValue<T> > { typedef mpl::int_<1> type; typedef mpl::integral_c_tag tag; BOOST_STATIC_CONSTANT(unsigned int, value = version::type::value); }; } } I tried instantiating (in the .cpp of the header where this stuff is declared), like this: boost::serialization::version< Model::KeyValue<QPointF> > a; but the link error for this type still persists. The code is compiled into a library, and then the link step fails on the application. I hope its not the linker being extra ingenious and throwing this fake definition away. Can anyone see what I'm doing wrong? The code works OK if I use/link against boost 1.42. Thanks -- John Clayton Skype: johncclayton

1 0

Re: [boost] Are memory leaks reported by Boost.Test Microsoft Memory Leak Detection Enabling spurious or real?
by Thomas Harning Jr. 07 Jan '11

07 Jan '11

Regarding this problem, I've found more details about it on the Visual Studio Connect website: http://connect.microsoft.com/VisualStudio/feedback/details/106937/memory-le… typeinfo is used by the unit test framework if you use BOOST_AUTO_TEST_CASE_TEMPLATE. Few fixes that seem reasonable: All use the following tools: _CrtMemCheckpoint [1] and _CrtMemDumpAllObjectsSince [2] available since VS2003 to report objects in specific regions Few reasonable cases: * For the entire test path, if dumping enabled, checkpoint before all tests start, dump after all tests complete * For each test suite, checkpoint before suite starts, dump after suite ends (complicated by nested suites...) * For each test case, checkpoint before test starts, dump after test ends 1: http://msdn.microsoft.com/en-us/library/h3z85t43(v=vs.90).aspx 2: http://msdn.microsoft.com/en-us/library/hhy09244(v=vs.90).aspx -- Thomas Harning Jr.

5 5

Re: [boost] [BGL] problem w/ push_relabel_max_flow and floating point capacities
by Marc Schafer 07 Jan '11

07 Jan '11

Jeremiah, I am looking at a particular case in the debugger and I see that is_flow returns false because of comparisons that fail by an error that is many orders of magnitude smaller than the numbers being compared. For example, x==y fails because x and y are both approximately 1. and x-y is 1.e-14. I could replace the particular comparisons that are failing for my test case, but I need to know how to make the entire algorithm generically suitable for use with floating point numbers. is_flow just performs a consistency check after the calculation is complete. Does the calculation itself require any modifications to work correctly with floating point numbers? What are the appropriate tolerances to use? Do the relational tests (<, >) also need modification to properly handle floating point? -Marc "Jeremiah Willcock" <jewillco(a)osl.iu.edu> wrote in message news:<alpine.LRH.2.00.1101051355460.26649(a)flowerpot.osl.iu.edu>... > On Wed, 22 Dec 2010, Marc Schafer wrote: > > > Using the push_relabel_max_flow feature on graphs that have edge > > capacities in double or single precision often results in a failed > > assertion (line 706 push_relabel_max_flow.hpp) on debug builds although > > the answer provided is correct for builds with assertions disabled. > > > > The is_flow() method (line 564, push_relabel_max_flow.hpp) performs some > > consistency checking after the algorithm completes and there is an > > assertion that it returns true. The comparisons inside is_flow are done > > using ==, !=, >, and <. Using a locally modified version, I was able to > > see that all the cases where is_flow returns false are caused by errors > > on the order of machine precision. > > > > I believe the error is a faulty comparison mechanism inside is_flow > > rather than a problem with my graphs or the push_relabel_max_flow > > algorithm. > > I agree with what you are saying. If you just replace the == and != > operations in is_flow (and not < and >), does the code work correctly? > Boost already has floating point equality comparisons with a tolerance, > but does not appear to have inequalities. > > -- Jeremiah Willcock > _______________________________________________ > Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost >

2 1

Re: [boost] [BGL] problem w/ push_relabel_max_flow and floating point capacities
by Marc Schafer 07 Jan '11

07 Jan '11

Apologies for the double post. Outlook crashed while I was typing the first one and I didn't think it got sent. -Marc "Marc Schafer" <Marc.Schafer(a)mathworks.com> wrote in message news:<AA067D07858B794CA4E1612284A7E8DAFFF4(a)exmb-01-ah.ad.mathworks.com>... > Jeremiah, > For my test case, is_flow fails on a comparison x==y where x and y are both approximately 1. and x-y is 1.e-14. > > However, the graphs I want to process could have capacities that are any valid floating point numbers. This leads to several questions: > > is_flow is a consistency check after the algorithm is complete, does the algorithm need modifications to work correctly with floating point numbers? > > How do I determine the correct tolerances to use for comparisons? > > How do I deal with the relational operators (<, >)? > > -Marc > > "Jeremiah Willcock" <jewillco(a)osl.iu.edu> wrote in message news:<alpine.LRH.2.00.1101051355460.26649(a)flowerpot.osl.iu.edu>... > > On Wed, 22 Dec 2010, Marc Schafer wrote: > > > > > Using the push_relabel_max_flow feature on graphs that have edge > > > capacities in double or single precision often results in a failed > > > assertion (line 706 push_relabel_max_flow.hpp) on debug builds although > > > the answer provided is correct for builds with assertions disabled. > > > > > > The is_flow() method (line 564, push_relabel_max_flow.hpp) performs some > > > consistency checking after the algorithm completes and there is an > > > assertion that it returns true. The comparisons inside is_flow are done > > > using ==, !=, >, and <. Using a locally modified version, I was able to > > > see that all the cases where is_flow returns false are caused by errors > > > on the order of machine precision. > > > > > > I believe the error is a faulty comparison mechanism inside is_flow > > > rather than a problem with my graphs or the push_relabel_max_flow > > > algorithm. > > > > I agree with what you are saying. If you just replace the == and != > > operations in is_flow (and not < and >), does the code work correctly? > > Boost already has floating point equality comparisons with a tolerance, > > but does not appear to have inequalities. > > > > -- Jeremiah Willcock > > _______________________________________________ > > Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost > > > _______________________________________________ > Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost >

1 0

Re: [boost] [BGL] problem w/ push_relabel_max_flow and floating point capacities
by Marc Schafer 07 Jan '11

07 Jan '11

Jeremiah, For my test case, is_flow fails on a comparison x==y where x and y are both approximately 1. and x-y is 1.e-14. However, the graphs I want to process could have capacities that are any valid floating point numbers. This leads to several questions: is_flow is a consistency check after the algorithm is complete, does the algorithm need modifications to work correctly with floating point numbers? How do I determine the correct tolerances to use for comparisons? How do I deal with the relational operators (<, >)? -Marc "Jeremiah Willcock" <jewillco(a)osl.iu.edu> wrote in message news:<alpine.LRH.2.00.1101051355460.26649(a)flowerpot.osl.iu.edu>... > On Wed, 22 Dec 2010, Marc Schafer wrote: > > > Using the push_relabel_max_flow feature on graphs that have edge > > capacities in double or single precision often results in a failed > > assertion (line 706 push_relabel_max_flow.hpp) on debug builds although > > the answer provided is correct for builds with assertions disabled. > > > > The is_flow() method (line 564, push_relabel_max_flow.hpp) performs some > > consistency checking after the algorithm completes and there is an > > assertion that it returns true. The comparisons inside is_flow are done > > using ==, !=, >, and <. Using a locally modified version, I was able to > > see that all the cases where is_flow returns false are caused by errors > > on the order of machine precision. > > > > I believe the error is a faulty comparison mechanism inside is_flow > > rather than a problem with my graphs or the push_relabel_max_flow > > algorithm. > > I agree with what you are saying. If you just replace the == and != > operations in is_flow (and not < and >), does the code work correctly? > Boost already has floating point equality comparisons with a tolerance, > but does not appear to have inequalities. > > -- Jeremiah Willcock > _______________________________________________ > Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost >

1 0

Re: [boost] [Boost-commit] svn:boost r67745 - trunk/boost/fusion/container/list/detail
by Steven Watanabe 07 Jan '11

07 Jan '11

AMDG On 1/6/2011 5:17 PM, marshall(a)idio.com wrote: > Author: marshall > Date: 2011-01-06 20:17:40 EST (Thu, 06 Jan 2011) > New Revision: 67745 > URL: http://svn.boost.org/trac/boost/changeset/67745 > > Log: > Applied patch; refs #2823; will merge to release once tests cycle > Text files modified: > trunk/boost/fusion/container/list/detail/build_cons.hpp | 3 ++- > 1 files changed, 2 insertions(+), 1 deletions(-) > > Modified: trunk/boost/fusion/container/list/detail/build_cons.hpp > ============================================================================== > --- trunk/boost/fusion/container/list/detail/build_cons.hpp (original) > +++ trunk/boost/fusion/container/list/detail/build_cons.hpp 2011-01-06 20:17:40 EST (Thu, 06 Jan 2011) > @@ -48,7 +48,8 @@ > static type > call(First const& f, Last const& l) > { > - return type(*f, next_build_cons::call(fusion::next(f), l)); > + typename result_of::value_of<First>::type v = *f; > + return type(v, next_build_cons::call(fusion::next(f), l)); > } > }; result_of::deref would be better. There's no reason to make an extra copy. (Although this code looks pretty copy-happy to begin with). In Christ, Steven Watanabe

1 0

[chrono] isuue with accuracy test on some platforms
by vicente.botet 06 Jan '11

06 Jan '11

Hi, I'm observing some errors in Boost.Chrono related to this accuracy test whcih fails if the elapsed time is over 200ms (see http://svn.boost.org/svn/boost/trunk/libs/chrono/example/chrono_accuracy_te… ). The results are showed below. I'm tempted to remove the check on the unit tests as there is nothing working wrong with the library but with the platform. This user can run this test and see the output to have an idea of the accuracy of the std::clock function on her platform. Comments? Best, Vicente ________________________________________ accuracy test for 1 second(s)... 1000000000 timeout_in_nanoseconds 200000000 maximum_delta 1811871936 sys_dur ../libs/chrono/test/../example/chrono_accuracy_test.cpp(74): test 'sys_dur > timeout_in_nanoseconds - maximum_delta && sys_dur < timeout_in_nanoseconds + maximum_delta' failed in function 'void<unnamed>::accuracy_test(int, char**)' 1811868977 mono_dur ../libs/chrono/test/../example/chrono_accuracy_test.cpp(80): test 'mono_dur > timeout_in_nanoseconds - maximum_delta && mono_dur < timeout_in_nanoseconds + maximum_delta' failed in function 'void<unnamed>::accuracy_test(int, char**)' 1811868554 hires_dur ../libs/chrono/test/../example/chrono_accuracy_test.cpp(86): test 'hires_dur > timeout_in_nanoseconds - maximum_delta && hires_dur < timeout_in_nanoseconds + maximum_delta' failed in function 'void<unnamed>::accuracy_test(int, char**)' 3 errors detected. Or accuracy test for 1 second(s)... 1000000000 timeout_in_nanoseconds 200000000 maximum_delta 1536756457 sys_dur ../libs/chrono/test/../example/chrono_accuracy_test.cpp(74): test 'sys_dur > timeout_in_nanoseconds - maximum_delta && sys_dur < timeout_in_nanoseconds + maximum_delta' failed in function 'void<unnamed>::accuracy_test(int, char**)' 1536855050 mono_dur ../libs/chrono/test/../example/chrono_accuracy_test.cpp(80): test 'mono_dur > timeout_in_nanoseconds - maximum_delta && mono_dur < timeout_in_nanoseconds + maximum_delta' failed in function 'void<unnamed>::accuracy_test(int, char**)' 1536855104 hires_dur ../libs/chrono/test/../example/chrono_accuracy_test.cpp(86): test 'hires_dur > timeout_in_nanoseconds - maximum_delta && hires_dur < timeout_in_nanoseconds + maximum_delta' failed in function 'void<unnamed>::accuracy_test(int, char**)' 3 errors detected.

1 0

[system][chrono] header-only libs
by vicente.botet 06 Jan '11

06 Jan '11

Hi, after discussion with Ion about whether Boost.Interprocess could use Boost.Chrono and Boost.System he has found as major drawback that both are not header-only libs. I have implemented Boost.Chrono as a header only lib. If the user wants Boost.Chrono be a header-only lib s/he needs to define the BOOST_CHRONO_INLINED macro. While this could be useful, there is a problem as Boost.Chrono depends on Boost.System that is not a header-only lib. * I have added this on the configuration file #ifdef BOOST_CHRONO_INLINED #define BOOST_CHRONO_INLINE inline #define BOOST_CHRONO_DECL #else #define BOOST_CHRONO_INLINE // as before #endif * Copied all the .cpp files to the detail/inlined directory. * Renamed the .cpp file by .hpp files * Included in the old .cpp files the corresponding .hpp file in the detail/inlined directory * I've replaced the prefix suffix as follows: #ifndef BOOST_CHRONO_INLINED #include <boost/config/abi_prefix.hpp> // must be the last #include #endif #ifndef BOOST_CHRONO_INLINED #include <boost/config/abi_suffix.hpp> // pops abi_prefix.hpp pragmas #else #include <boost/chrono/detail/inlined/file_name.hpp> #endif * prefixed the definitions of the function in the .cpp files by BOOST_CHRONO_INLINE While doing this I have found a minor issue on Windows platform. I hve nedeed to sorrounded by () all the use of min and max functions on the test files to avoid the macros defined on the windows.h file. That means that a header-only lib could break user sources as it will include implicitly some platform files. Another drawback that I have no inspected yet could be the increase in size and compilation time of the user code. Beman do you mind if I try to make your library configurable as header-only, so Ion could use Boost.System and Boost.Chrono and preserve Boost.Interprocess as a header-only lib? Best, Vicente P.S. You can see the sandbox for the last modifications _____________________ Vicente Juan Botet Escribá http://viboes.blogspot.com/

8 23

library_status.cpp
by Bryce Lelbach 06 Jan '11

06 Jan '11

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 library_status.cpp (cd $BOOST_ROOT/tools/regression/build && bjam library_status toolset=gcc) does not build for me. I don't know how long this has been broken for, but who is the maintainer of this software? - -- Bryce Lelbach aka wash boost-spirit.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAk0lOrQACgkQ9cB/V3/s9Ez94wCgpSQpaWDHsBFm1S1uvdRKrSG9 fwAAoKlJWaEaAuEKZwvZMCIwC5C//tOO =5BVP -----END PGP SIGNATURE-----

3 2

combinations and permutations
by Howard Hinnant 06 Jan '11

06 Jan '11

Warming this up for tr2: http://home.roadrunner.com/~hinnant/combinations.html Comments welcome. Real world use welcome. -Howard

11 32

[graph_parallel] Is a distributed directed edge list possible?
by caustik 06 Jan '11

06 Jan '11

Is it currently possible to represent a highly connected graph where any given vertex may contain more directed edges than can be held in a single process' OutEdgeListS? I see that the distributed version of adjacency_list allows vertices to be distributed across multiple processes in a process group, but I don't see the ability to allow directed edges to be distributed across multiple processes. Is this an intentional limitation? caustik

4 5

Re: [boost] [Boost-testing] [ratio] Intel compilers issue : internal error:assertion failed: copy_template_param_expr: bad expressionkind (shared/edgcpfe/il.c, line 12561)
by vicente.botet 05 Jan '11

05 Jan '11

Hi, sorry for cross-posting, but as no body answered on the Boost testing list ... Best, Vicente ----- Original Message ----- From: "vicente.botet" <vicente.botet(a)wanadoo.fr> To: "Running Boost regression tests" <boost-testing(a)lists.boost.org> Sent: Wednesday, January 05, 2011 8:56 AM Subject: [Boost-testing] [ratio] Intel compilers issue : internal error:assertion failed: copy_template_param_expr: bad expressionkind (shared/edgcpfe/il.c, line 12561) > Hi, > > on Intel compilers I have two test mpl_plus_pass.cpp and ratio_ext_pass.cpp that make this error. > > internal error: assertion failed: copy_template_param_expr: bad expression kind (shared/edgcpfe/il.c, line 12561) > > It seems that there is already an Intel ticket associated (tracker number #82149) see http://software.intel.com/en-us/forums/showthread.php?t=56558. > > Do someone know the state of this ticket and a workaround to this error for the failing tests? > > Thanks, > Vicente > _______________________________________________ > Boost-Testing mailing list > Boost-Testing(a)lists.boost.org > http://lists.boost.org/mailman/listinfo.cgi/boost-testing

1 0

[BGL] problem w/ push_relabel_max_flow and floating point capacities
by Marc Schafer 05 Jan '11

05 Jan '11

Using the push_relabel_max_flow feature on graphs that have edge capacities in double or single precision often results in a failed assertion (line 706 push_relabel_max_flow.hpp) on debug builds although the answer provided is correct for builds with assertions disabled. The is_flow() method (line 564, push_relabel_max_flow.hpp) performs some consistency checking after the algorithm completes and there is an assertion that it returns true. The comparisons inside is_flow are done using ==, !=, >, and <. Using a locally modified version, I was able to see that all the cases where is_flow returns false are caused by errors on the order of machine precision. I believe the error is a faulty comparison mechanism inside is_flow rather than a problem with my graphs or the push_relabel_max_flow algorithm. -Marc

2 1

[local] request SVN write access
by Lorenzo Caminiti 05 Jan '11

05 Jan '11

Hello, I would like to request write access to Boost SVN so I can commit Boost.Local. Boost.Local status is as follow: 1) Implemented and compiled on both MSVC and GCC. 2) Documented (using QuickBook). 3) There are examples to exercise all library features. 4) No regression tests yet. 5) Not peer-reviewed yet. I am not familiar with the process so I do not know at which point a Boost library under construction is committed into Boost SVN... please let me know if it is a good idea to commit Boost.Local or if I should wait. Thank you. -- Lorenzo

2 1

[Trac] Request to add chrono component.
by Vicente Botet 05 Jan '11

05 Jan '11

Hi, Rene please, could someone add the chrono component on Trac system associated to my account viboes? Thanks, Vicente -- View this message in context: http://boost.2283326.n4.nabble.com/Trac-Request-to-add-chrono-component-tp3… Sent from the Boost - Dev mailing list archive at Nabble.com.

2 1

[Review][Chrono] Boost.Chrono has been ACCEPTED into Boost
by Anthony Williams 05 Jan '11

05 Jan '11

Hi, I am pleased to announce that Boost.Chrono has been ACCEPTED into Boost. There were a reasonable number of reviews this time, and they were unanimous that Boost.Chrono should be accepted. Boost.Chrono provides the time facilities from the upcoming C++0x standard, so is an important base library. A few changes were requested by the reviewers which should be addressed before this library appears in a Boost release. I know that Vicente has already started working on some of these. The requested changes are: * The documentation needs revising to ensure everything is documented, and it is clear which time source is used for each clock type * The use of double underscores in identifiers should be stopped --- such identifiers are reserved for the implementation. * chrono::monotonic_clock will need renaming chrono::steady_clock to match the C++0x draft * the is_monotonic member of the clock types will need renaming is_steady to match the C++0x draft * Remove operator/ for dividing by a duration * Include examples for I/O in non-English languages * Remove "#if 0" blocks * Address all the "TODO" items in the source * Check the license on the time parsing code, and reimplement if the license is incompatible Apologies to the reviewers if I've missed anything. I would like to thank Vicente for submitting the library and those that took the time to write a review. Anthony -- Author of C++ Concurrency in Action http://www.stdthread.co.uk/book/ just::thread C++0x thread library http://www.stdthread.co.uk Just Software Solutions Ltd http://www.justsoftwaresolutions.co.uk 15 Carrallack Mews, St Just, Cornwall, TR19 7UL, UK. Company No. 5478976

2 1

[Trac] Request to add ratio component.
by Vicente Botet 05 Jan '11

05 Jan '11

Hi, please, could someone add the ratio component on Trac system? Thanks, Vicente -- View this message in context: http://boost.2283326.n4.nabble.com/Trac-Request-to-add-ratio-component-tp31… Sent from the Boost - Dev mailing list archive at Nabble.com.

4 5

[BGL] problem w/ push_relabel_max_flow and floating point capacities
by Marc Schafer 05 Jan '11

05 Jan '11

I am still hoping to hear back from somebody regarding the issues described below. Is the intent to support floating point? If we were to make changes that added tolerances to the comparisons, would they be accepted? -Marc From: Marc Schafer Sent: Wednesday, December 22, 2010 4:22 PM To: 'boost(a)lists.boost.org' Subject: [BGL] problem w/ push_relabel_max_flow and floating point capacities Using the push_relabel_max_flow feature on graphs that have edge capacities in double or single precision often results in a failed assertion (line 706 push_relabel_max_flow.hpp) on debug builds although the answer provided is correct for builds with assertions disabled. The is_flow() method (line 564, push_relabel_max_flow.hpp) performs some consistency checking after the algorithm completes and there is an assertion that it returns true. The comparisons inside is_flow are done using ==, !=, >, and <. Using a locally modified version, I was able to see that all the cases where is_flow returns false are caused by errors on the order of machine precision. I believe the error is a faulty comparison mechanism inside is_flow rather than a problem with my graphs or the push_relabel_max_flow algorithm. -Marc

2 1

[Review] Formal Review of Proposed Boost.Chrono Library Starts TOMORROW
by Anthony Williams 05 Jan '11

05 Jan '11

Hi everyone, The review of Vicente Botet's Chrono library starts TOMORROW (November 6th) and lasts until November 15th unless an extension occurs. What is it? ======== Boost.Chrono aims to implement the new time facilities in C++0x, as proposed in N2661 - A Foundation to Sleep On (http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2661.htm) That document provides background and motivation for key design decisions and is the source of a good deal of information in this documentation. See the current C++0x working draft at http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3126.pdf for details of what was accepted. The Boost.Chrono library provides: * A means to represent time durations: managed by the generic duration class . Examples of time durations include days, minutes, seconds and nanoseconds, which can be represented with a fixed number of clock ticks per unit. All of these units of time duration are united with a generic interface by the duration facility. * A type for representing points in time: time_point. A time_point represents an epoch plus or minus a duration. The library leaves epochs unspecified. A time_point is associated with a clock. * Several clocks, some of which may not be available on a particular platform: system_clock, monotonic_clock and high_resolution_clock. A clock is a pairing of a time_point and duration, and a function which returns a time_point representing now. * To make the timing facilities more generally useful, Boost.Chrono provides a number of additional clocks that are thin wrappers around the operating system's time APIs, thereby allowing the extraction of read (wall clock) time, user CPU time, system CPU time, - process_real_cpu_clock, captures real (wall clock) CPU times. - process_user_cpu_clock, captures user-CPU times. - process_system_cpu_clock, captures system-CPU times. - A tuple-like class __process_cpuclock_, that captures real, user-CPU, and system-CPU times together. - A thread_clock thread monotonic clock, when supported by a platform. * Boost.Chrono also includes typeof registration for duration and time_point to permit using emulated auto with C++03 compilers. * Boost.Chrono also provides I/O for duration and time_point. It builds on <boost/ratio/ratio_io.hpp> to provide readable and flexible formatting and parsing for types in <boost/chrono.hpp>. The duration unit names can be customized through a new facet: duration_punct. Getting the library ============= The latest version of this library may be downloaded from vault: http://www.boostpro.com/vault/index.php?action=downloadfile&filename=chrono… SVN: http://svn.boost.org/svn/boost/sandbox/chrono Boost.Chrono depends on Boost.Ratio http://www.boostpro.com/vault/index.php?action=downloadfile&filename=ratio.… and optionaly Boost.System Header Only http://www.boostpro.com/vault/index.php?action=downloadfile&filename=system…. and the docs may be viewed here HTML: http://svn.boost.org/svn/boost/sandbox/chrono/libs/chrono/doc/html/index.ht… PDF: http://svn.boost.org/svn/boost/sandbox/chrono/libs/chrono/doc/chrono.pdf You can get all these information also (which should avoid some long links) from http://svn.boost.org/trac/boost/wiki/LibrariesUnderConstruction#Boost.Chrono Writing a review ================ If you feel this is an interesting library, then please submit your review to the developer list (preferably), or to the review manager. Here are some questions you might want to answer in your review: - 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? And finally, every review should answer this question: - Do you think the library should be accepted as a Boost library? Be sure to say this explicitly so that your other comments don't obscure your overall opinion. Anthony Review Manager for the proposed Boost.Chrono library -- Author of C++ Concurrency in Action http://www.stdthread.co.uk/book/ just::thread C++0x thread library http://www.stdthread.co.uk Just Software Solutions Ltd http://www.justsoftwaresolutions.co.uk 15 Carrallack Mews, St Just, Cornwall, TR19 7UL, UK. Company No. 5478976

9 32

compiling Boost boost_1_45_0 regex with icu (redhat).
by Candid Shot 05 Jan '11

05 Jan '11

Greetings. I am trying to compile boost regex with icu. The icu library is placed in a non-standard place, so I have set the appropriate environment variable. However everytime I run bjam, console output (amongst many thing) says - has_icu builds : no I have invoked bjam with -sBOOST_HAS_ICU=1. No luck picking icu. I have invoked bjam with -sICU_PATH=/home/xxx/yyy, and no luck either. OTOH, if I go to the subdirectory : libs/regex/build and do 'make -f gcc.mak' It builds with -DBOOST_HAVE_ICU=1 and with the right icu include directory in the compile line. I am new to compiling boost, and would love to find out what is going on. And how can I rectify it. Thanks, CD.

3 6

[ratio] Test failing on trunk
by vicente.botet 04 Jan '11

04 Jan '11

Hi, Boost.ratio is failing with compiler option -pedantic Test output: Sandia-darwin-4.0.1 - ratio - ratio_pass / darwin-4.0.1 Rev 67644 / Tue, 4 Jan 2011 01:50:26 +0000 ... ../libs/ratio/test/ratio_ratio/ratio_pass.cpp:24: error: ISO C++ does not support 'long long' Do you know a compiler macro that states if the -pedantic option is set. Otherwise I see two options: A- Don't test Boost.ratio with this option and add to the documentation the limitation. B Add a explicit macro BOOST_DONT_USE_LONG_LONG The definition of boost::intmax_t should relay on another type in this case. I think the best is option A, as Boost.Ratio could not respect the requirements if the type is not long long. What other think? Best, _____________________ Vicente Juan Botet Escribá http://viboes.blogspot.com/

5 7

[Range] begin/end ADL issues in C++0x range-based for
by Michel MORIN 04 Jan '11

04 Jan '11

[Range] begin/end ADL issues in C++0x range-based for Hi, I recently played around with C++0x range-based for (available on GCC 4.6 Pre-Release). It turned out that some codes using Boost libraries do not compile. Compiler errors (ambiguous calls to begin/end) are generated, when ADL finds both std::begin/end and boost::begin/end in range-based for and there is no single best match. Remarkably, boost::iterator_range (and adapted ranges in Boost.Range) cannot be used in range-based for. First let us recall range-based for. A range-based for for (auto x : range_expr) { // do something } is equivalent to { // Special rule: namespace std is added to rng's associated namespaces auto&& rng = range_expr; for ( auto it = begin(rng), it_end = end(rng); it != it_end; ++it ) { auto x = *it; // do something } } Note that rng has namespace std as its associated namespaces and the unqualified begin/end function call triggers ADL. In C++0x, there are std::begin functions (for simplicity, let's ignore end): template <typename Range> auto begin(Range& r) -> decltype(r.begin()); template <typename Range> auto begin(Range const& r) -> decltype(r.begin()); And Boost.Range has boost::begin functions: template <typename Range> inline typename boost::range_iterator<Range >::type begin(Range& r); template <typename Range> inline typename boost::range_iterator<Range const>::type begin(Range const& r); So, if - rng has namespace boost as its associated namespaces, - the header file boost/range/begin.hpp is included, and - there is no single best match between std::begin and boost::begin, then unqualified begin function call becomes ambiguous. For example, all the following codes fail to be compiled: // code 1 #include <boost/range/iterator_range.hpp> for (auto x : boost::iterator_range<int*>(nullptr, nullptr)) {} // error // code 2 #include <boost/ptr_container/ptr_vector.hpp> for (auto x : boost::ptr_vector<int>()) {} // error // code 3 #include <vector> #include <boost/range/adaptor/reversed.hpp> for (auto x : std::vector<int>() | boost::adaptors::reversed) {} // error // code 4 #include <boost/algorithm/string.hpp> #include <boost/array.hpp> for (auto x : boost::array<int, 2>()) {} // error // code 5 #include <vector> #include <boost/shared_ptr.hpp> #include <boost/range/algorithm.hpp> for (auto x : std::vector<boost::shared_ptr<int> >()) {} // error These errors can be resolved by fixing boost/range/begin.hpp. The fix uses a using-declaration ("using std::begin;") and SFINAE (disable_if with "has_begin" metafunction). A summary of range-based-for-compatible <boost/range/begin.hpp> is the following: #ifndef BOOST_NO_RANGE_BASED_FOR namespace boost { using std::begin; // has_begin metafunction... template <typename Range> inline typename boost::range_iterator<Range>::type begin(Range& rng, typename disable_if<range_detail::has_begin<Range>>::type* = 0) { return range_begin(rng); } // const version ... } #else // existing code... For details, see the attached. I also attach a patch for Boost.Config to add BOOST_NO_RANGE_BASED_FOR. Any comments or thoughs? Regards, Michel

4 7

Fwd: Boost Digest, Vol 3137, Issue 2
by Brent Spillner 04 Jan '11

04 Jan '11

> On 24/12/2010 18:14, Thomas Heller wrote: (My apologies for the delay in responding; I've been travelling for the holidays and had irregular access to email.) >I think this comprehension syntax would be a wonderful addition to phoenix. >In fact i was thinking of adding it to phoenix V3 myself. >By basing your work on phoenix v3 you would introduce a kind of big >dependency, true. However, that dependency is imho not a bad thing, it would >provide you with a powerful basis for your work. The only thing that needed >to be done is to code the logic for the list comprehension... everything >else is already done for you. I managed to make a little time to acquaint myself with Phoenix (v2) and discovered that it wasn't that hard to add Phoenix support to the comprehension library-- a couple of traits specializations to derive the return types, a special case to treat void values as 'true' for the purpose of continuing the comprehension (applies in all cases, not just when using Phoenix expressions), and a mechanism to limit ambiguous operator overloads. I just uploaded a new version of the comprehension library (0.02) to the Vault that includes all of the above, along with the ability to nest comprehensions, support for increment/decrement and assignment operators, general code cleanup, a couple of compiler workarounds, reorganized example programs, and most importantly some preliminary documentation in the README file. As always, I'd appreciate reports of any compilation environments or use cases that cause problems. As far as integrating the comprehension syntax directly into Phoenix goes, it certainly looks feasible but I wonder how much there really is to be gained. Since Phoenix already overloads the <<= (and every other) operator, you'd either have to introduce a wordier sequential-assignment syntax or a special sequentially-assignable type, in which case the comprehension engine might as well be a separate component. One thing that would be handy in v3, though, would be control flow operators that return a value type (e.g. the value of the last expression in the statement list) rather than void. Right now if you need a comprehension to depend on some value computed within the body of a complex Phoenix statement, you have to assign that value to a temporary variable and reference the variable later in the comprehension. I think that this capability would be more generally useful outside the comprehension context, and it would mirror the semantics of many functional languages. I'm still not familiar enough with the Phoenix internals to recognize whether there's some other constraint that makes this impractical. On a more technical note, does anyone know of a safe compile-time way to detect whether the -std=c++0x (or /Qstd=c++0x) command-line option has been passed to the Intel C++ compiler? http://stackoverflow.com/questions/3744023/detecting-c0x-mode-on-intel-c suggests that the the constant __GXX_EXPERIMENTAL_CXX0X__ will be defined (as it is in g++), but that doesn't seem to be true, at least in version 12 under Linux. boost/config/compiler/intel.hpp doesn't seem to have any tricks for this either, which is unfortunate because it never enables BOOST_HAS_DECLTYPE, and the compiler chokes on parts of Boost.Typeof when -std=c++0x is /not/ defined (i.e. when you actually need it most.) Brent

1 0

[smart_ptr] enable_shared_from_this and multiple inheritance solution
by Philippe Cayouette 03 Jan '11

03 Jan '11

Fellow boosters, A little while ago I found a pernicious problem with enable_shared_from_this when used with multiple inheritance. Here is an example: #include <boost/smart_ptr.hpp> #include <boost/enable_shared_from_this.hpp> class Base1 : public boost::enable_shared_from_this< Base1 > { public: Base1() {} virtual ~Base1() {} boost::shared_ptr< Base1 > GetBase1() { return shared_from_this(); } }; class Base2 : public boost::enable_shared_from_this< Base2 > { public: Base2() {} virtual ~Base2() {} boost::shared_ptr< Base2 > GetBase2() { return shared_from_this(); } }; class Derived : public Base1, public Base2 { }; int main() { boost::shared_ptr< Derived > wDerived(new Derived()); // Either of the following lines crashes with GCC, but the first one // passes on VS2005 boost::shared_ptr< Base1 > wBase1 = wDerived->GetBase1(); boost::shared_ptr< Base2 > wBase2 = wDerived->GetBase2(); return 0; } Since Derived inherits from two bases that each inherits from enable_shared_from_this, it has two internal weak_ptr. These weak_ptr are usualy initialised in the constructor of the shared_ptr and I have observed two different behavior with the above code depending if I build it with VS2005 or GCC. With VS2005, the first base class in the inheritance list of Derived (here Base1) get its internal weak_ptr initialized, but not the second one, thus it crashes when we try to access the Base2 weak_ptr via shared_from_this. On GCC, neither base classes get their internal weak_ptr initialized and both base classes access to their internal weak_ptr provokes a crash. To prevent that kind of problem, I created a SmartPtrBuilder and a (very) slightly modified EnabledSharedFromThis (only one assert was removed). Here is the same program with the modifications: #include <boost/smart_ptr.hpp> #include "EnableSharedFromThis.h" #include "SmartPtrBuilder.h" class Base1 : public Generic::EnableSharedFromThis< Base1 > { public: Base1() {} virtual ~Base1() {} boost::shared_ptr< Base1 > GetBase1() { return SharedFromThis(); } }; class Base2 : public Generic::EnableSharedFromThis< Base2 > { public: Base2() {} virtual ~Base2() {} boost::shared_ptr< Base2 > GetBase2() { return SharedFromThis(); } }; class Derived : public Base1, public Base2 { public: // Factory method static boost::shared_ptr< Derived > Create() { return Generic::SmartPtrBuilder::CreateSharedPtr< Base1, Base2 >(new Derived()); } private: Derived() {} }; int main() { boost::shared_ptr< Derived > wDerived = Derived::Create(); // No more crashes boost::shared_ptr< Base1 > wBase1 = wDerived->GetBase1(); boost::shared_ptr< Base2 > wBase2 = wDerived->GetBase2(); return 0; } As you can see, Derived has now a factory method that uses the SmartPtrBuilder to create the shared_ptr. Two template arguments are used on CreateSharedPtr, allowing it to initialize the internal weak_ptr of each base classes. The SmartPtrBuilder I did can support up to 10 base classes as template arguments and I also did a variadic template version which has no limit. By using the factory method, the users of Derived don't need to know which of its base classes need its internal weak_ptr need to be initialized. Source code for the SmartPtrBuilder and the modified EnableSharedFromThis: http://spoluck.ca:8000/boost/EnableSharedFromThis.h http://spoluck.ca:8000/boost/SmartPtrBuilder.h That builder might be incorporated to the boost smart pointer library so that anyone could use its facilities to prevent the problem mentioned earlier. No modification to the mighty shared_ptr class required, only the addition of a builder. What do you think? Philippe

3 7

[units] inconvent printing of composite scaled units
by Matthias Schabel 03 Jan '11

03 Jan '11

> great, it works, using the CGS example, if I define: > > namespace boost{namespace unit{ > namespace si{ > typedef scaled_base_unit<boost::units::si::second_base_unit, > scale<10, static_rational<-15> > > femtosecond_base_unit; > typedef femtosecond_base_unit::unit_type femtosecond_unit; > static const femtosecond_unit femtosecond, femtoseconds; > } > }} > > then > > cout << 3.*si::meter/si::femtosecond << endl; // prints 3 m fs^-1 > > while > > cout << 3.*si::meter/(si::femto*si::second) << endl; //print 3 P(m > s^-1), notice the ugly P (for Peta) > > this gives better control on the intended output (at least). > > (Unfortunately this operation doesn't work 3.*si::femtosecond + > 2.*(si::femto*si::second) ) I'm guessing that this is an issue of mixing scaled and unscaled quantities... It should probably work, though, since si::femto*si::second should really return the scaled unit you define manually above. I'll look into it, though it may be a while. Matthias

1 0

[GCC 4.6] Problems catching exceptions
by Beman Dawes 03 Jan '11

03 Jan '11

Although GCC 4.6 isn't released yet, I've been getting good results on a non-Boost project with the weekly MinGW build. See http://www.equation.com/servlet/equation.cmd?call=fortran for the prebuilt MinGW binaries. When I try to run the Boost Filesystem V3 regression tests against this build, however, all the tests fail that involve catching an exception. These tests pass for numerous other compilers, and for other versions of GCC. Since 4.6 is getting close to release, I'd like to see the problem fixed. But I don't have enough knowledge of GCC and MinGW to know where the problem is, or whether this is already a reported bug. Is there anyone out there who knows enough about GCC and MinGW to tell if this bug is already known? --Beman

5 8

[inspect] Tag a directory to be ignored?
by Beman Dawes 03 Jan '11

03 Jan '11

The Boost inspection tool that generates the inspection reports has a hardwired list of directories not to recurse into. "CVS", ".svn", ".git", etc. While those particular cases make sense, some of the hardwired names are so specialized ("doc/xml", "tools/build/v2/engine", etc.) that a better approach might be to tag directories as not to be inspected. That way the inspect.cpp code wouldn't have to be changed to accommodate yet another directory to be avoided. One simple way to do this would be for inspect.cpp to ignore any directories with some special file. For example, "no_boost_inspect". Comments? --Beman

3 5

[SoC] BGL project idea
by Gautam Sewani 03 Jan '11

03 Jan '11

Hi, I am a Computer Science student hoping to contribute to Boost for this year's summer of code. I had a few questions regarding the BGL project idea (https://svn.boost.org/trac/boost/wiki/SoC2010#Boost.Graph) for SOC 2010. 1. I can think of only a few places where the suggested algorithms will be used. Does the community think that these algorithms are used frequently enough to put them in a library? How important does the community consider this project? 2. Will the project proposal be expected to include the API design? Thanks and Regards Gautam

5 29

[BGL] Get properties from an out_edge_iterator efficiently
by Shaun Jackman 03 Jan '11

03 Jan '11

Hi, I have a graph implementation where get(tag, graph, out_edge_iterator) is much more efficient than get(tag, graph, edge_descriptor) which is probably not an usual case. Would it make sense for BGL to provide a default implementation of the former that dereferences the iterator and calls the latter? Graphs for which the former is more efficient could then specialize this function template. Cheers, Shaun

2 3

IDL to C++0x mapping
by Johnny Willemsen 03 Jan '11

03 Jan '11

Hi all, Last summer I asked some questions about a possible IDL to C++0x mapping. The OMG now has issues a RFP (request for proposal) for a new IDL to C++0x mapping. This RFP solicits proposals for a totally new mapping for IDL to C++0x. It is not a solicitation to modify the existing IDL to C++ mapping. The existing mapping is kept intact and unmodified. I am searching for some people that have some background in CORBA and that are willing to give me ideas, prototype some code, give feedback, on the creation of this new IDL to C++0x mapping. If you are interested to assist, contact me directly. The RFP is publicly available at http://www.omg.org/rfp-rfi/cvl.htm The RFP work in progress page is available for OMG members at http://www.omg.org/techprocess/meetings/schedule/IDL_to_C++0x_Language_Mapp… Regards, Johnny Willemsen Remedy IT http://www.theaceorb.nl http://nl.linkedin.com/in/johnnywillemsen

1 0

Re: [boost] [msm] triggering of a transition on a subclass event does not work on sub state machines in case of favor_compile_time policy is used.
by Christophe Henry 02 Jan '11

02 Jan '11

> Hi All > > I have run it to a problem that feature : Event Hierarchy see doc : > http://svn.boost.org/svn/boost/trunk/libs/msm/doc/HTML/ch03s02.html#d0e1108 > > Does not work in case of sub state machine with favor_compile_time > policy. No trans get called on the sub state machine even it has a row > with event type to the event base class. > > This now hit me badly because compiler runs out of heap if > favor_compile_time policy is not used but when it is used I can not > dispatch based on base type and I have about 150 different event so > declare a transition for it is a no go. > > Is there any workaround for this problem ?. Hi Richard, This is a documented limitation of the favor_compile_time policy. See: http://svn.boost.org/svn/boost/trunk/libs/msm/doc/HTML/ch03s05.html#d0e2360. As written there, The current solution can only any_cast to the exact type. And no, at the moment, I unfortunately have no solution. I'll see if I can imagine a workaround. Regards, Christophe

1 0

Re: [boost] [MSM] constructor arguments for sub state/machines
by Christophe Henry 02 Jan '11

02 Jan '11

Hi Richard, > I have tried out the new feature of msm : using constructor arguments > for substate/machines : > namely : > > player p( back::states_ << Playing(back::states_ << Song1(some_Song1_data)) , > boost::ref(data),3); > > > see doc : http://svn.boost.org/svn/boost/trunk/libs/msm/doc/HTML/ch03s05.html#d0e2320 > > I have some problem with it :(. > > this case state Playing and Song1 will be constructed first with > default constructor in back end constructor than the internally > constructed Playing and Song1 will be assigned to the newly construed > Playing / Song1 copy which got copied by value. Copied by reference actually (unless I have a bug) and then assigned. > The only reason to use this feature is to able to use reference > members in the substates Actually not, I must have explained incorrectly because I see it purely as syntactic sugar as a replacement for most uses of fsm.get_state<Song1&>() or worse fsm.get_state<Playing&>().get_state<Song1&>(). > but for that reference members must be > initialised in the member initialisation list of the constructor of > the substates in order to provide the references constructor arguments > must be used. Ok you'll have to use pointers. > Since subsates must provide default constructors it is not possible to > always initialise reference members from outside. > Furthermore substate must be copyable and must implement assignment > which brings more harm than good :(. > > Is there a way to resolve these problems ? This seems to me at least slightly exagerated. Assignable is a requirement for types inside a STL container and the STL clearly brings more good than harm ;-) Joking aside, there is no easy solution. To avoid assignment we will need move semantics. I'm waiting for Boost.Move to be officially part of boost to support this. OTOH the solution hardly qualifies as simplier than an assignment operator, only faster. For the default constructor, the situation is not better. I'm using a fusion::set to hold the states and the doc doesn't mention the possibility to copy-construct a set from a smaller one (in our case). I tried it and it doesn't work. So for the moment, it seems I'll have to live with the current solution (default-construct the set, then assign the provided states) and you might have to resort to pointers. In any case, a solution will at least include copy/move-construction. I actually think there might be a way to patch fusion to avoid default-construction, but I have little wish to try this at the moment. I have limited development time (my nights) and it seems to me like a poor usage of this limited resource seeing the amount of features I still want to add into MSM (there will be a whole pack for the 1.46 and I have more in my plan). However, I am working by iterating so I will probably come back to it at a later time. > PS: > Looking to the test: > http://svn.boost.org/svn/boost/trunk/libs/msm/test/Constructor.cpp > > I think there is a bug : at with line : fsm.context_ = 20; Probably. It should be fsm.context_.bla = 20; Thanks, Christophe

1 0

[thread] boost::this_thread::sleep broken?
by Jamie Allsop 02 Jan '11

02 Jan '11

From the docs I'd expect to be able to write this: std::cout << "Time Before Sleep: " << boost::posix_time::microsec_clock::local_time() << std::endl; boost::this_thread::sleep( boost::posix_time::seconds(10) ); std::cout << "Time After Sleep : " << boost::posix_time::microsec_clock::local_time() << std::endl; and have the 'this' thread sleep for approximately 10 seconds. Instead sleep returns instantaneously: Time Before Sleep: 2010-Dec-25 01:38:50.949160000 Time After Sleep : 2010-Dec-25 01:38:50.949436000 I've tried this with boost 1.45 and boost 1.43 using gcc 4.4 on debian x86_64. Am I missing something obvious? Jamie

2 2

Respecting a projects toolchain decisions (was Re: [context] new version - support for Win64)
by Lars Viklund 02 Jan '11

02 Jan '11

>>> On Fri, Dec 17, 2010 at 9:34 PM, Lars Viklund<zao(a)acc.umu.se> wrote: >>>> Maybe you can adapt to the conventions of the real world, or use >>>> git-svn? >> On Fri, Dec 17, 2010 at 22:19, Dean Michael Berris >> <mikhailberis(a)gmail.com> wrote: >>> Which real world are you talking about, the one that I live in where >>> nobody uses SVN anymore and instead use Git for large open source >>> development projects? :) >Am 18.12.2010 09:47, schrieb Scott McMurray: >> Probably the "large commercial software company" world where the >> source control is so bad that branches get merged once every two weeks >> at best, and all checkins are blocked for over 24 hours when they do, >> so multiple releases get worked on in the same branch just to avoid >> the merging headaches. On Sat, Dec 18, 2010 at 03:46:30PM +0100, Oliver Kowalke wrote: >I think we should stop this talk - if desired you can start a new thread >with this topic. I apologise if the term "real world" was misunderstood, but I'm rather tired of when people come in from the outside, implying or demanding that a project should change their version control, build system or favourite bikeshed colour, just because they are used to something else (possibly "better") from elsewhere. As for version control, what does it matter if Boost uses Subversion, when you as a DVCS user can trivially use git-svn [1] to interop against the repository (in this case, the sandbox). You get to use your favourite toy, without affecting the existing infrastructure in any way. In the end, the version control you choose is rather tangential. As long as it's sufficiently competent (which Subversion in my eyes is), you'll survive. Of course, you may propose constructive criticism and suggest migration plans to other toolchains, with good arguments for why this is a good thing. See the mythical 'Ryppl' project, which aims to componentise Boost into a pile of Git repositories and some magical combination of scripts and CMake, aimed at letting you track exactly the versions of components you need. Remember that no tool is isolated. Changing from Subversion to <whatever> would result in many changes propagating to how test runners are set up, rewriting of commit hooks, modifying Trac (if possible) (although the SVN functionality is disabled there for now), requiring adaptation of any entity out there that use Boost's repositories in any way, including externals, build scripts, CI environments, etc. And of course, having to have the mirrored Subversion repositories up for years, as you can't really 'flag day' such things. -- Lars Viklund | zao(a)acc.umu.se

28 102

[netlib] Preparing for 0.9 and 0.8.1 Release, Help Wanted; Readying for Boost Submission
by Dean Michael Berris 01 Jan '11

01 Jan '11

Hi Guys! (Apologies in advance for the cross-post) I've just pushed the master, 0.8-devel, and 0.9-devel branch onto the cpp-netlib repository -- please take the time to test all these branches as I work on getting the documentation up to speed on the 0.9-devel branch preparing for the release and submission for review on the Boost developers mailing list. I'm also welcoming contributions in the form of: * Website help, the current documentation look is OK, but if you have time to fix up some of the issues like the fonts, adding anchors and maybe reformatting the API pages so that it's easier indexed, that would be *sweet*. Also, we need a landing page on cpp-netlib.github.com which introduces the library, hosts stats, and maybe has other goodies that are specifically for a website and not necessarily for documentation. * Documentation -- please, if you have example use cases that you want to contribute, now is the time to contribute them. If you have real world use cases where you're actually using cpp-netlib, now would be a good time to have your use case highlighted in the documentation. * More string implementations -- currently I need help with supporting Qt strings, MS CString, and wide strings in the implementation of the HTTP Clients. Those who are using wide strings and unicode strings natively and who have more experience with them (I only ever deal with the "C" locale) would be most welcome to contribute to getting the HTTP client to either do conversions or natively support different string implementations. I can help with the integration part by introducing the extension points that may not be obvious from the design (as it is still largely undocumented). * Examples -- the current set of examples are a little trivial, and if you have some interesting examples you want to build on (or would like to implement some of the examples highlighted here: https://github.com/cpp-netlib/cpp-netlib/issues/labels/Examples) your contribution would be most welcome. There are some things that I've pushed out for later releases, as I would like to concentrate at the moment to making the HTTP implementations more robust and support a wider range of use-cases. I'm looking for people with experience with ESMTP 1.0 who would like to contribute to implementing a simple client implementation that we can build along the same design as the HTTP client implementation. There's already a MIME parser/generator library in cpp-netlib thanks to Marshall Clow (which he presented in BoostCon 2010) also being developed for inclusion into Boost -- hopefully we can get that baked into the ESMTP client implementation early on to make it more immediately useful. At any rate, please expect a slightly delayed release of 0.9 which would be the first release which defaults to non-header-only, while 0.8.1 will be the first patch update version for 0.8. Appropriate changelogs to follow as soon as the releases are ready. In the meantime, please feel free to test out the code already in GitHub: http://github.com/cpp-netlib/cpp-netlib/ -- the stabilization effort for 0.9 and 0.8.1 will happen on this repository. Feedback would be most appreciated. Thanks everyone! -- Dean Michael Berris about.me/deanberris

1 0

[Review][Ratio] Boost.Ratio has been ACCEPTED
by Anthony Williams 01 Jan '11

01 Jan '11

Hi, I am pleased to announce that Boost.Ratio has been ACCEPTED into Boost. There were not as many reviews for Boost.Ratio as for some libraries, but they were overwhelmingly positive. Boost.Ratio is an important building block for other upcoming submissions, and provides an implementation of the C++0x rational arithmetic facilities. A few changes were requested by the reviewers, which I will list below. I know that Vicente has already started working on some of these. These changes should be addressed before the library appears in a Boost release. * Some of the macros had names with RATIO_RATIO in. These should be changed to just RATIO * The ratio_add, ratio_sub, ratio_multiply and ratio_divide templates should derive from the resulting ratio type as well as providing the nested ::type member, in order to closely emulate the template alias facility from C++0x * The typos in the documentation should be fixed, and the documentation reviewed for correctness and clarity (though several of the reviewers made positive comments on the quality of the documentation). * The library needs more tests under the Boost Software License. * All references to names from the boost namespace should be qualified with boost:: to avoid potential name clashes and ambiguity with names from the global namespace. * Sections commented out with #if 0 should be removed * The extensions beyond the facilities required by the C++0x draft should be able to be enabled or disabled through use of a configuration macro. * References to the tests, examples and documentation from within the code should be checked for correctness. I would like to thank Vicente for submitting the library and those that took the time to write a review. Anthony -- Author of C++ Concurrency in Action http://www.stdthread.co.uk/book/ just::thread C++0x thread library http://www.stdthread.co.uk Just Software Solutions Ltd http://www.justsoftwaresolutions.co.uk 15 Carrallack Mews, St Just, Cornwall, TR19 7UL, UK. Company No. 5478976

2 2

[fiber] new version
by Oliver Kowalke 01 Jan '11

01 Jan '11

boost.fiber has been refactored - most of the code has moved to another lib. The new version allows directly to run and yield the fiber. class jumpable is an example how a fiber can be used.

2 3