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

[Multi-Index] Skip-Scan "virtual" ordered-non-unique index on top of composite ordered-unique index
by Dominique Devienne 29 Nov '13

29 Nov '13

We have BMIs of entries with complex composite "natural-keys". For example: typedef boost::multi_index_container< FooIdPtr, // FYI: boost::shared_ptr<FooId> bmi::indexed_by< EntityIndex<ByUid>::unique, // FYI: Surrogate/Primary Key EntityIndex<ByNKey>::of<FooId>::unique, // FYI: Natural Key // additional indexes by type, name and parent EntityIndex<ByType>::non_unique, EntityIndex<ByName>::non_unique, EntityIndex<ByParent>::non_unique > > Impl; The EntityIndex template utility simply factors the index definitions used in several BMIs. For example template <> struct EntityIndex<ByNKey> { template <typename T_IDENT> struct of { typedef hashed_unique< // natural key (logical primary key) tag<ByNKey>, identity< shared_ptr<T_IDENT> >, EntityIdHash<T_IDENT>, EntityIdPred<T_IDENT> > unique; }; }; template <> struct EntityIndex<ByParent> { typedef hashed_non_unique< tag<ByParent>, BOOST_MULTI_INDEX_CONST_MEM_FUN( EntityId, const Uid&, parent_uid // FYI: EntityId is the base class of FooId and co. ) > non_unique; }; After recently reading http://www.sqlite.org/draft/optoverview.html#skipscan and its Skip-Scan optimization, I wondered about changing my ByNKey unique index from hashed to ordered, and thought that in theory, I could perhaps avoid the maintenance and memory cost of the additional type+name+parent indexes, since all three are subsets of the ByNKey unique index, and using a similar skip-scan strategy, which might/would still provide reasonable performance, at least better than no index at all (i.e. a full scan). I know BMI does not provide this of course, but do you think Joaquin that it would be possible to one-day add such "virtual" ordered non-unique indexes on top of an existing ordered (possibly unique) composite index? Of course in this case, the composite'ness is hidden inside FooId, and not exposed to BMI (it used to be a true BMI composite index, but modeling the identity as an object made more sense and simplified things), so whether an index is a subset of another would need to be "configurable" in some way, to yield a "compatible key" with the right "prefix" keys to skip to the next "sub-range" to scan (hopefully that makes sense...). I think I would be able to write custom code on top of a ByNKey ordered-non-unique index to implement a subset of the functionality a true BMI ordered non-unique index provides, for my own needs (with some difficulty, but feasible nonetheless), but the kind of template meta-programming BMI uses to implements its indexes is beyond my current skill level, which is why I'm posting to see what the experts (i.e. Joaquin) thinks about this Skip-Scan virtual indexes idea. Thanks, --DD

2 4

Serialization problem with cyclic references (pointers)
by krisdamato 29 Nov '13

29 Nov '13

