- Boost - lists.boost.org

how to mark a test "fail*"
by lcaminiti 25 Mar '12

25 Mar '12

Hello all, Expected regression test failures are marked with "fail*" and give an explanation for why the failure is expected: http://www.boost.org/development/tests/trunk/developer/output/Sandia-intel-… How do I add an explanation for a new expected failure? Is there some documentation on this process? For example, emulation_this and emulation_this_tpl are expected to fail on MSVC8 and the user should use native type-of for those-- how do I add a link with such explanation the regression test table? http://www.boost.org/development/tests/trunk/developer/output/VC8%20jc-bell… http://www.boost.org/development/tests/trunk/developer/output/VC8%20jc-bell… Thanks a lot! --Lorenzo -- View this message in context: http://boost.2283326.n4.nabble.com/boost-how-to-mark-a-test-fail-tp4503985p… Sent from the Boost - Dev mailing list archive at Nabble.com.

2 1

[mpi] all_reduce and MPI_IN_PLACE like feature
by Alain O Miniussi 25 Mar '12

25 Mar '12

Hi, MPI_Allreduce offers the possibility to use the same buffer for the send and recv data: http://www.open-mpi.org/doc/v1.4/man3/MPI_Allreduce.3.php#toc8 It seems that boost's all_reduce does not allow such a feature. First, I would like to know if the previous statement is correct and, if yes, if it was just overlooked or if there was a reason for that? Just in case, I filed a ticket regarding that issue, along with a tentative patch, in https://svn.boost.org/trac/boost/ticket/6704 Regards, Alain

1 0

Using C++11 lambdas to replace Phoenix in MPL expressions
by Augustus Saunders 25 Mar '12

25 Mar '12

I use Phoenix to essentially turn code into types which can then be manipulated through MPL. I mostly use this to conditionally select algorithms or to include/exclude code at compile time, based on some logic written with MPL. I was interested in writing the code fragments using the new C++11 lambda expressions as it gives a more natural way to write code. While you can get the type of a lambda expression with decltype, the problem I've run into is instantiating the resultant type in order to actually get the function to execute. Lambdas have no default constructor, which makes sense, as there would be no way to deal with the capture variables. So I'm wondering if anybody can shed some light on manually instantiating lambdas. I would think there is a way (possibly shady) to do this, at least for lambdas with no capture. Then passing around lambda types as template parameters would be useful, which I think would lead to many interesting results. I only get the digest, so it I would appreciate it if you CC me on any response. Thanks- Augustus

3 6

[lexical_cast][random] ADL problem with gcc c++11
by Joel de Guzman 25 Mar '12

25 Mar '12

Hi, I can't get this to compile on gcc-4.6.1 with -std=c++0x flag: #include <boost/random.hpp> int main() { return 0; } I'm getting an error in lexical_cast: C:\dev\boost/boost/lexical_cast.hpp:1323:120: error: there are no arguments to 'swprintf' that depend on a template parameter, so a declaration of 'swprintf' must be available [-fpermissive] Obviously, I can compile with -fpermissive, but I'd like to report this anyway. Regards, -- Joel de Guzman http://www.boostpro.com http://boost-spirit.com

5 7

Re: [boost] [git] Mercurial?
by David Greene 25 Mar '12

25 Mar '12

Edward Diener <eldiener(a)tropicsoft.com> writes: >> Also back to the point - DVCS are written to provide best possible >> support for merging. This makes 1) or 2) you propose above very >> efficient. In SVN or other centralized systems it is not so, just look >> up the bit I left from Joel's message above. > > I do not believe for even a second that any product can do merging of > the same source file automatically and flawlessly. This strawman keeps resurfacing. No one has claimed than any VCS can avoid manual merging at times. A centralized VCS needs to operate as you outlined: >> Bu how is this different from: >> >> 1) Creating a local SVN repository and importing some branches from >> another SVN repository. >> >> and/or >> >> 2) Having one's own branch of an SVN repository as one's own. #1 is a horribly manual operation. I don't know if you quite grasp how complicated it is. I've been doing it for years. Getting the history preserved correctly is not trivial. #2 has almost no support in SVN. Now that SVN has merge tracking it is marginally better but there are problems with this model. Foremost, the branch has to be in a centralized repository and everyone owkring on the project has to deal with it in some fashion. It's not private in any sense of the word. You can't work on it if you don't have 'net access. You can't back out changes that you realized later were bad and ensure no one else ever sees those changes. The difference with a DVCS is both #1 and #2 are natively supported in the tool. There is no difference between a private local branch, a remote branch in a _de_facto_ central repository and a remote branch in some other random repository. They all look and act the same. I admit it is a tough concept to grasp for someone not used to it. It took me some time to grok it. But now it is second-nature to me and there's no way I'm going back. -Dave

3 4

[config] Why does BOOST_NO_STD_LOCALE imply BOOST_NO_STD_WSTREAMBUF?
by Yechezkel Mett 25 Mar '12

25 Mar '12

I have found the following in config/suffix.hpp: // // We can't have a working std::wstreambuf if there is no std::locale: // # if defined(BOOST_NO_STD_LOCALE) && !defined(BOOST_NO_STD_WSTREAMBUF) # define BOOST_NO_STD_WSTREAMBUF # endif What is the reasoning behind this? My problem is that I am using Windows CE 6.0 with the supplied standard library, and it has no <locale>, yet still seems to provide a working wstreambuf. The effect is that I can't get boost::wformat, which is annoying, considering that the WinCE API uses only wide characters. I have checked that removing this line works. Is there any way to undefine BOOST_NO_STD_WSTREAMBUF without modifying the source? Yechezkel Mett

