- Boost-users - lists.preview.boost.org

activating Boost Graph Library finish_edge
by Michael Behrns-Miller 25 Nov '13

25 Nov '13

Hello boost users. I'm using BGL, and was happy to see the addition of the finish_edge() visitor to DFS. I had previously added code to finish_vertex() to emulate this visitor, had to track vertices, not ideal. But when I add the template function to my Visitor class, the code is never hit. Specifically, I'm using Visual Studio 2013 and the compiler is telling me my debug breakpoint will never get hit in the function as the code did not make it into the executable. The visitor class is below, any thoughts on what I'm doing wrong? I took a look at undirected_dfs.hpp and it includes call_finish_edge() in the DFS algorithm in undir_dfv_impl(). Thanks, Michael class BaseVisitor : public boost::dfs_visitor<> { public: template <class E, class G> void examine_edge(E e, const G& g) { // gets hit... } template <class V, class G> void discover_vertex(V v, const G& g) { // gets hit... } template <class V, class G> void finish_vertex(V v, const G& g) { // gets hit... } template <class E, class G> void finish_edge(const E& e, const G& g) { // NOT built or hit... // Tried using [E e] param as well... } };

1 0

Peer Review Report for proposed Boost.TypeIndex v2.1 Nov 12th – 21st 2013
by Niall Douglas 24 Nov '13

24 Nov '13