Try steppin through this code where the deserialization takes place. On every machine I've tried this (and I've tried it with two different Boost builds as well) parent stays null every time. Can anyone point out the reason why? This is giving me a headache :( I suspect it's got something to do with there being cyclic references between parent and child... #include <boost\archive\binary_oarchive.hpp> #include <boost\archive\binary_iarchive.hpp> #include <boost\serialization\vector.hpp> #include <fstream> #include <memory> #include <vector> class A { public: A() { parent = nullptr; someInt = 0; } template <class Archive> void serialize(Archive& archive, const unsigned int version) { archive & someInt; archive & parent; archive & children; } int someInt; A* parent; std::vector<A*> children; }; int main() { A* newA = new A(); A* newPtr = new A(); newPtr->someInt = 5; newPtr->parent = newA; newA->children.push_back(newPtr); // Save. std::ofstream outputFile("test", std::fstream::out | std::fstream::binary); if (outputFile.is_open()) { boost::archive::binary_oarchive outputArchive(outputFile); // Serialize objects. outputArchive << newA; outputArchive << newPtr; outputFile.close(); } delete newA; delete newPtr; newA = nullptr; newPtr = nullptr; // Load.| std::ifstream inputFile("test", std::fstream::binary | std::fstream::in); if (inputFile && inputFile.good() && inputFile.is_open()) { boost::archive::binary_iarchive inputArchive(inputFile); // Load objects. inputArchive >> newA; inputArchive >> newPtr; inputFile.close(); } return 0; } -- View this message in context: http://boost.2283326.n4.nabble.com/Serialization-problem-with-cyclic-refere… Sent from the Boost - Users mailing list archive at Nabble.com.

2 2

[Exception] How do I inherit custom exception hierarchy from std::runtime_error rather than from std::exception?
by Egor Tensin 29 Nov '13

29 Nov '13

Hi, The issue that's confusing me arose from my intention of inheriting my exception classes from std::runtime_error rather than from std::exception. It seemed logical to me, as my exceptions are really runtime errors; getting something meaningful via what() also seemed like a good idea. However, this doesn't compile: #include <iostream> #include <stdexcept> #include <boost/exception/all.hpp> typedef boost::error_info<struct tag_foo_info, unsigned long> foo_info; struct foo_error : virtual boost::exception, virtual std::runtime_error { explicit foo_error(const char *const what) : std::runtime_error(what) { } explicit foo_error(const std::string& what) : std::runtime_error(what) { } }; static void foo() { BOOST_THROW_EXCEPTION(foo_error("foo error") << foo_info(42)); } int main(int argc, char *argv[]) { try { foo(); } catch (const std::exception& e) { std::cerr << boost::diagnostic_information(e); return 1; } return 0; } It says that there's no default constructor available for std::runtime_error. How do I fix this or should I use the idiomatic approach? The interesting thing is that if I erase the "virtual" keyword, the program compiles flawlessly. I wonder what is the reason for that, e.g. why the original code doesn't work and why the new code does, what are the consequences of making boost::exception and std::runtime_error base (non-virtual) classes, etc. I'm confused as the docs clearly recommends I build exception classes hierarchy using virtual inheritance. Could somebody please give me an insight into the inner workings of the library & inheritance mechanisms? Thank you in advance, Egor.

4 7

[Bind & Function] c function pointers
by Matthijs Möhlmann 29 Nov '13

29 Nov '13

Hello all, It was pointed out to me that the subject line was not correct, so I resent this mail with a correct subject line. I'm not sure if this is possible at all, but let me explain: I have the following function signature: typedef int (*sasl_callback_ft)(void); That function in question gets called with unknown amount of parameters (usually 3 or 4) Now I want to assign a member function to it: class admin { public: int callback_fun(void *context, int id, const char **result, unsigned *len); } boost::function<int(void *, int, const char **, unsigned *)> callback = boost::bind(&admin::callback_fun, this, _1, _2, _3, _4); Obviously the compiler doesn't allow to assign callback to a sasl_callback_ft var sasl_callback_ft fun = callback; I get compiler errors like: matthijs@hammer:~/t2$ clang++ -o main -std=c++11 main.cpp main.cpp:22:19: error: no viable conversion from 'boost::function<int (void *, int, const char **, unsigned int *)>' to 'sasl_callback_ft' (aka 'int (*)()') sasl_callback_ft cbfun = cb; ^ ~~ /usr/include/boost/function/function_template.hpp:894:5: note: candidate function operator safe_bool () const ^ 1 error generated. Attached the testcase I made for this. Regards, Matthijs

2 2

Re: [Boost-users] [Thread] Using thread accross libraries
by Sébastien Gallou 29 Nov '13

29 Nov '13

Antony, Thanks a lot for your answer. But I check the configuration of each project, and same runtime-library is used (/MDd) in both cases. So my problem doesn't come from here. If you have another idea... Thanks for your help, Sébastien

2 1

[Multi-Index] performance difference between lower_bound() and upper_bound()
by Dominique Devienne 29 Nov '13

29 Nov '13

I have a multi-index BMI (Boost 1.44), with an ordered_non_unique index on a"name" string field, which is lexicographically ordered. I'm searching for the range of values of the form "$prefix $integer", i.e. "foo 1", "foo 99", etc... to obtain this "range", I initially used (pseudo-code): auto begin = by_name_index().lower_bound(prefix + " 0"); auto end = by_name_index().upper_bound(prefix + " 9"); and within the range I test the suffix for its number'ness and keep the largest number. But I was surprised to see it performed badly for large number of calls. I switched to using instead: auto begin = by_name_index().lower_bound(prefix + " 0"); auto end = by_name_index().lower_bound(prefix + " :"); And this performs much better (20x). The "corpus" of names of this particular test may be skewing the results, since entries are added to the BMI with monotonically increasing number suffixes, and all entries have the prefix I'm looking for, yet I'm very surprised of such a large performance difference between the lower/upper version, and the lower/lower version. Anyone has a clue what could be going on? Thanks, --DD PS: I'm assuming the two versions are equivalent. Let me know if I'm mistaken please. This is not yet thoroughly tested.

3 6

Put the Library Name in the Subject Line (was: boost and c function pointers)
by Mateusz Loskot 29 Nov '13

29 Nov '13

On 29 November 2013 09:29, Matthijs Möhlmann <matthijs(a)cacholong.nl> wrote: > boost::function<int(void *, int, const char **, unsigned *)> callback = > boost::bind(&admin::callback_fun, this, _1, _2, _3, _4); Please, Put the Library Name in the Subject Line [1], it will save people's time. Name Boost refers to a *collection of libraries, hence Boost has nothing to do with C function pointers. [1] http://www.boost.org/community/policy.html#subject-line Best regards, -- Mateusz Loskot, http://mateusz.loskot.net

1 0

boost and c function pointers
by Matthijs Möhlmann 29 Nov '13

29 Nov '13

Hello all, I'm not sure if this is possible at all, but let me explain: I have the following function signature: typedef int (*sasl_callback_ft)(void); That function in question gets called with unknown amount of parameters (usually 3 or 4) Now I want to assign a member function to it: class admin { public: int callback_fun(void *context, int id, const char **result, unsigned *len); } boost::function<int(void *, int, const char **, unsigned *)> callback = boost::bind(&admin::callback_fun, this, _1, _2, _3, _4); Obviously the compiler doesn't allow to assign callback to a sasl_callback_ft var sasl_callback_ft fun = callback; I get compiler errors like: matthijs@hammer:~/t2$ clang++ -o main -std=c++11 main.cpp main.cpp:22:19: error: no viable conversion from 'boost::function<int (void *, int, const char **, unsigned int *)>' to 'sasl_callback_ft' (aka 'int (*)()') sasl_callback_ft cbfun = cb; ^ ~~ /usr/include/boost/function/function_template.hpp:894:5: note: candidate function operator safe_bool () const ^ 1 error generated. Attached the testcase I made for this. Regards, Matthijs

1 0

[mpl][fusion] How to transform vector_c into std::vector?
by Mostafa 29 Nov '13

29 Nov '13

How does one transform an mpl:vector_c into a regular std::vector? Sample input: typedef mpl::vector<int, int_<10>, int_<11>, int_<12> > some_vector_c; Thanks, Mostafa

3 5

Where can I get ml64.exe
by niXman 28 Nov '13

28 Nov '13

Hi, I trying to build boost-1.55 using MinGW-W64 for x86_64 arch. boost.context library requires ml64.exe for building, but I can't find it. I have found ml.exe (it's for i686 arch) on MSDN site[1], but I can't find ml64.exe. The question is where can I get it? Thanks. [1] http://www.microsoft.com/en-us/download/details.aspx?id=12654 -- Regards, niXman ___________________________________________________ Dual-target(32 & 64-bit) MinGW-W64 compilers for 32 and 64-bit Windows: http://sourceforge.net/projects/mingw-w64/ ___________________________________________________ Another online IDE: http://liveworkspace.org/

