August 2014 - Boost-users - lists.boost.org

Re: [Boost-users] [Chrono] The default BOOST_CHRONO_VERSION is still 1
by DonM 24 Aug '14

24 Aug '14

-------- Original Message -------- Subject: Re: [Boost-users] [Chrono] The default BOOST_CHRONO_VERSION is still 1 From: "Vicente J. Botet Escriba" <vicente.botet(a)wanadoo.fr> Date: 8/23/2014 6:28 AM To: boost-users(a)lists.boost.org > > Le 23/08/14 01:41, DonM a écrit : >> The docs (boost_1_56_0/doc/html/chrono/reference.html) say: >> >> "The default value for BOOST_CHRONO_VERSION will be changed to 2 since Boost 1.55. " >> >> However, it still has the value 1 in both 1.55 and 1.56. >> >> Not a big deal, I just noticed and figured I'd mention it. >> > Hi, > > I must remove this comment as as there is a incompatibility this will break user code. I planned to do a smooth trarnsition, but there were some complains. > > Thanks for pointing this issue, > Vicente Are you saying that you never intend to change the default value? That would be a mistake, in my opinion. Version 2 is much better -- the I/O stuff works. If users need backwards compatibility, they can define version 1, but encourage people to use version 2. Just my $0.02. Don

2 1

[move] Movable but not copyable bug?
by Mostafa 24 Aug '14

24 Aug '14

Given the following code, if (1) is uncommented then it fails to compile under C++03 mode yet works in C++11 mode. If commented out, then it compiles successfully under both modes. (g++ 4.8.2 is being used) Is this behavior expected or a bug? #include <boost/move/core.hpp> #include <boost/move/utility.hpp> struct Foo { Foo(int x, int y) {} Foo(BOOST_RV_REF(Foo) rhs) {} private: //Purposefully declared and not defined. Foo & operator=(Foo); private: BOOST_MOVABLE_BUT_NOT_COPYABLE(Foo) }; template <typename T> struct Bar { Bar() : f(0, 1) {} // (1) // Bar(Bar const & rhs) // : f(rhs.f) // {} Bar(BOOST_RV_REF(Bar) rhs) : f(::boost::move(rhs.f)) {} private: //Purposefully declared and not defined. Bar & operator=(Bar); private: BOOST_COPYABLE_AND_MOVABLE(Bar) private: T f; }; Foo f1() { // (2) // Foo f(0, 1); // return f; // (3) return Foo(0, 1); } Bar<Foo> f2() { return Bar<Foo>(); } int main() { // Foo f( f1() ); Bar<Foo> b(Bar<Foo>()); return 0; }

2 2

BGL: boost::astar_search_no_init
by Georg Gast 24 Aug '14

24 Aug '14

Hi there! Currently i try to implement an astar search with BGL and boost. My graph is infinite, so i searched for an example of astar_search_no_init and found this: http://lists.boost.org/boost-users/2012/03/73707.php I am on gcc-4.9.0 and boost 1.52.0 on linux. I try to compile the above example and get the following error which i cant decipher ... make gcc -std=c++11 example.cpp -o example example.cpp: In function 'int main(int, char**)': example.cpp:274:140: error: no matching function for call to 'boost::associative_property_map<default_map<std::pair<XY, XY>, unsigned int> >::associative_property_map(default_map<std::pair<XY, XY>, unsigned int>)' . weight_map(boost::associative_property_map<default_map<std::pair<XY,XY>,unsigned> >(default_map<std::pair<XY,XY>,unsigned>(1))) I added the code as an attachement. For me it seems that this line is not ok .... but i currently have no clue how to fix it ... try { astar_search_no_init(g, start, distance_heuristic<XYGraph>(goal) , visitor(astar_goal_visitor(goal)) . distance_map(d) . predecessor_map(boost::ref(p)) . weight_map(boost::associative_property_map<default_map<std::pair<XY,XY>,unsigned> >(default_map<std::pair<XY,XY>,unsigned>(1)) // < --- line 274 . vertex_index_map(boost::associative_property_map<std::map<XY,unsigned> >(std::map<XY,unsigned>())) . rank_map(boost::associative_property_map<std::map<XY,unsigned> >(std::map<XY,unsigned>())) . color_map(boost::associative_property_map<std::map<XY,boost::default_color_type> >(std::map<XY,boost::default_color_type>())) . distance_compare(std::less<unsigned>()) . distance_combine(std::plus<unsigned>()) ); with clang 3.4 i get this error line. clang --std=c++11 example.cpp -o ex example.cpp:274:26: error: no matching conversion for functional-style cast from 'default_map<std::pair<XY, XY>, unsigned int>' to 'boost::associative_property_map<default_map<std::pair<XY, XY>, unsigned int> >' . weight_map(boost::associative_property_map<default_map<std::pair<XY,XY>,unsigned> >(default_map<std::pair<XY,XY>,unsigned>(1)) So what ant the author of this code do? Allocate a property map of size 1? Currently i dont see the forrest, there are so many trees in my view .... Any help would be appreciated! Thank you! Georg

