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

RE: [Boost-users] SUN sparc GNU 2.95.3 build fail
by Naeem ahmad 11 Apr '05

11 Apr '05

Hi Thanks, Can I able to get source code of boost compitable for unix OS. With lines will have CR/LF at the end from boost.org How to build the boost.org all libraries on SUN solaris machine. Thanks, Naeem -----Original Message----- From: boost-users-bounces(a)lists.boost.org [mailto:boost-users-bounces@lists.boost.org] On Behalf Of Peter Dimov Sent: 11 April 2005 18:51 To: boost-users(a)lists.boost.org Subject: Re: [Boost-users] SUN sparc GNU 2.95.3 build fail Naeem ahmad wrote: > Hi all, > > I am getting this error when try to build on solaris, using g++, I am > only using > > Class shared_ptr > > > > > > g++ -c -I/opt/sfw/lib/g++-include -I/usr/local/include > -I/opt/sfw/lib/gcc-lib/sparc-sun-solaris2.8/2.95.3/include > -I/usr/local/boost_1_32_0 console_app.cpp > In file included from /usr/local/boost_1_32_0/boost/config.hpp:44, > from /usr/local/boost_1_32_0/boost/shared_ptr.hpp:17, > from console_app.cpp:7: > /usr/local/boost_1_32_0/boost/config/stdlib/sgi.hpp:29: Invalid token > in _expression > In file included from > /usr/local/boost_1_32_0/boost/config/platform/solaris.hpp:17, > from /usr/local/boost_1_32_0/boost/config.hpp:53, > from /usr/local/boost_1_32_0/boost/shared_ptr.hpp:17, > from console_app.cpp:7: > /usr/local/boost_1_32_0/boost/config/posix_features.hpp:51: Invalid > token in _expression Check your line endings. If you moved Boost from a Windows machine to the Solaris box, the lines will have CR/LF at the end, not LF. _______________________________________________ Boost-users mailing list Boost-users(a)lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users AIRCOM to present OSS, Planning & Optimization products and services at the IIR Performance Measurement Conference, April 4-7th 2005, Budapest. Visit us at Booth 12. www.iir-conferences.com Disclaimer: The information contained in this e-mail, including any attachments to it, is confidential and intended only for the person(s) to whom it is addressed. Any examination, distribution, disclosure, printing, or copying of this information, or reliance upon this information by any person other than the intended recipient(s) is strictly prohibited. If this e-mail has been misdirected and you are not the intended recipient, please notify the sender immediately and delete this e-mail from your system. The views and opinions contained in this transmission represent those of the author and do not necessarily reflect those of AIRCOM International. AIRCOM International may monitor incoming and outgoing e-mails. By replying to this message, you consent to this monitoring. This e-mail has been scanned by McAfee Group Shield prior to transmission. However, recipients are advised to apply their own antivirus detection measures to this e-mail and any attachments upon receipt. AIRCOM International does not accept liability for any damage or losses arising as a result of receiving this e-mail.

3 2

Using shared_ptr slightly different
by Daniel Lidström 11 Apr '05

11 Apr '05

Hello, I want to use the shared_ptr with objects that are allocated using a factory. The problem is the deallocation. It has to be done with a ``manager'' class. For example, here is how the allocation and deallocation has to be done: PxyFileData& geo_file = dynamic_cast<PxyFileData&>(fileMan.New("geo")); fileMan.Close(geo_file); I would like to be able to put shared_ptr<PxyFileData>'s into a std::vector and then forget about the deallocation. I.e. fileMan.Close(...) should be done automatically when the objects aren't needed anymore. But since the deallocation isn't simply delete, how can I do this? Thanks! -- Daniel SBG AB

4 3

SUN sparc GNU 2.95.3 build fail
by Naeem ahmad 11 Apr '05

11 Apr '05

