- Boost - lists.preview.boost.org

RE: RE: [boost] Does anyone have an is_virtual_base_and_derived ?
by SRobb＠reflectionsinteractive.com 08 Jul '04

08 Jul '04

> > I wrote that very thing a year or so ago for the purpose of > testing if a > > base pointer type can be statically downcast to a derived type. > > My problem exactly ! I should warn you that this isn't quite enough information to test for static downcastability in all cases. Take the following example: struct b1 {}; struct b2 : b1 {}; struct b3 : virtual b2 {}; Here, b1 is not a virtual base of b3, but a downcast from b1* to b3* is still impossible. I don't believe there is any way to test for this case without compiler assistance. Testing for a virtual base happened to be good enough for us though, so we went with it; it may well be enough for your needs too.

1 0

Proposal: Minimalist ScopeGuard
by Jonathan Turkanis 08 Jul '04

08 Jul '04

Hi All, I've uploaded a very simple version of Andrei and Petru's ScopeGuard to the files section: http://groups.yahoo.com/group/boost/files/scope_guard.zip. It's only smart enough to handle cleanup functions or function objects with the signature 'void f()'; more complex cleanup is easy with Bind or Lambda. There are two object generators: - make_guard returns a scope guard which propagates exceptions - safe_guard returns a scope guard which catches and ignores exceptions Similarly, there are two macros - BOOST_SCOPE_GUARD declares an anonymous scope guard which propagates exceptions - BOOST_SAFE_GUARD declares an anonymous scope guard which catches and ignores exceptions Best Regards, Jonathan //------------------Example--------------------// #include <iostream> #include <boost/bind.hpp> #include <boost/lambda/lambda.hpp> #include <boost/lambda/bind.hpp> #include <boost/scope_guard.hpp> void goodbye() { std::cout << "goodbye\n"; } void crash() { throw 0; } struct T { void goodbye() { std::cout << "goodbye\n"; } }; // // Expected output: // hello // goodbye // goodbye // goodbye // goodbye // goodbye // int main() { using namespace boost; T t; // Scope guard which invokes t.goodbye(). scope_guard g1 = make_guard(boost::bind(&T::goodbye, t)); // Scope guard which invokes goodbye(). scope_guard g2 = make_guard(goodbye); // Scope guard which executes std::cout << "goodbye\n". scope_guard g3 = make_guard( std::cout << boost::lambda::constant("goodbye\n") ); // Scope guard which invokes crash() in a try-catch block. scope_guard g4 = safe_guard(crash); // Scope guard which invokes crash(). scope_guard g5 = make_guard(crash); g5.dismiss(); // Scope guard which invokes goodbye(). BOOST_SCOPE_GUARD(goodbye); // Same. (Shows that generated variable names are working.) BOOST_SCOPE_GUARD(goodbye); // Scope guard which invokes crash() in a try-catch block. BOOST_SAFE_GUARD(crash); std::cout << "hello\n"; }

1 0

[multi_index] scope_guard
by Jonathan Turkanis 08 Jul '04

08 Jul '04

Hi Joaquín, I'm looking at your version of scope_guard in the current CVS. I'm intersted to know why you didn't include boostified versions of the macros ON_BLOCK_EXIT from Andrei and Petru's original article. Was it just because you didn't need it or because you found it objectionable for some reason? Also, I read that you were disappointed with its performance, and I see that you only use it for checking invariants, when enabled. Do you plan on keeping it in Boost.MultiIndex? Have you considered submitting it for fast track review? Jonathan

3 6

RE: [boost] Re: VC7.1 Building...
by Brian Carlson 08 Jul '04

08 Jul '04

I just tried the vc71 option. But no jam file for that either. Am I suppose to create my own vc71-tools.jam file (copy or copy&edit)? What changes are needed? Thanks, Brian -----Original Message----- From: boost-bounces(a)lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Russell Hind Sent: Thursday, July 08, 2004 9:56 AM To: boost(a)lists.boost.org Subject: [boost] Re: VC7.1 Building... Have you tried bjam -sTOOLS=vc71 I'm pretty sure that is what I used but I do have a vc7.1-tools.jam file with boost-1.31.0 Russell Brian Carlson wrote: > I don't have a vc7.1-tools.jam file. And I have vc7.0 and vc7.1 > installed on my machine. So this is what I did... > > bjam -sTOOLS=vc7 -a > _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

2 1

RE: RE: [boost] Does anyone have an is_virtual_base_and_derived ?
by SRobb＠reflectionsinteractive.com 08 Jul '04

08 Jul '04

