July 2004 - Boost - lists.preview.boost.org

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

08 Jul '04

> > >I would start over if I were you. Open a Command Propmpt window. Change > > >directory to you boost_1_31_0 directory. Type the following _exactly_ > > >as > > >shown: > > > > > > bjam -sTOOLS=vc7.1 stage > > > > I did, but I'm using 1.29, not 1.31 That might be the problem....hmm > I'd think bjam changed significantly since 1.29? I don't think the build > instructions noted above are valid for pre 1.3x. Any reason your not using > 1.31? I'm using a third party api, that requires boost. I don't have a direct requirement. I wanted to move to vc7.1, and that's when I started to have link problems, "unresolved external... function0". I hoped that rebuilding 1.29 in vc7.1 would take care of the problem. I'm getting ready to try the api with 1.31. We'll see. Any thoughts would be arreciated. Thanks, Brian

2 1

RE: [boost] FYI: Trolltech's new generic containers
by Max Khesin 08 Jul '04

08 Jul '04

Hi Neal, What do you like about these? -----Original Message----- From: Neal D. Becker [mailto:ndbecker2@verizon.net] Sent: Thursday, July 08, 2004 2:36 PM To: boost(a)lists.boost.org Subject: [boost] FYI: Trolltech's new generic containers This may be of some interest: http://doc.trolltech.com/4.0/containers.html _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail.

1 0

Re: [boost] Re: Pretty Good Initialization Library
by brangdon＠cix.compulink.co.uk 08 Jul '04

08 Jul '04

In-Reply-To: <200407072103.i67L3Jk28273(a)tesh.systems.susq.com> stewart(a)sig.com (Rob Stewart) wrote (abridged): > > v << foo() << bar(); > > I don't like that. It suggests formatted insertion rather than > initialization. It's not intended to be initialisation. It does a push_back(), so you can do it at any time and not just on empty vectors. I guess I'd pick a different name for the library, but as written that includes += so it too is not just for initialisation. As I said, I don't think formatting is an essential characteristic of operator<<(). It happens to be necessary for streams because they are text oriented. The serialisation library uses operator<<() without formatting. > As you point out, conversion is possible, but one can't overload > operator<< to customize the initialization. Why not? vector<Foo> &operator<<( vector<Foo> &v, const Bar &bar ) { return v << bar.toFoo(); // Or whatever conversion you want. } Or whatever the right types are. > Thus, it doesn't fit neatly with IOStreams. It's not polymorphic with them, but I think it fits about as neatly as the serialisation library. -- Dave Harris, Nottingham, UK

2 1

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

08 Jul '04

>You might want to limit posts to plain text, whatever email format your >using defeats the auto-original-indent capabilities for Outlook Express. >Also directly reply to messages that you are reading. Many use the >gmane.org >newsreader interface which maintains message thread integrity. This is set to plain text, I'm using Outlook. Hopefully this works better. > I don't have a vc7.1-tools.jam file. And I have vc7.0 and vc7.1 > I've never heard of this file, and don't think there is one. When you run bjam -sTOOLS=XXX It takes the XXX and appends -tools.jam to find the .jam file for building for the specific compiler. > Your building for vc7.0, I'm not sure what the -a is. -a is rebuild all, even if current. >If you want to build for vc7.1 you should use vc7.1. I did (bjam -sTOOLS=vc7.1 stage) and I get the following error: Vc7.1-tools.jam No such file or directory. >I would start over if I were you. Open a Command Propmpt window. Change >directory to you boost_1_31_0 directory. Type the following _exactly_ as >shown: > > bjam -sTOOLS=vc7.1 stage I did, but I'm using 1.29, not 1.31 That might be the problem....hmm Thanks, Brian

3 2

FYI: Trolltech's new generic containers
by Neal D. Becker 08 Jul '04

08 Jul '04

This may be of some interest: http://doc.trolltech.com/4.0/containers.html

1 0

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