- Boost - lists.preview.boost.org

Json read...segment by segment
by vijay.singh＠edisphere.com 07 Jul '15

07 Jul '15

Hi, I am using below code to read load Json file in boost::property_tree::ptree object. Function read_json(.) read all file content at a time. I want to know is there any way to read file content segment by segment. Thanks and regards, Vijay int _tmai3n(int argc, _TCHAR* argv[]) { try { std::stringstream ss; std::ifstream file("D:\\EdisphereComp\\kit\\1003_Kit\\1003\\Inputfiles\\AI98_Test_3.json", std::ios::binary); // Make sure we have something to read. if (!file.is_open()) { throw (std::exception("Could not open file.")); } // Copy contents "as efficiently as possible". ss << file.rdbuf(); boost::property_tree::ptree pt; boost::property_tree::read_json(ss, pt); boost::property_tree::write_json("D:\\EdisphereComp\\kit\\1003_Kit\\1003\\In putfiles\\AI98_Test_3_sprite.json", pt); } catch (boost::property_tree::json_parser_error e) { ; } //} return 0; }

4 7

Boost.Test v3 is in master
by Gennadiy Rozental 07 Jul '15

07 Jul '15

Hi, I've merged new Boost.Test into the master branch. We'll look for any regressions, but I do not expect big changes before release. Gennadiy

2 1

[test] Bug in Mingw support?
by John Maddock 07 Jul '15

07 Jul '15

The short program below passes with MSVC and GCC Linux, but fails with Mingw-x64 at runtime (the expected failures count gets ignored). This is with current develop. Any ideas? BTW the new decorator based approach does work OK, but is only supported on a tiny number of compilers as it seems to rely on the preprocessor lib using variadic macros, as opposed to Boost.Config marking them as available. Here's the program: #define BOOST_TEST_MAIN #include <boost/test/unit_test.hpp> BOOST_AUTO_TEST_CASE_EXPECTED_FAILURES(test_main, 10000); BOOST_AUTO_TEST_CASE(test_main) { BOOST_ERROR("one"); BOOST_ERROR("two"); } Thanks, John.

3 7

Boost Graph maintenance
by Oodini 07 Jul '15

07 Jul '15

Hello, I've been working on BGL for several days, and I'll probably have to work on it for a long time. The documentation is not very clear (I suspect it is outdated on some points), and as it doesn't seem complete. Also, the official maintener, Jeremiah Willcock, hasn't commited since the end of 2013. I'd like to work on the documentation, in the first time on the organization and presentation. If I amend the text later, I will need a reviewer (my english is not good enough). What would be the process ? I havn't participated to any Boost library.

5 5

Boost.Experimental Re: [variant] Maintainer
by Gottlob Frege 07 Jul '15

07 Jul '15

On Sun, Jun 28, 2015 at 10:29 AM, Agustín K-ballo Bergé <kaballo86(a)hotmail.com> wrote: > On 6/28/2015 5:38 AM, Vicente J. Botet Escriba wrote: >> >> Le 27/06/15 21:32, Agustín K-ballo Bergé a écrit : >>> >>> On 6/27/2015 12:38 PM, Vicente J. Botet Escriba wrote: >>>> >>>> I would accept Eggs.Variant without even a review (or with a minimal >>>> review) as an experimental library as part of Boost.Variant after some >>>> minimal adaptation to fit in Boost of course. >>> >>> First of, as I have already said before, Eggs.Variant is an >>> experiment. As such it is highly unstable, and I reserve the right to >>> change things in any way I see fit, with no regards for backwards >>> compatibility, maintenance, or support. I have made these kinds of >>> changes in the past, and I have more planned for the near future. I >>> think it would be unwise to make it a part of Boost, even as an >>> experimental library, until the design has fully hatched ("Eggs", get >>> it?). >> >> Agustin, this is exactly the kind of constraints of an experimental >> library. When the design is fully hatched then it moves to non >> experimental. > > > I fail to see the point in including an experimental library that changes > its interface every month into Boost, which is released every 3 months or > so. By the time you get your hands in a release, the interface of the > library has already changed. And the library as such would only exist for a > single release. > > Who would benefit from Boost packaging old snapshots of experimental > libraries? > > Perhaps you'd wish to bring back the Sandbox > (http://www.boost.org/community/sandbox.html) which has been superseded by > standalone repositories since the move to Git. > I think we need *something* for experimental libraries. Even if it is just someone's own git repository stamped (but not endorsed) with the Boost "brand". Or a page in boost.org listing current experiments. Or... something. There are (at least) 2 needs that Boost tackles: 1. great libraries that solve problems for developers 2. great libraries that can turn into std:: libraries I think we are doing better on 1 than 2. I think 2 requires more experimentation (whereas 1 requires more stability). Yes I know 2 looks successful - just look at how much of boost is in C++11. But when each Boost library is brought to the committee, we have 2 choices: - make design changes before going into std - take as is Making design choices in a committee (and without experimenting) is not always a good idea. We are, in theory at least, suppose to standardize existing behaviour. Taking as is means we are accepting whatever was good enough to pass Boost review as *best*. Boost review is a high bar, but the std:: should be higher. It is common for the committee to hear/say "boost users have been using it this way for years". That is usually a good strong argument - we want/need implementation and usage experience. But saying "this works" doesn't mean something else could work better. Implementation/usage experience is most accurate when it says "this does NOT work", because then you have ruled out an option. When you say "this works", it doesn't rule out options that might work _better_. We are increasingly going with option 3: - put into std::experimental which delays the desired outcome of getting great libraries into the standard. I'd like some kind of experimental area that would help find the best possible libraries. What I'd _really_ like is more experimentation in _current_ Boost libraries, breaking users left and right - I'd rather break boost users than std:: users. (We have and will make breaking changes in the standard library). But I understand that current users wouldn't be too happy about breaking changes _just for experimentation's sake_. And if we lost the boost user base, boost would no longer be helpful to the standard at all. (As a reasonable example of not being afraid of breaking changes: Sean Parent's Adobe Standard Library would boldly break whenever he thought something could be made better. It didn't break just for experimenting, but he wasn't afraid to make breaking changes for the better.)

6 11

[predef] Using predef-check on 'develop' problem
by Edward Diener 06 Jul '15

06 Jul '15

In a jam file I have for a run test a predef-check which looks like: run test_variadic_macro.cpp : : : [ predef-check "BOOST_COMP_GNUC >= 4.3" "BOOST_OS_QNX == 0" : : <cxxflags>-std=c++0x ] ; When running on QNX with the gcc version greater than 4.3 I would expect that -std=c++0x would not be added as a C++ compile parameter to the run. Yet it is being added to the run. Another test confirms that BOOST_OS_QNX is indeed being set to a non-zero value. Is there a bug in predef-check ? Am I using it incorrectly ?

4 45

Testing InputIterator on the interface
by Benedek Thaler 05 Jul '15

05 Jul '15

Hi, I'd like to verify my methods accepting an input range (two iterators modelling InputIterator) do a single pass over the range at most. I'd like to have an iterator adaptor, which erases the visited element upon incrementing. So far, I found these: 1) https://github.com/boostorg/test/blob/master/include/boost/test/utils/itera… I couldn't find its documentation, and does not seem to what I want. 2) https://github.com/boostorg/container/blob/master/test/input_from_forward_i… Despite the name, still not something I want. I'm developing a Boost.Container class [0], so using container/test would be okay. Is there such a thing ready somewhere or shall I roll my own? Thanks, Benedek [0]: https://github.com/erenon/container/blob/devector/include/boost/container/d…

