- Boost-users - lists.boost.org

boost::filesystem::path construct from iterator
by Frank Kingswood 05 Jan '12

05 Jan '12

Hi I am getting surprising build errors when attempting to create a path from iterators. For example: boost::filesystem::path path("a/b/c"); boost::filesystem::path tail(path.begin(),path.end()); fails to build on the tail constructor. The actual error is about three screenfuls so I will omit this here for now. My intention is to do something a bit more interesting, e.g. path.begin()+1 to skip the leading path component. Thanks, Frank

1 0

boost:shared_ptr destructor, SIGBUS, MIPS 64
by sumanth krishna 05 Jan '12

05 Jan '12

I am using a STL list of boost shared pointer in my code and and it randomly dumps core. Below is the code snippet and the core stack. class A () { virtual ~A(); string getsomestring(); } class B: public A { } typedef shared_ptr<A> A_ptr; class C // singelton class { public: getList(list <A_ptr>& temp_list) { list<A_ptr>::iterator itr = _inv.begin(); for( ; itr != _inv.end(); itr++ ) { temp_list.push_back( (*itr) ); } getListContent ( list<string>& str_list) { list<A_ptr>::iterator itr = _inv.begin(); for( ; itr != _inv.end(); itr++ ) { str_list.push_back( (*itr)->getsomestring() ); } } private: list <A_ptr> _inv; } main() { C *c= new C; // create an instance ( its a singleton class) // On creating an instance of C, the private member variable inventory is populated. // inventory.push_back(A_ptr(new FRU ( fvar ))) thread 1 { list<A_ptr> var1; c->getList(var1); list <string> var2; c->getListContent(var2); } // End of thread delete c; } // end of main Now this code works fine for some iterations and then dumps core with the following stack ###################### Thread 1 (Thread 0x55567f7af0 (LWP 23773)): #0 0x0000000120038ecc in boost::detail::atomic_decrement (pw=0xa) sysroot/usr/include/boost/smart_ptr/detail/sp_counted_base_gcc_mips.hpp:66 #1 0x0000000120038f44 in boost::detail::sp_counted_base::release (this=0x2) #2 0x00000001200390ac in boost::detail::shared_count::~shared_count (this=0x1200b08d8, __in_chrg=<value optimized out>) #3 0x000000012003eaf4 in boost::shared_ptr<A>::~shared_ptr (this=0x1200b08d0, __in_chrg=<value optimized out>) #4 0x000000012003eb4c in __gnu_cxx::new_allocator<boost::shared_ptr<A> >::destroy (this=0xffffeaf640, __p=0x1200b08d0) #5 0x000000012003c9e0 in std::_List_base<boost::shared_ptr<A>, std::allocator<boost::shared_ptr<A> > >::_M_clear (this=0x1200a8ee8) #6 0x000000012003b4ac in std::_List_base<boost::shared_ptr<A>, std::allocator<boost::shared_ptr<A> > >::~_List_base (this=0x1200a8ee8, __in_chrg=<value optimized out>) #7 0x000000012003a0e8 in std::list<boost::shared_ptr<A>, std::allocator<boost::shared_ptr<A> > >::~list (this=0x1200a8ee8, __in_chrg=<value optimized out>) #8 0x0000000120068b64 in C::~C (this=0x1200a8e70, __in_chrg=<value optimized out>) ###################################################### This code is cross compiled for MIPS64 arch on linux x86_64 machine and is running on a 64 bit MIPS machine. I am not sure why it is dumping core. It dumps core giving a *SIGBUS* error. Do i have to specifically handle the delete operation of the List ? I am using the default destructor for "C" class and there is no pointers in the class A and Class A also doesnt have anything in its destructor, no memory allocations are done in Class A. Any suggestions regarding this problem would be highly helpful.

2 4

boost compilation error
by Prasanth Madhavan 05 Jan '12

05 Jan '12

I have a class using boost interprocess. some of the code used in it are here http://stackoverflow.com/questions/8653207/boost-interprocess-vector-creati… and here http://stackoverflow.com/questions/8517115/inserting-a-boost-vector-inside-… when i use g++ -c and compile it, it compiles. I have another big project with whom i would like to use this class. so i added it to that project, and made changes to accomodate the new class and use it. But when i compile it, it crashes with a really big error and i have no clue what the hell is going on. Please help. I have attached a sample output from make. One more thing. Inside the project. the class compiles fine. the attached message comes in when compiling another file that has the header file of this class attached to it. stats.hpp -> this is the header to the class that uses boost manager.hpp -> this has stats.hpp included filter.cpp -> this has manager.hpp included. -- Prasanth Madhavan