Please let me know as soon as possible any errata, missing credits etc. Niall Boost Peer Review Report for proposed Boost.TypeIndex v2.1 Nov 12th – 21st 2013 This report is the first edition, dated Sunday 24th November 2013. The review manager was Niall Douglas http://www.nedprod.com/. Source: https://github.com/apolukhin/type_index/zipball/master Documentation: http://apolukhin.github.com/type_index/index.html Peer review discussion detail: http://boost.2283326.n4.nabble.com/TypeIndex-Peer-review-period-for-library… My thanks to the Boost members whose peer review makes up this report: Robert Ramey, Vicente J. Botet Escriba, Gavin Lambert, Andrey Semashev, Steven Watanabe, pfultz2, Mathieu Champlon, Joël Lamotte Klaim, Rob Stewart, Jan Herrmann, Tony Van Eerd. Contents: · Summary of consensus from peer review ......................................................................................................... 1 · My recommendation to the library author and the Review Wizards ................................................................ 3 Summary of consensus from peer review: The consensus feedback was to accept TypeIndex after substantial modifications. There were two recommendations of rejection due to how substantial such modifications would need to be (i.e. a request for a second round of peer review with a new implementation). Note that my personal opinion based on post-review reflection is written in [square bracketed italics]. · Many seemed to feel that a boost::type_info’s member function API, where identically named to that of std::type_info member function API, ought to have identical compile-time effects. This implied that missing member function APIs, or other compile time errors for missing or incomplete functionality, would be okay but if name() returns some const char *, then any const char * so long as it meets the C++ standard is okay. [I think there are three use cases for a type_info like substitute: (i) as a lightest possible weight, non-RTTI requiring minimal type_info which can have any API it likes and ought to not be directly substitutable for std::type_info or std::type_index (ii) as a compile-time substitute for std::type_info in that it will compile without third party code modification, but may not produce reliable code due to not returning exactly the same values as std::type_info (iii) as a runtime substitute for std::type_info in that it will require code to be “ported” to it due to having a breaking API, but thereafter produces reliable code. I’ll be very blunt in saying that (ii) is a bad idea in my opinion, and (iii) is valuable but out of scope enhancement which could be added as a separate class after peer review. In my opinion, (i) is where we ought to focus, and I would recommend that the lightest possible weight type_info replacement be deliberately compile-time incompatible with std::type_info (where output is not identical to std::type_info) to force porting code to it so authors are not lazy.] · A large minority seemed to feel that a boost::type_info’s member function API, where identically named to that of std::type_info member function API, ought to have identical run-time outcomes. Most specifically, this would mean that member functions e.g. name() would return exactly what std::type_info’s name() does, even if for example name() returns a std::string instead of a const char * as would be necessary in pre-C++11 compilers. [This is really use case (iii) in the previous item.] · It was mentioned that it should be possible to optionally specialise std::hash<> for type_info for optional seamless use in hash taking containers. · Some felt that implementation-specific std::type_info quirks ought to be replicated. Others felt they should not, and a portable interface which works identically on all platforms is preferred. [This is really use case (iii) in the previous item.] · boost::type_info is currently initialised via a static cast from a std::type_info when RTTI is available. This is undefined behaviour, and some felt this to be a showstopper. I (Niall Douglas) looked into this more deeply due to its seriousness, and found that because most STL implementations define std::type_info with a virtual function table, the undefined behaviour static cast would cause dynamic_cast on a boost::type_info instance to misoperate. [I believe the RTTI induced misoperation to indeed be a showstopper, and that this use of undefined behaviour to reduce code bloat is an unsafe optimisation. A much lighter weight non-direct-substitute for std::type_info ought to be as code bloat parsimonious as is possible, while its lack of non-explicit interoperation ability with std::type_info ought to allow avoidance of needing any UB tricks.] · Some felt that any use of implied boost::type_info ought to be explicitly written as boost::type_info instead of relying on namespace lookup, as the name similarity to std::type_info may introduce confusion. [I agree] · It was mentioned that some function-local static data members are initialised in a thread unsafe way. [For information I have to hand a very lightweight BOOST_BEGIN_MEMORY_TRANSACTION() implementation ideal for this purpose. We could submit it to Boost.Detail and then everyone could use it?] · Magic macros such as __PRETTY_FUNCTION__ ought to not be referenced outside of a function as they don’t technically exist there. Checks for their existence ought to be within a function. · It was requested that a boost::type_id<> which takes some unknown variable instance as a parameter and therefore allows the compiler to deduce the type of the variable as the boost::type_index<T> type would be valuable. · A mechanism for programming compile-time logic with class inheritance trees such that inheritance can be determined at compile-time with RTTI disabled was requested. My recommendation to the library author and the Review Wizards: · In my opinion Antony ought to make TypeIndex v3 quite literally a very lightweight container of some unknown, but known to be uniquely identifying for some type, static const char * string. I think its class type and its list of member functions ought to be deliberately compile-time incompatible with std::type_info to force authors to upgrade their code. A conversion member function ought to be able to synthesise a corresponding std::type_info using typeid() from some boost::type_index<T>, but that’s about it. I would even, personally speaking, go so far as to only provide a boost::type_index and no corresponding boost::type_info, especially if the boost::type_id<T>() function can return a const boost::type_index<T>& and therefore can be used as a static const lref, or copy constructed from it etc. A suggested name() member function replacement which correctly breaks out the multiple confounding uses of std::type_info::name() into each of their three use cases (and which intentionally causes any use of name() to fail to compile) might be: Text Box: /*! Returns a static const char string of unknown format uniquelyidentifying this type.The only guarantee is that this string will beunique to the type within this process lifetime. */const char *unique_name() const noexcept;/*! Returns a representation of this type suitable for printing.This call may take some time as its storage may not be cached. */std::string pretty_name() const;class enum mangling{Native, //!< Whatever the native mangling used by this toolset isMSVC, //!< The Microsoft C++ mangling formatItanium //!< The Itanium C++ mangling format};/*! Returns the mangled form of the string representation of the type.After the calculation the value is cached statically such that the c_str()function can be used to convert the returned string to a const char *format identical to what may be returned by std::type_info::name() (orraw_name() on MSVC).This function may throw an exception if it does notsupport mangled type string calculation, including when mangling=Native onsome Bear in mind that user code can always subclass boost::type_index and add their own name() implementation based on one or more of the above new member functions. · In other words, here I think “less is more” in every way you look at it. I think a slimmer less heavy TypeIndex would be a superior solution. · I request the Review Wizards to allow Antony some time to make the changes to produce a v3 of the library, and then to allow TypeIndex v3 a Fast Track Review of five days to ensure the Boost community is happy and that its feedback has been incorporated. It was asked during peer review that such a five day period please include a weekend. I would be happy to serve as review manager again if requested. Niall Douglas Waterloo, Canada, November 2013