3 3

[Thread] Using thread accross libraries
by Sébastien Gallou 28 Nov '13

28 Nov '13

Hi all, first, thanks for this great library. I'm using Boost::thread and experiencing a problem when trying to interrupt thread executed in a dynamic library (DLL, under Windows). I reproduced it in a minimal example, that I join to this post (I don't know if attachment is authorized so I also put it on my GDrive<https://drive.google.com/file/d/0B3dXqBwTbfcAQ1E0MDRfU0hxNVE/edit?usp=shari…>, and copy the code at the end of this mail). In this code, I start a thread in the main, calling a function "doWork" of a plugin, dynamically loaded. The doWork just do some sleep and wait for boost::thread_interrupted exception. The problem is that the exception is never received when the main call interrupt on the thread. If the doWork code is in the main application, all works well. Trying to debug into Boost, I'm seeing that in the interruptible_wait function, the test "if(detail::get_current_thread_data() && detail::get_current_thread_data()->interruption_enabled)" doesn't give the same result if code is in DLL (test result is false) or in the main (true). What is the reason of this behaviour ? Thanks for your help, Sébastien Gallou Here is the code : *TestBoostThread.cpp :* IPlugin* Plugin; void doWork(){ try { Plugin->doWork(); } catch (boost::thread_interrupted&) { // End-of-thread exception was not catch by plugin, // it's a developer's error, we have to report it std::cout << "Plugin didn't catch boost::thread_interrupted."; }} int main(int argc, char* argv[]){ HMODULE libraryHandle = LoadLibrary(L"Dll.dll"); boost::function<IPlugin* ()> construct = (IPlugin* (*)(void))GetProcAddress(libraryHandle, "construct"); Plugin=construct(); boost::shared_ptr<boost::thread> thread = boost::shared_ptr<boost::thread>(new boost::thread(doWork)); Sleep(1500); thread->interrupt(); thread->join(); FreeLibrary(libraryHandle); return 0;} *Dll.cpp :* class MyPlugin : public IPlugin{ virtual ~MyPlugin(){} virtual void doWork() { try { while(1) { std::cout << "MyPlugin is running..."; // Give a chance to exit plugin thread boost::this_thread::sleep(boost::posix_time::milliseconds(1000)); }; } catch (boost::thread_interrupted&) { std::cout << "MyPlugin is stopped..."; } }}; extern "C" __declspec(dllexport) IPlugin* construct(){ return new MyPlugin;}

