- Boost-users - lists.boost.org

New Iterator Concepts deprecated?
by Peter Johansson 23 Mar '15

23 Mar '15

Hi boosters, I've been looking into the New Iterator Concepts http://www.boost.org/doc/libs/1_57_0/libs/iterator/doc/new-iter-concepts.ht… and then I found this comment on boost trac https://svn.boost.org/trac/boost/ticket/1296 where dave seven years ago wrote: "/the new categories are a dead-end as the standard has lifted the reference requirement on forward iterators, so I don't plan to implement anything like this. I actually plan to deprecate the new categories./" This was seven years ago and I can't see anything about that the concepts have been deprecated, so I just wonder if this statement still holds or did the standard take back the reference requirement? Cheers, -- Peter Johansson

3 2

Boost.Locale Examples doesn't runs in VS2010
by Sarvagya Pant 22 Mar '15

22 Mar '15

I have been trying to learn Boost.Locale Module. Consider http://www.boost.org/doc/libs/1_55_0/libs/locale/doc/html/conversions_8cpp-… example. The code gets successfully compiled but when I try to run it, it gives the error Unhandled exception at 0x74d34b32 in LearningCPP.exe: Microsoft C++ exception: std::bad_cast at memory location 0x00a6fa48.. I have attached the stack-trace of the program also. Here it is: KernelBase.dll!74d34b32() [Frames below may be incorrect and/or missing, no symbols loaded for KernelBase.dll] KernelBase.dll!74d34b32() > msvcr100d.dll!_nh_malloc_dbg(unsigned int nSize, int nhFlag, int nBlockUse, const char * szFileName, int nLine) Line 302 + 0x1d bytes C++ msvcr100d.dll!malloc(unsigned int nSize) Line 56 + 0x15 bytes C++ LearningCPP.exe!std::use_facet<boost::locale::converter<char> >(const std::locale & _Loc) Line 526 C++ LearningCPP.exe!boost::locale::to_upper<char>(const char * str, const std::locale & loc) Line 225 + 0x9 bytes C++ LearningCPP.exe!main() Line 170 + 0xc4 bytes C++ LearningCPP.exe!__tmainCRTStartup() Line 555 + 0x19 bytes C LearningCPP.exe!mainCRTStartup() Line 371 C kernel32.dll!75268543() ntdll.dll!776bac69() ntdll.dll!776bac3c() Did anyone faced this issue when using Boost.Locale in Visual Studio 2010? If so, how do I resolve this issue? *PS:* I have used option Use Unicode Character Set under the Character Set option of Visual Studio. I believe the libraries are correctly linked too. -- *sarvagya*

1 0

boost::property_tree::ptree with write_xml
by Uthpal Urubail 22 Mar '15

22 Mar '15

All, I am looking got the help with xml writer using property tree. My requirement is to write a user defined comment (in below example /*comment*/) in every line of XML file. Example: /*comment*/<debug> /*comment*/ <filename>debug.log</filename> /*comment*/ <modules> /*comment*/ <module>Finance</module> /*comment*/ <module>Admin</module> /*comment*/ <module>HR</module> /*comment*/ </modules> /*comment*/ <level>2</level> /*comment*/</debug> Can someone help me in solving the above? Any help on this would be highly appreciated. boost::property_tree::xml_writer_settings<std::string> w(' ', 4); write_xml(os, pt,w); Regards, UJ

3 4

phoenix 1.55 no-arg mem function fails
by MM 21 Mar '15

21 Mar '15