1 0

[boost-TLS] Thread Local Storage (TLS) Question
by Kyle Ketterer 24 Nov '13

24 Nov '13

Hello, I am using multiple threads for I/O operations. The issue I am having is joining these threads on the main thread. It appears that calling join() on a thread with TLS pointers, it results in a hang. I have multiple thread specific pointers declared outside of the function and in the beginning of the method I call reset ( new std::string ) ....etc etc. I also am acquiring some resource handlers as Im using a boost::thread_specific_ptr < ifstream > infile So, when I create the thread in the main thread and join() it I get a hang. The only thing I can think of is that the handlers are not being released so join() waits indefinitely. I read in the documentation that the pointers should be cleaned up on thread exit - but the thread apparently never exits because then resources are not released? I understand that it may not be "conventional" to use a tls pointer for ifstream but I find it a lot better than locking with mutexes. Also, I'm not sure if there are limits as to how many TLS pointers you can actually use but I am currently using about 10 for one thread method. Another thing to note is that when calling detach() on the thread, all of the threads execute properly and I get expected output. However, I need to call join() every x amount of threads due to OS limitations of how many threads can actually be created. I need to read about 5000 files so obviously I can't create 5000 threads as Windows maxes out at 700 I believe. I am reading files off of a RAID setup so I believe this is a situation that can benefit from multiple threads reading files. Basically, I only want to create 4 threads at a time, then join() the previous 4, ensure that they have all completed successfully and continue to create more. Any suggestions or comments on this issue? Thanks -- Kyle Ketterer <reminisc3(a)gmail.com>

3 3

Boost 1.55 and ICL : Compile error
by Adam Baxter 24 Nov '13

24 Nov '13