2 1

Hash collision for pairs of int
by Saurabh T 27 Nov '13

27 Nov '13

Hi, I'm experiencing a lot of collisions using the hash_combine function in functional/hash/hash.hpp for integer-pairs-as-keys when there are few unique ints in each of the pair's positions (put together the keys themselves are unique of course). I've uploaded a simple enough test case here: http://www.speedyshare.com/Wcem6/hash.cc.gz. If there's a more preferred way to upload, let me know and I'll reupload. With 400K pairs, this returns only 86K unique indices and has a max of 18 collisions in size_t. Am I doing something really wrong here? Thank you. saurabh

3 3

[Graph] filters and subgraphs?
by The Maschine 27 Nov '13

27 Nov '13

Hi all, What Im trying to do is the get a filtered or subgraph that holds the properties of the original graph (vertex and edge bundles). Ill use the 'subgraph' in other algorithms but from time to time I'd like to be able to trace the original vertex_descriptor and push data back to the original graph. (that might be able to happen via the original_vertex_d below but lets see..) Below is an attempt to use graph filters to do it but for reasons that can be found in topics by others, I think this is not going to work. (filtered graph are too simple.. etc) Is it possible to use the 'distance map', that I use to produce a filtered graph, for producing a subgraph that all info from the original (minus the filtered vertexes that we dont want of course) data are there and can be also further used in algorithms? Thanks ///////////////////////////// struct VertexProperties { boost::graph_traits<unGraph>::vertex_descriptor original_vertex_d; // might be needed for the question above double m_bc; // for betweenness ..... .... }; struct EdgeProperties { double m_weight1; double m_weight2; }; typedef double Weight; typedef boost::property<boost::edge_weight_t, double> EdgeWeightProperty; typedef boost::adjacency_list<boost::vecS, boost::vecS, boost::undirectedS, VertexProperties, EdgeProperties> unGraph; typedef boost::graph_traits < unGraph >::vertex_descriptor Vertex; typedef boost::property_map < unGraph, boost::vertex_index_t >::type IndexMap; typedef boost::iterator_property_map < Vertex*, IndexMap, Vertex, Vertex& > PredecessorMap; typedef boost::iterator_property_map < Weight*, IndexMap, Weight, Weight& > DistanceMap; struct vertex_distance_filter { vertex_distance_filter() { } vertex_distance_filter(std::vector<Weight> distance_map, double radius) : m_dist_map(distance_map), m_radius(radius) { } bool operator()(const typename boost::graph_traits<unGraph>::vertex_descriptor& v) const { return m_radius > m_dist_map[v]; } double m_radius; std::vector<Weight> m_dist_map; }; ////// int i = 0; // simplified boost::graph_traits<unGraph>::vertex_descriptor s_vertex = boost::vertex(i, m_ugraph); // Filter std::vector<Vertex> predecessors(boost::num_vertices(m_ugraph)); std::vector<Weight> distances(boost::num_vertices(m_ugraph), std::numeric_limits<double>::max() ); IndexMap indexMap = boost::get(boost::vertex_index, m_ugraph); PredecessorMap predecessorMap(&predecessors[0], indexMap); DistanceMap distanceMap(&distances[0], indexMap); boost::dijkstra_shortest_paths(m_ugraph, s_vertex, boost::weight_map(boost::get(&EdgeProperties::m_weight1, m_ugraph)).predecessor_map(predecessorMap).distance_map(distanceMap)); vertex_distance_filter filter(distances, 400.0f); typedef boost::filtered_graph<unGraph, vertex_distance_filter> FilteredGraphType; FilteredGraphType filteredGraph(m_ugraph, filter); // Work on the filtered graph. Subgraph maybe??? std::vector< double > v_centrality_vec(boost::num_vertices(filteredGraph), 0.0); // different weight from above. here m_weight2 boost::brandes_betweenness_centrality(filteredGraph , boost::centrality_map(boost::make_iterator_property_map(v_centrality_vec.begin(),boost::get(boost::vertex_index, filteredGraph),double())).vertex_index_map(get(boost::vertex_index, m_ugraph)).weight_map(boost::get(&EdgeProperties::m_weight2, m_ugraph)) ); // here we start having problems... comments above boost::graph_traits<unGraph>::vertex_iterator vertex_iterator_begin, vertex_iterator_end; for ( boost::tie(vertex_iterator_begin, vertex_iterator_end) = vertices(filteredGraph); vertex_iterator_begin != vertex_iterator_end; ++vertex_iterator_begin) { // this is the original unfiltered graph!!!! m_ugraph[*vertex_iterator_begin].m_bc = v_centrality_vec[*vertex_iterator_begin]; }

