- Boost - lists.preview.boost.org

another idea - two sets of regression tests ?
by Bronek Kozicki 19 Feb '04

19 Feb '04

This message is actually result of subthread in "1.31 regressions" where I started discussion about dropping support for older compilers. My idea was to split boost to two branches : "current" and "old compilers" (based on 1.31 release). New features could be developed in "current", while "old compilers" should be still supported, and some new features (and most importantly - fixes) could be backported to this branch. Here is part of discussion: >>>>>>>>>> (my voice) > Thus hopefully they will not mind if we just ask them to use > releases in 1.31.x branch. But it also means that we will need to > support two branches for (at least) next two years. This might be > cumbersome, but on the other hand it should simplify development in > "current" branch. (David Abrahams) Yep. It'll be cumbersome, that's for sure. Would it be any better than bringing in new "non-vc6" features with #ifdefs and new non-vc6 libraries without apology? >>>>>>>>>> (my voice) > However, I do suggest that *if there is new branch* of boost, > many regression tests targeted at old (nonconforming) compilers should > be pulled out from this branch. Effectively, to make new features > available for old compilers, these features have to be back-ported to > the "old branch". > (Pavel Vozenilek) I am afraid it woudn't work very well: - There are many small fixed and updates and these could be easily be missed. - The effort to keep multiple branches of Boost would take more than maintaining current state. >>>>>>>>>> (my voice) > I think nobody is going to prevent you from supporting any compiler you > want :> However, I do suggest that *if there is new branch* of boost, > many regression tests targeted at old (nonconforming) compilers should > be pulled out from this branch. (Peter Dimov) That's what I disagree with. I want these compilers to participate in the regression tests, so that I can see when I inadvertently introduce a regression. >>>>>>>>>> I can see there are strong points against this idea. However, I still feel there is urgent need to simplify regression tests in order to make future releases simpler. I'd also like to give choice to developers if they want to support old compilers (like MSVC6, GCC 2.95 or BCC32) or not. Here's another idea: two sets of regresion tests. Library maintained by developer willing to support old compilers will be tested against both, while other libraries will be tested against only one. Users of old compilers will have a list of libraries which have been tested against both sets (including results) - if they don't see on this list library they need, they can still use older release of boost. B.

2 2

boost thread static library
by Arkadiy Vertleyb 19 Feb '04

19 Feb '04

Hi all, I just built boost 1.31.0 (windows, with mingw toolset), and I can't find the static thread library. Did I do something wrong or is it no longer supported (it was there at least in 1.29)? Thanks, Arkadiy _________________________________________________________________ Find and compare great deals on Broadband access at the MSN High-Speed Marketplace. http://click.atdmt.com/AVE/go/onm00200360ave/direct/01/

6 14

boost::filesystem::exists bug and patch
by Jonathan Ultis 19 Feb '04

19 Feb '04