Hello all, I'm getting a compile error under Boost 1.55 using ICL's Closed Interval include: In file included from /home/abaxter/Projects/Du/apollo/libapollo/src/theory.cpp:21:0: /home/abaxter/local/include/boost/icl/closed_interval.hpp: In constructor 'boost::icl::closed_interval<DomainT, Compare>::closed_interval()': /home/abaxter/local/include/boost/icl/closed_interval.hpp:35:31: error: 'DefaultConstructibleConcept' was not declared in this scope BOOST_CONCEPT_ASSERT((DefaultConstructibleConcept<DomainT>)); ^ /home/abaxter/local/include/boost/icl/closed_interval.hpp:35:66: error: expected primary-expression before '>' token BOOST_CONCEPT_ASSERT((DefaultConstructibleConcept<DomainT>)); ^ /home/abaxter/local/include/boost/icl/closed_interval.hpp:35:67: error: expected primary-expression before ')' token BOOST_CONCEPT_ASSERT((DefaultConstructibleConcept<DomainT>)); ^ /home/abaxter/local/include/boost/icl/closed_interval.hpp:35:68: error: there are no arguments to 'BOOST_CONCEPT_ASSERT' that depend on a template parameter, so a declaration of 'BOOST_CONCEPT_ASSERT' must be available [-fpermissive] BOOST_CONCEPT_ASSERT((DefaultConstructibleConcept<DomainT>)); ^ /home/abaxter/local/include/boost/icl/closed_interval.hpp:35:68: note: (if you use '-fpermissive', G++ will accept your code, but allowing the use of an undeclared name is deprecated) /home/abaxter/local/include/boost/icl/closed_interval.hpp:36:31: error: 'LessThanComparableConcept' was not declared in this scope BOOST_CONCEPT_ASSERT((LessThanComparableConcept<DomainT>)); ^ /home/abaxter/local/include/boost/icl/closed_interval.hpp:36:64: error: expected primary-expression before '>' token BOOST_CONCEPT_ASSERT((LessThanComparableConcept<DomainT>)); ^ /home/abaxter/local/include/boost/icl/closed_interval.hpp:36:65: error: expected primary-expression before ')' token BOOST_CONCEPT_ASSERT((LessThanComparableConcept<DomainT>)); ^ /home/abaxter/local/include/boost/icl/closed_interval.hpp:36:66: error: there are no arguments to 'BOOST_CONCEPT_ASSERT' that depend on a template parameter, so a declaration of 'BOOST_CONCEPT_ASSERT' must be available [-fpermissive] BOOST_CONCEPT_ASSERT((LessThanComparableConcept<DomainT>)); ^ /home/abaxter/local/include/boost/icl/closed_interval.hpp: In constructor 'boost::icl::closed_interval<DomainT, Compare>::closed_interval(const DomainT&)': /home/abaxter/local/include/boost/icl/closed_interval.hpp:46:31: error: 'DefaultConstructibleConcept' was not declared in this scope BOOST_CONCEPT_ASSERT((DefaultConstructibleConcept<DomainT>)); ^ /home/abaxter/local/include/boost/icl/closed_interval.hpp:46:66: error: expected primary-expression before '>' token BOOST_CONCEPT_ASSERT((DefaultConstructibleConcept<DomainT>)); ^ /home/abaxter/local/include/boost/icl/closed_interval.hpp:46:67: error: expected primary-expression before ')' token BOOST_CONCEPT_ASSERT((DefaultConstructibleConcept<DomainT>)); ^ /home/abaxter/local/include/boost/icl/closed_interval.hpp:46:68: error: there are no arguments to 'BOOST_CONCEPT_ASSERT' that depend on a template parameter, so a declaration of 'BOOST_CONCEPT_ASSERT' must be available [-fpermissive] BOOST_CONCEPT_ASSERT((DefaultConstructibleConcept<DomainT>)); ^ /home/abaxter/local/include/boost/icl/closed_interval.hpp:47:31: error: 'LessThanComparableConcept' was not declared in this scope BOOST_CONCEPT_ASSERT((LessThanComparableConcept<DomainT>)); ^ /home/abaxter/local/include/boost/icl/closed_interval.hpp:47:64: error: expected primary-expression before '>' token BOOST_CONCEPT_ASSERT((LessThanComparableConcept<DomainT>)); ^ /home/abaxter/local/include/boost/icl/closed_interval.hpp:47:65: error: expected primary-expression before ')' token BOOST_CONCEPT_ASSERT((LessThanComparableConcept<DomainT>)); ^ /home/abaxter/local/include/boost/icl/closed_interval.hpp:47:66: error: there are no arguments to 'BOOST_CONCEPT_ASSERT' that depend on a template parameter, so a declaration of 'BOOST_CONCEPT_ASSERT' must be available [-fpermissive] BOOST_CONCEPT_ASSERT((LessThanComparableConcept<DomainT>)); ^ /home/abaxter/local/include/boost/icl/closed_interval.hpp: In constructor 'boost::icl::closed_interval<DomainT, Compare>::closed_interval(const DomainT&, const DomainT&)': /home/abaxter/local/include/boost/icl/closed_interval.hpp:55:31: error: 'DefaultConstructibleConcept' was not declared in this scope BOOST_CONCEPT_ASSERT((DefaultConstructibleConcept<DomainT>)); ^ /home/abaxter/local/include/boost/icl/closed_interval.hpp:55:66: error: expected primary-expression before '>' token BOOST_CONCEPT_ASSERT((DefaultConstructibleConcept<DomainT>)); ^ /home/abaxter/local/include/boost/icl/closed_interval.hpp:55:67: error: expected primary-expression before ')' token BOOST_CONCEPT_ASSERT((DefaultConstructibleConcept<DomainT>)); ^ /home/abaxter/local/include/boost/icl/closed_interval.hpp:55:68: error: there are no arguments to 'BOOST_CONCEPT_ASSERT' that depend on a template parameter, so a declaration of 'BOOST_CONCEPT_ASSERT' must be available [-fpermissive] BOOST_CONCEPT_ASSERT((DefaultConstructibleConcept<DomainT>)); ^ /home/abaxter/local/include/boost/icl/closed_interval.hpp:56:31: error: 'LessThanComparableConcept' was not declared in this scope BOOST_CONCEPT_ASSERT((LessThanComparableConcept<DomainT>)); ^ /home/abaxter/local/include/boost/icl/closed_interval.hpp:56:64: error: expected primary-expression before '>' token BOOST_CONCEPT_ASSERT((LessThanComparableConcept<DomainT>)); ^ /home/abaxter/local/include/boost/icl/closed_interval.hpp:56:65: error: expected primary-expression before ')' token BOOST_CONCEPT_ASSERT((LessThanComparableConcept<DomainT>)); ^ /home/abaxter/local/include/boost/icl/closed_interval.hpp:56:66: error: there are no arguments to 'BOOST_CONCEPT_ASSERT' that depend on a template parameter, so a declaration of 'BOOST_CONCEPT_ASSERT' must be available [-fpermissive] BOOST_CONCEPT_ASSERT((LessThanComparableConcept<DomainT>)); ^ make[2]: *** [libapollo/src/CMakeFiles/libapollo.dir/theory.cpp.o] Error 1 make[1]: *** [libapollo/src/CMakeFiles/libapollo.dir/all] Error 2 make: *** [all] Error 2 15:18:23: The process "/usr/bin/make" exited with code 2. Any ideas? Adam