#include <boost/phoenix/phoenix.hpp> struct Foo { const int& bar() const { return i; } int i; }; int main() { Foo f; const int& ir = boost::phoenix::bind(&Foo::bar, f)(); } The above fails to compile. linux g++492 -std=c++11 -c 1.cpp When bar() has a single int arg for e.g., boost::phoenix::bind(&Foo::bar, f, 5)(); succeeds. The error: In file included from /usr/include/boost/phoenix/bind/bind_member_variable.hpp:13:0, from /usr/include/boost/phoenix/bind.hpp:17, from /usr/include/boost/phoenix/phoenix.hpp:17, from 1.cpp:1: /usr/include/boost/phoenix/bind/detail/member_variable.hpp: In instantiation of ‘struct boost::phoenix::detail::member_variable<const int&() const, const int& (Foo::*)() const>’: /usr/include/boost/proto/make_expr.hpp:77:16: required from ‘struct boost::proto::detail::protoify<boost::phoenix::detail::member_variable<const int&() const, const int& (Foo::*)() const>, boost::proto::domainns_::basic_default_domain>’ /usr/include/boost/proto/detail/preprocessed/make_expr_.hpp:70:9: required from ‘struct boost::proto::detail::make_expr_<boost::phoenix::detail::tag::function_eval, boost::proto::domainns_::basic_default_domain, boost::phoenix::detail::member_variable<const int&() const, const int& (Foo::*)() const>, Foo, void, void, void, void, void, void, void, void, void>’ /usr/include/boost/proto/make_expr.hpp:185:13: required from ‘struct boost::proto::result_of::make_expr<boost::phoenix::detail::tag::function_eval, boost::proto::domainns_::basic_default_domain, boost::phoenix::detail::member_variable<const int&() const, const int& (Foo::*)() const>, Foo, void, void, void, void, void, void, void, void, void>’ /usr/include/boost/phoenix/core/preprocessed/expression_10.hpp:84:13: required from ‘struct boost::phoenix::expr_ext<boost::phoenix::actor, boost::phoenix::detail::tag::function_eval, boost::phoenix::detail::member_variable<const int&() const, const int& (Foo::*)() const>, Foo, void, void, void, void, void, void, void, void, void>’ /usr/include/boost/phoenix/core/preprocessed/expression_10.hpp:24:12: required from ‘struct boost::phoenix::expr<boost::phoenix::detail::tag::function_eval, boost::phoenix::detail::member_variable<const int&() const, const int& (Foo::*)() const>, Foo, void, void, void, void, void, void, void, void, void>’ /usr/include/boost/phoenix/core/detail/preprocessed/function_eval_10.hpp:7:561: required from ‘struct boost::phoenix::detail::expression::function_eval<boost::phoenix::detail::member_variable<const int&() const, const int& (Foo::*)() const>, Foo, void, void, void, void, void, void, void, void, void>’ /usr/include/boost/phoenix/bind/bind_member_variable.hpp:37:5: required by substitution of ‘template<class RT, class ClassT> const typename boost::phoenix::detail::expression::function_eval<boost::phoenix::detail::member_variable<RT, RT ClassT::*>, ClassT>::type boost::phoenix::bind(RT ClassT::*, ClassT&) [with RT = const int&() const; ClassT = Foo]’ 1.cpp:11:52: required from here /usr/include/boost/phoenix/bind/detail/member_variable.hpp:50:17: error: forming reference to qualified function type ‘const int&() const’ RT& operator()(Class& obj) const ^ /usr/include/boost/phoenix/bind/detail/member_variable.hpp:59:23: error: forming reference to qualified function type ‘const int&() const’ RT const& operator()(Class const& obj) const ^ /usr/include/boost/phoenix/bind/detail/member_variable.hpp:68:17: error: forming reference to qualified function type ‘const int&() const’ RT& operator()(Class* obj) const ^ /usr/include/boost/phoenix/bind/detail/member_variable.hpp:74:23: error: forming reference to qualified function type ‘const int&() const’ RT const& operator()(Class const* obj) const Rds,

1 0

phoenix: c++11
by MM 21 Mar '15

21 Mar '15

Hello Are there plans to add emplace_back to the stl part of phoenix? MM

1 0

what happens between "fixed in development" and "available in release"?
by oswin krause 21 Mar '15

21 Mar '15

