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

Re: [Boost-users] inheriting from boost::thread
by Simmons, Aaron 21 Sep '05

21 Sep '05

I write a lot of cross-platform code that's used from JNI. In JNI, you should tell the JVM about native threads that are running. Because Java threads are named, when you attach a native thread to the JVM you have to specify a name. It occurred to me that I could write a "jnithread" class that inherits from boost::thread. It would take a thread-name argument. Before the threadfunc runs it would attach the new thread to the JVM, and when the threadfunc ends it would detach from the JVM. It's relatively easy to write such a class, and would make life easier for thread creation within JNI. However, I hesitate because of the lack of a virtual destructor... -----Original Message----- From: boost-users-bounces(a)lists.boost.org [mailto:boost-users-bounces@lists.boost.org] On Behalf Of me22 Sent: Wednesday, September 21, 2005 1:27 PM To: boost-users(a)lists.boost.org Subject: Re: [Boost-users] inheriting from boost::thread On 21/09/05, Simmons, Aaron <a-simmons1(a)ti.com> wrote: > > I've been thinking about writing a class that inherits from boost::thread. > However, I noticed that the destructor isn't virtual. Shouldn't it be? > boost::thread is designed neither as a base class nor to be used polymorphically. Why do you want to inherit from a thread? You still couldn't get at the private thread handles and there are no virtual functions to modify behavior. - Scott _______________________________________________ Boost-users mailing list Boost-users(a)lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users

2 1

boost::test 1.33 compile problem on VC7.0+STLport (1.32 fine)
by Steve Streeting 21 Sep '05

21 Sep '05

Hi, I just upgraded to Boost 1.33 and a set of my unit test routines written against boost::test 1.32 have suddenly started reporting compile errors. I can trigger the issue very simply: --- #include <boost/test/included/unit_test_framework.hpp> #include <boost/test/unit_test.hpp> using namespace boost::unit_test; test_suite* init_unit_test_suite( int argc, char* argv[] ) { test_suite* test = BOOST_TEST_SUITE( "tests" ); } --- In Boost 1.32 this works fine, in Boost 1.33 it reports: --- c:\temp\boost_1_33_0\boost\test\impl\framework.ipp(305) : error C2440: 'initializing' : cannot convert from 'long' to 'boost::unit_test::for _each::static_any_t' Reason: cannot convert from 'long' to 'const boost::unit_test::for_each::static_any_base' No constructor could take the source type, or constructor overload resolution was ambiguous c:\temp\boost_1_33_0\boost\test\impl\framework.ipp(305) : error C2143: syntax error : missing ')' before '=' c:\temp\boost_1_33_0\boost\test\impl\framework.ipp(305) : error C2143: syntax error : missing ';' before '=' c:\temp\boost_1_33_0\boost\test\impl\framework.ipp(305) : error C2059: syntax error : ')' c:\temp\boost_1_33_0\boost\test\impl\framework.ipp(305) : error C2143: syntax error : missing ';' before '{' c:\temp\boost_1_33_0\boost\test\impl\framework.ipp(305) : error C2181: illegal else without matching if c:\temp\boost_1_33_0\boost\test\impl\framework.ipp(305) : error C2440: 'initializing' : cannot convert from 'long' to 'boost::unit_test::for_each::static_any_t' Reason: cannot convert from 'long' to 'const boost::unit_test::for_each::static_any_base' No constructor could take the source type, or constructor overload resolution was ambiguous --- .. and so on (hits upper error limit). I've just reverted back to 1.32 for now, but can you tell me why this happens? Many thanks Steveboost::test 1.33 compile problem on VC7.0+STLport

2 1

Re: [Boost-users] inheriting from boost::thread
by Sohail Somani 21 Sep '05

21 Sep '05

-----Original Message----- From: boost-users-bounces(a)lists.boost.org [mailto:boost-users-bounces@lists.boost.org] On Behalf Of Simmons, Aaron Sent: Wednesday, September 21, 2005 10:29 AM To: boost-users(a)lists.boost.org Subject: [Boost-users] inheriting from boost::thread I've been thinking about writing a class that inherits from boost::thread. However, I noticed that the destructor isn't virtual. Shouldn't it be? Your problem might be better solved using containment

1 0

inheriting from boost::thread
by Simmons, Aaron 21 Sep '05

21 Sep '05

I've been thinking about writing a class that inherits from boost::thread. However, I noticed that the destructor isn't virtual. Shouldn't it be? Thanks, aaron