1 0

[Thread] TLS / locking ?
by beet 24 Nov '13

24 Nov '13

Hi there, I have a number of threads and, within the context of each thread, a large number of objects may be active. I would now like to provide all objects accessed by a thread with a common random number generator. i.e., there would be as many random number generators as there are threads, and all objects active inside of a given thread would access the same generator, but objects in different threads use different generators. The obvious approach would be to store the generator in thread-local storage. I am concerned, however, about the performance implications. In particular, does access to thread-local storage implicitly involve locking of sorts? If so, the (very) frequent access to the random number generator would effectively serialize my application. Thanks and Best Regards, Beet

3 3

Design query using Boost.
by Rahul Mathur 24 Nov '13

24 Nov '13

All, I have a design sinerio. I have different struct (C structures) having different data's but NO similarities between struct and each struct does different operations. The struct for example are - struct Apple { int A; char B; long C; double d; .. ..}; struct Orange { char A; int B; unsigned int C; long d; .. }; and maybe few more. Above few struct data members have dynamic data and other members have fixed/hardcoded datas. The complete struct is send as a buffer to a remote machine through native send()/read() API calls which has been successfully implemented. Please note this data as tested were hard coded or completely static but didn't had combination of dynamic/real and static data.. Now such operations (viz different or repeated) with ONE/MULTIPLE SET of data could be many as 1000, I wish now to send complete operations to remote machine, get a ACK from it and work on this struct data with modification/cancellation/reject/etc operations. One way could be to work with something similar - struct Apple { ... ..}; vector <Apple> data; data.insert (begin();end()) --- But, I have few questions - 1. I can have "std::map<string, vector>" and send this data as native send(). Latter read/recv() with string. Am I correct as I would have multiple operations? 2. I do wish to maintain synchronisation using Boost::lockfree mechanism latter? 3. Any other techniques? Thanks.

1 0

