October 2013 - Boost - lists.preview.boost.org

Re: [boost] boost 153 interprocess_mutex much slower in windows 7 than xp?
by jim＠jc-bell.com 07 Oct '13

07 Oct '13

> We have 3 processes that are synchronized with an interprocess mutex. > Basically one of them has a multiplier which allows the others to run at a > synchronized accelerated rate. Under XP we typically can get it to run at > 5000 times realtime. New desktop refreshes are coming out running Windows > 7 and the same code with faster machines with more memory are maxing out > at 250 times with 95%+ cpu idle time. > > Am new to boost so am wondering if we're doing something wrong. Here's the > crux of the code. 3 processes and some shared memory. > ... It might be hitting the disk when it shouldn't be. Try pointing SysInternals' ProcMon at each and see if one's doing file accesses where the other isn't. (SysInternals.com.)

1 0

[interest] rich-typed smart pointers
by Julian Gonggrijp 07 Oct '13

07 Oct '13

Dear Boost members, I have designed a smart pointer that relies on the type system to offer safe and flexible automatic memory management at no runtime cost. It combines single ownership as in std::unique_ptr and reliable access from multiple places as in std::shared_ptr with some additional features. I believe it to be about as safe and practically useful as a smart pointer in C++11 could get. Further explanation and a proof-of-concept implementation is available over here: https://github.com/jgonggrijp/rich-typed-pointers There is no license yet, but you have my explicit permission to try the library and the example programs at your own risk. :-) Could this library be useful addition to Boost? I look forward to your comments. Thanks in advance, -Julian PS: a possible minor seed for discussion is the current lack of an implicit cast to bool. I agree with Jeff Flinn's argument why the implicit cast may be desirable [1]. However, it interferes with the comparison operators when one of the operands should be implicitly cast to weak_ptr, as explained in [2]. I could repeat myself and write comparison functions for all possible overloads, but this seems inelegant. [1] http://boost.2283326.n4.nabble.com/Looking-for-thoughts-on-a-new-smart-poin… [2] https://github.com/jgonggrijp/rich-typed-pointers/commit/89fcf2821cb39bbb9f…

5 24

[utility][enable_if]Fiddly function lookup failure on msvc11
by 山本賢一 07 Oct '13

07 Oct '13

Hi, I found a part of my code failed to compile with boost::enable_if_c when I was porting my code for msvc11 (Visual Studio 2012). The original code was bit too complex but I simplified it to boil down the issue. The simplified code is eventually like this: #include <boost/mpl/bool.hpp> #include <boost/mpl/not.hpp> #include <boost/utility/enable_if.hpp> template <class T> struct always_true : boost::mpl::true_ { }; template <class T> inline typename boost::enable_if_c< !boost::mpl::not_< always_true<T> // Argument of boost::mpl::not_ >::type::value // Refer the result of boost::mpl::not_ , int >::type get_one(T) { return 1; } void test() { get_one('a'); // Compile fails at this line with error C2893 } msvc11 fails to resolve the call to get_one() but I believe the code is definitely correct. With some more extra test, I found: (1)The same code compiles on msvc10 (Visual Studio 2010) and msvc9 (Visual Studio 2008). (2)If I changed the line I commented "//Argument of boost::mpl::not_" to "boost::mpl::true_", the code compiled on msvc11. template <class T> inline typename boost::enable_if_c< !boost::mpl::not_< boost::mpl::true_ // *** Argument of boost::mpl::not_ >::type::value // Refer the result of boost::mpl::not_ , int >::type get_one(T) { return 1; } (3)If changed the line I commented "// Refer the result of boost::mpl::not_" to ">::value", the code compiled on msvc11. template <class T> inline typename boost::enable_if_c< !boost::mpl::not_< always_true<T> // Argument of boost::mpl::not_ >::value // *** Refer the result of boost::mpl::not_ , int >::type get_one(T) { return 1; } The issue seems to be rather a compiler quirk of msvc11 than a enable_if's problem, but I posted the issue here because we need a workaround to avoid it (on msvc11) when we use enable_if. Please let me know if you have any idea about the issue. Thanks. Yamamoto

3 3

[algorithm] documentation mistakes in 'equal' and 'mismatch'
by Takatoshi Kondo 06 Oct '13

06 Oct '13