::exists is implemented using ::stat. The ::stat routine returns an error on file sizes larger than 2 gigs in libc-2.3.2, and several others. So, very large files never exists (). Using ::access seems to fix the problem. =================================================================== RCS file: /cvsroot/boost/boost/libs/filesystem/src/operations_posix_windows.cpp,v retrieving revision 1.29 diff -c -r1.29 operations_posix_windows.cpp *** operations_posix_windows.cpp 6 Feb 2004 01:27:06 -0000 1.29 --- operations_posix_windows.cpp 9 Feb 2004 06:19:28 -0000 *************** *** 302,309 **** BOOST_FILESYSTEM_DECL bool exists( const path & ph ) { # ifdef BOOST_POSIX ! struct stat path_stat; ! return ::stat( ph.string().c_str(), &path_stat ) == 0; # else return ::GetFileAttributesA( ph.string().c_str() ) != 0xFFFFFFFF; # endif --- 302,308 ---- BOOST_FILESYSTEM_DECL bool exists( const path & ph ) { # ifdef BOOST_POSIX ! return ::access (ph.string ().c_str (), F_OK) == 0; # else return ::GetFileAttributesA( ph.string().c_str() ) != 0xFFFFFFFF; # endif

3 6

Leaner type traits tests
by John Maddock 19 Feb '04

19 Feb '04

Those asking for leaner type traits tests will be pleased to know that they have been reworked so that they no longer depend on Boost.Test (unless you want it to by using --type-traits-unit-test as a command line arg to bjam). Unfortunately, while this does cut down on build dependencies, it doesn't reduce overall build times that much (which are mainly dominated by the time taken to instantiate the various templates). John.

1 0

Re: Three questions about the new license
by David Abrahams 19 Feb '04

19 Feb '04

"Diane Cabell" <dcabell(a)law.harvard.edu> writes: >> >> Thanks, that seems less prone to misinterpretation to me also. Would >> >> // Copyright David Abrahams 2004. Distributed under the Boost >> // Software License, Version 1.0. (See accompanying file >> // LICENSE_1_0.txt or copy at http://www.boost.org/LICENSE_1_0.txt) >> >> do just as well? It's just just a little less wordy -- "made >> available subject ot the terms of" sticks in my craw a bit. > > Yes. > >> > (....) >> >> > David Abrahams wrote: >> >> > >> >>(....) >> >> >> >> Ugh I don't think we ever considered that "display" would be >> >> interpreted other than to mean "display publicly". Does that mean >> >> that in the license: >> >> >> >> Permission is hereby granted, free of charge, to any person or >> >> organization obtaining a copy of the software and accompanying >> >> documentation covered by this license (the "Software") to use, >> >> reproduce, display, distribute, execute, and transmit the >> >> Software, and to prepare derivative works of the Software, and to >> >> permit third-parties to whom the Software is furnished to do so, >> >> all subject to the following: >> >> >> >> "display" ought to be "display publicly"? >> > >> > Yes. But again, private display doesn't require permission, so a >> > court would likely interpret this to language to mean "public >> > display." If it went to court, you'd get to testify as to that >> > intention. >> >> So IIUC, changing the license wording isn't critical. We should >> probably wait 'till a critical issue comes up before making any >> non-critical changes. > > Yep. Thanks again for all your help, Diane! -- Dave Abrahams Boost Consulting www.boost-consulting.com

2 1

RE: [boost] Re: Re:(For me a) showstopper [was: boost threadstaticlibrary]
by Randy Bowen 19 Feb '04

19 Feb '04

> -----Original Message----- > From: Stefan Slapeta [mailto:stefan@slapeta.com] > Sent: Wednesday, February 18, 2004 2:07 PM > To: 'Boost mailing list' > Subject: RE: [boost] Re: Re:(For me a) showstopper [was: > boost threadstaticlibrary] > > > I would be interested to learn how you achived this without > modifying boost. > In a MSVC++ 7.1 environment, we simply created a static library project and copied the Boost Thread cpp files into it. My only caveat would be that this was done with version 1.29.0 -- I don't know if there have been any subsequent changes that would cause complications in such an approach.

2 1

RE: [boost] Re: Re:(For me a) showstopper [was: boost thread static library]
by Randy Bowen 18 Feb '04

18 Feb '04

Edward Diener wrote: > > His problem is that if he builds a statically linked library > and uses the Boost threads library, he will be using a shared > library and all the shared RTL libraries also, since that is > what the shared Boost threads library needs to work. > > I also have found that mixing static and shared libraries in > any situation quite often leads to problems. In this latter > respect, one should use all shared libraries or all static > libraries, instead of mixing in both. > The thread_specific_ptr class is the only piece that really requires a shared library. Running in a Windows environment, we have repackaged the remainder of the library as a static library for some time now, and experience no problems. Randy Bowen Stamps.com

2 1

RE: [boost] FC++: lambda
by Powell, Gary 18 Feb '04

18 Feb '04

While I haven't had a chance to review the latest version of FC++ that's being offered for boost, I have reviewed most of the previous versions over the last few years. And I think quite highly of this library. And I believe that until there is core language support for lambda's a library solution will always be a trade off. Hence I believe that there is room in boost for both BLL and BFC++. Yours, -Gary Powell- powellg(a)amazon.com

1 0

RE: [boost] Re: Re: Future of threads (III)
by Hurd, Matthew 18 Feb '04

18 Feb '04

> On Behalf Of scott > Subject: RE: [boost] Re: Re: Future of threads (III) > > On Behalf Of Hurd, Matthew > > > AO's should either have a queue for work or hook into a > > queue. They are > > a bit like a worker pool with one worker ;-) > > yep. > > > > > Another idiom is a future value, where you ask for a value and don't > > block until you "read" the value. ACE also has an implementation of > > this. You can think of it as a bit like overlapped I/O. > > Yes. This was also in the ActiveObject pattern. It was on the "client- > side", i.e. available to the thread that submits Method Requests as a > means to acquire the results. > > While I understand its place in the ActiveObject pattern I would hope > that if a boost::active_object came into existence, there would be a > single (i.e. not _simple_) mechanism by which data passed from one thread > to the other, with an associated notification. In a behavioural sense, > the future mechanism wouldnt be appropriate for this. I'd agree here in principle to keep this asynchronous and have the equivalent of message passing with a function call with a void return type. The future_value is an elegant idiom for providing a C++ RPC / LPC equivalent. The whole store and forward expectation issue would suit this style as it just looks like a normal function or method call. > This way of thinking does require that all threads are active_objects > which may be too aggressive <shrug>. A small sample of empirical data > says its fine. It works a treat for a lot of things. Especially suited to workflows of things that you want to dynamically configure. Threading is a big overhead though. Consider these numbers: Safe increment (Athlon 2800+) (P4 3.2GHz) Interlocked primitive 11 ns 53 ns Critical section 138 ns 411 ns A bit slower than a single machine instruction. If I make a size_t volatile and time 100 increments in a row I get 3.8ns per increment on the P4 above, more then ten times slower than an interlocked increment. And it doesn't end there, the cache effects also add considerably. So in my mind, the active object pattern is good for configurability and where the work of the object is chunky enough to where the cost of the context switches and cache effects. In terms of work pools, this context overhead also led to the idea of a leader-follower pattern where you try and use the same worker if possible. This is also why we have seen the argument for a shared_ptr with multi-thread safety as a policy. On a Pentium 4 you are typically paying around ten times the cost of a normal increment for the privilege of thread safety. > > I also advocate a different architectural neutral style where you can > > have things at look like function calls that can be: > > 1. a function call > > 2. a call to queue work pool or active object > > 3. an IPC mechanism for same machine transfer, e.g. > > shared memory > > 4. a network mechanism, TCP, UDP, TIB or something, for > > > > Understand the reasons you ask for 1...4 but would like to add some > other thoughts to see what you think. > > An ActiveObject servant contains code. That code is implementation > of behaviour and its what (I believe) we tacitly want when we all > say that "thread-inherited-classes" or "active objects" are a nice > manner in which to deal with threads. > (note: more accurately the pattern says that thread==scheduler and > a scheduler executes servant code. but i think we can skip this > detail) > > If the code is in the servant, what do 1 and 2 mean? My best matching > of your thinking with the servant-based thinking would be that somehow > the "client" can submit something into the "worker pool" that _identifies_ > a function that is in the servant. It would be nice if this "work > submission" could carry some arguments for presentation to the servant. I think I understand what you're saying, but I'm not sure. Are you thinking about how the marshalling is done? > A detail that I am labouring is the separation of "calling" (would > much rather that this was "sending") and execution. Our active object > has no synchronous i/f with methods for us to call; it is simply a > "work pool" that we add to. As soon as we make a sync i/f available > then we go down that road that leads to servant code in the client. > > I suggest that notions of "function call" should be exorcised from > discussions that are targeting active objects. That type of thinking > is perfectly valid in some other thread (oops) but can scuttle work > targeting active objects; the behaviour (i.e. the code) is inherently > in the object. Not sure I agree. Think of it the small talk way. A message is a method call. You could have your active object providing a function call that puts a message on to its internal queue and returns. This way you could perhaps specialise by policy whether or not it had its own thread of control and make your architecture a lot more flexible similar to the relationship of 1. and 2. above. > a client can only submit "worker orders" or "Method Requests" or > jobs or messages or signals. > > I hope there is enough there to make a case :-) You certainly have a case. The nirvana I'm looking for is a policy approach to reconfiguring architecture so I can make late decisions about single, multi-thread, multi-process, distributed design. I think your active object can gel with this as I think you can consider parallels to the numbering above: 1. method call 2. method call that generates message to active object thread of control and returns 3. method call -> lightweight message on the same box or LRPC 4. method call -> external system message (tcp, udp, tib, etc) or RPC > > > If it can be enabled by a policy driven approach then you can > > change the > > architecture of your application by simply changing policies. > > > > I think David Abraham's named parameters could help greatly with this > > approach, along with the serialization lib for marshalling support. > > This should provide a solid basis for this. I've also thought that > > perhaps boost::signals might be the correct approach to take for this > > but I'm unsure. > > > > To support this approach you also need mutex aspects that are also > > policy driven. I am preparing to submit such locking that > > builds on the > > existing mutexes and locks. > > <phew> That is quite a scope. But yes, I can see that ultimately > it should cover all these dimensions. Maybe a phasing? Yep, I think the locking and mutex stuff needs to be cleaned up or wrapped to suit a policy approach. Need atomic op support too. Next step is a thread safe queue. Perhaps two, one with priority and a normal one. I've got these I can submit but they're defective in terms of exception safety. Next step is a way having a policy based interface approach to make calling a function result in the calling of a function or marshalling the parameters and calling something else... This is the bit where I'm not sure how best to approach it. Then it is a latter of adding transports to enrich the approach. > Cheers, > Scott Good thinking there Scott. Regards, Matt Hurd _______________________ Susquehanna Pacific P/L hurdm(a)sig.com +61.2.8226.5029 _______________________ IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.