Hi all, I am getting this error when try to build on solaris, using g++, I am only using Class shared_ptr g++ -c -I/opt/sfw/lib/g++-include -I/usr/local/include -I/opt/sfw/lib/gcc-lib/sparc-sun-solaris2.8/2.95.3/include -I/usr/local/boost_1_32_0 console_app.cpp In file included from /usr/local/boost_1_32_0/boost/config.hpp:44, from /usr/local/boost_1_32_0/boost/shared_ptr.hpp:17, from console_app.cpp:7: /usr/local/boost_1_32_0/boost/config/stdlib/sgi.hpp:29: Invalid token in _expression In file included from /usr/local/boost_1_32_0/boost/config/platform/solaris.hpp:17, from /usr/local/boost_1_32_0/boost/config.hpp:53, from /usr/local/boost_1_32_0/boost/shared_ptr.hpp:17, from console_app.cpp:7: /usr/local/boost_1_32_0/boost/config/posix_features.hpp:51: Invalid token in _expression /usr/local/boost_1_32_0/boost/config/posix_features.hpp:67: Invalid token in _expression In file included from /usr/local/boost_1_32_0/boost/config.hpp:57, from /usr/local/boost_1_32_0/boost/shared_ptr.hpp:17, from console_app.cpp:7: /usr/local/boost_1_32_0/boost/config/suffix.hpp:34: Invalid token in _expression /usr/local/boost_1_32_0/boost/config/suffix.hpp:61: Invalid token in _expression /usr/local/boost_1_32_0/boost/config/suffix.hpp:70: Invalid token in _expression /usr/local/boost_1_32_0/boost/config/suffix.hpp:97: Invalid token in _expression /usr/local/boost_1_32_0/boost/config/suffix.hpp:105: Invalid token in _expression /usr/local/boost_1_32_0/boost/config/suffix.hpp:113: Invalid token in _expression /usr/local/boost_1_32_0/boost/config/suffix.hpp:121: Invalid token in _expression /usr/local/boost_1_32_0/boost/config/suffix.hpp:130: Invalid token in _expression /usr/local/boost_1_32_0/boost/config/suffix.hpp:140: Invalid token in _expression /usr/local/boost_1_32_0/boost/config/suffix.hpp:200: Invalid token in _expression /usr/local/boost_1_32_0/boost/config/suffix.hpp:211: Invalid token in _expression /usr/local/boost_1_32_0/boost/config/suffix.hpp:226: Invalid token in _expression In file included from console_app.cpp:7: /usr/local/boost_1_32_0/boost/shared_ptr.hpp:264: Invalid token in _expression /usr/local/boost_1_32_0/boost/shared_ptr.hpp:271: Invalid token in _expression make: *** [console_app.o] Error 1 my cpp file is console_app.cpp #include <map> #include <boost/shared_ptr.hpp> using namespace std; using namespace boost; class mytest { public: mytest() { } ~mytest() { bool b = true; } }; int main() { map<int,shared_ptr<mytest> > m_map1; shared_ptr<mytest> p(new mytest); m_map1[1] = p; m_map1.clear(); return 0; } Thanks, Naeem AIRCOM to present OSS, Planning & Optimization products and services at the IIR Performance Measurement Conference, April 4-7th 2005, Budapest. Visit us at Booth 12. www.iir-conferences.com Disclaimer: The information contained in this e-mail, including any attachments to it, is confidential and intended only for the person(s) to whom it is addressed. Any examination, distribution, disclosure, printing, or copying of this information, or reliance upon this information by any person other than the intended recipient(s) is strictly prohibited. If this e-mail has been misdirected and you are not the intended recipient, please notify the sender immediately and delete this e-mail from your system. The views and opinions contained in this transmission represent those of the author and do not necessarily reflect those of AIRCOM International. AIRCOM International may monitor incoming and outgoing e-mails. By replying to this message, you consent to this monitoring. This e-mail has been scanned by McAfee Group Shield prior to transmission. However, recipients are advised to apply their own antivirus detection measures to this e-mail and any attachments upon receipt. AIRCOM International does not accept liability for any damage or losses arising as a result of receiving this e-mail.

2 1

smart_ptr question
by Serge Skorokhodov 11 Apr '05

11 Apr '05

