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

Boost.Build commit heads up
by Beman Dawes 23 Oct '13

23 Oct '13

Here is the commit message for revision 86392: Add Boost.Build support for the Git modular layout, using links to to new header locations, thus preventing breakage to vast amounts of user code and build setups. Being added to SVN so that changes will automatically propagate to Git and modular Boost. Thanks to Steven Watanabe, Jürgen Hunold, Vladimir Prus, and Bjørn Roald for developing this patch. Steven in particular conceived the approach and did the initial implementation, which was further refined by the other contributors. In theory this commit won't break any existing boost builds. To verify that, on Win 7 and Ubunto I've done a fresh SVN checkout of trunk and verified bootstrap.bat, bootstrap.sh, and a b2 build work both before and after the patch is applied. On Windows, I verified that after the patch is applied a b2 build using an unpatched prior compilation of b2 still works. These tests increase confidence that committing the patch to trunk now isn't likely to cause breakage, but please post to this list right away if you spot any build breakage or other odd behavior. The files modified are listed below. Thanks, --Beman Modified: D:\boost\trunk\Jamroot Modified: D:\boost\trunk\libs\geometry\index\example\Jamfile.v2 Modified: D:\boost\trunk\libs\numeric\odeint\examples\vexcl\Jamfile.v2 Modified: D:\boost\trunk\libs\parameter\doc\html\index.html Modified: D:\boost\trunk\libs\parameter\doc\index.rst Modified: D:\boost\trunk\libs\python\example\Jamroot Modified: D:\boost\trunk\libs\python\example\quickstart\Jamroot Modified: D:\boost\trunk\libs\python\example\tutorial\Jamroot Modified: D:\boost\trunk\libs\signals2\example\Jamfile.v2 Modified: D:\boost\trunk\libs\spirit\example\qi\json\build\Jamfile Modified: D:\boost\trunk\libs\units\test\Jamfile.v2 Modified: D:\boost\trunk\tools\Jamfile.v2 Modified: D:\boost\trunk\tools\regression\build\Jamroot.jam

5 6

Re: [boost] [git help] Documenting common modular boost workflows
by Daryle Walker 23 Oct '13

23 Oct '13

Since a project that’s made of a bunch of sub-repositories that’s later merged is (AFAIK) unusual, I don’t think the writer of gitflow had it in mind. I’m guessing that each sub-repository independently uses gitflow. When it’s shipping time, the release-merge script grabs from the “master” branch of each sub-repository. Of course, this doesn’t cover multiple libraries that have to work together or what happens when fixing is necessary (probably due to cross-library problems). And do the test runners work off “develop,” “master,” “release,” or does it shift depending where we are in the release cycle? Sent from Windows Mail From: Peter Dimov Sent: ‎Monday‎, ‎October‎ ‎21‎, ‎2013 ‎10‎:‎16‎ ‎AM To: Boost Dev-List Dave Abrahams wrote: > IIUC we already agreed long ago to use gitflow: It's not entirely clear to me what using gitflow would mean in the context of a Boost superproject with per-library submodules. Who is "we" who would be using gitflow, the Boost release managers or the library maintainers? When Boost release 1.64.0 is started, who is going to create the gitflow release branch, and from what? _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

4 4

Reading & Parsing an .ini input file using BOOST... ..!!
by Rahul Mathur 22 Oct '13

22 Oct '13

All, Need small help. I have an "input.ini" input file which contains sample values like – --- App=| 5000 | 5001 | 0 | | | | 1BYTE | --- Starting with word (viz. App), followed by equal sign, than data within pipes (|) and blank space between two pipes ( | | ). Anything only between two pipes is to be read. I am looking to parse this input file. After parsing, assign each data to struct member type and than send this complete struct as socket. I am looking to use Boost property tree (or the needed one) and finally the ASIO to send the complete filled struct as stream. I tried below code to read complete data and it worked but - --- #include <iostream> #include <boost/property_tree/ptree.hpp> #include <boost/property_tree/ini_parser.hpp> #include <boost/filesystem/fstream.hpp> int main() { boost::property_tree::ptree pt; boost::property_tree::ini_parser::read_ini("input.ini", pt); std::cout << pt.get<std::string>("App") << std::endl; } --- But, how to read between pipes? Any clue?

1 0

Re: [boost] Boost.Build commit heads up
by Klaim - Joël Lamotte 22 Oct '13

22 Oct '13

(my last email is still in moderaition because of the zip with the log) On Tue, Oct 22, 2013 at 11:40 PM, Klaim - Joël Lamotte <mjklaim(a)gmail.com>wrote: > The boost build on my Win764bit finished for me for both VS2012 and > VS2013, apparently no error in the log I'm attaching to this mail with the > build script (which uses b2). > I'll try now to compile my main project. > I forgot to say that the revision I built was trunk r86395. So building boost with b2 now don't spawn errors, but compiling my project I still hit this bug: https://svn.boost.org/trac/boost/ticket/9266 see comments for details. (By the way, does the test suite is able to catch such compiler crashes?) To continue compiling my project, see other errors, I modified synchronized_value to activate only the code that do use variadic templates, which is a workaround I suggested in the bug report. I'm waiting for the rest of the project build right now.

1 1