2 1

Re: [Boost-users] static maps (was trouble with boost::assign)
by Gottlob Frege 21 Sep '05

21 Sep '05

On 9/20/05, boost-users-request(a)lists.boost.org < boost-users-request(a)lists.boost.org> wrote: > > Message: 2 > Date: Mon, 19 Sep 2005 12:35:08 -0500 > From: "Lee Crabtree" <lcrabtree(a)goisi.com> > Subject: [Boost-users] trouble with boost::assign > To: boost-users(a)lists.boost.org > Message-ID: <dgmsos$amg$1(a)sea.gmane.org> > > Hi, I'm trying initialize a static map with map_list_of. Something along > the > lines of: > > map<int,int> blarg = map_list_of(1, 2); > > However, when I go to compile, I receive the following error: ... Lee Crabtree > > > Can't help you with the error, unfortunately, but just wondering - does this map *remain* static after initialization? ie Do you do any inserts or deletes after init? I wrote a static_map<K, T> that is constructed from a static array, which I use for those cases where the map doesn't change, and I was just wondering how useful people thought it might be - ie how often do you have maps that never change after initialization from static data?

2 1

Re: [Boost-users] algorithms and member functions
by Foster Gareth 21 Sep '05

21 Sep '05

> " > class A { > void wee(); > } > > container<A> as; > for_each(in as, a::wee()); > " > So as as not to miss the point, I think I'd better expand the pseudo code example just a tad ... " class A { int wee() { return m_wee } // returns bit flag style int int m_wee; }; container<A> as; find_if ( in as, // somehow need to say here "current->wee() & SOME_FLAG" ); " Hope that is a little more clear. Thanks again, Gaz

1 0

algorithms and member functions
by Foster Gareth 21 Sep '05

21 Sep '05

Hello all, Take for example, a situation where, in psuedo code of course, I want to do this sort of thing ... " class A { void wee(); } container<A> as; for_each(in as, a::wee()); " I did a little google work on this and found this amazing flame war between a Java user and a Boost/C++ user: [ http://episteme.arstechnica.com/groupee/forums/a/tpc/f/6330927813/m/26500301 5731 ] It seems from this that we, as c++ users, have as options: * writing a new functor to call methods * using std::mem_fn * using the boost enhancements to the above I get the impression that boost bind and lambda are relevent here, although I've only glanced at examples. What interests me is the anonymous methods / class style syntax that Java offers. I've played with it myself, and it seems nice, and one of the proponents in the afore mentioned flame war advocates it. What is the thinking behind not introducing such syntax into C++? I am sort of working from the assumption that the template solutions (as opposed to language modification solutions) in boost at the moment, will be moved into std:: and offered as a solution rather than an update to the language. It may be that I have the wrong end of the stick there, and that the boost solutions are a temporary solution. It may also be there are good reasons to prefer the template style solution. It may also be I am talking tripe :) Anyway, I hope this doesn't make a mountain out of a mole hill. I'm just wondering about the decisions that have been / are likely to be made, in this area. I don't claim to hold any opionion on the matter, other than "I think it is an interesting matter" :) Thanks all, Gaz ********************************************** * http://www.mozilla.org/products/firefox/ * **********************************************

1 0

BGL - edge descriptor and map
by Giulio Veronesi 21 Sep '05

21 Sep '05

I'd like to specify better my problem. I'd like to use an edge_descriptor (graph_traits<G>::edge_descriptor) as key in a map. The graph type is something like this: typedef adjacency_list<vecS, vecS, bidirectionalS, no_property, MyStuff> G; I think that I've to overload the < operator for graph_traits<G>::edge_descriptor. Is this correct? If so, given two edge_descriptors I need to access the source and the target of the edge in such a way to define a sort ordering. Thanks, Giulio

2 1

enable_if missing from status summary
by Steven Solie 21 Sep '05

21 Sep '05

I'm finding the utility/enable_if tests are missing from the status summary for my AmigaOS port. I think the process_jam_log tool is unable to handle it for some reason because the xml output files are incorrect. I see from a Google search this has been discussed before. Has there been any resolution to this problem? --Steven

3 2

[BGL] detecting cycles path in a graph
by Giulio Veronesi 21 Sep '05

21 Sep '05

Hi, I'd like to obtain the path of a cycle in a graph. The file dependency example in the user guide only allow to discover cycles and not the path that forms the cycle. Please, could you help me to address this problem? Thanks a lot, Giulio

1 0