Hi, Question is in the subject. What has to happen after a fix of a bug in development stage before it enters an official release? Do not get me wrong, I like boost and all it does for the community and all the effort people put into it. And i really would like to help to speed up certain...processes, but for this i have to know what can block this step? Apparently a bug in serialisation - which totally breaks my software to the point where it can not be compiled on several linux distributions und MacOsX since release of boost 1.56 - is fixed in development even prior to 1.57 and is still not available in 1.58. And what I hear from several mails across the mailing list, this is not the only change that got stuck. And somehow i have the feeling that the new boost release cycle won't make the situation any better. As I said, do not get me wrong, but this situation becomes unbearable as these boost versions spread more and more through the ecosystem and there is really nothing on my side I can do about it, except rolling my own implementation and maintaining it, until this whole thing is faded out of all major distributions(you might already get the feeling that I am not really happy about doing that). if there is something i can do to help, I will do it. But I now know that "report bugs and investigate possible fixes and send patches" does not necessarily lead to a fast fix and i am pretty frustrated by the situation. Best, Oswin

8 17

[multi_index] iterating over keys and "extracting" key extractors
by Nick Stokes 20 Mar '15

20 Mar '15

Q1: Is there a builtin in way in MI to iterate over keys rather than elements? I.e. the iterator's value type will be that of the key, not the element. Q2: Is there a way to obtain the type of key extractors given a multi index container? (it is related to Q1, as this sort of a thing could be passed to boost::transform iterator to obtain an alternative answer for Q1) An example is in order: struct Foo { int id; sting name; }; using namespace boost::multi_index; typedef multi_index_container< Foo, indexed_by< ordered_unique< member< Foo, int, &Foo::id > >, ordered_unique< member< Foo, string, &Foo::name > > > MFoo; MFoo foos; // .. populate // Now, we want to iterate over sorted name's only, for e.g: auto beg = answer_to_Q1(foos).begin(); auto end = answer_to_Q1(foos).end(); std::copy( beg, end, ostream_iterator<string>(cout, " ") ); // Continuing the example for Q2: auto aFunctorThatExtractsFooName = answer_to_Q2<M>::type(); auto beg = make_transform_iterator( M.get<1>.cbegin(), aFunctorThatExtractsFooName ); auto end = make_transform_iterator( M.get<1>.cend(), aFunctorThatExtractsFooName ); std::copy( beg, end, ostream_iterator<string>(cout, " ") ); Thanks! Nick

2 6

From: giridhar
by giridhar 20 Mar '15

20 Mar '15

Hello boost http://thalbangla.org/business.php?broken=6zpp82zkpkd1 giridhar Sent from my iPhone

1 0

[afio][v1.30 "C++ Now edition" released]
by Niall Douglas 20 Mar '15

20 Mar '15