4 4

[bind] bug when used together with function.hpp on BCB
by Pavel Vozenilek 18 Feb '04

18 Feb '04

BCB 6.4, Boost 1.31 (1.30.2 fails too). Following snippet fails to compile: ---------------------------------------- #include <boost/function.hpp> // remove and it will compile OK #define BOOST_MEM_FN_ENABLE_FASTCALL // or remove this and it will be OK #include <boost/bind.hpp> // or move <function.hpp> after <bind.hpp> and it will compile OK int main() { return 0; } ---------------------------------------- with error: [C++ Error] bind_mf_cc.hpp(20): E2316 'mf0_fastcall' is not a member of '_mfi' Full parser context Unit1.cpp(6): #include C:\boost\boost_1_31_0\boost/bind.hpp bind.hpp(44): namespace boost bind.hpp(1544): #include C:\boost\boost_1_31_0\boost/bind/bind_mf_cc.hpp [C++ Error] bind_mf_cc.hpp(20): E2040 Declaration terminated incorrectly Full parser context Unit1.cpp(6): #include C:\boost\boost_1_31_0\boost/bind.hpp bind.hpp(44): namespace boost bind.hpp(1544): #include C:\boost\boost_1_31_0\boost/bind/bind_mf_cc.hpp [C++ Error] bind.hpp(1577): E2190 Unexpected } Full parser context Unit1.cpp(6): #include C:\boost\boost_1_31_0\boost/bind.hpp When the #include <boost/function.hpp> is removed it compiles cleanly. The code compiles OK on Intel C++ so it seems to be caused by some strange interaction with Boost.Function. /Pavel

3 4