1 0

[log] switching from n loggers to 1
by Eric Prud'hommeaux 27 Nov '13

27 Nov '13

I'm updating an old library which sets up eight separate loggers with different channel labels: BOOST_LOG_INLINE_GLOBAL_LOGGER_DEFAULT(DefaultLog, SWObjectsLogger); BOOST_LOG_INLINE_GLOBAL_LOGGER_CTOR_ARGS(RewriteLog, SWObjectsLogger, (channel = "Rewrite")); ... BOOST_LOG_SEV(L::RewriteLog::get(), L::info) << "foo->bar\n"; I'd like to update to 1.54 (or 1.55) and before I `perl -i` the heck out of it, I'm wondering what are the tradeoffs around using a single logger: BOOST_LOG_INLINE_GLOBAL_LOGGER_DEFAULT(TheLogger, boost::log::sources::severity_channel_logger< severity_level >) ... BOOST_LOG_CHANNEL_SEV(L::TheLogger::get(), L:Rewrite, L::info) << "foo->bar"; I can guess that many loggers gives me more (future) versatility to log Rewrite stuff to a different stream and that these eight loggers come with some memory footprint. Is that about right? (Also, why does adding a template parameter for the channel BOOST_LOG_INLINE_GLOBAL_LOGGER_DEFAULT(TheLogger, boost::log::sources::severity_channel_logger< severity_level >) barf with macro errors? expressions_channel_severity_filter.cpp:306:127: error: macro "BOOST_LOG_INLINE_GLOBAL_LOGGER_DEFAULT" passed 3 arguments, but takes just 2 expressions_channel_severity_filter.cpp:306:1: error: ‘BOOST_LOG_INLINE_GLOBAL_LOGGER_DEFAULT’ does not name a type? ) -- -ericP office: +1.617.599.3509 mobile: +33.6.80.80.35.59 (eric(a)w3.org) Feel free to forward this message to any list for any purpose other than email address distribution. There are subtle nuances encoded in font variation and clever layout which can only be seen by printing this message on high-clay paper.

1 0

[multiarray] How to make a generic one from an existing C multi-array.
by Mostafa 27 Nov '13

27 Nov '13