[log] Why aren't logger operations const ?
by Mauricio Carneiro 24 Nov '13

24 Nov '13

I am trying to use a severity channel logger but I hit the problem with BOOST_LOG_SEV not being a const method -- I'm thinking because of both open_record() and push_record() This will basically force me to make all methods in my classes not const because they want to write out to their loggers. I can't really afford to do that -- so I'm restricted to global loggers at the moment. In my current implementation, each class has a logger with the class name as the channel (initialized in their constructors), and it issues log messages at any point with BOOST_LOG_SEV(this->logger, level) I'd love to hear the reason behind the non-constness and if my design is not the intended for Boost::Log. Thank you for your help. Mauricio Carneiro, Ph.D. http://www.broadinstitute.org/~carneiro/

2 4

Re: [Boost-users] New-style for on an iterator-range of filter_iterator of strings crashes/hangs
by Ami Tavory 24 Nov '13

24 Nov '13

Steven Watanabe: > AMDG > > On 11/23/2013 11:12 AM, Ami Tavory wrote: > > <snip> > > typedef > > filter_iterator<function<bool (const string &)>, > > vector<string>::const_iterator> > > filter_it_t; > > auto r = make_iterator_range(filter_it_t(fn, ss.begin()), > > filter_it_t(fn, ss.end())); > > <snip> > > > > yields an executable that crashes with > > {{{ > > Segmentation fault (core dumped) > > }}} > > > > <snip> > > > > You're not constructing the filter_iterators correctly. > From the documentation: > > filter_iterator(Predicate f, Iterator x, Iterator end = Iterator()); > > Effects: > > Constructs a filter_iterator where m_iter is either > the first position in the range [x,end) such that > f(*m_iter) == true or else``m_iter == end``. The > member m_pred is constructed from f and m_end from end. > > You need to pass the end iterator as well. (Or use > the Boost.Range version) > > In Christ, > Steven Watanabe Many thanks!

1 0

New-style for on an iterator-range of filter_iterator of strings crashes/hangs
by Ami Tavory 23 Nov '13

23 Nov '13

Hello, Using g++ 4.8.1 (g++ (Ubuntu/Linaro 4.8.1-10ubuntu8) 4.8.1) with boost 1.5.3, building the code below with {{{ g++ -o example/filter.out -std=c++0x -Wall -g -rdynamic -I/usr/include/boost example/filter.cpp }}} {{{ #include <vector> #include <string> #include <iostream> #include <functional> #include <boost/iterator/filter_iterator.hpp> #include <boost/range/iterator_range.hpp> using namespace std; using namespace boost; int main() { vector<string> ss{"hello", "world"}; // function<bool (const string &)> fn = [](const string &s){return false;}; function<bool (const string &)> fn = [](const string &s){return s.size() > 3;}; cout << fn("Hello") << endl; // (1) cout << fn("world") << endl; // (2) typedef filter_iterator<function<bool (const string &)>, vector<string>::const_iterator> filter_it_t; auto r = make_iterator_range(filter_it_t(fn, ss.begin()), filter_it_t(fn, ss.end())); for(const string &a: r) cout << a << endl; return 0; } }}} yields an executable that crashes with {{{ Segmentation fault (core dumped) }}} Exchanging the comment in the two lines {{{ // function<bool (const string &)> fn = [](const string &s){return false;}; function<bool (const string &)> fn = [](const string &s){return s.size() > 3;}; }}} (so that the first lambda is used) yields an executable that hangs. In either case, the application first prints the results of the lines marked (1) and (2). Can't figure out what I'm doing wrong, and would appreciate advice. Thanks, Ami

2 1

self_loop=false for Unique R-MAT generator
by Николай Кинаш 23 Nov '13

23 Nov '13

>The R-MAT graph model is different from the BA model; are you sure you >want R-MAT? Hmm.... I`m not sure. How to create BA model in BPGL? Thanks.

2 1