- Boost - lists.preview.boost.org

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

[config] Macro for unused declarations
by Jeremiah Willcock 21 Oct '13

21 Oct '13

Would it be possible to have a macro for __attribute__((unused)) and similar pragmas to portably avoid "unused typedef" and related warnings (especially from recent versions of GCC)? I have mostly removed those in Boost.Graph, but there are some that need to remain---creating a typedef to a member type of a class to make sure that the member exists, for example. Thank you. -- Jeremiah Willcock

3 2

When Boost modularization and Git migration coupling were accepted on this ML?
by Vicente J. Botet Escriba 21 Oct '13

21 Oct '13

Hi, I would not take the time to inspect all the post relating to this subject. There are a lot of post related to the subject, a lot of discussion, but what I'm locking for is a decision. So please don't replay to this post by telling me, you have just to use this tool or this other tool to have the answer. If you consider that this post is bicksheding or a bad post, please, just ignore it. I remember a post that deceded to move to Git long time ago. I would just know if (and when) the Boost community has decided to couple the move to Git and the Boost modularization. And i would like to know also if changes to the trunk repository without requesting authors permission were allowed on this move. Who accepted the plan described by S. Kelly ? Who gave him the right to update the whole Boost repository? Was this discussed on this ML or on a specific ML that is not an official Boost ML? Le 18/10/13 00:24, Stephen Kelly a écrit : > my plan for modularizing and modernizing Boost was roughly this: > > * Phase 0 - remove dead weight by bumping compiler feature requirements > * Phase 1 - move some files around so that the modularized repos form a > mostly directed graph > * Phase 2 - Form some kind of 'boost core library' or 'boost feature > normalization library' from the guts of existing libraries like > type_traits, static_assert, config mpl and utilities. > * Phase 3 - Try to port the mpl to variadic templates so that the > dependency on Boost.PP is not needed when variadic templates are available. Apologies if this is clear for most of you. IMHO, this kind of decisions should be posted with an explicit title. Best, Vicente

3 2