Given the following: template <typename T, std::size_t D1> void foo(T (&arr)[D1]) { typedef boost::multi_array_ref < typename boost::remove_all_extents<T>::type, boost::rank<T[D1]>::value > arr_type; // ? = ExtentList or extents_tuple. arr_type ma(arr, ?); } Are there any existing tools to create an ExtentList or extents_tuple obj from the type of arr? Thanks, Mostafa

1 0

[graph] How to use default ColorMap when using depth_first_visit
by Laila, Akeel 26 Nov '13

26 Nov '13

Hi, I'm looking to use depth_first_visit to traverse a labeled_graph, but the below code fails to compile due to the absence of ColorMap argument: depth_first_visit(dependencyGraph, targetDepVertex, visitor(cycleDetector)); error C2780: 'void boost::depth_first_visit(const IncidenceGraph &,graph_traits<G>::vertex_descriptor,DFSVisitor,ColorMap,TerminatorFunc)' : expects 5 arguments - 3 provided e:\TR\ToolsRelease\git\boost\1.54.0\src\boost/graph/depth_first_search.hpp:320:0 : see declaration of 'boost::depth_first_visit' error C2780: 'void boost::depth_first_visit(const IncidenceGraph &,graph_traits<G>::vertex_descriptor,DFSVisitor,ColorMap)' : expects 4 arguments - 3 provided e:\TR\ToolsRelease\git\boost\1.54.0\src\boost/graph/depth_first_search.hpp:309:0 : see declaration of 'boost::depth_first_visit' On the other hand, depth_first_search compile just fine: depth_first_search(dependencyGraph, visitor(cycleDetector)); I guess what it comes down to is that a default ColorMap is utilized by depth_first_search. Anyone know how I can access this same default ColorMap (which I can then feed to depth_first_visit()) FYI, my labeled_graph type is defined as follows: typedef boost::adjacency_list<boost::vecS, boost::vecS, boost::bidirectionalS , DependencyVertex, DependencyEdge> DependencyGraphInternalType; typedef boost::labeled_graph<DependencyGraphInternalType, string> DependencyGraphType; Thanks, Akeel Laila ________________________________ This email is non-binding, is subject to contract, and neither Kulicke & Soffa Industries Inc nor its subsidiaries shall have any obligation to you to consummate the transactions herein or to enter into any agreement, other than in accordance with the terms and conditions of a definitive agreement if and when negotiated, finalized and executed between the parties.

1 0

how to learn Boost
by e.palmero＠googlemail.com 26 Nov '13

26 Nov '13

Dear Boost Developer: I am new to Boost and I would like to know any suggestion for books to get deeply inside the Boost libraries. Best Ernesto

4 3

[multiprecision] FMA without expression templates?
by Francesco Biscani 26 Nov '13

26 Nov '13

Hello, I would like to start using the Boost multiprecision library in my code. For a series of reasons, I would like to disable the expression template support (I need the return type of a + b to be the type of a or b, and not an expression). My understanding after briefly venturing into the library code is that there is the concept of a multiply_add() function (e.g., in boost/multiprecision/detail/default_ops.hpp), but that such support is hidden behind the expression template magic and it is not exposed when ET is disabled. I tried to look into Boost math as well, where there is a fused multiply-add function, but it seems like it is built to support floating-point types and I need support for integral types (for the implementation of algebraic operations on polynomials with integer coefficients). Is my understanding correct or is there a way to use some kind of a multiply_accumulate function in multiprecision without using ET? Many thanks, Francesco.

1 0

[random] infinite loop in uniform_real_distribution
by Jérémy Coulon 26 Nov '13

26 Nov '13

Hello, I'm using Boost 1.54. The following code hangs in infinite loop when generating a single floating point number : #include <boost/random.hpp> #include <iostream> #include <limits> int main() { boost::random::mt19937 rng; boost::random::uniform_real_distribution<float> distrib( -std::numeric_limits<float>::max(), std::numeric_limits<float>::max()); std::cout << distrib(rng) << std::endl; return 0; } I can reproduce the bug with both - Linux GCC 4.8 x86_64 and - Windows VisualStudio 2012 32bits It looks like this uniform distribution doesn't work if the range [min,max] is large. From uniform_real_distribution.hpp:61 T result = numerator / divisor * (max_value - min_value) + min_value; Here the operation (max_value - min_value) produces an overflow. Regards, Jeremy

3 7

[Iostreams] Segmentation fault when stream is flushed or closed
by Steven Maenhout 26 Nov '13

26 Nov '13

Hello, I'm trying to open a boost::iostreams::stream in the constructor of a class and to close the stream in the destructor. This works fine but when I pass a reference to a std::stringstream in that same constructor I get a segmentation fault in the destructor when I flush or close the stream. This happens irrespective if the passed std::stringstream reference takes part in the boost::iostream::stream or not. I'm using gcc 4.6.3 with boost 1.53 on Linux x86_64. Below I provided a small example that exhibits this behaviour. Any ideas anyone? #include "test.h" int main(int argc, char **argv) { std::stringstream logStream; Test test(logStream); return 0; } where test.h contains: #include <fstream> #include <sstream> #include <boost/iostreams/stream.hpp> #include <boost/iostreams/tee.hpp> typedef boost::iostreams::tee_device<std::stringstream, std::ofstream> TeeDevice; typedef boost::iostreams::stream<TeeDevice> TeeStream; class Test { public: Test(const std::stringstream& logStream) { std::ofstream dummyFileHandle("/dev/null", std::ios_base::out | std::ios_base::app); std::stringstream logStream2; TeeDevice myTee (logStream2, dummyFileHandle); m_out.open(myTee); } virtual ~Test() { if(m_out.is_open()) { m_out.flush(); m_out.close(); } }; protected: TeeStream m_out; };

2 4

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