1 0

[Chrono] The default BOOST_CHRONO_VERSION is still 1
by DonM 23 Aug '14

23 Aug '14

The docs (boost_1_56_0/doc/html/chrono/reference.html) say: "The default value for BOOST_CHRONO_VERSION will be changed to 2 since Boost 1.55. " However, it still has the value 1 in both 1.55 and 1.56. Not a big deal, I just noticed and figured I'd mention it. Don

2 1

Boost.ASIO calling handler guarantees
by Фёдор Трушкин 23 Aug '14

23 Aug '14

Hello, Dear All, I'm playing with Boost.ASIO framework and failed to find a complete answer on the following question. Under which circumstances is it guaranteed that asynchronous operation completion handler is called? Plainly speaking, is this example code correct? void my_handler(const error_code &ec) { if(!ec) { /* process successful operation */ } else { /* process failed operation */ } try { async_write(port, my_handler2) } catch(...) { // processing failure to execute asynchronous operation } } Obviously here I rely heavily upon the above mentioned guarantee. Looking at least at async_write() implementation, it cannot be relied upon: - async_write executes a chain of boost::asio::detail::write_op() operations: - if asio_handler_allocate() may throw then - write_op::stream_.async_write_some() may throw then - write_op.handler_() might never be called So, either we should never rely on this assumption, or there's a bug in async_write(). Not relying on this assumption what is the reliable way of building applications with Boost.Asio? Sincerely yours, Fedor Trushkin

3 3

Installing 1.56 on Fedora 20
by Robert Jones 22 Aug '14

22 Aug '14

It's been a while since I've installed Boost. Running this command on a completely vanilla Fedora 20 b2 --prefix=~/local/boost-1.56.0 --layout=tagged link=shared threading=multi,single install Finally says... ...failed updating 58 targets... ...skipped 12 targets... ...updated 12214 targets... Is this normal? Thx, Rob.

3 5

exercism.io -- crowd-sourced mentorship C++ track online
by legalize+jeeves＠mail.xmission.com 22 Aug '14

22 Aug '14

[Please do not mail me a copy of your followup] Hi Boost-ers, Katrina Owens has created <http://exercism.io>, a web site designed to help programmers get better at their craft through crowd-sourced mentorship. The whole thing is free and open source and all you need to participate is a github account. I have contributed a basic set of completed exercises to enable the C++ language track. I would love for people from the boost community to participate in the C++ track. I had fun doing the initial set of exercises. Most of them could be completed in under 20 minutes, although the intention is that they increase in difficulty as you progress through them. For each exercise you are presented with the problem statement and a set of Boost.Test unit tests. The goal is to get a program that achieves the function and is expressive and readable. First you get all the tests passing in order to achieve the desired function, but then revise the code to get it to be more expressive and idiomatic in the language. It's that last part where the crowd-sourced mentorship comes into play -- once you've submitted your solution for a problem to the website, you'll be able to view the solutions other people have submitted for the same exercise in the same language. You can mentor them in how to write more expressive, idiomatic C++11 code. Who knows, maybe you'll also improve your C++11 skills by reading feedback from others on your submissions. Feel free to comment here or file an issue on the exercism.io github repository <http://github.com/exercism/exercism.io> if you think the C++ track needs more or better instructions or helpful links. -- "The Direct3D Graphics Pipeline" free book <http://tinyurl.com/d3d-pipeline> The Computer Graphics Museum <http://computergraphicsmuseum.org> The Terminals Wiki <http://terminals.classiccmp.org> Legalize Adulthood! (my blog) <http://legalizeadulthood.wordpress.com>