Hi all, I've encountered a situation when destructors to local objects are not called after an exception is raised. I use Borland C++ version 5.6.4 (Borland C++Builder 6). The examples are compiled with following command to ensure that destructor cleanup is on: bcc32 -RT -x -xd -I<boost_include_path> boosttest.cpp bcc32 -RT -x -xd -I<boost_include_path> boosttest1.cpp The code is attached. Output of boosttest.cpp is: C:\buf\temp\ttt>boosttest1 A is created! Global shared_ptr<A> destroyed! A is created! Local A variable destroyed! A is created! auto_ptr<A> destroyed! A is created! scoped_ptr<A> destroyed! A is created! Local shared_ptr<A> destroyed! Access to global object through the local one! Global shared_ptr<A> destroyed! B is being created! scoped_ptr<A> destroyed! auto_ptr<A> destroyed! Local A variable destroyed! Exception cought: Too bad! Global shared_ptr<A> destroyed! Output of boosttest1.cpp is: C:\buf\temp\ttt>boosttest1 A is created! Global shared_ptr<A> destroyed! A is created! Local A variable destroyed! A is created! auto_ptr<A> destroyed! A is created! scoped_ptr<A> destroyed! A is created! Local shared_ptr<A> destroyed! Access to global object through the local one! Global shared_ptr<A> destroyed! B is being created! scoped_ptr<A> destroyed! auto_ptr<A> destroyed! Local A variable destroyed! Exception cought: Too bad! Global shared_ptr<A> destroyed! The problem is that the object created with the line "shared_ptr<A> spa(new A("Local shared_ptr<A> destroyed!"));" is destroyed in boosttest.cpp and is not destroyed in boosttest1.cpp. If shared_ptr is replaced with plain pointer, everything works fine (see boosttest2.cpp). I would appreciate explaining what's wrong in my code. TIA.

2 1

matrix<double> to double[][] conversion
by Simon Monckton 11 Apr '05

11 Apr '05

Hello all, I'm interested in passing the raw data of a BOOST matrix<double> through a CORBA transaction (mostly founded on simple data types).Given that I'm a newbie to BOOST, Is there a way to convert a BOOST matrix to a double[][] array without element-by-element assignment? -- --------------------------------------------------------------------- Dr. Simon Monckton Defence Scientist Tactical Vehicle Systems Section DRDC Suffield Defence Research and Development Canada Phone: (403) 544-4724 Email: Simon.Monckton(a)drdc-rddc.gc.ca ---------------------------------------------------------------------

1 0

Tuples and stringstream
by CodeLogic 11 Apr '05

11 Apr '05

Hi, I'm trying to use stringstreams in a tuple like fstream fin(filename.c_str(), ios_base::in); tuple<stringstream, stringstream, stringstream, stringstream> test; fin>>test; I also just tried declaring a variable of type: tuple<stringstream> test; However, both, in MS VC++ 7.0 give me the following error: c:\.....\include\boost-1_32\boost\tuple\detail\tuple_basic_no_partial_spec.hpp(190): error C2558: class 'std::basic_stringstream<_Elem,_Traits,_Alloc>' : no copy constructor available or copy constructor is declared 'explicit' with [ _Elem=char, _Traits=std::char_traits<char>, _Alloc=std::allocator<char> ] I'm basically looking for a solution of being able to stream tuples with strings in the them in and out of a file. Any suggestions will be appreciated. Thanks !

2 4

[BGL] Problem with counting paths/custom dfs_visitor
by Pete Donnell 11 Apr '05

11 Apr '05