1 0

Re: [boost] [Boost-commit] svn:boost r77506 - in trunk: boost/property_map libs/property_map/doc libs/property_map/test
by Michel Morin 25 Mar '12

25 Mar '12

> Author: jewillco > Date: 2012-03-23 15:35:52 EDT (Fri, 23 Mar 2012) > New Revision: 77506 > URL: http://svn.boost.org/trac/boost/changeset/77506 […] > --- (empty file) > +++ trunk/boost/property_map/function_property_map.hpp 2012-03-23 […] > +#ifndef BOOST_PROPERTY_MAP_FUNCTION_PROPERTY_MAP_H > +#define BOOST_PROPERTY_MAP_FUNCTION_PROPERTY_MAP_H […] > +#endif /* BOOST_PROPERTY_MAP_FUNCTION_PROPERTY_MAP_H */ s/H/HPP > +template<typename Func, typename Key, typename Ret = typename boost::result_of<Func(Key)>::type> > +class function_property_map: public put_get_helper<Ret, function_property_map<Func, Key, Ret> > { […] > + typedef Ret reference; […] > + reference operator[](const Key& k) const { > + return f(k); > + } > + > + reference operator[](const Key& k) { > + return f(k); > + } […] > + private: > + Func f; > +}; In const version of the subscript operator, `f` is treated as `const Func`. So `reference` might not be appropriate for its return type. You can avoid this issue by making `f` mutable. Or, how about defining the default template argument of `Ret` as `boost::result_of<const Func(Key)>::type` and removing non-const version of the subscript operator? (Since property maps are often passed around by values, it makes less sense to allow stateful functors in `function_property_map`, IMHO.) Regards, Michel

2 2

Re: [boost] Please advise: Boost with LLVM Clang and 0x11 dialect ?
by Steve Ramsey 24 Mar '12

24 Mar '12

On Mar 21, 2012, at 1:35 AM, "John M. Dlugosz" <mpbecey7gu(a)snkmail.com> wrote: > Can someone please advise on how to get Boost headers to work when compiling using Clang (as found on Apple OSX/iOS development) when the 0x11 dialect is enabled? > > We're stuck at Boost 1.47 because 1.48 doesn't even work with the current settings (C++03 dialect). The Mac developers don't want to fiddle with 1.49 without knowing what the deal is. > > Is there someone who has used Boost on the Apple with Clang who can relate some tales of how it works and offer suggestions? I've had no luck on the Boost.Users mailing list, or a previous post here on Boost.Devel. Is there anyplace else I might ask? At this point, any scrap of wisdom would be appreciated. It's not an automatic process, but once the initial effort is spent, it works beautifully. I should point out that I use both C++11 and libc++, and I ended up making a number of changes to boost build files to get various features working. The biggest problem is the lack of support in tools/build/v2/tools/clang-darwin.jam for specifying the SDK/platform for cross-compiling. My solution since boost 1.47 has been to replace it with a modified copy of tools/build/v2/tools/darwin.jam; if I thought this was going to be an issue for anywhere near as long as it has, I would've sent in a patch half a year ago (aside: do any of the maintainers actually use boost on OS X?). An additional complication is that as of Xcode 4.3, variant toolchains are stored in a different location and use a slightly different directory structure; a nice solution would be to support a build feature to indicate this and respond accordingly; I just hardcode for Xcode 4.3+. I'm happy to send you diffs off-list if you're interested, but it's frankenhacks all the way down until I get around to making a clean patch file for clang-darwin.jam. Steve P.S. The only source/header file with a problem is libs/signals/src/named_slot_map.cpp, which is trivially fixable.

2 1

[filesystem] [svn] How to remove V2 files without loss of V3 history?
by Beman Dawes 24 Mar '12

24 Mar '12

The boost/filesystem directory currently looks like this: v2 config.hpp // actual header convenience.hpp exception.hpp fstream.hpp operations.hpp path.hpp v3 config.hpp // actual header convenience.hpp exception.hpp fstream.hpp operations.hpp path.hpp config.hpp // forwards to v2/config.hpp or v3/config.hpp convenience.hpp exception.hpp fstream.hpp operations.hpp path.hpp It is time to remove the dual version support. What I'd like to do is: * create a branch, * switch to it, * delete the top level forwarding headers, * move the v3 headers up to boost/filesystem, * delete the v2 and v3 directories, * modify the headers as needed, * merge back to trunk. At the completion of the merge, the history for the boost/filesystem headers should include the full history of what were the boost/filesystem/v3 headers. What are the svn commands to accomplish that? Thanks, --Beman

6 15

[utility] Adding noexcept to boost::declval
by Michel Morin 24 Mar '12

24 Mar '12

Now that we have BOOST_NOEXCEPT macro, it is reasonable to add noexcept to boost::declval (by means of BOOST_NOEXCEPT). As a note, std::declval is marked as noexcept. I made a ticket with a patch here: https://svn.boost.org/trac/boost/ticket/6570 If it looks sensible, could someone apply the patch? Regards, Michel

1 1