Hi, Marshall IIUC, I found some mistakes in the documentation of 'equal' and 'mismatch'. http://www.boost.org/doc/libs/1_54_0/libs/algorithm/doc/html/algorithm/CXX1… http://www.boost.org/doc/libs/1_54_0/libs/algorithm/doc/html/the_boost_algo… In the first code block, auto seq1 = { 0, 1, 2 }; auto seq2 = { 0, 1, 2, 3, 4 }; std::equal ( seq1.begin (), seq1.end (), seq2.begin ()); // true std::equal ( seq2.begin (), seq2.end (), seq1.begin ()); // Undefined behavior std::equal ( seq1.begin (), seq1.end (), seq1.begin (), seq2.end ()); // false The second seq1.begin() in the last line should be seq2.begin() as follows. std::equal ( seq1.begin (), seq1.end (), seq2.begin (), seq2.end ()); // false Similarly, std::mismatch ( seq1.begin (), seq1.end (), seq1.begin (), seq2.end ()); // <3, 3> should be std::mismatch ( seq1.begin (), seq1.end (), seq2.begin (), seq2.end ()); // <3, 3> Thanks, Takatoshi

2 1

[svn] Server problems?
by Rene Rivera 06 Oct '13

06 Oct '13

I'm getting a persistent error on te SVN server like so: === Froggy:trunk grafik$ svn up Updating '.': svn: E175002: Server sent unexpected return value (413 Request Entity Too Large) in response to REPORT request for '/svn/boost/!svn/vcc/default' === Any ideas? Rene -- -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - grafikrobot/yahoo

2 1

[circular-buffer] Missing images.
by Daniel James 06 Oct '13

06 Oct '13

Hi, I made a change to try to fix some broken links in the circular buffer documentation: https://svn.boost.org/trac/boost/changeset/86174/ You can see the broken links in the inspect report: http://boost.cowic.de/rc/docs-inspect-trunk.html#doc Although hopefully in a couple of hours they'll be gone. But there are still a couple of links to images which I can't find: 'circular_buffer.png' and 'space_optimized.png', did someone forget to check them in? It's probably best not to check them in at 'libs/circular_buffer/doc/html/images', but instead at something like 'libs/circular_buffer/doc/images', that way the images are kept separate from generated documentation. I'll help get the image links right, as it's more tricky than it should be. thanks, Daniel

1 0

[regression] Beagle Bone Black
by Jim Bell 05 Oct '13

05 Oct '13

For anyone interested, Boost regression tests fare pretty well on the $45 Beagle Bone Black (beaglebone.org). Stop by the release regression matrix and check it out (http://www.boost.org/development/tests/release/developer/summary.html). And while you're over there, investigate & fix a regression test failure on your platform: submit a patch and make the matrix a greener place! (See http://www.boost.org/development/bugs.html.) Cheers! -Jim

1 0

[log] logger linking problem
by Tadeusz Jordan 05 Oct '13

05 Oct '13

Hi everyone, I have been using Boost for some time now and really like it. Unfortunately, recently I have bumped into a linker issue when trying to use boost::log, was wondering if anyone has seen this before, or has any insights … thank you very much. The problem is described in the below post. http://stackoverflow.com/questions/18881602/boost-logger-linking-issue -- Sincerely, Tadeusz Jordan Software Engineer at The Broad Institute of MIT and Harvard MS Candidate in CS at Northeastern University This email message and any attachments are confidential and may be privileged. It is intended only for the individual or individuals to whom it is addressed and may not be saved, copied, printed, disclosed or otherwise used by anyone else. If you are not the intended recipient, kindly notify the sender and delete this email and any attachments immediately.

3 11

Re: [boost] [type_traits][function_types] Discard param const qualification, bug or feature?
by Sergey Zhuravlev 05 Oct '13

05 Oct '13

Signature type int(int, const std::string) can be used as parameter for some compiletime algorithm. For example, algorithm that generate new signature type with optimal transfer arguments int (int, const std::string&) or generate signature with all argument references int (int&, const std::string&) Can't use type_traits, function_types at that cases, because const be omitted. This will lead to compiletime error, if function with first signature call function with second signature and use arguments from function with first signature for this call. Signature type void(int, const std::string) can use as types tuple for some compiletime algorithm. Can't use type_traits, function_types, at that case, because const be lost. Signature type void(int, const std::string) can use as parentheses dropper for "types list", e.g. for macro parameter. (int, const std::string) => int, const std::string. Can't use type_traits, function_types, at that case, because const be lost. I think default behavior is correct, but need parameter for change this behavior. At least function_types.

6 16

lots of warning with gcc-4.8.1 + boost-1.54.0
by Neal Becker 04 Oct '13

04 Oct '13

Lots of warnings like this: ./boost/bind/arg.hpp:37:22: warning: typedef ‘T_must_be_placeholder’ locally defined but not used [-Wunused-local-typedefs] when building 1.54.0 with gcc-4.8.1 (fedora f19)

8 9