2 3

Re: [boost] [Boost-users] Boost.DLL formal review is ongoing
by Klaim - Joël Lamotte 04 Jul '15

04 Jul '15

On 4 July 2015 at 11:38, Antony Polukhin <antoshkka(a)gmail.com> wrote: > 2015-07-04 0:16 GMT+03:00 Klaim - Joël Lamotte <mjklaim(a)gmail.com>: >> >> >> On 3 July 2015 at 15:50, Vladimir Prus <vladimir.prus(a)gmail.com> wrote: >>> >>> - What's your evaluation of >>> - Design >>> >> >> I consider the solutions provided to solve each usual issue with plugin >> systems to be simple >> and clear, easy to use (as long as you understand what loading plugins >> imply). >> >> Until I check in some complex cases, I think the design is very good. >> The symbol name magic might be tricky to understand sometime but it's an >> issue which is a side effect of providing >> a simple tool to manage symbole names, so it's still good. >> >> One thing I was wondering: would it be possible to provide a way to load >> shared libraries from >> raw memory? Or does the OS APIs all requires that the library have to be >> on a file sytem? >> > > Unfortunately, there's no portable way to load libraries from raw memory. > However you can always mount a filesystem that directly maps to memory (for > example Tmpfs on Linux) and store your data in there. This may look like a > big performance overhead, but actually loading a shared library takes much > time so you won't probably notice the overhead of additional create_file + > memcpy. > It's ok, the solution to write a shared library in the the filesystem before loading it is what Ihave been doing so far and it works well. I was just wondering if it was possible with memory. :) If the plugin is in an archive file, I have to extract it in a temporary directory before loading it, which is what I would like to avoid, but it seems unavoidable. > > If you're planing this feature to write interpreters\JIT compillers and > you just need a place to store end execute generated native code, then > Boost.Interprocess's memory mapped files fill probably suit you better. > Shared libraries contain a lot of headers, helper data for load and a bunch > of other stuff that would be really hard to generate. > I don't write an interpreter (I'm really just managing plugins) but I didn't know that, it seems useful in some other contexts. Thanks for the pointer.