[1.55] VS2013 massively failing
by Joaquin M Lopez Munoz 22 Oct '13

22 Oct '13

I understand this is being taken care of, but... VS2013 is failing to pass most libs in the release branch. For the one I care about most the problem is: D:\teeks99-10\boost\boost/mpl/aux_/preprocessed/plain/arg.hpp(45) : error C2039: 'assert_not_arg' : is not a member of 'boost::mpl' which seems to be fixed in trunk. Thank you, Joaquín M López Muñoz Telefónica Digital

3 2

Reading & Parsing an .ini input file using BOOST... ..Thanks!!
by Rahul Mathur 22 Oct '13

22 Oct '13

All, I have an .ini input file which contains sample values like – --- App=| 5000 | 5001 | 0 | | | | 1BYTE | --- Starting with word (viz. App), followed by equal sign, than data within pipes (|) and blank space between two pipes ( | | ). Anything only between two pipes is to be read. I am looking to parse this input file. After parsing, assign each data to struct member type and than send this complete struct as socket. I am looking to use Boost property tree (or the needed one) and finally the ASIO to send the complete filled struct as stream. Any clue?

2 2

Request permission to apply patch to trunk.
by Beman Dawes 22 Oct '13

22 Oct '13

I'd like to apply the attached patch to trunk. It is not supposed to break anything on an svn checkout, but we held off applying it until 1.55 beta shipped because of concern it would be disruptive if it somehow messed up the build system right in the middle of getting the beta out. Thanks to Bjørn Roald for developing the patch. Without this patch, the only way to test modular-boost headers mechanism is to manually apply the patch yourself, and that pretty much limits testing. OK to apply? --Beman

5 7

[modernization][skelly] Surprising changes
by Agustín K-ballo Bergé 22 Oct '13

22 Oct '13

I was going through recent Boost.Spirit changes and I was surprised to see this code: #if (defined(BOOST_MSVC) && (BOOST_MSVC < 1310)) \ || (defined(__BORLANDC__) && (__BORLANDC__ <= 0x570)) \ || (defined(__GNUC__) && (__GNUC__ < 3)) \ || (defined(__GNUC__) && (__GNUC__ == 3) && (__GNUC_MINOR__ < 1)) # error "Compiler not supported. See note in <boost/spirit/core/config.hpp>" #else // Pass... Compiler supported. #endif modified into this code: #if (defined(__BORLANDC__) && (__BORLANDC__ <= 0x570)) # error "Compiler not supported. See note in <boost/spirit/core/config.hpp>" #else // Pass... Compiler supported. #endif The whole point of the check is to detect unsupported compilers. It seems the modernization changes do not take into account the context in which they are done. To Stephen Kelly: I would like to suggest going over your modernization commits looking for unwanted changes like this one, and reverting them. I have already revisited your modifications to Boost.Spirit and found all changes but the one I mentioned to be valid ones (thank you for those!). Regards, -- Agustín K-ballo Bergé.- http://talesofcpp.fusionfenix.com

2 1

[multiprecision] New binary floating point type
by John Maddock 21 Oct '13

21 Oct '13

Folks, One of the main feature requests during the multiprecision lib review was for a binary floating point type. There is now such a type in the sandbox under the "multiprecision.cpp_bin_float" directory - you will also need latest SVN Trunk to try this out. This new type is correctly rounded to nearest for all arithmetic operations plus binary-decimal conversions and sqrt. Minimal docs so far here: https://svn.boost.org/svn/boost/sandbox/multiprecision.cpp_bin_float/libs/m… I'd welcome comments, and if folks would like to try and break it, that would be cool too ;-) Regards, John.

2 4

Re: [boost] [mpl] integral_c [type_traits] integral_constant limits
by Krzysztof Czainski 21 Oct '13

21 Oct '13

2012/1/4 Vicente Botet <vicente.botet(a)wanadoo.fr> > > Any new on the application of this patch? Could I apply my self and commit > in trunk? > > Vicente > > -- > View this message in context: > http://boost.2283326.n4.nabble.com/mpl-integral-c-type-traits-integral-cons… > > Hi, I just bumped into this bug with MinGW-4.8, which treats this as an error. I use boost-1.54 My simple test case is: #include <boost/mpl/integral_c.hpp> typedef boost::mpl::integral_c<int,0x7fffffff>::type next_ovf; typedef boost::mpl::integral_c<int,0x80000000>::type prior_ovf; I worked around my test by doing changing linest 74-75 of boost/mpl/aux_/integral_wrapper.hpp to typedef AUX_WRAPPER_INST( BOOST_MPL_AUX_STATIC_CAST(AUX_WRAPPER_VALUE_TYPE, (::boost::intmax_t(value) + 1)) ) next; typedef AUX_WRAPPER_INST( BOOST_MPL_AUX_STATIC_CAST(AUX_WRAPPER_VALUE_TYPE, (::boost::intmax_t(value) - 1)) ) prior; This only moves the problem from int to intmax_t, but the workaround works for me ATM. Could this please be fixed? I had this idea of fixing it by providing specializations of integral_c for the limits cases? And the specializations wouldn't typedef the offending next or prior. Would that work? I'd have tried that myself, but this integral_wrapper.hpp file and it's macros scared me away from this idea ;-) Regards, Kris

1 0