- Boost - lists.boost.org

[filesystem] Heads up; filesystem in trunk unstable while V2 removed
by Beman Dawes 26 Mar '12

26 Mar '12

To ensure that history is preserved, the removal of version 2 will be done as three commits. Filesystem in trunk will be unstable during until all three commits are completed. Hopefully this will take less than an hour. I'll post a notice when complete. --Beman

3 7

[gsoc]
by Andrew Sutton 26 Mar '12

26 Mar '12

It looks like there will be no summer of Code for Boost this year. For whatever reason, Google has decided not to accept Boost as a mentoring organization. Andrew

10 18

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

26 Mar '12

(Forgot to send to the list; now back to the list again.) Vicente J. Botet Escriba wrote: > OK, I will rollback it and analyze the breaking change. The important thing is that declval<T>() should preserve the constness/non-constness and the rvalueness/lvalueness of T. Essentially, it's OK to define declval<T>() as simply T. Then, why declval<T>() is defined as add_rvalue_reference<T>::type? This is because * When declval<T>() is defined as T, we cannot use abstract types as T. * When declval<T>() is defined as T&&, we cannot use void as T. The definition with add_rvalue_reference<T>::type also allows to use incomplete types as T. In C++03, it is not possible to construct rvalues of abstract types or incomplete types. So, the correct way to define declval<T>() in C++03 is to just use T. And this is the definition of declval<T>() in the previous version of boost::declval when BOOST_NO_RVALUE_REFERENCES is defined. Summary: Defining declval<T>() as add_lvalue_reference<T>::type is wrong; add_lvalue_reference should be removed! Regards, Michel

1 0

Re: [boost] [gsoc]
by Andrzej Krzemienski 26 Mar '12

26 Mar '12

> From an outside point of view, i do agree. I don't see a lot of Boost GSOC > projects completed. And that's really disapointing. > In my fileds of interests, i would love to see some libraries integrated > that deals with : > - large integer / large fixed point computation > - json parser/ writer > - xml parser/ writer like pugiwml > - crossplatform async file io for boost asio (not only for windows) > - xmpp/sip stack Boost does provide parsers and writers for JSON and XML files. See http://www.boost.org/doc/libs/1_49_0/doc/html/property_tree.html. Regards, &rzej

2 1

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