> My problem exactly ! > > So I think this is what I need. Just to prove once again that no good deed > goes unpunished - > > a) at a very minimum I want to add a boost copyright license and for that I > would need your name which wasnn't on your post. Steve Robb is my name. I've updated my profile so that it should hopefully now appear on these mails. > b) any chance of this getting "boostified" with a couple of tests an maybe a > micro-review?. Certainly can. I'm only capable of testing it with a few compilers though: VC++s 6, 7 and 7.1, and GCCs 2.95 and 3.2. > c) I notice that the type_traits already in the library are much - much more > elaborate due to the variations in compilers. Any chance of this getting > subjected to this kind of treatment? Actually, this leads to an issue we've had with compile times. The sheer volume of code included in the Type Traits headers to support all compilers lead me to re-implement a significant proportion of them in a 'minimal' fashion. Our build times almost halved as a result. Obviously our traits code doesn't cover the same body of compilers that Boost supports, but perhaps a rethink of the structure of the Type Traits library may be in order. To take a typical example like <boost/type_traits/is_same.hpp>, which can be implemented in terms of partial specialisation in a few lines on the majority of common compilers, still causes 59 headers (on my current configuration) on VC7.1. From this point of view, I prefer Loki's system of having a 'reference' copy of the traits class which fully-compliant compilers are directed to, with non-compliant compilers having their own implementations in separate files. I'm sure this issue has been raised here already, but I think it's worth reiterating, as it can save many man hours of wasted time.

2 1

VC7.1 Building...
by Brian Carlson 08 Jul '04

08 Jul '04

I don't have a vc7.1-tools.jam file. And I have vc7.0 and vc7.1 installed on my machine. So this is what I did... bjam -sTOOLS=vc7 -a How can I verify that it built with the vc7.1 compiler. Or am I wrong in using vc7 for the tools? Thanks, Brian

3 2

[Thread] [Patch] gcc-3.4.x issues
by Jürgen Hunold 08 Jul '04

08 Jul '04

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi ! The attached patch fixes some gcc-3.4.x errors and warnings: boost/thread/tss.hpp: libs/thread/src/tss.cpp: gcc complains about extra token after #endif. I've added the needed c++ comments. boost/thread/detail/lock.hpp: Typo in member template. Yours, Jürgen - -- * Dipl.-Math. Jürgen Hunold ! Institut für Verkehrswesen, Eisenbahnbau * voice: ++49 511 762-2529 ! und -betrieb, Universität Hannover * fax : ++49 511 762-3001 ! Appelstrasse 9a, D-30167 Hannover * hunold(a)ive.uni-hannover.de ! www.ive.uni-hannover.de -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFA7UYsljbJ/LLrxrYRAnyXAKC3rjawDEOJgRU1xQoHZqnmD7BzqgCgryyO 1Lpe5xjEQE/lhw8txYA+6Ww= =3DQI -----END PGP SIGNATURE-----

3 2

[BGL] [Patch] graph/dijkstra_shortest_paths.hpp
by Jürgen Hunold 08 Jul '04

08 Jul '04

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi ! in revision 1.38 Jeremy cvs log : "removed inf parameter for the no_init version of Dijkstra's" but forgot to change the call of the no_init version at line 211. The following patch corrects this. Yours, Jürgen - -- * Dipl.-Math. Jürgen Hunold ! Institut für Verkehrswesen, Eisenbahnbau * voice: ++49 511 762-2529 ! und -betrieb, Universität Hannover * fax : ++49 511 762-3001 ! Appelstrasse 9a, D-30167 Hannover * hunold(a)ive.uni-hannover.de ! www.ive.uni-hannover.de -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFA5Q4IljbJ/LLrxrYRApJcAKDeWInG0yNhEtT3Nhik0J4KqojT1wCfY5gE 5+1FQmkTgp7Qw8L8yNiqu/U= =L0GY -----END PGP SIGNATURE-----

2 2

[Bind] Increasing the max number of arguments bind supports?
by Doug Gregor 08 Jul '04

08 Jul '04

We just ran into a need for passing 12 arguments to boost::bind(), which only supports up to 9 arguments. Is there any way to (easily?) increase this number? With Function, one can just set BOOST_FUNCTION_MAX_ARGS to change the value; does/could Bind have something similar? Doug

3 4

[filesystem + iterator] directory iterator problem
by Vladimir Prus 08 Jul '04

08 Jul '04

There's a bug report on sourceforge: https://sourceforge.net/tracker/index.php?func=detail&aid=937606&group_id=7… which boils down to the fact that directory_iterator it(...); path p = *it++; does not work correctly. The exact problem is that the above line return a copy of the iterator, and increments 'it', but both iterators have shared_ptr to the same internal structure, so by time user deferences the copy, it gets the next file in the directory. The filesystem lib sources contain the following comment: The *r++ requirement doesn't appear to apply to the new single_pass_traversal category Thus I'm leaving the proxy out pending confirmation from the N1477 authors I'm not sure I understand that. It seems that *r++ should work, since signle pass iterator requires that r++ should work and return object of type X (call it r2), and the reabable iterator requires that *r2 should work. Am I wrong? And BTW, don't the above requirements mean r++ cannot return a proxy object, but only a real copy of the iterator? - Volodya

2 25