May 2014 - Boost - lists.boost.org

Anyone is interested in being review manager of ‘Application’?
by Renato Forti 30 May '14

30 May '14

Hi All, The proposed ‘Boost.Application’, needs a Review Manager. Anyone is interested? The Docs: http://www.dokfile.com/appbeta4/docs/libs/application/doc/html/index.html The Project: https://github.com/retf/Boost.Application

40 124

[utility][detail] Moving binary_search_test from utility to detail.
by Daniel James 30 May '14

30 May '14

Hi, I've created a couple of pull requests to move this test from utility to detail, as the header it's testing is in detail. I guess it's in utility because there weren't any detail unit tests when it was created. If there are no objections I'll merge them this weekend. https://github.com/boostorg/utility/pull/9 https://github.com/boostorg/detail/pull/2 Daniel

1 0

How do you read this list?
by Gennadiy Rozental 30 May '14

30 May '14

Hi, I am having real problem following boost list nowdays. The second time this year gmane stopped posting RSS feed updates (last time it did not post any updates for like two month) and it was not even updating web interface for like a week recently. Is there any other browser based alternative for reading and posting? Gennadiy

4 4

[smart_ptr][intrusive] boost::unique_ptr<>
by Adam Wulkiewicz 30 May '14

30 May '14

Hi, I remember that there was plans to release an "official" STD-conformant implementation of boost::unique_ptr<>. I found: http://boost.2283326.n4.nabble.com/unique-ptr-for-C-03-td4650231.html http://boost.2283326.n4.nabble.com/C-03-unique-ptr-emulation-td2658449.html Do someone know what's the outcome of this initiative? Regards, Adam

4 6

[test] Looking for co-developer/maintainer
by Gennadiy Rozental 29 May '14

29 May '14

Hi, I think this is somewhat overdue. It's obvious various forces pulling me in different direction won't allow me to continue to do this all by my own. I am still plan to contribute and maintain the library, but I do believe it can be served better if someone can volunteer to share the load with me. There are both maintenance and development tasks in pipe. I have in mind quite a few very interesting features we can extend Boost.Test with (aside from those already requested by users and waiting to be implemented). These include: MT testing support performance testing support Mocking library GUI/DE integration and more Short term though I need help pushing to the release features which are already implemented in trunk and waiting to be released. Major showstopper is absence of proper documentation for these. So one of the first things we'll need to do is to write one. We also need to improve unit testing and finally push this release though some form of boost review. I do not have any specific requirements for the applicant, aside from interest in the library and willingness to work with me. I do not mind several people helping out with documentation, but longer term I'd prefer not very large group of maintainers for the library. If you are interested please shoot me email off list to rogeeff at gmail. Regards, Gennadiy

14 49

[config][predef] Is it OK for boost.config to depend on boost.predef?
by Beman Dawes 29 May '14

29 May '14

There is a config pull request outstanding that includes <boost/predef.h>. If it was almost any library other than config, I'd apply this without a second thought. But Boost config is special in that if it breaks, virtually the whole of boost breaks. So it makes sense to be cautious about dependencies. Has there been any discussion about the relationship between Boost.config and Boost.predef? Even if we accept the patch, is <boost/predef.h> the right header? It just forwards: #include <boost/predef/language.h> #include <boost/predef/architecture.h> #include <boost/predef/compiler.h> #include <boost/predef/library.h> #include <boost/predef/os.h> #include <boost/predef/other.h> #include <boost/predef/platform.h> The rationale for the pull request is a need in other Boost libraries to detect Windows platform variants like BOOST_PLAT_WINDOWS_DESKTOP andBOOST_PLAT_WINDOWS_RUNTIME. Boost.Predef does a nice job of that. But the only header strictly needed is <boost/predef/platform.h>. So the desired effect can be achieved several ways: 1) #include <boost/predef.h> in the include/boost/config/platform/ headers. 2) #include <boost/predef/platform.h> in the include/boost/config/platform/ headers. 3) #include <boost/predef.h> in the files that actually use the desired macros. 4) #include <boost/predef/platform.h> in the files that actually use the desired macros. If I had been writing the code myself, I probably would have selected option (4). What do others think? --Beman

5 11

[utility][optional] boost::equal_pointees -- move it?
by Andrzej Krzemienski 29 May '14

29 May '14

Hi, I recently noticed that there is a plan to move everything out of Boost.Utility. Is that right? There is a small feature in there: http://www.boost.org/doc/libs/1_55_0/libs/utility/OptionalPointee.html (header <boost/utility/compare_pointees.hpp>, added along Boost.Optional. Should it be moved out of Utility to Boost.Optional also? If so, any hints on how I should preserve the backwards compatibility for its users? Regards, &rzej

1 0

Re: [boost] [config][predef] Is it OK for boost.config to depend on boost.predef?
by Rene Rivera 29 May '14

29 May '14

On Wed, May 28, 2014 at 12:45 PM, Robert Ramey < robertmacleranramey(a)gmail.com> wrote: > > The whole existence of boost predef was a huge surprise to me. > It was reviewed and accepted ;-) > Looking at the dates it seems its been in boost for a while. I perused > the documentation. I'm still not getting how this doesn't overlap with > config..hpp. I thought that config.hpp was designed to address the issue > of portability between platforms. > Boost Config is indeed designed to address portability between platforms. As a requirement of that design it also has to deal with detecting the different platforms it's trying to define feature/defect macros for. Detecting the platform is not a requirement for Config to work. And you can run the Config configure program to generate a set of portability feature/defect definitions without knowing about the platform. > So I would expect that a facility such as > > #include <boost/predef/platform/windows_desktop.h> > #include <boost/predef/platform/windows_runtime.h> > > would depend upon config.hpp rather than the other way around. > > And since config.hpp is designed to determine the platform automatically, > I'm very surpassed to see predef at all. > "config.hpp" has to partially determine the "platform" by need not by design. > Any additional information you want to submit would be interesting to see. > Predef's design is to *not* detect or define feature/defect macros. All it does is the detection of the platform (compiler, libraries, etc). With enough fine grained platform information one can use it to define know feature/defect macros. Predef defines a much larger superset of the Config platform defs <http://tinyurl.com/o68ovjz> in a consistent (and consistent to check) manner. Or more succinctly: * Predef detects the environment you are compiling in. * Config defines what is or isn't broken with that environment relative to the ideal/standard -conforming environment. HTH -- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net -- rrivera/acm.org (msn) - grafikrobot/aim,yahoo,skype,efnet,gmail

2 1

[config] any macro to detect "Rvalue references for *this"?
by Andrzej Krzemienski 29 May '14

29 May '14

Hi, Is there a macro in Boost.Config that would help me test if a compiler supports a C++11 feature "Rvalue references for *this" ( http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2439.htm)? Regards, &rzej

3 11

Adding spirit::is_container to boost::traits
by Rodrigo Madera 28 May '14

28 May '14

Is there any intention of including is_container [1] into boost::traits? I find myself using that particular Spirit header, which could be useful if isolated into traits. Cheers, Madera [1] http://www.boost.org/doc/libs/1_55_0/libs/spirit/doc/html/spirit/advanced/c…

4 9