Hi, I hope you will forgive me for asking a rather simple question. I have been having a lot of trouble writing a visitor for use in depth first search. The algorithm I'm attempting to write is supposed to count the number of different paths between two vertices on a directed graph. The graph may or may not contain cycles, and of course walks that contain cycles are not counted as paths. The way I've approached the problem is to induce a subgraph on the source and sink vertices, by copying the graph and then removing any vertices that do not lie on a path between the source and sink. My plan then is to do a depth first search on the induced subgraph, using a custom visitor that counts the number of forward or cross edges, which I think will be a count of the number of paths between the source and sink. To be honest, I haven't thought too hard about whether this is algorithmically correct, as the main problem is with the visitor. If I figure out to write custom visitors then it shouldn't be too hard to write other algorithms. As things stand, the function to induce a subgraph is working fine (although I am not using the Boost subgraph, mainly because it isn't documented in the book and so I didn't become aware of its existence until after I'd written the code). Incidentally, this function is useful in itself, which is why I have used it. I'm aware that it's not a very efficient way of solving the problem. The code I've written for the visitor to call on the path counting algorithm currently goes like this (I have slightly modified it a lot of times to try and get it to work): template<typename OutputIterator> class EnumeratorVisitor : public boost::dfs_visitor<OutputIterator> { private : long unsigned int pathCount; public : EnumeratorVisitor() : boost::default_dfs_visitor(), pathCount(1) {} EnumeratorVisitor(OutputIterator out) : boost::dfs_visitor<OutputIterator> (out), pathCount (1) {} long unsigned int getPathCount() const { return pathCount; } template <typename Graph, typename Edge> void forward_or_cross_edge(const Edge& e, const Graph& g) { ++pathCount; } }; The code where I use it looks like this: template<typename Graph> long unsigned int enumeratePaths(const Graph& graph, const typename boost::graph_traits<Graph>::vertex_descriptor& startNode,[BGL] problem with const typename boost::graph_traits<Graph>::vertex_descriptor& endNode) { typedef typename boost::graph_traits<Graph>::edge_descriptor Edge; std::vector<Edge> forwardOrCrossEdges; // vector used to store the forward or cross edges Graph* tempGraph = generateSubGraph(graph, startNode, endNode); // this function induces a subgraph as previously mentioned typedef boost::color_traits<boost::default_color_type> Colour; std::vector<boost::default_color_type> colourMap(boost::num_vertices(*tempGraph), Colour::white()); EnumeratorVisitor<typename std::back_insert_iterator<typename std::vector<Edge> > > edgeInserter(std::back_inserter(forwardOrCrossEdges)); depth_first_visit(graph, startNode, edgeInserter, boost::make_iterator_property_map(colourMap.begin(), boost::get(boost::vertex_index, *tempGraph)) ); return edgeInserter.getPathCount(); } I'm sure there are obvious errors in there to those who know what they're doing, but I've been looking at this problem for over a month now without success, so it's got to that stage where I don't really know what's going on anymore. I've hunted through the book, online code and so on, but I can't figure it out. It gives about three pages of template errors at the moment! There have been other minor variants, but all of them have given errors of some kind. If anyone can point out what I'm doing wrong, I'd greatly appreciate it. If more information is needed, I'll happily provide it. By the way, I'm sure that this problem of path counting has been approached before, it anyone has any insights to offer, I'd also appreciate that! Many thanks for your time, Pete

1 1

Bad adjacency_iterator with -O2, -m64 and gcc 3.2.2 on an opteron
by Michal Simecek 11 Apr '05

11 Apr '05

Hi, compiling and linking the following program on a opteron with the following command and the operating system red hat 3 (current enterprise server version) gcc-3.2.2 -c -I. -I../source -I./boost_1_32_0 -O2 -m64 boosttest.cc -o boosttest.o gcc-3.2.2 -m64 -o boosttest boosttest.o -lstdc++ will cause, that the program runs into an endles loop. I figured out, that the pointer in VIter which is compared when comparing VIter and VIterEnd is damaged. With a lot of differen gcc versions and also in 32 bit mode and with lower optimization it works fine. The problem is, I have to run it also compiled with gcc 3.2.2. Is it an optimization bug in the compiler or any mistake I made or a problem in the boost? I was looking for a hint on the net but without success. Can anybody help? Thanks ------------------------------------------------------------------------------- int main (int argc, char **argv) { typedef boost::adjacency_list < boost::listS, boost::listS, boost::undirectedS > my_graph2_t; my_graph2_t MyGraph2; boost::graph_traits<my_graph2_t>::vertex_descriptor MyVDescriptor; boost::graph_traits<my_graph2_t>::vertex_descriptor MyNextVDescriptor; MyVDescriptor = boost::add_vertex(MyGraph2); MyNextVDescriptor = boost::add_vertex(MyGraph2); boost::add_edge(MyVDescriptor, MyNextVDescriptor, MyGraph2); boost::graph_traits<my_graph2_t>::adjacency_iterator VIter; boost::graph_traits<my_graph2_t>::adjacency_iterator VIterEnd; tie(VIter, VIterEnd) = boost::adjacent_vertices(MyVDescriptor, MyGraph2); while ( VIter != VIterEnd ) { std::cout << "loop ..." << std::endl; ++VIter; } return 0; } --------------------------------------------------------------------------------

2 2

Re: You provide gun, I provide foot.
by C. Michailidis 10 Apr '05

10 Apr '05

> > Answer.. Don't take the examples at their face value Likewise. > > you can do this: > > > > class counter > > { > > public: > > counter() : guard(this->mutex) { > > this->count = 0; > > this->guard.unlock(); > > } > > void lock() { > > guard.lock(); > > } > > int increment() { > > assert(this->guard.locked()); > > return ++count; > > } > > void unlock { > > assert(!this->guard.locked()); > > this->guard.unlock(); > > } > > // ..Nothing to do here.. > > // ~counter() { > > // } > > > > private: > > boost::mutex mutex; > > boost::mutex::scoped_lock guard; > > int count; > > }; > > This is not equivalent to the above scenario. You can't have two threads > calling lock() at the same time, because a scoped_lock object (as currently > specified) is not thread safe (whereas a mutex is, by its very nature.) > Ugh, it would seem you are right Peter! Again, I quote the docs: "sharing a lock object between threads results in undefined behavior". Phooey! > > > class counter > > { > > public: > > counter() : count(0) { > > } > > void lock() { > > // nothing, methods act as self monitors > > } > > int increment() { > > boost::mutex::scoped_lock guard(this->mutex); > > return ++count; > > } > > void unlock { > > // nothing, methods act as self monitors > > } > > // ..Nothing to do here.. > > // ~counter() { > > // } > > > > private: > > boost::mutex mutex; > > int count; > > }; > > This is also not quite equivalent to the original. In it, a lock() op1() > op2() unlock() is a transaction; no other thread can inject its own op3 > between op1 and op2. Exactly - this is why I said "likewise" earlier, d-oh! > The closest you can get to the original, while somewhat respecting the > requirement for it to be callable from outside C++, is: > > scoped_lock * lock() > { > return new scoped_lock( mutex ); > } > > void unlock( scoped_lock * lock ) > { > delete lock; > } Although this respects the requirement that the code be callable from outside C++, it completely ignores the requirement that the COM interface (i.e. method prototype) should not change :-( Anyway, the last suggestion (changing the COM interface and returning a pointer to the scoped_lock) is probably the best I can do for now - I have indeed already considered this. The practitioner in me says it should be fine for my purposes. The theorist in me says I should keep moaning and groaning until someone truly feels my pain. soap_box->lock(); I've been making a stink largely because (IMHO) the decision to NOT expose functionality as fundamental as mutex.lock() and mutex.unlock() seems ridiculous! The boost library and accompanying docs should absolutely encourage the use of scoped_locks - I agree 100%. But it certainly shouldn't *disallow* me from using mutexes in the traditional way - to me this is a shortcoming. Even if there is some kind of overly complicated way (perhaps by deriving from mutex and calling some protected lock/unlock methods) I still think lock/unlock functionality should be exposed by mutex objects. Did you ever hear of the expression "you've polished the brass right off of the hinges"? This honestly seems like arrogance on the boost development team's part - why do they know how to use mutexes so much better than the rest of us? What am I, chopped liver over here? It is belittling! I'm not a child, whaaaaa!!!! ;-) There is little sense in going to such extreme lengths to protect developers from themselves - after all they are the ones writing the programs! Believe me, I would love to live to see the day that I simply install the Boost libraries and BINGO by some stroke of genius the program I intended to write is already done. I have a feeling it will be some time before this happens, until then my gun should shoot bullets wherever I point it, and I should be allowed to point it wherever I want (not where the boost developers THINK it should be pointed, but where I KNOW it should be pointed). As they say, "guns don't kill people, people kill people", lol. soap_box->unlock(); Just my 2 cents, C. Michailidis

4 4

Re: You provide gun, I provide foot.
by C. Michailidis 10 Apr '05

10 Apr '05

> Whining won't take you far on this list, sorry. Call it arrogance, call it > indifference, whatever -- don't forget that Boost authors have volunteered > enormous amounts of their own time. Seriously, you have the boost source, if > you don't like the implementation of something in threads go change it and > propose it. Or just use it for yourself. That will get you much further than > soapbox grandstanding any day... > > BTW, I think the question of what to expose was discussed in the library > review, so you might search back thru the mailing lists. Also you should know > that the original threads author has disappeared and the new maintainer is > pretty busy -- so I'd say threads is somewhat undersupported at the moment... > > Jeff Yeah, I've got to agree - you make good points here! However, you have to admit, ranting and raving will (occasionally) make you FEEL better, LOL. In any case, the boost libs still rock! Maybe I'll dig a little deeper and make a proposal; after April 15th of course! Cheers, Dino P.S. Thanks to everyone who put up w/ my moaning and groaning. I just wanted to make sure I wasn't overlooking something dumb, which I will do every now and again ;-)

1 0