4 5

Serializing std::vector<double>**
by salman arshad 22 Aug '14

22 Aug '14

Hello, I want to serialize std::vector<double>**. I tried but may be I did not look into right places but I can serialize a std::vector<double>* without any problem but not a pointer to a pointer to vector. I think I am doing something really stupid here or missing something. Any help is highly appreciated. Regards, Salman Arshad

2 1

[review] Formal review period for VMD library begins today, Aug 21, and ends Sat, Aug 30
by Steven Watanabe 21 Aug '14

21 Aug '14

AMDG The formal review of the VMD library by Edward Diener starts today, Aug 21st and is scheduled to continue until Aug 30th. About VMD =============== The Variadic Macro Data library is a library of variadic macros which enhance the functionality in the Boost preprocessor library ( Boost PP ). The main focus of the library is the parsing/identifying of a subset of C++ preprocessor data types and of all Boost PP data types. This allows enhanced preprocessor metaprogramming based on the type of macro input. The library may also be seen as a repository for future enhancements to the Boost PP library functionality using variadic macros. Where to get it =============== The library is available on github at https://github.com/eldiener/variadic_macro_data Review guidelines ================= Reviews should be submitted to the developer list (boost(a)lists.boost.org) with '[vmd]' in the subject. Or if you don't wish to for some reason, you can send them privately to me. If so, please let me know whether or not you'd like your review to be forwarded to the list. For your review you may wish to consider the following questions: - What is your evaluation of the design? - What is your evaluation of the implementation? - What is your evaluation of the documentation? - What is your evaluation of the potential usefulness of the library? - Did you try to use the library? With what compiler? Did you have any problems? - How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? - Are you knowledgeable about the problem domain? And finally, every review should answer this question: - Do you think the library should be accepted as a Boost library? Be sure to say this explicitly so that your other comments don't obscure your overall opinion. In Christ, Steven Watanabe

1 0

A library for "string chains"?
by legalize+jeeves＠mail.xmission.com 21 Aug '14

21 Aug '14

[Please do not mail me a copy of your followup] For a motivating example, see this gist: <https://gist.github.com/LegalizeAdulthood/7b67968bd93fbd4f9dbb> It uses boost::mapped_file to map a mail message into memory and then proceeeds to parse it. This is simply an example, but I think this hacked up parser comes fairly close to handling the full RFC2822 message, ignoring MIME extensions. <https://tools.ietf.org/html/rfc2822> I hacked it up from memory of mail message format rules and a single example message, so don't consider it production quality :-). The intention here is to parse a file without copying it's input text into any buffers. Notice that this parser builds structure from a buffer by identifying interesting substrings as (b,e) pointer pairs. A more traditional approach would have involved at least 2 more copies: one that gets the data from the file system into the stream buffer and another one that copies the data from the stream buffer into a std::string. The extra copying can take significant amounts of time when processing thousands of mail messages. Mail messages tend to be short, so mapping them into memory is not such a big deal. Obviously there is a lifetime relationship between the mapped file (the source character buffer) and the associated strings. For my use case, I'm not interested in being able to write to the strings, just read from them. (If you look closely you'll see that I "cheat" and add a few segments into my string that are associated with const char* C-style strings, but they too are read-only.) I'm interested to know if anyone is aware of a "string chain" library that provides a (read-only) API similar to std::string, but is fundamentally just managing (b,e) pointer pairs into some larger buffer. Boost.Test has a funky string class hiding in it called basic_cstring, but it wasn't created for this purpose. -- "The Direct3D Graphics Pipeline" free book <http://tinyurl.com/d3d-pipeline> The Computer Graphics Museum <http://computergraphicsmuseum.org> The Terminals Wiki <http://terminals.classiccmp.org> Legalize Adulthood! (my blog) <http://legalizeadulthood.wordpress.com>

6 12