Dear Boost, I am very pleased to announce the v1.30 release of proposed Boost AFIO, a Boost library implementing asynchronous file input/output which has been in the review queue since 2013. This is the version of AFIO which will be overviewed in my talk at C++ Now 2015. It also demonstrates the validity of the clang AST driven BindLib standalone Boost library conversion technique which will also be overviewed at C++ Now. Source distro: https://github.com/BoostGSoC13/boost.afio/archive/v1.30_Boost_v1.57.zi p Docs and CI dashboard: https://boostgsoc13.github.io/boost.afio/ Major new features in the v1.30 release: * Performance was improved by removing the transactional memory support in the v1.2 engine which is now compile time enabled only. Throughput now reaches up to 85% of raw ASIO and average latencies were reduced by 48%, yielding a 15 microsecond average latency with +/- 0.15 microsecond at a 95% confidence interval. This should enable AFIO to handle the latest generation PCIe SSDs with their 80 microsecond latencies reasonably well. * AFIO is now capable of complete standalone usage no Boost dependencies whatsoever, including for its unit testing via a Boost.Test emulation. * Due to its use of libclang AST generated template aliasing to allow user swapping of STL 11 implementation, minimum compilers required are now VS2013, GCC 4.7 and clang 3.2. All the VS2010 workarounds baggage has been eradicated. * All things related to async_data_op_req are now fully metaprogrammed with automatic generation by the compiler of suitable ASIO scatter-gather buffers from input types and STL containers with correct scatter-gather buffer coalescing where safe to do so. This automatic generation is user customisable via free function specialisation. * Support for relative paths from an open file descriptor was added. This lets you specify a file descriptor as a base from which a path fragment operates with the path resolution atomically performed in the kernel, and therefore the path of the base file descriptor may rapidly change safely. * AFIO is now optimally filing system race condition safe on all supported platforms, with per-API documentation of how much race safety is guaranteed per platform. A soak unit test verifies per commit that perfect race safety under severe and rapid filing system change is maintained. * A new afio::path type which very thinly wraps filesystem::path was added. The new afio specific path type makes the management of NT kernel path to Win32 path transition and conversion explicit, and therefore much harder to accidentally get wrong. A new normalise_path() function can convert a NT kernel path to a traditional Win32 path, complete with drive letter. * New platforms supported: Apple OS X and Android 5.0. * New filing system features support: All platforms: sparse file support, storage extent enumeration, extent deallocation ("hole punching"), volume metadata fetching (statfs), open file handle path discovery, hard link support, atomic relink (rename) support. Windows only: file symlinking, NT lock file performance flags (lock file performance is now not far from POSIX), workaround semantics for all the ways Windows will surprise you on the filing system such as files and directories which won't delete. AFIO now does a fair job of replicating POSIX filing system semantics on Windows (and better than Mingw/Cygwin presently). Linux: symlinks are now opened as file descriptors on kernels supporting that feature. * Doubled the size of the tutorial, with all the new material being non-toy examples. There is a particularly nifty "File locking via only atomic appending and hole punching" algorithm implementation in there, and it holds up surprisingly well compared to traditional file locks except on ZFS. Plus, it's completely portable. * Some utility routines in preparation for AFIO v1.4: a cryptographically strong random filename generator, a hugepage TLB STL allocator useful for efficient file copy buffers, a very highly optimised C++ 14 constexpr constructing arbitrary Hamming code SECDED template class (an amazing 22 cycles per byte for the 32784,32768 code), and secure to-hex and from-hex validating converters. * No shortage of bug fixes, helped hugely by additional unit testing for correct error handling. Detailed changelog can be found at https://boostgsoc13.github.io/boost.afio/doc/html/afio/release_notes.h tml. I'll tag a Boost 1.58 release on github once Boost 1.58 is out. This release took far longer than I originally intended mainly due to the extensive debugging of weird filing system races, and for six weeks now I've been working till 5am every night after my day job. I cannot tell you how glad I am to see this release out! My enormous thanks to my family who have put up with a lot for this release, and to my employer for a fairly dopey employee recently. Bed, here I come! Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/

3 2

[Phoenix] Version 1.57 of Phoenix breaks when used with MSVC 2010 compiler?
by Andrew Nordquist 20 Mar '15

20 Mar '15

Hello, folks - I must be doing something wrong, but I can't figure it out. I/we have been using Boost in our 20,000+ lines of C++ code for a few years now. We started with 1.43, went smoothly to 1.53, and although it was bumpy going from MSVC 2008 to MSVC 2010, we are there now. We are now using MSVC 2010 and Boost 1.53. We use many routines, including Phoenix, Spirit, bind, tie, etc. I am attempting to migrate to Boost 1.57. Got clobbered with about 400 lines of unexpected diagnostic in the compiler. That is the attached file. In the file, the lines showing the files named "cutoffitem.cpp" and "densitydelegate.cpp" are ours, but what is between these two lines is coming from Boost. It appears that it could be a C++11 type of problem, but I'm not sure . I read about that potential problem with the [utility] [result_of] class template in the report designated n3276 and in the 1.57 [utility] documentation. I think the major concern with this issue was going to Boost 1.52. In our code, I tried a quick-fix precompiler #define, but it did not work. Got any ideas? I'm about to go back to version 1.53, at least until I upgrade to Visual Studio 2013. Thank you, /Andrew Nordquist Research Analyst Southwest Research Institute San Antonio, TX, USA

1 0