1 0

Fwd: [Boost-users] Boost.DLL formal review is ongoing
by Antony Polukhin 04 Jul '15

04 Jul '15

2015-07-04 0:16 GMT+03:00 Klaim - Joël Lamotte <mjklaim(a)gmail.com>: > > > On 3 July 2015 at 15:50, Vladimir Prus <vladimir.prus(a)gmail.com> wrote: >> >> - What's your evaluation of >> - Design >> > > I consider the solutions provided to solve each usual issue with plugin > systems to be simple > and clear, easy to use (as long as you understand what loading plugins > imply). > > Until I check in some complex cases, I think the design is very good. > The symbol name magic might be tricky to understand sometime but it's an > issue which is a side effect of providing > a simple tool to manage symbole names, so it's still good. > > One thing I was wondering: would it be possible to provide a way to load > shared libraries from > raw memory? Or does the OS APIs all requires that the library have to be > on a file sytem? > Unfortunately, there's no portable way to load libraries from raw memory. However you can always mount a filesystem that directly maps to memory (for example Tmpfs on Linux) and store your data in there. This may look like a big performance overhead, but actually loading a shared library takes much time so you won't probably notice the overhead of additional create_file + memcpy. If you're planing this feature to write interpreters\JIT compillers and you just need a place to store end execute generated native code, then Boost.Interprocess's memory mapped files fill probably suit you better. Shared libraries contain a lot of headers, helper data for load and a bunch of other stuff that would be really hard to generate. -- Best regards, Antony Polukhin

1 0

[next gen futures] Lightweight monad ready for inspection
by Niall Douglas 03 Jul '15

03 Jul '15

Some may remember the thread starting from http://boost.2283326.n4.nabble.com/next-gen-future-promise-What-to-cal l-the-monadic-return-type-td4676039.html and that I would firstly prepare an optimally lightweight monad<T> for review here before going on to base a next-gen lightweight future-promise on that monad<T>. I didn't expect it would take nearly four weeks to get there, but writing STL quality C++ with full conformance test suite is amazingly labourious. Anyway you can now view the design and tell me what you think. A quick overview of the design: This monad can hold a fixed variant list of empty, a type R, a lightweight error_type or a heavier exception_type at a space cost of max(20, sizeof(R)+4). Features: * Very lightweight on build times and run times up to the point of zero execution cost and just a four byte space overhead. Requires min clang 3.2, GCC 4.7 or VS2015. A quick sample of runtime overhead, min to max opcodes generated by GCC 5.1: 1 opcodes <= Value transport <= 113 opcodes 8 opcodes <= Error transport <= 119 opcodes 22 opcodes <= Exception transport <= 214 opcodes 4 opcodes <= then() <= 154 opcodes 5 opcodes <= bind() <= 44 opcodes * Just enough monad, nothing more, nothing fancy. Replicates the future API with a fair chunk of the Expected<T> API, so if you know how to use a future you already know how to use this. * Enables convenient all-noexcept mathematically verifiable close semantic design, so why bother with Rust anymore? :) * Can replace most uses of optional<T>. * Deep integration with lightweight future-promise (i.e. async monadic programming) also in this library. * Comprehensive unit testing and validation suite. * Mirrors noexcept of type R. * Type R can have no default constructor, move nor copy. * Works inside a STL container, and type R can be a STL container. * No comparison operations nor hashing is provided, deliberately to keep things simple. Documentation page: https://ci.nedprod.com/view/Boost%20Thread-Expected-Permit/job/Boost.S pinlock%20Test%20Linux%20GCC%204.8/doxygen/classboost_1_1spinlock_1_1l ightweight__futures_1_1monad.html Source code: https://github.com/ned14/boost.spinlock/blob/master/include/boost/spin lock/monad.hpp Online wandbox compiler: http://melpon.org/wandbox/permlink/cnZM5KRNpjErXrPH Any opinions or thoughts gratefully received, particularly if I have the exception safety semantics right (i.e. a throw during move or copy leaves the monad empty). Do you also like the polymorphic bind() and map() which does different things depending on the parameter type your callable takes? Do you like that by simply changing the callable's type to a rvalue reference you can move state, or is this being too clever? This monad will become the basis of lightweight future-promise which is essentially a "split monad" with the setter interface and getter interface potentially in different system threads. The then(), bind() and map() work as here but only are triggered at the point of the value being changed. This effectively makes the lightweight future a "lazy continued monad". That lightweight future-promise will then enter AFIO to replace its async_io_op type hopefully in time for the peer review this time next month. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/

10 42