1 0

Properties error reading undirected graph with "read_graphviz"
by nunofaria 05 Jan '12

05 Jan '12

Hi, I am trying to read an undirected_graph from a .dot file with read_graphviz, but I seem to some problems regarding the properties of the graph, which are *vertex_index* and *edge_weight*. /terminate called after throwing an instance of 'boost::exception_detail::clone_impl<boost::exception_detail::error_info_injector<boost::dynamic_const_put_error> >' what(): Attempt to put a value into a const property map: / The code I am using is followed: *typedef property<edge_weight_t, int> EdgeWeightProperty; typedef adjacency_list<vecS, vecS, undirectedS, no_property, EdgeWeightProperty> undirected_graph; typedef property_map<undirected_graph, edge_weight_t>::type weight_map_type; typedef property_traits<weight_map_type>::value_type weight_type; typedef std::pair<int, int> edge_t; undirected_graph read_graph(std::string filename, dynamic_properties * dp) { std::ifstream in(filename.c_str()); // ... check errors in file ... undirected_graph g(0); read_graphviz(in, g, *dp, "node_id"); in.close(); return g; } int main() { boost::dynamic_properties dp; // populate graph properties by reference undirected_graph g = read_graph("test_boost_graph.dot", &dp); dp.property("node_id", get(vertex_index, g)); dp.property("w", get(edge_weight, g)); // write to cout write_graphviz_dp(cout, g, dp, "node_id"); return 0; }* I think the example is pretty simple and it should work. However I don't get much when googling the resulting error. Does someone know what's this about? Thanks in advance -- View this message in context: http://boost.2283326.n4.nabble.com/Properties-error-reading-undirected-grap… Sent from the Boost - Users mailing list archive at Nabble.com.

1 0

Problems using boost::interprocess on Mac OS X
by Robert Bielik 05 Jan '12

05 Jan '12

Hi All, I'm trying to use boost::interprocess::named_mutex (1.47.0) on Mac OS X (10.6.7) with GCC 4.0, but I get loads of errors when compiling, the first ones shown here: /boost_1_47_0/boost/interprocess/sync/emulation/named_creation_functor.hpp:38:0 /boost_1_47_0/boost/interprocess/sync/emulation/named_creation_functor.hpp:38: error: expected type-specifier before 'Lm_arg' /boost_1_47_0/boost/interprocess/sync/emulation/named_creation_functor.hpp:38:0 /boost_1_47_0/boost/interprocess/sync/emulation/named_creation_functor.hpp:38: error: expected `)' before 'Lm_arg' /boost_1_47_0/boost/interprocess/sync/emulation/named_creation_functor.hpp:38:0 /boost_1_47_0/boost/interprocess/sync/emulation/named_creation_functor.hpp:38: error: expected `;' before 'Lm_arg' /boost_1_47_0/boost/exception/exception.hpp:320:0 /boost_1_47_0/boost/exception/exception.hpp:320: error: anachronistic old-style base class initializer /boost_1_47_0/boost/exception/exception.hpp:320:0 /boost_1_47_0/boost/exception/exception.hpp:320: error: unnamed initializer for 'boost::exception_detail::error_info_injector<T>', which uses multiple inheritance /boost_1_47_0/boost/exception/exception.hpp:321:0 /boost_1_47_0/boost/exception/exception.hpp:321: error: 'Lx' was not declared in this scope /boost_1_47_0/boost/exception/exception.hpp:418:0 /boost_1_47_0/boost/exception/exception.hpp:418: error: anachronistic old-style base class initializer /boost_1_47_0/boost/exception/exception.hpp:418:0 /boost_1_47_0/boost/exception/exception.hpp:418: error: unnamed initializer for 'boost::exception_detail::clone_impl<T>', which uses multiple inheritance /boost_1_47_0/boost/exception/exception.hpp:419:0 /boost_1_47_0/boost/exception/exception.hpp:419: error: 'Lx' was not declared in this scope ... Any ideas how to fix this ? TIA /Rob

2 2

[Phoenix][v3] Argument/State dependent return type of actors?
by Josef Weinbub 05 Jan '12

05 Jan '12

Hi Recently I made myself familiar with Phoenix v3, more specifically with actors. I did a few test implementations, and I wondered if there is a way to access the argument types (nested in the context's environment) and/or the type of the state(s) (nested in the proto expression) for the actor's result type declaration. Have a look at the following actor dummy implementation, especially at the line ''typedef int result_type;'': (for the sake of completeness, the complete actor implementation is provided) ------------------------------------------------------------ BOOST_PHOENIX_DEFINE_EXPRESSION( (boost)(phoenix)(myactor) , (boost::phoenix::meta_grammar) ) struct myactor_eval { // ------------------------ // the result type can not be made dependable from // one of the actors argument types .. it is // typedef int result_type; // ------------------------ template <typename StateExpr, typename Context> result_type operator()(StateExpr const& state_expr, Context & ctx) const { return -1; } }; namespace boost { namespace phoenix { template <> struct default_actions::when< rule::myactor> : boost::phoenix::call< ::myactor_eval> {}; template <typename T> typename expression::myactor<T>::type const inline myactor(T& t) { return expression::myactor<T>::make(t); } }} ------------------------------------------------------------ As I already stated, I wonder if there is a way to have access to the argument and state types for the result type, maybe as it was possible in Phoenix v2 via a nested template struct which got the same template parameters as the functor, like the simple example in the following: ------------------------------------------------------------ struct myactor_eval { template <typename StateExpr, typename Context> struct result { typedef typename result_of::env<Context>::type Environment; typedef typename remove_reference< Environment>::type::args_type Args; typedef typename result_of::value_at_c< Args, 0>::type Parameter; // make the result type argument dependent! typedef typename Parameter::value_type type; }; ... }; ------------------------------------------------------------ I do hope that I haven't overlooked something in the docs, sorry if I did. Thanks for your support! Cheers, Josef Weinbub

2 3

Re: [Boost-users] [Iostreams] Buffering nonblocking I/O
by Nat Linden 05 Jan '12

05 Jan '12

On Wed, Jan 4, 2012 at 5:21 PM, Chris Cleeland <chris.cleeland(a)gmail.com> wrote: > On Wed, Jan 4, 2012 at 1:44 PM, Nat Linden <nat(a)lindenlab.com> wrote: >> Let's postulate a new Boost.Iostreams Concept to describe an object >> capable of buffering data between producer and consumer. >> Until we can settle on a better name, as a placeholder, let's just >> call this a Queue. > You could call this thing a "conduit". Interesting! Although the term doesn't quite jump out at me, I can understand the metaphor, and to my knowledge it has the virtue of not already being hopelessly overloaded. If other people like it, I could go with that. >> ... I actually need an unbounded Queue for this. > > AND > >> It would also be possible to implement a Queue based on an actual OS pipe. > > Beware that OS pipes are bounded. Yup, I know that. Sorry I wasn't clearer: I intended to suggest three different plausible implementations of the Queue/Conduit concept, with variations on the one I'm actually planning to build. For an unbounded implementation I'm toying with a std::list< std::basic_string<Ch> >. I consider it interesting that you could fairly simply build an implementation around an OS pipe, but that doesn't address the use case that interests me most at the moment. I tossed it out there for purposes of illustration -- I guess a bit too tersely.

1 0

[geometry] GGL mailing list moved
by Mateusz Loskot 04 Jan '12

04 Jan '12

Hi, To Whom It May Concern... The Boost.Geometry library mailing list has moved from ggl at lists.osgeo.org server to geometry at lists.boost.org server. All existing subscribers and archives have been moved to the new server. The new list is available at: http://lists.boost.org/mailman/listinfo.cgi/geometry as well as listed on the main page: http://lists.boost.org/ It is also mirrored at Nabble: http://boost-geometry.203548.n3.nabble.com/ (Mirror at gmane.org may be added in future.) The old list at lists.osgeo.org will be wiped out soon. If anyone experiences any problems with the new geometry at lists.boost.org, please contact me directly. I'd like to thank OSGeo Foundation for hosting the first mailing list and the Boost mailman admins for help with the new one. Best regards, -- Mateusz Loskot, http://mateusz.loskot.net

1 0

[Iostreams] Buffering nonblocking I/O
by Nat Linden 04 Jan '12

04 Jan '12

I find myself wanting to extend Boost.Iostreams to support (at least a particular use case for) nonblocking I/O. I'd like to sketch a couple concepts, hoping you will improve and generalize the notion. In particular, it's easily possible that I don't yet understand Iostreams well enough: what I'm describing may well fit into existing Concepts better than I realize. Boost.Iostreams intends to provide more complete support for nonblocking I/O in future [0]. We can hope that a discussion around these ideas could help evolve the library in that direction. First I want to acknowledge Alexander Nasonov's work from 2003 [1]. I haven't used or even looked at his "iostream-like pipes" library [2] because I'm dubious about registering with Yahoo! before being allowed to download it. (John Torjo seems to have had some trouble too. [3]) If it were posted somewhere more freely accessible, I'd be interested to examine it because I think there's at least conceptual overlap. Let's postulate a new Boost.Iostreams Concept to describe an object capable of buffering data between producer and consumer. It's not quite a Filter because, as I understand it, control is passed to a Filter at only one end. An InputFilter receives control at the consumer end; it forwards the call to its upstream Source. Conversely, an OutputFilter receives control at the producer end, forwarding the call to its downstream Sink. I'm talking about an object that receives control at both the producer and consumer end, providing a buffer between them. My first thought was to call this concept a Pipe because it bears a strong conceptual resemblance to OS pipes. But others in the aforementioned mail thread ([4], [5]) point out that using the word "pipe" in connection with Iostreams (or C++ streams in general) is too easily misinterpreted: one tends to assume a stream interface to a real OS pipe. Other plausible names are "buffer" or "synchronization channel" [4] or "message queue." Talking about a "buffer stream" versus a "streambuf" could fairly quickly get confusing. I shy away from any form of "channel" simply because, in our own code base, the word "channel" is already overloaded to mean four or five vastly different things. Of course "message queue" already has another specific meaning too. [6] Until we can settle on a better name, as a placeholder, let's just call this a Queue. Naturally the producer end should model Sink, and the consumer end should model Source. Why elevate this to a concept? Why not just provide a class? Because different use cases suggest different implementations -- all of which could be plug-compatible. To the extent I understand it, Alexander's library [1] appears to be targeted at cross-thread message passing. It implicitly handles thread synchronization. He also mentions unlimited vs. limited capacity, that is, a bounded max size: when the buffer is full, a producer will block until a consumer has eaten some of the pending data. Unless I went off the rails somewhere, this would be a valid model of the Queue concept. My use case targets an interactive program built around an event loop. I'm not passing data between different threads, so thread synchronization would be unnecessary overhead. Instead, every iteration of the main loop I intend to poll a nonblocking source and a nonblocking sink. I want to use a couple such Queue objects to buffer the data. The application logic must be able to write data to a std::ostream. (If the producer end of a Queue models Sink, it should be straightforward to construct such an ostream based on this Queue.) Because the Sink underlying an ostream operation must model Blocking, I actually need an unbounded Queue for this. Then each iteration of the main loop will attempt to write all pending data on the nonblocking sink; data actually written can be consumed from the Queue. Unwritten data will be handled by subsequent iterations. The input side is similar. Each iteration of the main loop will attempt to fill a temporary buffer from the nonblocking source; the data it obtains will be put into the other Queue. (This can be a bounded Queue: given a way to determine how much buffer remains available, we can limit the size of the nonblocking read.) Presently there will be "enough" data for the application logic to read an istream attached to the consumer side of the Queue. This is so we can guarantee that the application-level istream read operation can be completely satisfied without blocking. Determination of "enough" is of course protocol-specific, as is the means for notifying the application logic. I would want such details to belong to a specific instance of the concept, perhaps a subclass of a provided base class, rather than part of the Queue concept itself. I've been speaking of a nonblocking "source" and "sink" (in lowercase) because, for me, these are actually APR I/O functions. But it occurs to me that we could provide adapters to existing Iostreams Source and Sink objects, using the Iostreams conventions for nonblocking I/O. One need only arrange to poll the adapters periodically. It would also be possible to implement a Queue based on an actual OS pipe. Does this avenue seem worth pursuing? I'm going to build something like this anyway, but (a) I hope you can help me improve the abstractions and (b) it may be worth trying to Boostify the code for possible contribution. [0] http://www.boost.org/doc/libs/1_48_0/libs/iostreams/doc/guide/asynchronous.… [1] http://lists.boost.org/Archives/boost/2003/08/51289.php [2] http://groups.yahoo.com/group/boost/files/pipes.zip [3] http://lists.boost.org/Archives/boost/2003/08/51310.php [4] http://lists.boost.org/Archives/boost/2003/08/51405.php [5] http://lists.boost.org/Archives/boost/2003/08/51448.php [6] http://www.amqp.org/

1 0

[Container] deque emplace() requirements
by Szymon Gatner 04 Jan '12

04 Jan '12

Hi, question: why container::deque<T>::emplace_back() requires T to be copyable? Shouldn't it just be using placement new operator with passed c-tor params? Unless growing of deque causes elements to be copied which is not what I want at all (hence deque and not vector). Cheers, Simon -- Szymon Gatner The Lordz Games Studio www.thelordzgamesstudio.com

3 5