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

Re: [boost] Re: static sized strings
by Reece Dunn 10 Sep '04

10 Sep '04

Rob Stewart wrote: >From: "Reece Dunn" <msclrhd(a)hotmail.com> > > [1] How do I pass the buffer and capacity to the implementation while > > allowing both fixed_string_base and fixed_string access to the >basic_string > > interface? I have chosen to route the data through one of the >basic_string > > constructors, requiring a const_cast. This is the best approach AFAICS. > >I haven't looked at your recent implementation, and I don't >presently have the time, so I really don't know what you're >talking about. If you can explain the dependencies to which you >refer, I'd appreciate it. I think it has bearing on the swap() >discussion. I have a class called detail::fixed_string_impl that has three data members: size, capacity and a pointer to the data buffer (len, cap and str respectively). Doing this allows the virtual functions to be removed and the implementation moved out of fixed_string. The fixed_string class can then pass its buffer and the capacity template parameter to the implementation via a constructor. The problem is that fixed_string is derived from fixed_string_base, which itself is derived from detail::basic_string_impl. This is needed to allow both fixed_string and fixed_string_base to have access to the full basic_string interface (like was done in the old implementation). The solution I have taken is to use the basic_string_impl( const CharT * s, size_type l ) constructor and use this to pass the buffer (s) and capacity (l) to the string. This is not ideal since it requires a const_cast to extract the buffer. This required modifying the constructor implementation in basic_string_impl to forward the parameters to Base and not implement them using append. The old implementation had the same problem with swap as the current one, since the string would get clipped when it is copied. For now, I will leave the implementation of swap as is (i.e. clipping and not signalling an exception), but add a note on this issue in the docs so that users are aware of it. Another problem I can forsee is using a custom char_traits or format_policy class, e.g. boost::fixed_string< 20, char, std::char_traits< char > > s1; strcpy( s1, "Hello" ); // ok boost::fixed_string< 20, char, win_char_traits< char > > s2; strcpy( s2, "There" ); // error This is the problem shared with basic_string when implementing functions using std::string. I have also fixed the problems relating to using the strxxx functions with Borland: the compiler may set them as instrinsic and add a macros defining strxxx as __strxxx__. To get around this, I now detect if they are macros and the Borland compiler is being used, then create an inlined function to the __strxxx__ version. Regards, Reece _________________________________________________________________ Express yourself with cool new emoticons http://www.msn.co.uk/specials/myemo

2 1

RE: [boost] [Boost.Test] New testing procedure?
by Rozental, Gennadiy 27 Aug '04

27 Aug '04

> According to http://tinyurl.com/3f32c tests have been failing > (IIUC for several days if not longer) because of > protected/private access violations in the test library. See > the end of http://tinyurl.com/35ole for details. IMO this > situation is unacceptable, and I'm looking for practical > solutions. Problems with the Boost.Test affect our ability > to get meaningful feedback on the state of other libraries. > > If Gennadiy can't test on more compilers before checking in, > and respond faster to problems introduced in its source, and > if library authors genuinely find Boost.Test useful, maybe we > need to move to a different model wherein the test library's > own tests are run on a CVS branch of the code (?) so that > Gennadiy can see and deal with his problems before they are > merged into the main trunk and break everything else? I do test on as much compilers I have accessible. In this particular case It was working on all compilers but Borland. I posted request for workaround while ago. Still no response. I had to test other configuration and I committed it. Actually I was surprised that so many compilers had an issue with completely innocent using declaration. Anyway I think it should be fixed as of last night. I found some hack that should work on complaining compilers. I will see the results of regression test today. As for creating separate brunch for Boost.Test development, I do not really mind. But I believe it will create an extra headache for regression testers (and me). Essentially we will need to have two copies of development tree. And run Boost.Test unit test in a separate tree. I will need to keep moving files back and forth 2 branches. Also I wonder how it will interact with release procedure. You may noticed that I am trying to introduce modification in Boost.Test in "packages", meaning I do not d code modifications all the time. I am not sure that several days of "no regression test on some compilers", worth all that trouble. Especially since all the developers could always rollback Boost.Test modification locally for development testing. Regards, Gennadiy.

4 10

boost::filesystem with network paths on windows
by Arne.Adams＠t-online.de 25 Aug '04

25 Aug '04

Hi, I am trying to use boost filesystem to copy files from a local directory to a directory on a network server (the latter having a path like \\databaseserver\c$\importfiles\myTabledump.txt <file:///\\databaseserver\c$\importfiles\myTabledump.txt> ) Unfortunately the leading double backslashs (\\) get converted in the constructor of filesystem::path to double slashs - yielding a different meaning. Is there a way to copy files on windows to network servers like this? Regards, Arne Adams Nerotal 23 65193 Wiesbaden Tel.: (+49) 611 3413745 Mobil: 0172 6147473 Mail: inbox(a)arneadams.com

3 2

mingw-stlport toolset
by Janusz Piwowarski 13 Aug '04

13 Aug '04

Hello, I created these toolset trying to run program_options library (mingw actually doesn't support wide char streams). Maybe it could be useful for someone else. Regards, Janusz

2 2

Re: Boost Mathematicians
by Michael Stevens 05 Aug '04

05 Aug '04

Hi Dave, hi all, I read with interest you plans for reviving MTL. It is certainly a shame that development of MTL was been stagnant for so long. It certainly had many interesting design features and I used it for all my work for many years. That said I switched to using and developing uBLAS long ago and it has an excellent design. On Saturday 05 June 2004 13:53, David Abrahams wrote: > "Neal D. Becker" <ndbecker2(a)verizon.net> writes: > > David Abrahams wrote: > >> Tom Brinkman <reportbase(a)yahoo.com> writes: > >>> In short, lets tell the world that this is the > >>> premiere place for advanced mathmatical library > >>> development, as I believe that it could be. > >>> > >>> Comments? > >> > >> 1. I think oonumerics.org has the jump on us here, though the site > >> seems to be douwn at this moment. > >> > >> 2. I will be starting work on a rewrite of MTL (the Matrix > >> Template Library) for linear algebra soon. > > > > What do you plan for MTL? How is it different than ublas? > > MTL is aimed at linear algebra, whereas IIUC ublas is not. Well the L and A in uBLAS certainly stand for Linear Algebra! Of course the B stands for Basic and uBLAS's primary aim is to provide the standard set of BLAS functions in a modern C++ environment. Of course as it stands the complete uBLAS library is more then just the BLAS functions and includes some common Linear Algebra algorithms and many useful types. That said I think it is important to separate BLAS functions from domain specific linear algebra algorithm development. This is something that proved itself since the seventies. > There's a lot more to what's in the current plan than I can lay out > here, but the focus will be on support for different kinds of matrices > with combinations of these aspects > > o Shape > o Orientation > o Symmetry > o Sparsity > o Blocking > o Upper / Lower storage > o Unit diagonal Other then the many forms of blocking (other then banded) uBLAS supports all these in its design. This really is its strength! To a large extent they can even be combine these properties where it makes mathematical sense. For example you can wrap up one of a number of sparse matrix types in a symmetric adaptor. > > and operations like: > > o scalar-vector (vector-scalar) multiplication > o vector addition (and subtraction) > o apply linear operator (left) > o norm > o inner product > o triangular solve Other then 'apply linear operator' these are all in uBLAS! > with expression templates, and of course, zero abstraction penalty ;-) Of course uBLAS does this all with ET, but the abstraction penalty may not be zero :-) Other then the lack of ET in the current MTL the big difference between the two libraries is the definition of iterators. Neither design seems to be perfect with regard to efficiency. Since uBLAS is already in Boost and has a well established and clean user syntax it would seem strange to ignore it. For the perspective of building further Linear Algebra algorithms it would not be too hard to use the syntax sufficiently portably so that a future MTL with expression templates could not be used interchangeably. Michael -- ___________________________________ Michael Stevens Systems Engineering Navigation Systems, Estimation and Bayesian Filtering http://bayesclasses.sf.net ___________________________________

12 18

[Boost.Thread] mutex Win32 implementation changes
by Michael Glassford 25 Jul '04

25 Jul '04

I've just checked in changes to Win32 implementations of the mutex and recursive_mutex classes. They now use a Win32 critical section instead of a mutex whenever possible for the normal and try_ variations, though not for the timed_ variations. These are changes that were started on the mutex classes quite some time back on the thread_dev branch; I've finished the changes and applied them to the recursive_mutex classes as well. In addition, the thread_dev branch has code that allows a mutex to be named, which allows it to be shared between two or more processes. This change was begun by Bill Kempf, but is only implemented for Win32. Any suggestions about the best way to add this feature to the pthreads and MPTasks implementations? Mike

4 35

boost/test/detail/algorithm.hpp: request for promotion and/or fast review
by Gennadiy Rozental 24 Jul '04

24 Jul '04

Hi, I added several algorithms that extent STL algorithms set. I use them in my Boost.Test development. But since they seems to be generic and IMO should be present in STL I propose to push them in boost/algorithm.hpp (or under boost/algorithm). I remember there was a discussion already about these algorithms. Here is the list (I hope name and spec is self -explanatory): template <class InputIter1, class InputIter2> inline std::pair<InputIter1, InputIter2> mismatch( InputIter1 first1, InputIter1 last1, InputIter2 first2, InputIter2 last2 ); template <class InputIter1, class InputIter2, class Predicate> inline std::pair<InputIter1, InputIter2> mismatch( InputIter1 first1, InputIter1 last1, InputIter2 first2, InputIter2 last2, Predicate pred ); template<class ForwardIterator1, class ForwardIterator2> inline ForwardIterator1 find_first_not_of( ForwardIterator1 first1, ForwardIterator1 last1, ForwardIterator2 first2, ForwardIterator2 last2 ); template<class ForwardIterator1, class ForwardIterator2, class Predicate> inline ForwardIterator1 find_first_not_of( ForwardIterator1 first1, ForwardIterator1 last1, ForwardIterator2 first2, ForwardIterator2 last2, Predicate pred ); template<class BidirectionalIterator1, class ForwardIterator2> inline BidirectionalIterator1 find_last_of( BidirectionalIterator1 first1, BidirectionalIterator1 last1, ForwardIterator2 first2, ForwardIterator2 last2 ) template<class BidirectionalIterator1, class ForwardIterator2, class Predicate> inline BidirectionalIterator1 find_last_of( BidirectionalIterator1 first1, BidirectionalIterator1 last1, ForwardIterator2 first2, ForwardIterator2 last2, Predicate pred ); template<class BidirectionalIterator1, class ForwardIterator2> inline BidirectionalIterator1 find_last_not_of( BidirectionalIterator1 first1, BidirectionalIterator1 last1, ForwardIterator2 first2, ForwardIterator2 last2 ); template<class BidirectionalIterator1, class ForwardIterator2, class Predicate> inline BidirectionalIterator1 find_last_not_of( BidirectionalIterator1 first1, BidirectionalIterator1 last1, ForwardIterator2 first2, ForwardIterator2 last2, Predicate pred ); Implementation together with doxigen docs is here: http://tinyurl.com/35pfj Test is here: http://tinyurl.com/yvlgu If we don't find this header eligible for review I would like to ask then for permision to at least put this algorithm in boost namespace (currently boost::unit_test), for it inconvenience for me to keep it in deep namespace. Gennadiy.

7 13

Boost.Threads: Do we need all those mutexes?
by Batov, Vladimir 20 Jul '04

20 Jul '04

Do we need all three separate concepts -- mutex, try_mutex and timed_mutex? I'd expect the mutex concept to remain unchanged and "try" and "timed" refinements to be related solely to the ways I try locking that only mutex. That is, I always have one mutex and under different circumstances lock it unconditionally (scoped_lock) or try locking it and check if that attempt succeeds (scoped_try_lock) or try locking within a certain time period (scoped_timed_lock).

11 62

pdf files in libs/iterator/doc
by Janusz Piwowarski 16 Jul '04

16 Jul '04

Hello, These files are not marked as binary: M libs/iterator/doc/iterator_concepts.pdf M libs/iterator/doc/iterator_traits.pdf Regards, Janusz

2 1

RE: Boost.Threads: Do we need all those mutexes?
by Batov, Vladimir 16 Jul '04

16 Jul '04

Guys, Could we please resist complicating interfaces when we do not have to? I personally consider an additional blocking parameter for something like try_lock excessive because it distorts try_lock into becoming scoped_lock. Let's keep different concepts different. Blocking in try_lock is an oxymoron -- try_lock cannot block because it is "try". The basic usages (covering about 80%) are: scoped_lock l(m); // Block until it locks. scoped_try_lock l(m); // Try (!) to lock. I'll check the result. scoped_timed_lock l(m, time); // Block until it locks or time runs out. I'll check the result. Simple and clean. The only functionality that I can see beyond that is when I have to only declare a lock but apply it later. Like: Void Foo() { scoped_lock l(m, do_not_lock); if (something) { l.lock(); // Can't declare here. ... } } For that purpose we'll need something like scoped_lock(mutex&, nolock_t); That's it. Isn't it? Alternatively we might consider making timed_lock our basic lock as scoped_lock and try_lock are merely border-cases (time=infinite and time=0 respectively). Then, scoped_lock and try_lock would be real refinements (convenience interfaces) of that general concept. V. Christopher Currie wrote: > Michael Glassford wrote: > > > To address these problems, I would like to redefine the lock concept > > constructors as follows (changes indicated with "^"): > > > > Definitions > > ----------- > > L: lock type > > l: lock variable (type L) > > m: mutex variable (appropriate Mutex type) > > s: initial lock state (enum type {NO_LOCK=0, LOCK=1}) > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > b: block? (enum type blocking_state {NON_BLOCKING=0, BLOCKING=1}) > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > > > Lock Concept > > ------------ > > L l(m,s) //Blocking lock if s > > L l(m) //Blocking lock > > > > > > TryLock Concept > > --------------- > > L l(m,s,b) //Lock if s; blocking if b > > ^ ^^^^^^^^^^^^^ > > L l(m,b) //Lock; blocking if b > > ^ ^^^^^^^^^^^^^ > > > > TimedLock Concept > > ----------------- > > L l(m,s,b) //Lock if s; blocking if b > > ^ ^^^^^^^^^^^^^ > > L l(m,t) //Blocking lock, failing if not obtained by time t > > > > I like this proposal, if for no other reason than the move to enums > makes the arguments clearer. A couple of points: Yes, I like LOCK and NO_LOCK better than true and false for the same reason. > TryLock: What would be the semantics of l(m, NO_LOCK, b)? In other > words, if you're not going to lock on construction, why specify a > blocking policy? The only reason is so that if you write l(m, LOCK, ...) you could also specify the blocking parameter. An expansion of Vladimir Batov's of using structs rather than enums could help here: struct nolock_t {}; nolock_t nolock; struct lock_t {}; lock_t lock; class TryLock { TryLock(TryMutex m, no_lock_t s) {...} TryLock(TryMutex m, lock_t s, blocking_t b) {...} } > L l(m, b) and L l(m, s) seem to cover the two > scenarios: either I don't want to lock, or I do and I need to specify > the blocking policy. > > TimedLock: I'm not sure I follow the reasons why TimedMutex refines > TryMutex. (This is a comment on the original design, not your specific > changed, but bear with me.) I think a timeout of zero seconds achieves > the same goal, even if TimedLock/TimedMutex don't implement the same > operations. > So I don't think that TimedLock needs a constructor that > takes a blocking argument, and ultimately I think TimedLock/TimedMutex > should refine Mutex/Lock, and not TryMutex/TryLock. > Also, the current implementation of TimedLock doesn't support a single > argument constructor, even though it is supposedly a refinement of > TryLock, which does. I'd like to see TimedLock implemented in such a way > that I could use it as if it were a simple Lock, which I currently cannot. > In summary, this is what I'd like to see: > > Lock Concept > --------------- > L l(m) //Blocking lock > L l(m,s) //Blocking lock if s > > TryLock Concept > --------------- > As Lock, *plus:* > L l(m,b) //Lock; blocking if b > > TimedLock Concept > ----------------- > As Lock (not TryLock), *plus:* > L l(m,t) //Blocking lock, failing if not obtained by time t > //If t == 0, acts as TryLock. > As I said in another post, I'll think about this some more. Thanks for taking the time to comment. Mike

15 169

libs/iterator/doc/iterator_concepts.pdf not marked as binary
by Peter Dimov 14 Jul '04

14 Jul '04

libs/iterator/doc/iterator_concepts.pdf is not marked as binary in the CVS. The result is that it apparently has been scrambled at commit time, as neither a Windows nor a Linux check out a readable PDF. In addition, Windows always shows it as locally modified; my cvs commit just committed a new revision of iterator_concepts, but I didn't touch the file. I can't fix it because I don't have the original PDF, and cvs can't check out a working version. -- Peter Dimov http://www.pdimov.com

2 1

Math functions for statistics - a draft TR2 proposal.
by Paul A Bristow 13 Jul '04

13 Jul '04

As promised recently, I am presenting a draft of proposals for math functions which are needed for even most elementary statistics. I have been encouraged to submit this to both the C and C++ Standard Library groups at the same time. (They seem to speaking more than in the past). These are additions to the list drawn up by Walter Brown accepted into TR-1. The style and format follows his closely even though there were some opposition to them from the C++ community. However I think we have to accept that C and C++ compatibility are valued more than C++ 'ideality', and not try to re-open this area of dissent. The draft has been uploaded to the files area in a new folder Math Functions as "More Mathematical Functions.pdf" 220 kb. I'd be grateful if some CVS whizz would copy it to the sandbox as I know that many are unable to access the fiels section. It would be useful to have comments on 1 Typographical mistakes. 2 Mathematical mistakes (prepared by someone with seriously rusty math!). 3 The choice of functions espcially if there are any your feel strongly are missing, or are not needed (say why). 4 The choice of names. Clarity is preferred to curtness. 5 The choice of names for derivatives like the inverse and complement. I have added suffixes _inc and _c (or _com?). ( for C there will be suffixes f and l for the float and long double versions). Thanks. Paul PS I am on holiday for two weeks and will not respond to your observations until July. Paul A Bristow Prizet Farmhouse, Kendal, Cumbria UK LA8 8AB +44 1539 561830 +44 7714 330204 mailto: pbristow(a)hetp.u-net.com

2 3

boost::function code size
by Vladimir Prus 11 Jul '04

11 Jul '04

Hello, I've became interested in how efficient code-size-wise boost::function is, so I wrote a small script which generates a function which calls boost::function object N times and finds the size of the generated function. The results are somewhat interesting and somewhat alarming (to me). On gcc 3.3 with -Os, each call to boost::function costs 147 bytes of code size. With -O3 it's about 166 bytes. On gcc 3.4 calls cost 203 bytes with -Os and between 220 and 240 with -O3. However, when boost::function is called 15 times, the inliner heuristics kick in and calls are no longer inlined -- meaning each call costs about 14 bytes. This is a good thing for 3.4, but still: 1. For 3.3 boost::function causes a serious code bloat. 2. Even for 3.4, I'm not sure how it will perform if calls are done in several modules. Or how the heuristics will work on non-trivial cases: if they use the % of size increase then on large modules boost::function inlining can cost much more. Given that, IIUC, boost::function has to do indirect call somewhere anyway, I'm not sure inlining is such a good idea. Maybe some of the methods should be declared out-of-line, so that compiler don't try to inline them? - Volodya

2 3

[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

Boost Mathematicians
by Tom Brinkman 07 Jul '04

07 Jul '04

What is the current status of all Boost mathmatical, statistical and econometric libraries currently in development? The collection of boost math libraries that are currently included in the library are world-class and provide a wonderful foundation to build-upon. However, many areas of advanced statistical and mathmatical inference are not currently being addressed by any of the boost libraries. Is there currently a way for those boost developers with a background in mathmatics to coordinate their efforts. If not, why not? Lets get such a discussion started. A continued and regular dialog of mathmatics as it relates to boost library development would be of great use, primaryily to avoid overaping our efforts. If your a mathmetician and agree with me that boost is a great foundation to build-upon, let the group/me know. Points for Discussion: 1) We should keep a seperate list of boost::math libraries that are currently under development and provide a forum for advanced discussions. How can we do this? 2) We need a way to attract the best mathmaticians in the world. How can we make the boost libraries an even more attractive development platform for the mathemiticians? 3) We should create a list of mathmatical algorithims and libraries that are needed. 4) We need some very basic boost specific math-tutorials for our future mathemiticans and potential library writers. 5) We need to advertise to the development community about how strong of a foundation boost is for mathmatical library development. In short, lets tell the world that this is the premiere place for advanced mathmatical library development, as I believe that it could be. Comments? Regards, Tom Brinkman __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

23 70

Re:Re: [boost] Re: 1.32 release preparation
by Robert Ramey 06 Jul '04

06 Jul '04

Johannes Brunen wrote: >> And if there are a large >> number of new things left out by that approach then we should plan >> another release sooner rather than waiting 4 months. >However, then you need new volunteers which have to spend the time for the >whole procedure again. The release procedure is too onerous. This isn't the problem, it's a symptom of a more subtle problem. If the source of this difficulty can be found can corrected, then releases can occur more frequently. My personal view is that it's a symptom of a development process that couples otherwise independent/orthogonal efforts. This is due to the fact that we're all working against a development tree that has experimental code in it. So minor issues ripple across all efforts. >I could think of a review process which accepts a library only after the >list of requested changes has been made. > I would prefere a review process which leads to final > acceptance only after a library is 'CVS' compatible i.e. does not yield to > any (known) regressions of the existing pool libraries and is equipted > with a working testing facility. The review process qualifies submissions for inclusion into boost. I don't think there are any libraries that have been accepted then suffered changes which made them unacceptable. It's not fair to ask a submitter to require that that he totally "finish" the package before submission when it cannot be guaranteed that it will be accepted. The review process isn't the problem, its working quite well. It's just that there is more effort than first meets the eye between the time a library is deemed acceptable and the time it is ready for inclusion into boost. The serialization library including code, headers, tests, html, jamfiles, *.bat, and shell scripts is has passed 25,0000 lines. This takes time and no changes in the review or release procedure can change that. There is the review package which seems to work pretty well. But I would be reluctant to check it in as it doesn't match the review acceptance conditions and I'm concerned about trying to maintain a package which I have now moved beyond. Robert Ramey

3 3

Re:Re: [boost] Re: 1.32 release preparation
by Robert Ramey 06 Jul '04

06 Jul '04

Message: 16 Date: Sun, 27 Jun 2004 22:25:47 -0500 From: "Aaron W. LaFramboise" <aaronrabiddog51(a)aaronwl.com> Subject: Re: [boost] Re: 1.32 release preparation To: boost(a)lists.boost.org Message-ID: <40DF8FBB.4040408(a)aaronwl.com> Content-Type: text/plain; charset=us-ascii Aaron W. LaFramboise wrote: >Robert Ramey wrote: >> Dave Abrahams wrote: >> >> >>>I'd like to know the reasons for "all the sudden rush". We did >>>announce a schedule long ago, and it has already been delayed by three >>>weeks. I'm not asking in order to point fingers; I just want to know >>>how to avoid the "sudden rush" next time. >> >> >> Here is the current scenario. >> >> a) The announcement gets posted - release 1.32 scheduled for date x. >> b) Each developer decides - uh oh I better get in my changes before date x. >> c) Of course these changes take longer >> d) and break some other things >> e) which takes longer still >> >> Personally I think the concept of scheduling a release fundamentally flawed. >> I would suggest another idea. >As an observer, I'm fairly impressed with GCC's release methodology. >http://gcc.gnu.org/develop.html >A critical component is a schedule that includes several stages during >which certain sorts of changes are unacceptable. >There's still rush, but most of the rush for major features or other >destabilizing elements happens long before the release comes around. I found this to be very interesting. I had never seen this before. It basically implements my view that the "Main Line" should be code that is always works and is ready to be used, tested and potentially released. As far as I'm concerned it's totally consistent with my proposal which I thought was un-orthodox but now see that is used at least by GCC. So, my view would be - stick to the original 28 June date, require that new libraries be added to branches and merge to main as appropriate. I realize its not THAT easy - but it would address the concerns that I have about the whole process and allow all libraries to proceed on independent schedules. New libraries would be tested against the "known good tree" independently of one another. Take as a small example changes in MPL. The current method is to check in a new version of MPL and see what happens. Presumable some issues will arise and now we have a broken system which inhibits development of other libraries until the issues are resolved. Under the proposed method, the new MPL would be check in under its own branch and issues would be detected on all libraries before they affect other developers. Anyway - my 2 cents. Robert Ramey

8 16

Administrative Requests
by David Abrahams 05 Jul '04

05 Jul '04

Just a reminder -- I'm not the only moderator. Please post all administrative requests to boost-owner(a)lists.boost.org so that the workload of responding to them is distributed across everyone who can handle them. Thanks, -- Dave Abrahams Boost Consulting http://www.boost-consulting.com

2 2

codewarrior 8.0 problem
by Pavol Droba 04 Jul '04

04 Jul '04

Hi, Regression tests show that codewarrior 8.0 have some problems with string algo lib. Report is here: http://tinyurl.com/35asy It seems, that compiler cannot find std::locale class. Can somebody with an access to this compiler help here. Thanks in advance. Regards, Pavol

6 7

Proposal: Addition to boost::integer_traits
by Jeffrey C. Jacobs 04 Jul '04

04 Jul '04

A while ago I proposed adding a signed_traits class and then after receiving some input decided it better this be a property of some existing traits object, ideally "integer_traits" since only integer can be signed. I tried to contact some people to whom I'd been referred about changing integer_traits.hpp but never heard back. Otherwise I have received no negative feedback from this proposal. The idea is simple, as with the min and max constants associated with boost::integer_traits, there would be: boost::integer_traits<x>::unsigned_type boost::integer_traits<x>::signed_type I also proposed a boost::integer_traits<x>::type But that would be x and so wouldn't be very useful. With these additions, one would be able to get the signed or unsigned form of a type without knowing the type detail. In other words, one can apply "signed" or "unsigned" to any specialized integral type that supports it. (Obviously bool would not be supported, nor would any non-integral types.) OTOH, a user-defined pseudo-integral type could provide its own specialization which would be a way of converting between signed and unsigned Abstract Integral Types (AITs) in a generic way: template <> class integer_traits<my_signed_type> : public std::numeric_limits<my_signed_type>, public detail::signed_integer_traits_base<my_signed_type, my_unsigned_type> { BOOST_STATIC_CONSTANT(bool, is_integral = true); }; Note: here I do not use the boost::detail::integer_traits_base helper because my_signed_type does not have a min or max value and even if it did, it is not possible to do in-class initialization with abstract data types. I would also be providing a specialization of std::numeric_limits. Note also because of these orthagonal properties, I provide a separate base class for signed_integer_traits_base, rather than adding to integer_traits_base. The idea would then be to have a new type in the boost::details namespace: template <class ST, class UT> class signed_integer_traits_base { public: typedef ST signed_type; typedef UT unsigned_type; }; And define each integral type correspondingly, e.g.: template<> class integer_traits<bool> : public std::numeric_limits<bool>, public detail::integer_traits_base<bool, false, true>, public detail::signed_integer_traits_base<bool, bool> { }; template<> class integer_traits<char> : public std::numeric_limits<char>, public detail::integer_traits_base<char, CHAR_MIN, CHAR_MAX>, public detail::signed_integer_traits_base<signed char, unsigned char> { }; // ... template<> class integer_traits<int> : public std::numeric_limits<int>, public detail::integer_traits_base<int, INT_MIN, INT_MAX>, public detail::signed_integer_traits_base<signed int, unsigned int> { }; template<> class integer_traits<unsigned int> : public std::numeric_limits<unsigned int>, public detail::integer_traits_base<unsigned int, 0, UINT_MAX>, public detail::signed_integer_traits_base<signed int, unsigned int> { }; // ... The one problem with this as I see is cv-qualification. Clearly, this will only provide the cv-unqualified types input as if I read ISOC++ 14.1.5 correctly, and I may not be, the top-level cv-qualification of the integral type template parameter would be dropped. E.g.: boost::integer_traits<const int>::signed_type would be [signed] int, NOT const [signed] int. In general, this is what you want because it saves you from writing specialization for each cv-qualification, but it then looses information about the source type, namely how it was cv-qualified. For the other traits, where static functions or constants are provided, the cv-qualification does not matter; it is only in the manifestation of the typedef that causes this inconvenience. However, I think this approach better than none though suggestions and corrections are welcome. Jeffrey.

3 3

boost/config/suffix.hpp: spurious BOOST_HAS_THREADS with g++ 3.4
by Christoph Ludwig 03 Jul '04

03 Jul '04

While testing gcc 3.4 (on a x86 PC running Linux), I encountered linker errors due to missing pthread symbols, even though my program is single threaded. I found that some translation units using boost::shared_ptr included boost/detail/lwm_nop.hpp whereas other translation units included boost/detail/lwm_pthreads.hpp. I didn't observe any errors with gcc 3.3.x. The problem turns out to be that gcc 3.4 defines the preprocessor variable _REENTRANT if certain standard library headers are included even if the compiler is *not* called with the '-pthread' command line option. The following test exhibits this behavior and shows that it causes BOOST_HAS_THREADS to be erroneously defined in boost/config/suffix.hpp if, e.g., the standard header string is included: cludwig@lap200:~/C++/gcc3.4/tmp> g++ -v Lese Spezifikationen von /opt/gcc/gcc-3.4.0/lib/gcc/i686-pc-linux-gnu/3.4.0/specs Konfiguriert mit: ../gcc-3.4.0/configure --prefix=/opt/gcc/gcc-3.4.0 --enable-threads=posix --enable-version-specific-runtime-libs --enable-languages=c,c++ --enable-__cxa_atexit --enable-c-mbchar --enable-concept-checks --enable-libstdcxx-debug --enable-c99 --enable-libstdcxx-pch Thread-Modell: posix gcc-Version 3.4.0 cludwig@lap200:~/C++/gcc3.4/tmp> cat test-BOOST_HAS_THREADS.cc #if defined(WITH_STRING_HEADER) # include <string> #endif #include <boost/config.hpp> #if defined(__MT__) # warning "__MT__ defined" #endif #if defined(_MT) # warning "_MT defined" #endif #if defined(_REENTRANT) # warning "_REENTRANT defined" #endif #if defined(_PTHREADS) # warning "_PTHREADS defined" #endif #if defined(BOOST_HAS_THREADS) # warning "BOOST_HAS_THREADS defined" #endif cludwig@lap200:~/C++/gcc3.4/tmp> g++ -c -I ../boost_1_31_0/ test-BOOST_HAS_THREADS.cc cludwig@lap200:~/C++/gcc3.4/tmp> g++ -c -I ../boost_1_31_0/ -DWITH_STRING_HEADER test-BOOST_HAS_THREADS.cc test-BOOST_HAS_THREADS.cc:16:4: Warnung: #warning "_REENTRANT defined" test-BOOST_HAS_THREADS.cc:24:4: Warnung: #warning "BOOST_HAS_THREADS defined" I have no idea what the gcc developers recommend in order to detect multi-threading support or if this should be reported to the gcc developers as a bug. But it will certainly break many programs using Boost. A user can work around this problem by either including boost/config.hpp before any other headers (even Boost headers since boost/lexical_cast.hpp, for example, includes string before boost/config.hpp). Or the user builds everything with MT-support, even if the program itself is single threaded. Neither workaround is satisfying. Regards Christoph PS: FWIW, I could trace back the problem to a change in include/c++/i686-pc-linux-gnu/bits/gthr-default.h. This change was discussed in http://gcc.gnu.org/ml/gcc-patches/2003-07/msg01607.html. -- http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/cludwig.html LiDIA: http://www.informatik.tu-darmstadt.de/TI/LiDIA/Welcome.html

4 21

logging library
by John Torjo 02 Jul '04

02 Jul '04

Dear boosters, Finally, found some time to work on the logging library ;) (for those interested - find it at http://groups.yahoo.com/group/boost/files/logging.zip or http://www.torjo.com/code/logging.zip) note: this first draft works only for Win32 :( In short, it makes it very easy to log messages, while being efficient. And on top of that, it's thread-safe. Table of contents: ****** Declaring/defining logs ****** Log hierarchies ****** Modifier/ Log functions ****** Enabling/disabling of logs ****** Example ****** Declaring/defining logs Every log has: - a unique ID, by which you refer when you write to it - a name, by which you can modify its behavior (for example, enabling/disabling). The name is very useful so that you can manipulate multiple logs at once (for instance, disable multiple logs at once) and to be externally known - to easily manipulate logs at run-time. Also, this way is also easier to form hierarchies of logs (see below). Cutting to the chanse: // declare a log, in a header file BOOST_DECLARE_LOG(dbg) // define the log, in a source file BOOST_DEFINE_LOG(dbg, "app.dbg") // writing to the log BOOST_LOG(dbg) << "this is a debug message, i=" << i << std::endl; ****** Log hierarchies Logs can be hierarchical. In a hierarchy, a log inherits all anscestors' behaviors. Log A is said to be a descendant of Log B if when B's name starts with A's name (example: "app.charts.gui.dbg" is a descendant of "app.charts", but not a descendant of "app.err") When manipulating logs, you're always manipulating a hierarchy - the wildcard '*' stands for "anything" - see below. ****** Modifier/ Log functions When a message is written to a log, the following will happen: - first, check if the log is enabled. If so, continue. Otherwise, do nothing. - run all modifiers for this message - run all log functions for this message A modifier is a function that can modify the original message before it's printed to any destination. Examples can be: prefix the message with the current time, or prefix the message with the current thread ID. The log function is a function that will actually print this message to a destination. An example: void write_to_cout(const std::string &, const std::string &msg) { std::cout << msg; } When setting modifier/log functions, you're manipulating hierarchies of logs. Example: // add this modifier to all logs that start with "app" name add_modifier_func("app*", &write_prefix); // write all messages to cout add_log_func("*", write_to_cout); ****** Enabling/disabling of logs By default, all logs are enabled. You can specifically enable/disable some of them - wildcards work. Example: // disable all logs disable_logs("*"); // enable all dbg logs enable_logs("*dbg*"); Note that enabling/disabling is VERY EFFICIENT. In case a log is not enabled, the code after BOOST_LOG(...) is not executed AT ALL. Example: BOOST_LOG(app) << some_time_consuming_msg << std::endl; If 'app' is disabled, some_time_consuming_msg will not be executed. ****** Example // full sample found in logging.zip // Modifiers for all: // [type_of_message] original_message append_enter_if_needed add_modifier_func("*", &prefix_time, std::numeric_limits<int>::max() ); add_modifier_func("*", &append_enter); // Modifiers for app and its ascendants // <time> [type_of_message] original_message append_enter_if_needed add_modifier_func("app*", &write_prefix); // Modifiers for "app" only // <time> [Thread ID] [type_of_message] original_message append_enter_if_needed add_modifier_func("app", &prepend_thread_id, 0); // Log Functions // all messages are written to cout add_log_func("*", write_to_cout); // "app*" messages are written to file as well add_log_func("app*", write_to_file); // 'app' only and dbg messages are written to Output Debug Window as well add_log_func("app", write_to_dbg_wnd); add_log_func("*dbg*", write_to_dbg_wnd); int i = 1, j = 2, k = 3; BOOST_LOG(app) << "testing" << i << '-' << j << '-' << k; // written to both cout & the file & Output Debug Window BOOST_LOG(dbg) << "this is a debug message, i=" << i << std::endl; BOOST_LOG(info) << "I just wanted to tell you something...."; BOOST_LOG(warn) << "Logged-on Users approach max. limit"; BOOST_LOG(err) << "Too many users!"; BOOST_LOG(charts::gui) << "Creating main window" << std::endl; BOOST_LOG(charts::dbg) << "A debug msg coming from {charts} module" ; BOOST_LOG(charts::gui) << "Destroying main window" << std::endl; // disable all descendants of 'app' (not the 'app' itself) disable_logs("app.*"); BOOST_LOG(dbg) << "this won't be written" << std::endl; BOOST_LOG(app) << "However, this msg. will" << std::endl; enable_logs("app.dbg"); // specifically, only dbg log is enabled back now BOOST_LOG(dbg) << "this will be written - this log just got enabled" << std::endl; BOOST_LOG(err) << "this still won't be written" << std::endl; enable_logs("app.*"); disable_logs("app.dbg"); // now, all logs are back to the 'enabled' state BOOST_LOG(err) << "this will be written - all logs are enabled" << std::endl; // disable all logs disable_logs("*"); BOOST_LOG(err) << "this won't be written" << std::endl; BOOST_LOG(app) << "neither will this" << std::endl; BOOST_LOG(dbg) << "or this..." << std::endl; BOOST_LOG(warn) << "or this..." << std::endl; BOOST_LOG(info) << "or this..." << std::endl; // enable all dbg logs enable_logs("*dbg*"); BOOST_LOG(app) << "this won't be written" << std::endl; BOOST_LOG(dbg) << "this will be written" << std::endl; BOOST_LOG(info) << "this won't be written" << std::endl; // enable info log enable_logs("*info*"); BOOST_LOG(info) << "a simple info" << std::endl; /*** Console 18:59:44 [app] [Thread 1384] testing1-2-3 18:59:44 [app.dbg] this is a debug message, i=1 18:59:44 I just wanted to tell you something.... 18:59:44 [app.warn] Logged-on Users approach max. limit 18:59:44 [app.err] Too many users! 18:59:44 Creating main window 18:59:44 A debug msg coming from {charts} module 18:59:44 Destroying main window 18:59:44 [app] [Thread 1384] However, this msg. will 18:59:44 [app.dbg] this will be written - this log just got enabled 18:59:44 [app.err] this will be written - all logs are enabled 18:59:44 [app.dbg] this will be written 18:59:44 a simple info */ /*** Output Debug Window 19:00:03 [app] [Thread 1384] testing1-2-3 19:00:03 [app.dbg] this is a debug message, i=1 19:00:03 A debug msg coming from {charts} module 19:00:03 [app] [Thread 1384] However, this msg. will 19:00:03 [app.dbg] this will be written - this log just got enabled 19:00:03 [app.dbg] this will be written */ /*** out.txt file 19:00:03 [app] [Thread 1384] testing1-2-3 19:00:03 [app.dbg] this is a debug message, i=1 19:00:03 [app.warn] Logged-on Users approach max. limit 19:00:03 [app.err] Too many users! 19:00:03 [app] [Thread 1384] However, this msg. will 19:00:03 [app.dbg] this will be written - this log just got enabled 19:00:03 [app.err] this will be written - all logs are enabled 19:00:03 [app.dbg] this will be written */ There's some more work - the docs also ;) , but I'm pretty happy with the first draft. What do you all think? Best, John -- John Torjo Freelancer -- john(a)torjo.com -- http://www.torjo.com/logview/ - viewing/filtering logs is just too easy!

5 10

logging library v1.1 - with documentation!
by John Torjo 02 Jul '04

02 Jul '04

Dear boosters, Worked some more on the logging library, and here's what's new: - added ***documentation*** - added samples - made static library (improved compilation times) - added efficient thread-safe logger, which does the logging on a dedicated thread (in order to be as fast as possible, it caches multiple log messages - which could be coming from multiple threads, and has a dedicated thread, which once at X milliseconds, writes them) Get it from: http://groups.yahoo.com/group/boost/files/logging.zip or http://www.torjo.com/code/logging.zip Looking forward to your feedback. Best, John -- John Torjo Freelancer -- john(a)torjo.com -- http://www.torjo.com/logview/ - viewing/filtering logs is just too easy!

3 5

RE: [boost] Re: Boost.Threads: Do we need all those mutexes?
by Batov, Vladimir 01 Jul '04

01 Jul '04

> Well, as you point out, try_lock is like a timed_lock with > time = 0, and lock is like a timed_lock with time = infinity, > so why not give timed_lock both lock() and try_lock() > methods as shorthand notation for lock(m, t=0) and > lock(m, t=infinity)? [Batov, Vladimir] Because, in my view, it violates the fundamental (and I think widely accepted) OO design principle (guideline?) that in simple terms can be expressed as "one class, one responsibility". Names like Bertrand Meyer, Herb Sutter and many others immediately come to mind. We can either achieve that by having a universal lock (with timed_lock as the basis) and shorthand notations in separate derived classes (lock, timed_lock and try_lock) or by keeping those three completely unrelated (probably at the expense of some code/functionality duplication). I am personally leaning towards latter, as even though technically all three concepts are related, from the user point of view they are distinct. > The argument for try_lock not having a blocking lock() method, > which you seem to stress more often, is much clearer; I'm much > more inclined to agree with you there. [Batov, Vladimir] Thank you. I feel that it is important that every class does what it promises to do. No more, no less.

2 1

RE: [boost] Re: Boost.Threads: Do we need all those mutexes?
by Batov, Vladimir 01 Jul '04

01 Jul '04

[Christopher Currie] In the need of extreme memory efficiency and speed: I already have, from prior use, a scoped_try_lock 'l' around my mutex, currently unlocked. I need to lock my mutex in a blocking fashion. I do not wish to pay the memory and time cost to create an instance of scoped_lock just to do this. I therefore call 'l.lock()' and not 'l.try_lock()'. [Batov, Vladimir] I am sorry but I am far from being convinced that "extreme memory efficiency" can be achieved by saving on one lock. Locks are very transient creatures and created on the stack. Commonly the stack is predefined by OS regardless if you use it or not. Consequently, even when you do not create another object on the stack, that memory is not available to you for anything else anyway. Even if it is, I greatly doubt that that approach is the right approach to achieve efficiency. The common approach would be to worry about the right design first and foremost, then run profilers/monitors/tests to see where we actually can save memory/gain performance. Twisting design for the sake of perceived performance/memory gains is often (I'd say always) a very bad idea. Even if you do not buy into my arguments in the prev. paragraph, you'll probably agree it'll be unfair to expect that the majority of library users and overall general-purpose library design need to pay the price of accommodating your very specific requirements. For example, general memory allocation is often slow for me. Then, I write my own special memory allocator. I am not asking for the general-purpose allocator to be changed. ... [Christopher Currie] Constructor parameters are, admittedly, a different discussion, and most of them boil down to syntactic sugar for a non-locking constructor and a call to some locking operation, blocking or otherwise. But (IMO) it's a useful syntactic sugar that *can* if used properly make programs less cumbersome to construct without sacrificing correctness or clarity. [Batov, Vladimir] I am not against syntactic sugar if it is in line with what is reasonably expected from a class. However, I am against syntactic sugar which is not relevant to class functionality. Like I am happy if I can simply give my credit card to a taxi driver and not worry about having cash. However, I am not sure if I'd like that driver singing. As far as S/W design is concerned, I'd prefer a taxi driver class (with its responsibilities) and a singer class (with its responsibilities). We all know how to blend those two classes if we ever need that.

2 1

min, max, GCC 2.95.3, and STLport
by Doug Gregor 01 Jul '04

01 Jul '04

The new handling of min/max seems to break under GCC 2.95.3 with STLport. I'm not quite sure _why_ it doesn't work (I don't have the compiler around), but you can see the failure here: http://tinyurl.com/ytdlf Perhaps someone with that compiler/lib combination could get preprocessed output for the problem area so we could see what's happening? Doug

4 5

ccref
by alnsn＠yandex.ru 01 Jul '04

01 Jul '04

This is not a typo, I'm trying to emphasize that ref, cref, ... sequence lacks one element which imposes more strict requirements on its argument. According to IQ tests logic that sequence should be continued with ccref :) If seriously, cref allows silent binding of a temporary to a reference. Apparently, this is not always fine. Inspired by N1610 (thanks to Dave and Gary) I've tried to detect both const and non-const rvalues. I didn't yet opened my copy of the standard to check it but the code seems to work on g++ 3.2.2, g++ 3.4.0, Intel 8.0 (all under linux) and Comeau online. #include <boost/ref.hpp> template<class T1, class T2> struct enable_if_same { }; template<class T> struct enable_if_same<T,T> { typedef int type; }; template<class T> boost::reference_wrapper<T const> const ccref(T volatile& r, typename enable_if_same<T,T const>::type = 0) { return boost::reference_wrapper<T const>(const_cast<T const&>(r)); } struct convertible_to_int { operator int() const { return 0; } }; template<class T> boost::reference_wrapper<T const> const ccref(T const volatile& r) { return boost::reference_wrapper<T const>(const_cast<T const&>(r)); } int rvalue() { return 0; } int const const_rvalue() { return 0; } int main() { int i; int const j = 0; ccref(i); ccref(j); // Try uncommenting any of these lines: // ccref(rvalue()); // ccref(const_rvalue()); } -- Alexander Nasonov

3 4

Links at ACCU
by David Abrahams 01 Jul '04

01 Jul '04

Hi, I recently got this request from the ACCU website admins: Please take a look at www.accu.org/terse/cpp.htm and let me know how the Boost library/people would like to be represented on www.accu.org/terse/cpp.htm. So I figured I'd ask. Anyone have an opinion? -- Dave Abrahams Boost Consulting http://www.boost-consulting.com

5 4

RE: [boost] Re: Cvs tag dependency
by Rozental, Gennadiy 01 Jul '04

01 Jul '04

> "Rozental, Gennadiy" <gennadiy.rozental(a)thomson.com> writes: > > > Hi, > > > > Inn a light of recent discussion on earlier freezing, I > have following > > question/proposition: > > > > Is it exist in Boost.Build or could we add feature that allow us to > > specify cvs tag dependency as a dependency grist? > > I _think_ what you're proposing is interesting, but the means > of getting there may be completely inappropriate for > Boost.Build, if I understand it at all. Why don't you try to > say what you're trying to accomplish without trying to design > the Boost.Build feature? I want to be able to use regression testing facility not only for HEAD cvs state. > Are you trying to get cvs checkout > actions into the build system? Namely. I want build system be aware about different versions of files/components and want to be able to specify which version I prefer to use for this particular test. > If so, why? What's wrong with doing > > cvs update -rwhatever_tag > before kicking off the test? Nothing. I just want it happened automatically on a computer that performs regression testing, depends on a rule defined in a Jamfile. > Dave Abrahams Gennadiy.

3 2

[MPL] rational_c and fixed_c
by Cromwell Enage 30 Jun '04

30 Jun '04

A while back it was mentioned that boost::mpl::rational_c and boost::mpl::fixed_c needed redesigning. Before I attempt to tackle this task anymore than I already have, I should have some questions answered. 1. For those compilers for which BOOST_NO_LIMITS is defined, I've learned that there is no way to include a floating-point number in an integral constant expression. Does this mean that no matter how I define fixed_c::value, I cannot pass fixed_c as a template argument to a metafunction that ordinarily takes integral_c as input? Do I have to duplicate the functionality as a result? If so, what should be the naming convention for these new metafunctions? 2. Should I define fixed_c in terms of rational_c, to reduce the amount of functionality I may need to duplicate? Something like this: template <typename IntType, IntType N, IntType PowerOf10> struct fixed_c { typedef rational_c<IntType,...,...> type; }; 3. Eventually the compile-time rational-number representation will need to be converted to a runtime floating-point value. Should I define this conversion function within rational_c (which means an additional template parameter, with either function or class scope, defining the return value type), within a wrapper struct, or somewhere else? And how? 4. I only have to deal with rational numbers, right? I don't have to worry about accurately representing a transcendental number or a complex-number expression? TIA! Cromwell Enage __________________________________ Do you Yahoo!? Yahoo! Domains � Claim yours for only $14.70/year http://smallbusiness.promotions.yahoo.com/offer

3 7

Implicit failures in MetaComm regression tests?
by Doug Gregor 30 Jun '04

30 Jun '04

The Boost.Function test case "lambda_test" for intel-win32-7.1-vc6 (and its STLport variant) come out as unexpected passes. I'd like to move these over to explicit passes, but they don't seem to be marked as expected failures in status/explicit-failures-markup.xml. How can I make these expected passes, to get that nice cushy all-green feeling? Doug

3 4

Cvs tag dependency
by Rozental, Gennadiy 30 Jun '04

30 Jun '04

Hi, Inn a light of recent discussion on earlier freezing, I have following question/proposition: Is it exist in Boost.Build or could we add feature that allow us to specify cvs tag dependency as a dependency grist? Example1: Jamfile ------- MY_SRCS = .... tag_to_test = my_lib_dev # HEAD run my_test : <tag:$(tag_to_test)>$(MY_SRCS) Now If I want to test my new development branch I just set tag to appropriate value. Example2: Jamfile ------- exe my_test : ...sources... <tag:1_31_0><lib>../build/boost_unit_test_framework Now I want stable version of library - I specify which one I want. Example3: Jamfile ------- exe my_test : ...sources... <tag:1_30_0>...abc.h Here I know my code works with that version of header file I want to use it specifically. And so on. This feature could allow us to: 1. Test development branches for regressions 2 .Test new features before moving it in cvs HEAD 3. Depend on stable version of dependency, without need to keep up with changes in it. 4. Test development version Boost.Test with stable version of it e.t.c I am sure it's not easy to do. But may be it worth a shot. Gennadiy.

3 2

boost::variant visitor member instantiation question
by craig perras 30 Jun '04

30 Jun '04

Hello - I want to do type conversions (checked at compile-time) using boost::variant. So I naively made a 'convert' visitor, which has designed to (hopefully) safely convert the variant value to another type (eg: a client might try to assign the variant's int value to an unsigned short). For instance: typedef boost::variant < std::string, int, double > ParamValue; // ----- ConvertParamValueVisitor //T is the type which will be assigned the variant's value //V is the Variant/Visitor template<typename T> struct ConvertParamValueVisitor<T> { typedef ConvertParamValueVisitor self; typedef void result_type; self( T*& val ) : value_(val) {} template<typename V> result_type operator()( const V& v, typename boost::enable_if<TypeTraits::is_arithmetic<V> >::type* dummy = 0 ) const { *value_ = boost::numeric_cast<T>(v); } template<typename V> result_type operator()( const V& v, typename boost::enable_if<TypeTraits::is_string<V> >::type* dummy = 0 ) const { *value_ = v; } private: T*& value_; }; It seems boost::variant will instantiate all members for all variant types, even the ones I try to suppress using enable_if. To work around this, I've tried various things, like specializing ConvertParamValueVisitor based on T, using lazy_enable_if, etc. Here's one attempt: // ----- ConvertParamValueVisitor //T is the type which will be assigned the variant's value //V is the Variant/Visitor //not implemented template<typename T, class Enable = void> struct ConvertParamValueVisitor; //ConvertParamValueVisitor int, double: use numeric cast template<typename T> struct ConvertParamValueVisitor<T, typename boost::enable_if<TypeTraits::is_arithmetic<T> >::type > { typedef void result_type; typedef ConvertParamValueVisitor self; self( T*& val ) : value_(val) {} template<typename V> result_type operator()( const V& val, typename boost::enable_if<TypeTraits::is_arithmetic<V> >::type* dummy = 0 ) const { *value_ = boost::numeric_cast<T>(val); } //not implemented template<typename V> result_type operator()( const V& val, typename boost::enable_if<TypeTraits::is_string<V> >::type* dummy = 0 ) const; private: T*& value_; }; //ConvertParamValueVisitor string template<typename T> struct ConvertParamValueVisitor<T, typename boost::enable_if<TypeTraits::is_string<T> >::type > { typedef void result_type; typedef ConvertParamValueVisitor self; self( T*& val ) : value_(val) {} //not implemented template<typename V> result_type operator()( const V& val, typename boost::enable_if<TypeTraits::is_arithmetic<V> >::type* dummy = 0 ) const; template<typename V> result_type operator()( const V& val, typename boost::enable_if<TypeTraits::is_string<V> >::type* dummy = 0 ) const { *value_ = val; } private: T*& value_; }; Is there any way to get something like this to work? Am I simply mis-applying boost::variant? I could of course just throw an exception in the unsupported/not implemented methods above, but I'd like this checked at at compile time if possible. (note that my question is generally applicable to visitors, not just to boost::variant). thanks! --craig __________________________________ Do you Yahoo!? Yahoo! Mail - 50x more storage than other providers! http://promotions.yahoo.com/new_mail

1 0

Boost Signal Bug
by Neal Coombes 30 Jun '04

30 Jun '04

I've experienced the same problem discussed on June 3rd titled "Bug, signals, use of default Combiner" http://thread.gmane.org/gmane.comp.lib.boost.devel/103903 . I would have just replied except its a little old, thus a new thread. Doug Gregor wrote: > We intentionally did not return a default-constructed value because > the returned type might not have a default constructor. Granted, this > case might be sufficiently rare to justify using your version of > last_value. I would like to say a few things about this and offer an alternative solution. First, I think not returning a default constructed value is the correct approach with the last_value combiner for the reasons you've mentioned. I don't think the bug is with the last_value combiner, but with the fact that the last_value combiner is the default combiner (ok an exception rather than an assert would probably be better). However, I would venture to claim that a signal being called without any slots is not a rare case. In fact I'd guess that might be the most likely case. Certainly, as a library writer, I cannot assume that all the signals I provide to my users are going to be used in every application. My suggestion is to provide a default combiner that does the bare minimum, just call the slots: namespace boost { struct default_combiner { typedef void result_type; template<typename InputIterator> result_type operator()(InputIterator first, InputIterator last) const { while (first != last) *first++; } }; } I believe this would solve the problem without restricting use of default signals to objects with default constructors, or to signals with at least one slot connected.

2 1

RE: [boost] Re: Boost.Threads: Do we need all those mutexes?
by Batov, Vladimir 30 Jun '04

30 Jun '04

1. Oh, c'mon, I never implied that your design was "dubious and likely incorrect". It was said in the context of operator[] for std:list. 2. IMHO for a library to be accepted, embraced, popular, survive it has to be suitable/convenient/intuitive for 80% of the users. The library should not go out of its way to satisfy esoteric requirements of 20% at the expense of clarity/simplicity/good design. Or example, std:auto_ptr is not for everyone and not always work where I'd like it to work. It does not mean std::auto_ptr needs to sacrifice its efficient and minimalistic beauty to make me happy. Getting back to Boost.Threads I'd still like to see a compelling example where I'd need to declare try_lock but twist its intuitive functionality into behaving like scoped_lock (that is blocking until locked). -----Original Message----- From: boost-bounces(a)lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Matt Hurd Sent: Wednesday, 30 June 2004 10:42 AM To: boost(a)lists.boost.org Subject: Re: [boost] Re: Boost.Threads: Do we need all those mutexes? On Wed, 30 Jun 2004 10:17:04 +1000, Batov, Vladimir <vladimir.batov(a)ca.com> wrote: > > Why give the user an alternative with is > dubious and likely incorrect? It is a pattern of need for multithreaded programming where I work to require single and multithreaded awareness for objects where performance excludes the option of using separate object instances. I don't think the design is dubious or incorrect it is mandated by the business requirements. Though most of my designs usually are incorrect or dubious ;-) I just call those tactical :-) matt. _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

3 2

[Graph] problem with set_property method when using subgraph?
by Daniel Lou 30 Jun '04

30 Jun '04

Hi, I wanted to set meaningful names for individual subgraphs but I failed with the following test code.... ---------------------------------------------------------------------------- --------------- typedef adjacency_list<vecS, vecS, directedS,no_property, no_property, property<graph_name_t, string> > mygraph_t; typedef subgraph < graph_t > mysubgraph_t; graph_t g; boost::set_property(g, graph_name, "graph"); // **** this is O.K. mysubgraph G; boost::set_property(G, graph_name, "subgraph"); // **** Error C2784 cout << boost::get_property(G, graph_name) << endl; ---------------------------------------------------------------------------- - I use .NET 2003. The error message says: could not deduce template argument for 'boost::adjacency_list<OutEdgeListS,VertexListS,DirectedS,VertexProperty,Edg eProperty,GraphProperty,EdgeListS> &' from 'mysubraph_t' Any thoughts? Thanks, Daniel

2 1

[BGL] remove_edge bug
by Vladimir Prus 30 Jun '04

30 Jun '04

Jeremy, I think your reversion 1.120 of detail/adjacency_list.hpp: 2004-04-01 05:30 jsiek * detail/adjacency_list.hpp: fixed remove_edge for bidirectional graphs actually breaks remove_edge in a different way. Please take a look at http://zigzag.cs.msu.su:7813/program_graph.cpp The code there add two vertices, an edge between them, and then removes the edge. After that 'num_edges' returns 1, not 0 as expected. I seems like now remove_edge removes elements from out_edges and in_edges storage, but not from global edges vector. Is it possible to fix this problem? TIA, Volodya

2 3

[BGL] Unused parameter "inf" in dijkstra_shortest_paths?
by Douglas Gregor 30 Jun '04

30 Jun '04

Hmmm, this could be a bug, but I don't have time to look into it now: /home/gregod/Projects/Boost/boost/boost/graph/dijkstra_shortest_paths.hpp: In function `void boost::dijkstra_shortest_paths_no_init(const VertexListGraph&, typename boost::graph_traits<G>::vertex_descriptor, PredecessorMap, DistanceMap, WeightMap, IndexMap, Compare, Combine, DistInf, DistZero, DijkstraVisitor) [with VertexListGraph = boost::adjacency_list<boost::listS, boost::vecS, boost::bidirectionalS, boost::property<boost::vertex_name_t, std::string, boost::no_property>, boost::property<boost::edge_name_t, std::string, boost::property<boost::edge_length_t, double, boost::property<boost::edge_speed_limit_t, int, boost::property<boost::edge_direction_t, char, boost::property<boost::edge_snow_route_t, bool, boost::no_property> > > > >, boost::no_property, boost::listS>, DijkstraVisitor = boost::dijkstra_visitor<boost::null_visitor>, PredecessorMap = boost::iterator_property_map<__gnu_cxx::__normal_iterator<Intersection*, std::vector<Intersection, std::allocator<Intersection> > >, boost::vec_adj_list_vertex_id_map<boost::property<boost::vertex_name_t, std::string, boost::no_property>, size_t>, Intersection, Intersection&>, DistanceMap = boost::iterator_property_map<__gnu_cxx::__normal_iterator<double*, std::vector<double, std::allocator<double> > >, boost::vec_adj_list_vertex_id_map<boost::property<boost::vertex_name_t, std::string, boost::no_property>, size_t>, double, double&>, WeightMap = boost::adj_list_edge_property_map<boost::bidirectional_tag, double, double&, size_t, boost::property<boost::edge_name_t, std::string, boost::property<boost::edge_length_t, double, boost::property<boost::edge_speed_limit_t, int, boost::property<boost::edge_direction_t, char, boost::property<boost::edge_snow_route_t, bool, boost::no_property> > > > >, boost::edge_length_t>, IndexMap = boost::vec_adj_list_vertex_id_map<boost::property<boost::vertex_name_t, std::string, boost::no_property>, size_t>, Compare = std::less<double>, Combine = boost::closed_plus<double>, DistInf = double, DistZero = double]': /home/gregod/Projects/Boost/boost/boost/graph/dijkstra_shortest_paths.hpp:171: warning: unused parameter `double inf' /home/gregod/Projects/Boost/boost/boost/graph/dijkstra_shortest_paths.hpp: In function `void boost::dijkstra_shortest_paths_no_init(const VertexListGraph&, typename boost::graph_traits<G>::vertex_descriptor, PredecessorMap, DistanceMap, WeightMap, IndexMap, Compare, Combine, DistInf, DistZero, DijkstraVisitor) [with VertexListGraph = boost::adjacency_list<boost::listS, boost::vecS, boost::bidirectionalS, boost::property<boost::vertex_name_t, std::string, boost::no_property>, boost::property<boost::edge_name_t, std::string, boost::property<boost::edge_length_t, double, boost::property<boost::edge_speed_limit_t, int, boost::property<boost::edge_direction_t, char, boost::property<boost::edge_snow_route_t, bool, boost::no_property> > > > >, boost::no_property, boost::listS>, DijkstraVisitor = boost::dijkstra_visitor<boost::null_visitor>, PredecessorMap = boost::iterator_property_map<__gnu_cxx::__normal_iterator<Intersection*, std::vector<Intersection, std::allocator<Intersection> > >, boost::vec_adj_list_vertex_id_map<boost::property<boost::vertex_name_t, std::string, boost::no_property>, size_t>, Intersection, Intersection&>, DistanceMap = boost::iterator_property_map<__gnu_cxx::__normal_iterator<double*, std::vector<double, std::allocator<double> > >, boost::vec_adj_list_vertex_id_map<boost::property<boost::vertex_name_t, std::string, boost::no_property>, size_t>, double, double&>, WeightMap = TravelTimePropertyMap, IndexMap = boost::vec_adj_list_vertex_id_map<boost::property<boost::vertex_name_t, std::string, boost::no_property>, size_t>, Compare = std::less<double>, Combine = boost::closed_plus<double>, DistInf = double, DistZero = double]': /home/gregod/Projects/Boost/boost/boost/graph/dijkstra_shortest_paths.hpp:171: warning: unused parameter `double inf' Doug

2 1

Re: Boost.Threads: Do we need all those mutexes?
by Batov, Vladimir 30 Jun '04

30 Jun '04

>>" Thread-safety should not be a run-time configurable property." > I think this is somewhat incorrect as absolutes usually are. Well, I'll probably lose the fairly abstract discussion of general incorrectness of absolutes. :-) I just think that compile-time vs. run-time is a pragmatic choice. Why give the user an alternative with is dubious and likely incorrect? For that reason std::list does not provide operator[] even though it could. Surely, one could come up with his/her design that would "require" such an operator for std::list. Does it invalidate the decisions STL designers made? I do not think so. That is why I am suspicious of temptations to lump distinctly different functions of scoped_lock, try_lock and timed_lock into one universal blob. V.

3 2

Re: Boost.Threads: Do we need all those mutexes?
by Batov, Vladimir 30 Jun '04

30 Jun '04

> bool foo(bool threadsafe) > { > mutex::scoped_lock l(m, !threadsafe); > } I am not sure if the example above is appropriate and indicative of the problem we are trying to solve. Thread-safety should not be a run-time configurable property. Like we do not decide on the fly (at run-time) if our ref.-counting class is to be thread-safe or not. All that is resolved at compile time. More so, that still can be solved with statically defined lock/nolock constructors: bool foo(bool some_condifion) { mutex::scoped_lock l(m, boost::nolock); if (some_condition) l.lock(); } 2. I feel that our assumptions of try_lock (yes, I know it is try_scoped_lock, I am just lazy) and timed_lock being refinements of scoped_lock are incorrect. At best scoped_lock and try_lock are refinements of timed_lock as scoped_lock is timed_lock with time=infinite and try_lock is timed_lock with time=0. Therefore, we you insist on common lock functionality, it has to be encapsulated in one timed_lock (or maybe some basic_lock or just a lock). Then, all locks would refine that common behavior. That approach has the advantage of covering the case when I do not know what I want :-) -- then I'd simply use the basic_lock. 3. However, I personally feel that our attempts of generalizing locks are misguided. Locks are different, serve different purposes and provide different and distinct functionality. I feel that we should make an effort to keep different locks different and lean. Like try_lock actually tries to lock. Adding blocking (lock()) functionality to such a lock looks like a mistake as IMHO it encourages bad programming style as it allows to use try_lock where scoped_lock is needed. I feel that the situation when I do not know what kind of lock I need when I step into a function shows that the function needs to be-restructured/split so that in every new component I do know what I need. V.

3 2

Boost.Threads proposed change: lock constructors
by Michael Glassford 30 Jun '04

30 Jun '04

Below I detail proposed changes to the Boost.Threads lock class constructors. Comments? Questions? Mike ----------------------------------------------------------------- The Boost.Threads lock concept constructors are currently defined as follows: Definitions ----------- L: lock type l: lock variable (type L) m: mutex variable (appropriate Mutex type) s: initial lock state (type bool, true=locked, false=unlocked) Lock Concept ------------ L l(m,s) //Blocking lock if s L l(m) //Blocking lock TryLock Concept --------------- L l(m,s) //Blocking lock if s L l(m) //Non-blocking lock TimedLock Concept ----------------- L l(m,s) //Blocking lock if s L l(m,t) //Blocking lock, failing if not obtained by time t These definitions have the following drawbacks: 1) That one of the TryLock constructors blocks while the other doesn't is neither obvious nor very consistent. 2) That the single-parameter constructor of Lock blocks while the single-parameter constructor of TryLock doesn't is neither obvious nor very consistent. 3) Part of the reason for the above inconsistencies is that it's not clear whether the constructors of TryLock should block or not. 4) The TimedLock constructors have no way to request a non-blocking lock. To address these problems, I would like to redefine the lock concept constructors as follows (changes indicated with "^"): Definitions ----------- L: lock type l: lock variable (type L) m: mutex variable (appropriate Mutex type) s: initial lock state (enum type {NO_LOCK=0, LOCK=1}) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ b: block? (enum type blocking_state {NON_BLOCKING=0, BLOCKING=1}) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Lock Concept ------------ L l(m,s) //Blocking lock if s L l(m) //Blocking lock TryLock Concept --------------- L l(m,s,b) //Lock if s; blocking if b ^ ^^^^^^^^^^^^^ L l(m,b) //Lock; blocking if b ^ ^^^^^^^^^^^^^ TimedLock Concept ----------------- L l(m,s,b) //Lock if s; blocking if b ^ ^^^^^^^^^^^^^ L l(m,t) //Blocking lock, failing if not obtained by time t Note: s and b are defined as enums rather than bools to prevent existing code from breaking silently: e.g., if s and b were bools, "TryLock l(m, false)", which currently means "construct a lock object but don't obtain a lock", would change with the new definitions to mean "construct a lock and make a non-blocking attempt to obtain a lock". Also, enums are more explicit than bools. Note: these changes will cause some existing code to break by producing compile errors; the compile errors can be fixed by appropriately adding or changing parameters being passed to the changed TryLock and TimedLock constructors. Mike

4 10

[1.32 release] Boost.Test plan
by Rozental, Gennadiy 30 Jun '04

30 Jun '04

I plan to add one more big feature and several small one into this release. I should be able to finish all of this within 3 weeks. I mostly worry about some regression on old compilers. I will try to address most of it before committing. Gennadiy.

8 14

two thread libs? [was: Re: [boost] Re: logging library]
by John Torjo 30 Jun '04

30 Jun '04

> [snip] > Static-link build option added > > The option to link Boost.Threads as a static library has been added back with some limitations. This feature was originally removed because boost::thread_specific_ptr required that Boost.Threads be dynamically linked in order for its cleanup functionality to work on Win32 platforms. Several options are currently being explored to resolve this issue. In the meantime, the ability to link Boost.Threads statically has been added back with boost::thread_specific_ptr support removed from the statically linked version. The decision to add it back was made because its lack is one of the most frequent complaints about Boost.Threads and because the other approaches that are being investigated to deal with boost::thread_specific_ptr cleanup look fairly promising. so if I get the latest boost.thread I'll have all this (ability to use it as a static lib)? > > Note > Boost.Threads is still dynamically linked by default. In order to force it to be statically linked, it is necessary to #define BOOST_THREAD_USE_LIB before any of the Boost.Threads header files are #included. I'm not sure this is ok with me. I think it should still be statically linked by default (see below). > > Note > If the boost::thread_specific_ptr cleanup issue cannot be resolved by some other means, it is highly likely that the option to statically link Boost.Threads will be removed again in a future version of Boost, at least for Win32 platforms. This is because the boost::thread_specific_ptr functionality will be increasingly used by Boost.Threads itself, so that proper cleanup will become essential in future versions of Boost.Threads. Again, I don't understand why you need thread_specific_ptr within boost.threads so much. Anyway, if you need thread_specific_ptr so much, maybe we could do away with two libraries, something like: 'thread' and 'thread_ext' or so. In the thread, we should keep what was roughly before: - mutexes (don't tell me they need TLS) and scoped locks - thread class (no cleanup support) - xtime In the thread_ext, include whatever needs thread_specific_ptr, and extra goodies - this will have the statically/dynamically linked issue. I think this would be quite good in the long run, since there are so many libs/applications that only need basic thread support, and who really don't want an extra DLL added to the maintenance list. Best, John -- John Torjo Freelancer -- john(a)torjo.com -- http://www.torjo.com/logview/ - viewing/filtering logs is just too easy!

1 0

[1.32 Plan] multi_index
by Joaquín Mª López Muñoz 30 Jun '04

30 Jun '04

This is the plan for release of Boost.MultiIndex. This is a newly added library. Current status: commited in the CVS since 6 weeks or so. Regression tests are OK for all the compilers that I intend to support. If someone is interested in some other compiler being supported, please contact me. Pending issues: #1 Minor updates to the docs. No big deal. #2 Some changes related to the new defect macro BOOST_NO_POINTER_TO_MEMBER_TEMPLATE_PARAMETERS These issues will be resolved way before the branching date, I hope. Questions: #1 Dave talked about Aleksey going to merge a new version of MPL in the main trunk. When will that happen? How disruptive do you expect it to be wrt to the rest of libraries? #2 Should I update the additional stuff right away (links in the main and libraries pages, uploading of bio and picture etc.)? Or is anybody else taking care of that stuff? #3 Vladimir just talked about "adding markup for the failures". What is this? Is this something required as part of the regression fixing process? Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

3 5

Explicit markup notes
by Aleksey Gurtovoy 30 Jun '04

30 Jun '04

Could I ask that every time we are adding an explicit failure to "status\explicit-failures-markup.xml" or, even more so, marking up a library as unusable, we also provide a note explaining the markup? We don't have to come up with a specific wording for every single failure -- there are a few standard notes at the end of the document that fit many common situations, and can be simply referenced by their ID (e.g. <note refid="3"/>), but not saying anything at all significantly defeats reports' usefullness. -- Aleksey Gurtovoy MetaCommunications Engineering

1 0

Library doc link is broken
by Jeff Garland 30 Jun '04

30 Jun '04

The current CVS doc link seems to have gone down... Not Found The requested URL /regression-logs/cs-win32_metacomm/doc/html/libraries.html was not found on this server. Jeff

2 1

[Formal review result] Tribool
by Thomas Witt 30 Jun '04

30 Jun '04

Hi, I am happy to report that the "Tribool" library by Doug Gregor has been ACCEPTED into boost. Other than this there is very little to be said. Reviews were generally in favour of the library and the issues surfaced during the review have been addressed by Doug. There were some comments regarding the scope of the library. While I agree that an broader coverage of 3-valued logic might be good to have, I do not think it justifies delaying acceptance of the library. Regards Thomas Review Manager Tribool -- Thomas Witt witt(a)acm.org

1 0

Bug in token_functions.hpp
by Joe Gottman 30 Jun '04

30 Jun '04

I have found a bug in token_functions.hpp. I have a hello-world program that looks like this: ----------begin file #include <boost/token_functions.hpp> int main(int argc, char* argv[]) { boost::char_separator<char> sep; printf("Hello World!\n"); return 0; } ----------end file It fails under MSVC 6.0 with the following error messages: c:\jobs\boost\token_functions.hpp(261) : error C2065: 'is_pointer' : undeclared identifier c:\jobs\boost\token_functions.hpp(267) : see reference to class template instantiation 'boost::tokenizer_detail::get_iterator_category<Iterator>' being compiled c:\jobs\boost\token_functions.hpp(261) : error C2275: 'Iterator' : illegal use of this type as an expression c:\jobs\boost\token_functions.hpp(267) : see reference to class template instantiation 'boost::tokenizer_detail::get_iterator_category<Iterator>' being compiled c:\jobs\boost\token_functions.hpp(261) : error C2059: syntax error : ',' c:\jobs\boost\token_functions.hpp(267) : see reference to class template instantiation 'boost::tokenizer_detail::get_iterator_category<Iterator>' being compiled c:\jobs\boost\token_functions.hpp(264) : error C2238: unexpected token(s) preceding ';' c:\jobs\boost\token_functions.hpp(267) : see reference to class template instantiation 'boost::tokenizer_detail::get_iterator_category<Iterator>' being compiled c:\jobs\boost\token_functions.hpp(266) : error C2653: 'cat' : is not a class or namespace name c:\jobs\boost\token_functions.hpp(267) : see reference to class template instantiation 'boost::tokenizer_detail::get_iterator_category<Iterator>' being compiled I believe the problem is that we need to add the line #include <boost/type_traits/is_pointer.hp> to token_functions.hpp. If I add this line to my program before including token_functions.hpp, everything compiles fine. Joe Gottman

1 0

RE: [boost] Re: Boost.Threads: Do we need all those mutexes?
by Hurd, Matthew 29 Jun '04

29 Jun '04

> Behalf Of Batov, Vladimir > > > bool foo(bool threadsafe) > > { > > mutex::scoped_lock l(m, !threadsafe); > > } > > I am not sure if the example above is appropriate and indicative of the > problem we are trying to solve. Thread-safety should not be a run-time > configurable property. Like we do not decide on the fly (at run-time) if > our ref.-counting class is to be thread-safe or not. All that is > resolved at compile time. >" Thread-safety should not be a run-time configurable property." I think this is somewhat incorrect as absolutes usually are. I currently have a design where I use both an interface that supports locking and an interface which does not. It is an important feature of the design. Using such a run time parameter is not my choice because I am especially sensitive to performance but it might be a better design for others given other requirements. Non-locking versions are also useful when you want to combine operations. Take a lock, do stuff, and then release lock. Repeatedly locking has deficiencies which may or may not matter to you. $0.005, Matt Hurd. FWIW I wrap boost mutexex and locks in my own policy-like stuff. E.g: ___________________________________________________________ struct shareable { protected: struct adapted_mutex : public boost::rw_mutex { adapted_mutex( lock_priority::type lp = lock_priority::exclusive ) : rw_mutex( convert( lp) ) {} ~adapted_mutex() {} }; struct adapted_try_mutex : public boost::try_rw_mutex { adapted_try_mutex( lock_priority::type lp = lock_priority::exclusive ) : try_rw_mutex( convert( lp) ) {} ~adapted_try_mutex() {} }; struct adapted_timed_mutex : public boost::timed_rw_mutex { adapted_timed_mutex( lock_priority::type lp = lock_priority::exclusive ) : timed_rw_mutex( convert( lp) ) {} ~adapted_timed_mutex() {} }; public: typedef adapted_mutex mutex; typedef adapted_try_mutex try_mutex; typedef adapted_timed_mutex timed_mutex; typedef shareable_lock<mutex> lock; typedef shareable_lock<try_mutex> try_lock; typedef shareable_lock<timed_mutex> timed_lock; typedef atomic_op_interlocked atomic_op; }; ___________________________________________________________ So I can parameterise classes with a synch policy. (Less than ideal but I haven't got around to making it nicer yet.) For the interface where I need to support single threaded and multi-threaded usage of the same object ( as opposed to type ) I use this approach... ___________________________________________________________ template < class S = synch::shareable > class instrument : public synch::monitor<S> { SYNCH_SIMPLE_ATTRIBUTE( susquehanna_code, std::string ); SYNCH_SIMPLE_ATTRIBUTE( exchange_code, std::string ); SYNCH_SIMPLE_ATTRIBUTE( underlying, std::string ); SYNCH_SIMPLE_ATTRIBUTE( bid, double ); SYNCH_SIMPLE_ATTRIBUTE( bid_volume, double ); SYNCH_SIMPLE_ATTRIBUTE( ask, double ); SYNCH_SIMPLE_ATTRIBUTE( ask_volume, double ); SYNCH_SIMPLE_ATTRIBUTE( last, double ); SYNCH_SIMPLE_ATTRIBUTE( last_volume, double ); SYNCH_SIMPLE_ATTRIBUTE( prior_settlement, double ); }; ___________________________________________________________ This way I can use an object in the following manner: ___________________________________________________________ te::instrument<> i_sample; i_sample.exchange_code<true>("hello"); // locking { te::instrument<>::lock lk( i_sample.guard() ); i_sample.exchange_code<false>("hello"); // non-locking } i_sample.exchange_code("hello"); // locking std::string hello = i_sample.exchange_code(); // locking hello = i_sample.exchange_code<false>(); // non-locking hello = i_sample.exchange_code<true>(); // locking hello = i_sample.exchange_code_ref(); // non-locking by nature ___________________________________________________________ I could also specify te::instrument< synch::no_synch > // locking is elided te::instrument< synch::simple > // exclusive locking te::instrument< synch::no_synch > // allows recursive locking te::instrument< synch::shareable > // allows shared or exclusive locks (think r/w) The interface to the non-locking version is still valid. User must code to shareable concept for everything to work for all concepts. Where SYNCH_SIMPLE_ATTRIBUTE defines a bunch of simple attribute helpers and looks like: #define SYNCH_SIMPLE_ATTRIBUTE( VAR_NAME, VAR_TYPE ) \ \ public: \ template< bool > \ void \ VAR_NAME \ ( \ boost::call_traits< VAR_TYPE >::param_type new_ ## VAR_NAME \ ) \ { \ if ( boost::needs_lock<VAR_TYPE>::value ) { \ lock lk(guard_ ); \ VAR_NAME<false>( new_ ## VAR_NAME); \ } else { \ VAR_NAME<false>( new_ ## VAR_NAME); \ } \ } \ \ void \ VAR_NAME \ ( \ boost::call_traits< VAR_TYPE >::param_type new_ ## VAR_NAME \ ) \ { \ VAR_NAME < true > ( new_ ## VAR_NAME ); \ } \ \ template< > \ void \ VAR_NAME<false> \ ( \ boost::call_traits<VAR_TYPE>::param_type new_ ## VAR_NAME \ ) \ { \ VAR_NAME ## _ = new_ ## VAR_NAME; \ } \ \ template< bool > \ VAR_TYPE \ VAR_NAME( ) const \ { \ if ( boost::needs_lock< VAR_TYPE >::value ) { \ lock lk(guard_, synch::lock_status::shared ); \ return VAR_NAME<false>( ); \ } else { \ return VAR_NAME<false>( ); \ } \ } \ \ VAR_TYPE \ VAR_NAME( ) const \ { \ return VAR_NAME<true>( ); \ } \ \ template< > \ VAR_TYPE \ VAR_NAME <false>() const \ { \ return VAR_NAME ## _; \ } \ \ boost::call_traits<VAR_TYPE>::const_reference \ VAR_NAME ## _ref( ) const \ { \ return VAR_NAME ## _; \ } \ \ private: \ VAR_TYPE VAR_NAME ## _; \ SYNCH_SIMPLE_ATTRIBUTE includes an extra thing boost::needs_lock<VAR_TYPE>::value that checks if the size of the type is > pointer size which means, for Intel & AMD, that locking is not required as the assignment of aligned types is atomic. Copy constructors, assignment and cloning are further issues ;-) 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.

1 0

Proposal: signed.hpp
by Jeffrey C. Jacobs 29 Jun '04

29 Jun '04

Based on Dave Abrahams' recent notes, may I suggest the following draft for revision? http://starship.python.net/crew/timehorse/signed.hpp Thanks! Jeffrey

2 1

ReL[boost] Re: 1.32 release preparation
by Robert Ramey 29 Jun '04

29 Jun '04

David Abrahams <dave(a)boost-consulting.com> writes: >> Robert, I'm very happy to have your contributions in this discussion, >> but it's hard to take your diagnosis of where the problem lies all >> that seriously when you haven't even been through a single Boost >> release with a library of your own! >I hope I didn't squash the discussion with this remark; I'm really >interested in exploring the possibilities here. I guess I should've >asked how you formed your impressions of the problem's cause. As I recall, the previous release was scheduled for beginning November. I was working on the serialization library at the time and using the development tree at the time. When the release was announced, lots of new stuff was added. There were a couple of tweaks in the new iterators which required changes for me to keep up. Trying to develop new stuff based on he development tree became inconvenient but I needed features not it 1.30 . Then about the middle of January "is_abstract" was dropped in. This was an evolved version of one I had adapted from ?R Sharoni's code. It was slightly different from the original in the way compilers not supported. So we didn't have real good knowledge about which platforms supported it and what value it should return on platforms that didn't support it. I was considered a very small change but consumed maybe a week of back and forth. It became clear that I could not submit a proposed serialization library based on the development tree that could be reviewed by large number of members downloading the library over an extended period without users encountering a lot of frustration and my trying to keep up with a morphing main trunk. As soon as it was released, I switched to maintain compatibility with the released 1.31 and it has worked out well. Based on this experience, it is my perception that the main development trunk was at least somewhat fluid over a period of 2 to 3 months and this made development more difficult. These are just the things I happen to run into first hand. The traffic on the list left me with the impression that my experience wasn't unique. That is how I formed my impression of the problem's cause. It is my reluctance to contribute to this problem which has discouraged me from checking in the serialization library until it is at a point where I believe there are no undocumented bugs/deficiencies. That is why the serialization library is not yet checked in. At this point nothing in boost depends on the serialization library. Should that change in the future, this discussion convinces me that before checking in any non-trivial changes, I should re-run the whole test suite on my local setup. In the case of MPL, I would think that it would be prudent to run that part of the test suite that depends upon MPL on one's local environment before checking it in - given that we don't use a branch for untested code. Robert Ramey

2 1

1.32 release preparation
by Aleksey Gurtovoy 29 Jun '04

29 Jun '04

Hi All, I'm finally ready to start working towards the next release, which as some of you might remember I volunteered to manage. Below is a preliminary schedule what I would like to propose, subject to adjustments as I receive your input: June 24-27: Announce a preliminary release schedule, collect information about everyone's plans for the release, adjust/confirm the schedule, make regression reports to reflect the actual status of the main trunk, setup nighly runs of the inspection report (http://tinyurl.com/2vo5p) construct a "Release Progress" page publishing the milestones, the collective TODO list, and links to all the reports. June 27-July 16: Use regression reports to identify and resolve the outstanding issues with the main trunk. Walk through and deal with all the patches and bug reports submitted to the list/SourceForge tracker since the last release. In accordance with the TODO list, track the progress of individual developers. By July 15, 24:00 US Central Time every line of code that is intended to be put into this release should be in the CVS, and the next round of regression reports should show no regressions against the then-current expected failures markup. July 16: Branch for release. Switch regression tests to run on the branch. July 17-July 18: No code checkins are allowed expect to fix the failures resulted from branching (hopefully none). Documentation checkins are still OK. Perform the rest of the pre-release tasks listed in http://tinyurl.com/2meuh. July 18, 24:00 US Central Time marks a complete freeze of the branch. July 19-July 20: Prepare and test the release candidate archives. Fix any found issues and repeat. July 21: Release according to the http://tinyurl.com/2meuh procedure. As you can see from the first milestone's description, at this point I'd like to collect everybody's plans for the release (for those developers who do plan to do something, of cource), with approximate dates, so that we have a better understanding of how everything is going to fall together. Please post these plans to the list with "[1.32 Plan]" prefix in the subject. As usual, any other comments/suggestions are more than welcome. Thank you! -- Aleksey Gurtovoy MetaCommunications Engineering

14 29

typo in boost::thread
by Janusz Piwowarski 29 Jun '04

29 Jun '04

Hello, Numerous files of boost::thread has CR+CR+LF as line ending. I noticed it happens regularly, maybe there's a way to prevent this? Also, there's a typo in try_lock member of scoped_timed_lock<TimedMutex> class: is: return (m_locked = lock_ops<TryMutex>::trylock(m_mutex)); should be:? return (m_locked = lock_ops<TimedMutex>::trylock(m_mutex)); Regards, Janusz

2 2

RE: [boost] The Test Tools Docs, Concept Checking
by Rozental, Gennadiy 29 Jun '04

29 Jun '04

I could add proposed text, once somebody prepared it. Gennadiy. > Hi, > > I have been reading the Test Tools docs. Would it be a > good idea to add ConceptChecking to the list of alternative > methods of reporting errors, in > /test/doc/index.html#introduction ? A recent post on boost > alluded to the fact that Concepts (ie What is a concept? ) > can be difficult to understand. Well ... ConceptChecks are > the medium for pinning down Concepts in C++ code and are > probably the most effective means of error reporting at > compile time, but are not used as much as they could be. The > Boost Test Library would seem to be as good a place as any to > promote them, which could help to remove some of the mystery. > > regards > Andy Little

3 2

[Test] Failures on GCC 2.95.3
by Doug Gregor 29 Jun '04

29 Jun '04

The file boost/test/detail/basic_cstring/io.hpp contains this workaround function for GCC 2.95.3: template<typename CharT> inline std::ostream& operator<<( std::ostream& os, basic_cstring<CharT> const& str ) { typedef typename basic_cstring<CharT>::mutable_char char_type; char_type const* const beg = reinterpret_cast<char_type const* const>( str.b egin() ); char_type const* const end = reinterpret_cast<char_type const* const>( str.e nd() ); os << std::basic_string<char_type>( beg, end - beg ); return os; } What is mutable_char? It doesn't show up anywhere else in Boost. Doug

2 1

Missing http://www.boost.org/regression-logs/cs-win32_metacomm/developer/index.html
by Doug Gregor 29 Jun '04

29 Jun '04

I have a sinking feeling that I might have broken something when modifying the explicit failures file :( Doug

2 1

Re: Boost.Threads proposed change: lock constructors
by Batov, Vladimir 28 Jun '04

28 Jun '04

> Part of the point, though, is that try_lock doesn't actually work that > way: one of the try_lock constructors does a non-blocking try_lock(), > and the other does a blocking lock(). Without looking, do you always > remember which one does which? I don't. Well, first, the behavior that I was talking about in my prev. email (ones I was happy about) were the 'basic' constructors (that I called 'default' constructors -- what an embarassment). The following is IMHO good and I would not like see them complicated: 1. scoped_lock l(m); // Blocks until it locks. 2. scoped_lock l(m, true); // As above. 3. scoped_lock l(m, false); // Only declaration. Does nothing. Needed if I need to declare but use it later. 4. try_lock l(m); // Tries to lock. Always falls through. I need to check the result. 5. try_lock l(m, false); // Only declaration. Does nothing. 6. timed_lock l(m, time); // Blocks until locks or 'time' expires. 7. timed_lock l(m, false); // Only declaration. Does nothing. I have to agree that the following behavior 8. try_lock l(m, true); 9. timed_lock l(m, true); that according to the documentation call lock() instead of respective try_lock() and timed_lock() look wrong. I'd be temted to say that merely making (8) work as (4) would be sufficient fo fix try_lock. (9) does not appear "fixable" in a similar way. I am tempted to suggest something similar to overloaded 'operator new': struct nolock_t {}; nolock_t nolock; 1. scoped_lock l(m); 2. scoped_lock l(m, nolock); 3. try_lock l(m); 4. try_lock l(m, nolock); 5. timed_lock l(m, time); 6. timed_lock l(m, nolock); It removes redundancy (as with the original scoped_lock(m) and scoped_lock(m, true)) and makes everything simple and consistent. Just a thought. V

2 1

How to handle name mangling in "versioned" toolsets?
by John Maddock 28 Jun '04

28 Jun '04

At present we have two types of toolsets: 1) Unversioned toolsets such as "intel-win32", which produce unversioned toolset suffixes to library names, "iw" in this case. 2) Versioned toolsets such as "intel-win32-7.1-vc6-stlport-4.5.3" which produce versioned toolset suffixes to library names, "iw71" in this case. This produces a problem with the autolinking code which can take either approach, but not both (or at least not both auto-magically, and this is causing some regression test failures at present). In other words I'm asking for some kind of consistent policy here; note that if the choice is to consistently use "versioned" toolsets then we're committing ourselves to constantly updating the build system and autolinking code to keep up with new compiler releases. So, I guess I'm leaning towards "unversioned" mangled toolset names, but would like more some feedback, so: what does everyone else think? Thanks, John.

3 2

Re: Boost.Threads: Do we need all those mutexes?
by Batov, Vladimir 28 Jun '04

28 Jun '04

My question was more about the design rather than how I could work it around. I may be wrong but specializing mutex does not look like a good idea as it appears to be lock-specific functionality. So, I thought we might consider having only mutex and typedefing others to it (not to break old code) -- the simpler the better. Isn't it? V. > Do we need all three separate concepts -- mutex, try_mutex and > timed_mutex? I think the idea was that it would be possible to implement the mutex types that supported fewer operations more efficiently. Whether this actually turned out to be true is another question. > I'd expect the mutex concept to remain unchanged and "try" > and "timed" refinements to be related solely to the ways I try locking > that only mutex. That is, I always have one mutex and under different > circumstances lock it unconditionally (scoped_lock) or try locking it > and check if that attempt succeeds (scoped_try_lock) or try locking > within a certain time period (scoped_timed_lock). If you want this, just use a timed_mutex and scoped_timed_lock. In the current release it supports lock() and timed_lock() operations; in the next release it will support try_lock() as well. Mike ------------------------------ _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost End of Boost Digest, Vol 772, Issue 2 *************************************

1 0

GCC 3.4 lpthread warnings
by Jeff Garland 28 Jun '04

28 Jun '04

On the regression tests I'm seeing lots of warnings from gcc 3.4. For example: date_time - test_greg_wstream - gcc-3.4.0-linux Compiler output: In file included from /boost/head-regression/boost/boost/config.hpp:44, from /boost/head-regression/boost/boost/date_time/locale_config.hpp:19, from /boost/head-regression/boost/boost/date_time/compiler_config.hpp:14, from /boost/head-regression/boost/boost/date_time/gregorian/gregorian.hpp:19, from ../libs/date_time/test/gregorian/testgreg_wstream.cpp:10: /boost/head-regression/boost/boost/config/stdlib/libstdcpp3.hpp:33:7: warning: #warning "Boost threading support turned on, you may need to link against -lpthread unless you define BOOST_DISABLE_THREADS when building." Lots of other libraries are seeing similar warnings with gcc 3.4. Date-time does nothing with threads so I believe based that I should just set define BOOST_DISABLE_THREADS for the test cases to resolve this. But since I'm not certain of all the implications of this I thought I'd as for advice before proceeding. One specific question that comes to mind is do I need to limit the scope to gcc so I don't break MT, dll mode on Windows? Thanks, Jeff

6 15

[admin] Wiki Spam -- IP's are being banned
by Jeff Garland 28 Jun '04

28 Jun '04

All - I'm cross-posting this to boost-users and the developer list since it pertains to both. Over the last couple months there has been a rise in 'spam attacks' on the Wiki. Basically people are inserting links to commercial sites on wiki pages. These sites are totally unrelated to boost, c++, etc. I thank the many boosters that have spent their precious time removing the defacements. But the time has come to crack down. The following IP ranges have been banned from the Wiki. 61.55.32.* 61.55.33.* 69.63.103.* 210.82.76.* 210.82.106.* 219.233.195.* 218.5.65.* I will be monitoring and banning additional IP addresses as needed. If I have accidentally banned someone incorrectly, please let me know offlist: jeff at crystalclearsoftware.com Thanks, Jeff

1 0

shared_ptr<> and atomic_count
by Colin Rafferty 28 Jun '04

28 Jun '04

Hi- Looking at the implementation of shared_count<>, it seems as though it always uses a mutex for incrementing and decrementing the counter. Is there a reason why we aren't using atomic_count instead? In the worst case, it will have the same performance, but in the best case, it can be significantly faster (BOOST_USE_ASM_ATOMIC_H). Thanks. -- Colin Rafferty

1 0

Re: 1.32 release preparation
by Johannes Brunen 28 Jun '04

28 Jun '04

On Mon, 28 Jun 2004 07:37:24 -0400, David Abrahams wrote > Boost.Graph changes have caused plenty of regressions in Boost.Python > in the past. Sorry, I thougth that this would be a pretty good example of a high level library. So I was wrong. On Mon, 28 Jun 2004 07:33:26 -0400, David Abrahams wrote > We should have more releases. Waiting for libraries to be checked in > is one thing that keeps us from being able to release more frequently. Yes, but if I have the choice of waiting one additional week for the check in of an accepted library against waiting 2 month for the next release I would choose to wait that additional week. However, I have read in one of the other mails that you have a deadline with your book. So live is not that simple at all. I won't persist on changing the planned schedule. Don't get me wrong. > It sounds like you want a whole new Boost procedure for reviews *and* > releases. That seems like a stretch; we don't have any idea whether > it would work at all. No, I merely think that a library should be accepted when it is ready for checkin and there is not a list of changes and request pending. On Mon, 28 Jun 2004 07:34:22 -0400, David Abrahams wrote >> On Mon, 28 Jun 2004 10:51:36 +0200, Johannes Brunen wrotes >> We should list them on the lib page but in a special section. > I don't like the sound of that. It should be very clear to people > which things are part of Boost and which aren't. Ok, I second that. If it not clear for people what is part of boost then it is the wrong way. People should be able to build on a boost release. With kind regards Johannes

1 0

iterator_traits.pdf not marked as binary
by Peter Dimov 28 Jun '04

28 Jun '04

libs/iterator/doc/iterator_traits.pdf is not marked as binary in the CVS. -- Peter Dimov http://www.pdimov.com

2 1

[Graph] What to do about broken compilers?
by Doug Gregor 28 Jun '04

28 Jun '04

The graph library has always been in a "barely usable" support on certain compilers (Borland <= 5.6.4 and MSVC 6.0, in particular). The regression tests have always been a mess---Boost 1.31.0 has very few passes for these compilers, and 1.32.0 isn't looking any better. However, the library is somewhat usable, if you stick to a very small subset and don't mind working around INTERNAL COMPILER ERRORs all of the time. What to do? I'm marking the library "unusable" on both compilers, so that we can concentrate our efforts on those compilers that might actually work. Complain loudly, quickly, and preferably with patches if you think this is the wrong approach. Doug

4 5

Boost.Threads: RW mutexes and locks.
by Batov, Vladimir 28 Jun '04

28 Jun '04

RW mutexes/locks are important to a threading library and appear simple to implement. However, Boost.Threads lacks it. I wrote something simple that appear to do the job using the functionality already available in Boost.Threads. If the idea is considered good/robust/efficient enough and worth having in the library, I can re-write it to conform with the rest of Boost.Threads. class rw_mutex : private boost::noncopyable { typedef boost::condition Condition; public: friend class writer_lock; friend class reader_lock; rw_mutex() : num_readers_(0), num_writers_(0) {} private: boost::mutex mutex_; Condition reader_condition_; Condition writer_condition_; int num_readers_; int num_writers_; }; class writer_lock : public boost::mutex::scoped_lock { typedef boost::mutex::scoped_lock super; public: writer_lock(rw_mutex& mutex) : super(mutex.mutex_), mutex_(mutex) { ++mutex_.num_writers_; // Make new readers wait. // If there are readers in-progress, wait for them to finish. while (mutex_.num_readers_) mutex_.writer_condition_.wait(*this); } ~writer_lock() { --mutex_.num_writers_; // Last writer notifies waiting readers. // If not last, wake up the next writer. if (!mutex_.num_writers_) mutex_.reader_condition_.notify_all(); else mutex_.writer_condition_.notify_one(); } private: rw_mutex& mutex_; }; class reader_lock : public boost::mutex::scoped_lock { typedef boost::mutex::scoped_lock super; public: reader_lock(rw_mutex& mutex) : super(mutex.mutex_), mutex_(mutex) { // If there are writers waiting, let them in first. while (mutex_.num_writers_) mutex_.reader_condition_.wait(*this); ++mutex_.num_readers_; // Make new writes wait. unlock(); } ~reader_lock() { lock(); --mutex_.num_readers_; // Last reader notifies if (!mutex_.num_readers_) mutex_.writer_condition_.notify_one(); } private: rw_mutex& mutex_; };

3 2

Re:[boost] Re: 1.32 release preparation
by Johannes Brunen 28 Jun '04

28 Jun '04

On Sun, 27 Jun 2004 19:05:45 -0700, Robert Ramey wrote > Here is the current scenario. > > a) The announcement gets posted - release 1.32 scheduled for date x. > b) Each developer decides - uh oh I better get in my changes before date x. > c) Of course these changes take longer > d) and break some other things > e) which takes longer still IMHO, point d) touches a weak point: There are two kind of libraries in a system like boost. At first, there are core libraries which are used by many other libraries. Changes at these libraries are potentially dangerous and must be well-considered since they can broke a lot of stuff. They should early checked into CVS to get time for stabelizing the base. Secondly, there are libraries which 'only' provide a special feature like the boost graph library the circular_buffer library. They shouldn't be expected to lead to regressions of other boost libraries. I think that they could be handled differently than the core libraries. > a) the release manager or the core influential developers keep an eye on the > current state of the CVS tree and tests. > b) When things look "pretty good", branch for release without warning. None > of this loading my latest feature in to make the schedule. > c) the Main tree goes on as usual > d) pending issues in the release branch are addressed by nagging the person > responsible. > e) the new version is releases with a number like 1.31.1 or maybe even 28 > July 2004. > f) any changes between branch and release should be just bug fixes which can > then be merged back into the development tree. > > Under this system, releases would occur more frequently - on the order of 6 > weeks. If you're ready to check in your latest feature and the new release > branch catches you with your pants down - well too bad. But it's no big deal > because the next release will be in 6? weeks anyhow which is close to what > its going to take to shake out the repercussions of your check in anyway. We should seriouly consider such a release process. Howerver, then the CVS main tree must always be in a nearly 'Release-Ready' state. But IMO that is anyway a good idea. > But I > think it's really hard to get such a large number of people working > independently on exactly the same schedule. Yes ... > Almost all libraries are accepted subject to some changes being made. Many > such changes seem simple but end up rippling through the whole library. This > takes time. This is IMHO an indication of a flaw in the current boost review process. A library should be only accepted after the list of requested changes has been made. Additionally, I think a library should be accepted only if it is compatible to the current CVS main tree. > Once a library is accepted, then one can get serious about making it pass > with a larger number of compilers. This also takes time - a lot of time Passing compilers which weren't supported during the review process under no circumstances shouldn't delay the integration of the library into the boost main pool. Supporting a special compiler is only a nice to have feature. This means not that it not worth spending the effort supporting important platforms. However, in the first iteration I just expect a library to be written in ANSI C++ and to be usable on platforms which support it. > These changes end up having a ripple effect and can result it changes like > moving things in namespaces and subdirectories. While this is going on, the > system is broken and really not suitable to be subject to the daily testing > routine. This is IMHO an indication of a flaw ... (s.a) > So it seems attractive to deal with all this stuff before one does > the initial check in to CVS. This way one can start with a relatively clean > start. I second this. With best regards Johannes

2 1

Re: 1.32 release preparation
by Johannes Brunen 28 Jun '04

28 Jun '04

On Sun, 27 Jun 2004 16:35:15 -0400, David Abrahams wrote > Should we have accepted libraries checked in immediately (on a branch, > maybe?), Maybe we should reconsider the meaning of 'acceptance' in the review process. Apart of that, I think that this is a very good idea. > and then only added to the libs page when the authors > deem them ready? We should list them on the lib page but in a special section. > If they're checked in on the trunk they can even get the benefit of > regression testing while the authors whip them into shape. Yes, that would be fine. With best regards Johannes

2 1

Re: [boost] Re: 1.32 release preparation
by Johannes Brunen 28 Jun '04

28 Jun '04

On Sun, 27 Jun 2004 08:30:20 -0700, Jeff Garland wrote: > As much as I'd like to see circular_buffer, serialization, etc in this release I'd rather > see us pull off a release that doesn't take 2-3 months to accomplish. I > believe we should hold the line on the schedule now and anything that isn't > ready should simply go in the next release. I disagree on that. We don't have that many Boost releases. Waiting for the next one could be a long time. Therefore, I propose to wait until all (or as many as possibly considering a reasonable time schedule) accepeted libraries will be checked into CVS and be part of the release. > And if there are a large > number of new things left out by that approach then we should plan another > release sooner rather than waiting 4 months. However, then you need new volunteers which have to spend the time for the whole procedure again. > One is that we have been reviewing and > accepting a large number of libraries recently. So, many of these have been > accepted in the last couple months. The other thing that seems to be a > pattern is that libraries get accepted, then authors get a list of changes to > make. I could think of a review process which accepts a library only after the list of requested changes has beem made. > If they get busy it often takes months to get these done and then > finally they check into CVS. So a release tends to trigger the evaluation of > anything that is in that multi-month pipeline. That isn't good. I would prefere a review process which leads to final acceptance only after a library is 'CVS' compatible i.e. does not yield to any (known) regressions of the existing pool libraries and is equipted with a working testing facility. With best regards Johannes

2 1

Re:[boost] Re: 1.32 release preparation
by Robert Ramey 28 Jun '04

28 Jun '04

Dave Abrahams wrote: >I'd like to know the reasons for "all the sudden rush". We did >announce a schedule long ago, and it has already been delayed by three >weeks. I'm not asking in order to point fingers; I just want to know >how to avoid the "sudden rush" next time. Here is the current scenario. a) The announcement gets posted - release 1.32 scheduled for date x. b) Each developer decides - uh oh I better get in my changes before date x. c) Of course these changes take longer d) and break some other things e) which takes longer still Personally I think the concept of scheduling a release fundamentally flawed. I would suggest another idea. a) the release manager or the core influential developers keep an eye on the current state of the CVS tree and tests. b) When things look "pretty good", branch for release without warning. None of this loading my latest feature in to make the schedule. c) the Main tree goes on as usual d) pending issues in the release branch are addressed by nagging the person responsible. e) the new version is releases with a number like 1.31.1 or maybe even 28 July 2004. f) any changes between branch and release should be just bug fixes which can then be merged back into the development tree. Under this system, releases would occur more frequently - on the order of 6 weeks. If you're ready to check in your latest feature and the new release branch catches you with your pants down - well too bad. But it's no big deal because the next release will be in 6? weeks anyhow which is close to what its going to take to shake out the repercussions of your check in anyway. I realize that this is not the most orthodox way of doing things. But I think it's really hard to get such a large number of people working independently on exactly the same schedule. >How come we have so many >accepted libraries that have not even been put in the CVS? Almost all libraries are accepted subject to some changes being made. Many such changes seem simple but end up rippling through the whole library. This takes time. Once a library is accepted, then one can get serious about making it pass with a larger number of compilers. This also takes time - a lot of time These changes end up having a ripple effect and can result it changes like moving things in namespaces and subdirectories. While this is going on, the system is broken and really not suitable to be subject to the daily testing routine. So it seems attractive to deal with all this stuff before one does the initial check in to CVS. This way one can start with a relatively clean start. Robert Ramey

6 6

Problems compiling regex with gcc3 on aix and hpux
by Goetz Isenmann 28 Jun '04

28 Jun '04

Hi! I get ugly warnings (they look dangerous to me) when I compile boost/regex on AIX and HP-UX with gcc. On Linux and FreeBSD everything is fine. For example /usr/local/gcc-3.3.3/bin/g++ -c -I. libs/regex/src/cregex.cpp compiles without any complains. On aix43 and hpux11 this gives me the attached warning messages. The order of the messages is slightly different on both platforms, but after sorting the output is identical. I use boost-1.31.0 and see no differences with and without boost-1.31.0-regex-patch-20040503. -- Goetz Isenmann

2 3

Provisional schedule for Boost-1.33
by John Maddock 28 Jun '04

28 Jun '04

Booster's: It's apparent that several of us will just miss the 1.32 deadlines, and I'm sure some people will be concerned when their code will get released as a result, so provisionally I'd like to propose a schedule for 1.33 so we all know where we are. Unless someone else would like to volunteer (and please don't be shy in doing so!), then I guess that means I've just volunteered to manage the release.... Regards, John Maddock. Provisional 1.33 release schedule: ~~~~~~~~~~~~~~~~~~~~~~ Mon 30th August 2004 [1]: ~~~~~~~~~~~~~~~~ Deadline for additions and changes (other than patches to known issues, and docs) to core Boost libraries [2]. Deadline for the addition of new libraries to cvs unless they pass all tests with the core compiler set [3]. Mon 13th September 2004: ~~~~~~~~~~~~~~~~~~ Deadline for additions and changes (other than patches to regressions, and docs) to all Boost libraries. Deadline for all new library additions. Mon 27th September 2004: ~~~~~~~~~~~~~~~~~~ Branch for release, no changes to the release branch without the release managers permission (except for docs). Mon 4th October 2004: ~~~~~~~~~~~~~~~~ First release candidate published, actual release will be as soon as possible thereafter. Notes: ~~~~ 1) There should be a few reminders of this deadline in the weeks beforehand. 2) The core Boost libraries are those that other Boost libraries heavily depend upon: bind config (unless change is restricted to a single compiler, and can be tested with all effected versions of that compiler before commit). enable_if. integer. iterators (the construction framework subset only). mpl operators preprocessor smart_ptr's static_assert test type_traits. 3) The core compiler set includes those compilers that are known to be highly conforming, and for which no failures will normally be expected: gcc 3.3 or later on Linux. Visual C++ 7.1 on Win32. Intel C++ 8 on Win32 or Linux.

1 0

Re: 1.32 release prepar
by Robert Ramey 28 Jun '04

28 Jun '04

Last time we ended up making a release candidate which isolated a couple of final issues. Maybe this is a symptom and maybe it points in the direction of an interesting idea. New code is checked in and tested in the development tree just as it is now. Regression testing and everything remains exactly as it is. Code that documents all test failures and is considered ready for release is moved to the Release Candidate tree. The exact same regression testing setup used on the development tree is used here. Presumably, it would be run much less as things would only be checked in when thought to be perfect which is an infrequent occurrence. Developers develop against the Release Candidate tree. When they have something they like, the check into the Main Development tree as they do now. Traffic on the main development tree is the same as it is now. The Release Candidate Tree should be ready for "shipment" at any convenient time. This basically should consist of assignation of a version number to the tree state. It would not be or scheduled event dramatic event. It could happen as frequently as is convenient. Of course a test failure on the RC tree would be dramatic event. The check in causing such an event could be cast from the RC Tree (Heaven) back into the Main Development Tree (Purgatory) and the author would suffer the attendant embarrassment. Hopefully this would be an infrequent event. I realize that I haven't personally had a library go through the release process so feel free to ignore this idea. Robert Ramey

2 1

[config] about BOOST_NO_POINTER_TO_MEMBER_TEMPLATE_PARAMETERS
by Joaquín Mª López Muñoz 28 Jun '04

28 Jun '04

In config/intel.hpp, this defect macro is defined as follows #if defined(__ICL) && (__ICL <= 710) # define BOOST_NO_POINTER_TO_MEMBER_TEMPLATE_PARAMETERS #endif The macro should be defined *only* for Intel C++ 7.1 or older for Windows 32-bit. So my questions are: 1. Is the definition correct in light of what I said above? 2. What's the meaning of all those different macros __ICC, __ICL and __ECC? I've googled for them but found nothing conclusive. Thanks Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

3 4

RE: Boost.Threads: RW mutexes and locks.
by Batov, Vladimir 28 Jun '04

28 Jun '04

John Torjo wrote: > Batov, Vladimir wrote: >> >> class writer_lock : public boost::mutex::scoped_lock >> { >> typedef boost::mutex::scoped_lock super; >> >> public: >> >> writer_lock(rw_mutex& mutex) : super(mutex.mutex_), mutex_(mutex) >> { >> ++mutex_.num_writers_; // Make new readers wait. > ^^^^ > > just curios, shouldn't this be thread-safe? I believe it is thread-safe as writer_lock currently inherits from scoped_lock and, consequently, we get inside the writer_lock constructor after its base-class scoped_lock constructor. The base-class constructor does the synchronization.

1 0

store a boost::bind
by Nico Massi 27 Jun '04

27 Jun '04

Hi, Is it possible to store a boost::bind? boost::bind<int> x( f, _1, _2 ); int i = x( 3, 4 ); I get errors if i want to declare a variable of type boost::bind. The point is: I want to have an object that gets a boost::bind, stores it and executes it with the correct values to the time i want. How can i do this? Ciao

4 6

[1.32 Plan] Any date for new version of MPL
by JOAQUIN LOPEZ MU?Z 27 Jun '04

27 Jun '04

Any tentative date for the new version of MPL making it into the CVS? Specially if we stick to July 21st a the release date, I'm concerned that the new MPL will have us fixing regressions for quite a few weeks. OTOH, maybe the update is smooth enough and not many problems arise, but it'd be good to know. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

1 0

detail/atomic_count_gcc.hpp error
by Rene Jager 27 Jun '04

27 Jun '04

trying to do: boost::detail::atomic_count c(0); std::cout << long(c) << std::endl; with gcc 3.2.2 gives: /usr/include/boost/detail/atomic_count_gcc.hpp: In member function `boost::detail::atomic_count::operator long int() const': /usr/include/boost/detail/atomic_count_gcc.hpp:46: invalid conversion from ` const _Atomic_word*' to `volatile _Atomic_word*' in the following function: operator long() const { return __exchange_and_add(&value_, 0); } The problem can be solved by making the private member "_Atomic_word value_" mutable. renej ps I know I shouldn't use detail/* stuff directly... --

3 3

[Concept checking] Missing TrivialIteratorConcept
by Hervé Brönnimann 27 Jun '04

27 Jun '04

Hi just occured to Sylvain Pion and myself recently that the TrivialIteratorConcept is documented but not part of the code, and same for Mutable_TrivialIteratorConcept. It is also missing from the test suite (concept_check_test.cpp) and from the archetypes. This may be intentional or not, but probably either the concepts and archetypes should be added to the code, or removed from the documentation. A small and easy bugfix for 1.32? -- Herve'

2 1

A new way of sorting and searching
by Nic Roets 27 Jun '04

27 Jun '04

Often when I write searching or sorting code in C or C++, I'm frustrated that I have to make a new "callback type" compare function. E.g. when you want to sort a number of points in 2D space according to their distance from a reference point, it's tempting to do something like struct Pt { int x, y; }; static Pt center; // Global or static variable yuck. int PtDistToCenterCmp (Pt &a, Pt &b) { return Dist (a, center) - Dist (b, center); } main() { ... center.x = ...; center.y = ...; ... sort (...); ... } This type of solution has many problems. Reviewing the code for correctness is difficult because now you have to read half way through main, stop to find the definition of center, then continue with main, then find the definition of PtDistToCenterCmp, then continue with main. To solve this problem I suggest a new template class "sorter" : template<class t> struct sorter { // Qsort would require a stack here. Heapsort only a few variables. iterator a, b; sorter(iterator begin, iterator end); // Exuse my cpp if it's // incorrect int Operate (int cmpResult); }; Then it would be used like this : void main () { ... sorter<Pt> sortObj (..., ...); while (sortObj.Operate ( Dist (sortObj.a, center) - Dist (sortObj.b, center))) {} ... } IMHO this is much clearer. A binary searching template class can also be implemented in this way. -- Regards Nic Roets

3 2

Request for reviewers for a CUJ article
by Joaquín Mª López Muñoz 27 Jun '04

27 Jun '04

I've just finished an article for publication in CUJ about Boost.MultiIndex (they accepted the preliminary proposal.) The author guidelines suggest that a couple of technical peers do a review of the text before submission (specifically, the purpose is that the peers "can give you candid feedback regarding accuracy and adherence to standard industry practices".) So, I kindly request some volunteer wanting to do the job. The review shouldn't be too time-consuming (about 3,000 words of text.) I guess someone without prior exposure to the library is a better candidate, so as to probe the introductory quality of the article. Due to (c) issues I guess I cannot just put the article on the web for you to download. If you are interested, please contact me privately and I'll send you the text. Thanks very much for your help. Regards, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

2 2

Re:BOOST_STATIC_ASSERT(false) - was (no subject)
by Robert Ramey 27 Jun '04

27 Jun '04

I hadn't considered Michaels idea. I've been using BOOST_STATIC_ASSERT(0 == sizeof(T)). Michiel Salters wrote: >Robert Ramey wrote: >> BOOST_STATIC_ASSERT(false) >This *should* work. IMHO, if it doesn't, we should fix it, not work >around it like Michiel suggested. I don't think I'ts fixable. But maybe one might want to make another macro named something like BOOST_BETTER_NOT_ARRIVE_HERE - lol >> However, its doesn't work >> with compilers that are too smart for their own good. In order to make this >> work I need something like: >Which compiler and which version of boost and the Compiler are you >using? Can you provide a minimal but complete example? Also, you might >want to have a look at checked_delete where we had similar problems in >the past IIRC. I've noticed it at least on Comeau. I just used the fix above so now I don't see it. So now I don't know which compilers complain. Robert Ramey

2 1

newbie question: Cannot open include file: 'boost/filesystem/operations.hpp': No such file or directory
by Chris 27 Jun '04

27 Jun '04

Hi to all.. sorry for the newbie question. I believe I have built the Boost libs correctly. I used: bjam -s"TOOLS=vc7.1" -s"VC71_ROOT=C:\Program Files\Microsoft Visual Studio .NET 2003\Vc7" install The Includes and Libs are in C:\Boost as described in the "Getting Started Guide" Also I didn't get any errors during the building process (that's why I assume the build was succesfull), so I decided to test the libraries and just took one of the examples form the site. Compiled it and got the: "fatal error C1083: Cannot open include file: 'boost/filesystem/operations.hpp': No such file or directory" #include "boost/filesystem/operations.hpp" #include "boost/filesystem/path.hpp" #include <iostream> namespace fs = boost::filesystem; int main( int argc, char* argv[] ) { //removed for brevity... } I also added the path to the environmental variables in windows, under INCLUDE and LIB, but this didn't seem to change anything. Can anyone help me understand why the compiler doesn't find the headers? What am I missing? Thank you in advance for your help... Chris PS. I am really sorry for the newbie question....

2 1

Problems with conditions in boost::thread
by Andreas Pokorny 27 Jun '04

27 Jun '04

Hi, I just started to use boost::thread in a bigger application. Since the condition variables do not work as expected - e.g. the waiting thread never wakes up ( example can be found here: http://svn.zynot.org/svn/zynot/projects/xeta/trunk/source/src/xeta/curl.cpp ) - I started writing a smaller test case to see if I use the library correctly. That little test application works fine if I run it in with the gnu debugger, and if I have debugging symbols in my glibc. In all other cases the process gets terminated before any debuging print outs show up or the debugger fails to run the application: #include <list> #include <iostream> #include <boost/bind.hpp> #include <boost/thread/xtime.hpp> #include <boost/thread/thread.hpp> using namespace boost; struct Mini { bool running; thread worker; mutex list_mutex; condition items_empty; std::list<std::string> items; typedef mutex::scoped_lock lock; Mini(); ~Mini(); void run(); void add( std::string const& item); }; Mini::Mini() : worker( bind( &Mini::run, this ) ) { } Mini::~Mini() { running = false; { lock the_list( list_mutex ); items_empty.notify_one(); } worker.join(); } void Mini::run() { running = true; while( running ) { lock the_list( list_mutex ); if( running && items.empty() ) { std::cout << "Waiting for item" << std::endl; items_empty.wait( the_list ); std::cout << "Continue" << std::endl; } std::cout << "Removing :" << items.front() << std::endl; items.pop_front(); } } void Mini::add( std::string const& item ) { lock list_access( list_mutex ); std::cout << "Adding :" << item << std::endl; items.push_back( item ); std::cout << "Notifying other thread" << std::endl; items_empty.notify_one(); } int main() { Mini my_mini; my_mini.add("Once upon a time"); my_mini.add("there was a little mouse"); my_mini.add("that lived in a little house"); xtime xt; xtime_get(&xt, TIME_UTC); xt.sec += 2; thread::sleep(xt); } After that I tried to do it without boost. This time everything works as expected, with and without debugger. #include <list> #include <unistd.h> #include <iostream> #include <pthread.h> struct Mini { bool running; pthread_t worker; pthread_mutex_t mutex; pthread_cond_t not_empty; std::list<std::string> items; Mini(); ~Mini(); static void * call_run( void *); void run(); void add( std::string const& item); }; void* Mini::call_run( void * ptr) { static_cast<Mini*>(ptr)->run(); return 0; } Mini::Mini() { pthread_mutex_t temp_mut = PTHREAD_MUTEX_INITIALIZER; mutex = temp_mut; pthread_cond_t temp_cond = PTHREAD_COND_INITIALIZER; not_empty = temp_cond; worker = pthread_create( &worker, 0, Mini::call_run, this ); } Mini::~Mini() { running = false; { pthread_mutex_lock( &mutex ); pthread_cond_broadcast( &not_empty ); pthread_mutex_unlock( &mutex ); } pthread_join( worker, 0 ); pthread_cond_destroy( &not_empty ); } void Mini::run() { running = true; while( running ) { pthread_mutex_lock( & mutex ); if( running && items.empty() ) { std::cout << "Waiting for item" << std::endl; pthread_cond_wait(&not_empty, &mutex); std::cout << "Continue" << std::endl; } std::cout << "Removing :" << items.front() << std::endl; items.pop_front(); pthread_mutex_unlock( &mutex ); } } void Mini::add( std::string const& item ) { pthread_mutex_lock( & mutex ); std::cout << "Adding :" << item << std::endl; items.push_back( item ); std::cout << "Notifying other thread" << std::endl; pthread_cond_broadcast(& not_empty); pthread_mutex_unlock( &mutex ); } int main() { Mini my_mini; my_mini.add("Once upon a time"); my_mini.add("there was a little mouse"); my_mini.add("that lived in a little house"); sleep(2 ); } Any ideas?

2 2

Autolinking problem on Intel (Win32) with STLport
by Doug Gregor 26 Jun '04

26 Jun '04

It looks like there is a problem with autolinking as mentioned in the subject. It looks like a library naming issue: http://tinyurl.com/2djmv Doug

2 2

How to use boost::thread::condition
by Andreas Pokorny 26 Jun '04

26 Jun '04

Hi, I have problems understanding how mutexes, scoped locks and conditions should work togehter. I took the condition.cpp example and with the buffered shared by two threads as a basis of my code: http://svn.zynot.org/svn/zynot/projects/xeta/trunk/source/src/xeta/curl.cpp There is a list filled by one thread, and a thread that removes the entries after they have been downloaded using curl. The worker-thread waits for a jobs_empty condition and the insertion method calls notify_one after every insertion. Currently the worker-thread just prints "Sitting and waiting", and never reacts on any calls of notifiy_one(). Regards Andreas Pokorny

1 1

BOOST_WORKAROUND in test files?
by Gennaro Prota 26 Jun '04

26 Jun '04

Hi, is it allowed/OK to use BOOST_WORKAROUND in the boost test files? Or should we simply use #if/#ifdef? For instance, Codewarrior 8.3 for Windows has some problems in parsing a function template in dyn_bitset_unit_tests4.cpp. A simple fix, suggested by Howard, is: #ifdef __MWERKS__ // will be: __MWERKS__ && __MWERKS__ <= xxx #pragma parse_func_templ off #endif Should this use BOOST_WORKAROUND? In general: What should compiler/library vendors see when they define BOOST_STRICT_CONFIG? Just errors in the boost headers or errors in the test files too? -- Genny.

2 1

intrusive_ptr: proposal for common base class
by Stefan Slapeta 26 Jun '04

26 Jun '04

Hi all, Sorry if this has been discussed yet, but I think there is an obvious pattern in the usage of intrusive_ptr which should be exposed as common functionality in boost. In most of the cases you just want to handle a simple reference count and delete the object which is held by the intrusive_ptr when the reference count is decreased to zero. It's very annoying that you currently have to write external add_ref/release functions for every class you want to use with this smart pointer. Additionaly, it makes the code unreadable. That's why I would like to suggest having a base class which provides the simplest functionality a user could expect from intrusive_ptr: handling the reference count and deleting the object. A class which should be maintained by intrusive_ptr can derive from it and would not have to provide any further interfaces. I'm not glad about the class name 'intrusive_ptr_base' but I don't have any good ideas at the moment :( Awaiting you comments! (code: see below) Stefan namespace boost { class intrusive_ptr_base; void intrusive_ptr_add_ref(intrusive_ptr_base*); void intrusive_ptr_release(intrusive_ptr_base*); class intrusive_ptr_base { friend void intrusive_ptr_add_ref(intrusive_ptr_base*); friend void intrusive_ptr_release(intrusive_ptr_base*); int ref_count__; protected: intrusive_ptr_base() : ref_count__(0) {} virtual ~intrusive_ptr_base() {} }; inline void intrusive_ptr_add_ref(intrusive_ptr_base* o) { ++o->ref_count__; } inline void intrusive_ptr_release(intrusive_ptr_base* o) { if (--o->ref_count__ == 0) { delete o; } } } // namespace

2 2

Hmmm.. how do I add a new test to the regressions?
by Fernando Cacciola 26 Jun '04

26 Jun '04

I forgot it.... I need to add the Numeric Conversions Library so I can start hunting compiler problems. Fernando Cacciola SciSoft

2 1

RE: Boost.Threads proposed change: lock constructors
by Batov, Vladimir 25 Jun '04

25 Jun '04

Mike, With all due respect I am not sure that the additional complexity you are proposing is justified. It appears that the differences in lock and try_lock default constructors' behavior are consistent with other libraries and actually feel intuitive and natural to me. After all, it is reflected in what I do -- with lock I try until I succeed (that is [Batov, Vladimir] the lock blocks until succeeds), with try_lock I try once and may fail (that is it unconditionally falls through for me to check the result). Best, V. Date: Thu, 24 Jun 2004 14:14:02 -0400 From: Michael Glassford <glassfordm(a)hotmail.com> Subject: [boost] Boost.Threads proposed change: lock constructors To: boost(a)lists.boost.org Message-ID: <cbf5as$hvv$1(a)sea.gmane.org> Content-Type: text/plain; charset=us-ascii; format=flowed Below I detail proposed changes to the Boost.Threads lock class constructors. Comments? Questions? Mike ----------------------------------------------------------------- The Boost.Threads lock concept constructors are currently defined as follows: Definitions ----------- L: lock type l: lock variable (type L) m: mutex variable (appropriate Mutex type) s: initial lock state (type bool, true=locked, false=unlocked) Lock Concept ------------ L l(m,s) //Blocking lock if s L l(m) //Blocking lock TryLock Concept --------------- L l(m,s) //Blocking lock if s L l(m) //Non-blocking lock TimedLock Concept ----------------- L l(m,s) //Blocking lock if s L l(m,t) //Blocking lock, failing if not obtained by time t These definitions have the following drawbacks: 1) That one of the TryLock constructors blocks while the other doesn't is neither obvious nor very consistent. 2) That the single-parameter constructor of Lock blocks while the single-parameter constructor of TryLock doesn't is neither obvious nor very consistent. 3) Part of the reason for the above inconsistencies is that it's not clear whether the constructors of TryLock should block or not. 4) The TimedLock constructors have no way to request a non-blocking lock. To address these problems, I would like to redefine the lock concept constructors as follows (changes indicated with "^"): Definitions ----------- L: lock type l: lock variable (type L) m: mutex variable (appropriate Mutex type) s: initial lock state (enum type {NO_LOCK=0, LOCK=1}) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ b: block? (enum type blocking_state {NON_BLOCKING=0, BLOCKING=1}) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Lock Concept ------------ L l(m,s) //Blocking lock if s L l(m) //Blocking lock TryLock Concept --------------- L l(m,s,b) //Lock if s; blocking if b ^ ^^^^^^^^^^^^^ L l(m,b) //Lock; blocking if b ^ ^^^^^^^^^^^^^ TimedLock Concept ----------------- L l(m,s,b) //Lock if s; blocking if b ^ ^^^^^^^^^^^^^ L l(m,t) //Blocking lock, failing if not obtained by time t Note: s and b are defined as enums rather than bools to prevent existing code from breaking silently: e.g., if s and b were bools, "TryLock l(m, false)", which currently means "construct a lock object but don't obtain a lock", would change with the new definitions to mean "construct a lock and make a non-blocking attempt to obtain a lock". Also, enums are more explicit than bools. Note: these changes will cause some existing code to break by producing compile errors; the compile errors can be fixed by appropriately adding or changing parameters being passed to the changed TryLock and TimedLock constructors. Mike

2 1

Regression logs oddity
by Gennaro Prota 25 Jun '04

25 Jun '04

Hi everybody, does anyone have hints as to why the Linux regression logs include the first 3 dynamic_bitset test files twice, in two different versions? Example: gcc-3.4.0- linux 3.4.0 ------------------------------------------------------------------- dyn_bitset_unit_tests1 Fail dyn_bitset_unit_tests1 Pass dyn_bitset_unit_tests2 Fail dyn_bitset_unit_tests2 Pass dyn_bitset_unit_tests3 Fail dyn_bitset_unit_tests3 Pass dyn_bitset_unit_tests4 Pass -- Genny.

2 1

dynamic_any campaign?
by fehrin＠t-online.de 25 Jun '04

25 Jun '04

On http://www.cuj.com/boost/ (Boost Corner) the first article is I/O System: dynamic_any campaign by Alexander Nasonov. Is dynamic_any really scheduled for inclusion in boost (1.32 say)? Greetings Franz

3 2

Re:[boost] 1.32 release preparation
by Robert Ramey 25 Jun '04

25 Jun '04

I would very much like to see the serialization library in the 1.32 Release. However, I'm not sure it will be possible to make the posted schedule. I have made all changes to address issues raised in the review. On my personal machine I have passed tests for the compilers VC 7.1 VC 6, gcc 3.3. Borland compiles (almost everything but requires some debug - it will pass most tests) Comeau- compiles everthing - accept for a show stopping problem I've been unable to resolve. My intention has been: a) post version compatible with 1.31 next week. b) build and test against the CVS tree on my computer c) check in In order to do this I need: a) authority to check in b) information on how to mark tests/compilers known to fail. c) I have a couple of questions that I need an expert opinion on. i) the first one is that in order to work, versions for vc 6.0 and borland need to be compiled with spirit 1.61. So the a special environmental variable indicating the directory path where this version of spirit is located on the testing machine. SPIRIT_ROOT. This variable has to be set when serialization libraries are built for these compilers. I should say I'm more than a little bit concerned about changes to mpl and iterators. I'm very much aware of the delays and difficulties associated with the 1.31 release - and it didn't even include this package. So I would like to continue on the path I've established above and we'll see where things stand July 16 when/if you are ready to branch for release. Good Luck ! Robert Ramey

4 4

Random number library
by Oliver Kullmann 25 Jun '04

25 Jun '04

Hi, one of my students tried some time in vain to use the random number generator from the boost library, but he couldn't understand the documentation. I must say, the documentation is not exactly "user-friendly". Here's the problem: Given integers min and max, we want to have a pseudo-random-number generator for random numbers from min, min + 1, ..., max (uniform distribution). The generator should take a seed, and then producing a sequence of pseudo-random numbers (and we should be able to find out about the period of the generator). I couldn't think of anything more basic for a library on random numbers, and so I would expect an example of how to get such a thing in the documentation. (I mean, a real example, complete with code, explanations, and how to use it.) But there's no such a thing, which I find rather strange. We have the concept of a "Uniform Random Number Generator", which looks exactly what we want, but, alas, it seems to be more of a fictitious concept, since no models seem to be provided?!?! So well, let's have a look at "Random Distribution". Only that it needs as input a "Uniform Random Number Generator", and the library does not seem to provide these things?!?! (We have the "Random Number Library Generators", but this library seems to provide only models for the most general concept, the concept of a "Number Generator", but not of a "Uniform Random Number Generator".) Let's ignore this for a moment, and continue our investigations into "Random Distribution". Here are actually some models, most useful for our purpose seems to be "Class template uniform_smallint" and "Class template uniform_int". Now, even if we would know where to get the argument urng from, still we wouldn't know which to choose: The documentation on these class templates is rather cryptic, and additionally asks us to be "wise". Shouldn't this be the job of the library?! Final rescue: "random_demo.cpp". The macros don't enhance readability. But there is an example "Define a uniform random number distribution of integer values between // 1 and 6 inclusive." where I find the text misleading (since we don't define a distribution, which is an assignment of probabilities to certain events, but we define a generator), but looking at the output of the program experiment: roll a die 10 times: 3 3 2 6 6 5 5 6 6 3 it seems to be what we want. So I could copy and past the relevant parts of the program (which is not completely trivial), and I would get close to my goals. If only I would understood the meaning of what I'm doing! Unfortunately, variate_generator.hpp seems to be of some importance, but is not documented. Sigh. --------------------------- My student didn't get to this point, although he is rather good. But there are too many unknowns in the "equation" to solve (starting with the concept of a concept, ...), so the job becomes overwhelming. Now it doesn't look too complicated for me to write a nice explanation for the above problem in a tutorial style, explaining on the way all the concepts and concepts of concepts in the library, and that's what I wanted to kindly request with my e-mail. (And also the rest of the documentation could need a sentence here and there, as mentioned in the above case study.) And, of course, for any example of the best way how to solve the above problem with the library, and explanations how it works, I would be glad! Oliver

4 9

boost::any debug assertion failed in destructor
by Olivier Tristan 25 Jun '04

25 Jun '04

Hi guys, I'm currently trying got use boost::any to create some container with different type and I'm having some trouble with a small exemple. I try this on VC2003, VC2002 and gcc 3.3 Here is my class class A { public: A(unsigned long size) : mSize(size), mBuffer(new boost::any[size]) {} ~A() { delete mBuffer; } private: unsigned long mSize; boost::any *mBuffer; }; int main(void) { A(256); return 0; } and I got an assertion in the destructor of A; Can someone tell me if I did something wrong or if there is some problem is boost::any Thanks, -- Olivier Tristan Ultimate Sound Bank

2 2

[program_options, function] vc7 problem
by Vladimir Prus 25 Jun '04

25 Jun '04

The regression logs show this error message from vc7 http://tinyurl.com/39fgc which says that pointer to function can be converted to boost::function The relevant code is: int stored_value; void notifier(const vector<int>& v) { stored_value = v.front(); } void test_semantic_values() { .... ("int", po::value< vector<int> >()->notifier(notifier)) ; } Where the 'notifier' member function is defines as: typed_value* notifier(function1<void, const T&> f) and in this case, T = vector<int>. Any ideas what I can do to make this work? - Volodya

3 3

The Test Tools Docs, Concept Checking
by Andy Little 25 Jun '04

25 Jun '04

Hi, I have been reading the Test Tools docs. Would it be a good idea to add ConceptChecking to the list of alternative methods of reporting errors, in /test/doc/index.html#introduction ? A recent post on boost alluded to the fact that Concepts (ie What is a concept? ) can be difficult to understand. Well ... ConceptChecks are the medium for pinning down Concepts in C++ code and are probably the most effective means of error reporting at compile time, but are not used as much as they could be. The Boost Test Library would seem to be as good a place as any to promote them, which could help to remove some of the mystery. regards Andy Little

1 0

(no subject)
by Robert Ramey 25 Jun '04

25 Jun '04

BOOST_STATIC_ASSERT - On occasion I find it convenient to use: BOOST_STATIC_ASSERT(false) In templated code that should be unreachable. However, its doesn't work with compilers that are too smart for their own good. In order to make this work I need something like: BOOST_STATIC_ASSERT(boost::false_<T>::value) Where boost::false<T> is a type that yields false for any type T. Am I correct here? Where should such a code snippet be placed? Could it be added to mpl, type_trait or what? Robert Ramey

4 3

Re: [boost] 1.32 release preparation
by Reece Dunn 25 Jun '04

25 Jun '04

Mathew Robertson wrote: > > > To allow the autoconf tools (ie configure) to detect the presence of >the various Boost libs and header file versions, would it be possible to >add a C-linkage function to each libraries' source file(s). This would >allow users to add a configure check which detects if a particular library >instance is installed. For example, we add the following code to each >library instance: > > > > > > extern "C" boost_autoconf() {} > > > > > > This allows autoconf users to add a test to their configure.in script: > > > > > > AC_CHECK_LIB(boost_regex,boost_autoconf,...,[Boost::Regex library >not found]) > > > > I don't see why you need a function with C linkage for this to work. > > The behavior of autoconf depends on the current language specified > > in configure.ac at the point where you call AC_CHECK_LIB. If that >language > > is C++, you should well be able to test for functions with C++ linkage. > > See >http://www.gnu.org/software/autoconf/manual/autoconf-2.57/html_chapter/auto… > >Yeah - thats what I'm trying to do. Specifically, I'm trying to detect if >"libboost_regex..." is installed, so I have the following: > >AC_CHECK_LIB(boost_regex-gcc,<somefunc>,,AC_ERROR([Must have the >Boost::Regex library installed]) > >Now the problem is, 'What do I put in for <somefunc>?' All other C++ >libraries I have used, specifically contain a C-linkage function to allow >configure to detect it. I am not familiar with the autoconf tool, but is it possible to have something like this: // include_test.cpp #include <boost/regex.hpp> int main() { // simple regex use here return( 0 ); } //--end That way, you'd get a compile error if regex.hpp is not found (Boost is not on the system) or a link error if the library is not available (library hasn't been built or configured). I am not sure how this translates to autoconf: have you had a look to see how GCC checks for stdio.h, etc.? Regards, Reece _________________________________________________________________ Express yourself with cool new emoticons http://www.msn.co.uk/specials/myemo

2 1

Boost.Variant concepts and LessThanComparable documentation
by Guillaume Melquiond 25 Jun '04

25 Jun '04

Hi, Looking through the documentation of Boost.Variant (both 1.31 and cvs versions), I see that "variant is itself LessThanComparable if and only if every one of its bounded types meets the requirements of the concept". The documentation directly hyper-links to the concept part of Boost and this concept description explains that "LessThanComparable types must have <, >, <=, and >= operators". Unfortunately, boost::variant implementation only defines operator<. So here we have a contradiction between the implementation and the interface. The same kind of problem arises with operator!= and the EqualityComparable concept. I am not sure what the best solution is: - define the missing operators in boost::variant, - remove any reference to LessThanComparable and EqualityComparable concepts from boost::variant documentation, - correct the concepts so they only speak about operator< and operator==. The last solution corresponds to the way the concepts are defined in the [lib.utilities] part of the C++ standard. But I would rather see the missing operators defined in boost::variant if possible. Regards, Guillaume

2 1

Child processes
by Angus Leeming 25 Jun '04

25 Jun '04

I am in the process of writing a little library to control the interaction of a parent program with any child processes that it spawns. Would there be any interest in such a library here? Assuming that there would, please excuse me diving in at the deep end. I'm currently mulling over how best to ensure that system resources are cleaned up automatically when the child exits and would value some advice. Under unix, I've defined a handler for SIGCHLD signals. The handler does two things only: * reaps the zombie * stores the return status in a std::map<pid_t, int> completed_children; variable. Each time a new child is spawned, the pid of the child process is registered in the map, so the handler needs do nothing other than find the entry. namespace { std::map<pid_t, int> completed_children; int status; sig_atomic_t pid; } extern "C" void child_handler(int) { pid = wait(&status); std::map<pid_t, int>::iterator it = completed_children.find(pid); if (it != completed_children.end()) it->second = status; } I'm pretty sure that the above is safe code. It does the absolute minimum in the handler routine. wait() is guaranteed to be async-safe. Moreover, the handler receives only SIGCHLD signals and so cannot receive multiple calls simultaneaously. However, I'm unsure whether it Ok to search the map like this. Any advice? My one other worry is that the SIGCHLD handler could be redefined elsewhere in the code, but AFAICS there's nothing that I can do about that. Furthermore, it means only that the user of my Child library won't be able to ascertain the exit status of child processes launched using it. (If the zombie is reaped elsewhere then a subsequent call to waitpid(pid, &status, WNOHANG); will result in errno being set to ECHILD. Ie, I'll know that the child process has ended but just won't know its exit status.) Under windows, I'm proposing to use a separate thread to wait() for each child process. This seems to be the standard way of dealing with the problem, but I'm a total novice when it comes to Windows programming so know only what I've read. Again, any advice would be greatly appreciated. Regards, Angus

9 24

[1.32 Plan] uBLAS preperation
by Michael Stevens 24 Jun '04

24 Jun '04

Hi Aleksey, Thanks for the clear plan. The current status of uBLAS is that it has been relatively untouched in the Boost CVS single 1.30.0. The active development takes place on a separate CVS. Therefore now would be a good time to bring in the latest code which as some quite significant improvements. The code is relatively stable and tested on core compilers. Issues: On exotic (old) compiler the code is relatively untested and expected to fail. Therefore the real need with regard to 1.32 is to get feedback from extensive regression testing results in good time. As ever the documentation could do with further work to bring it up to date with the to be release version. Thanks, Michael ___________________________________ Michael Stevens Systems Engineering 34128 Kassel, Germany Phone/Fax: +49 561 5218038 Navigation Systems, Estimation and Bayesian Filtering http://bayesclasses.sf.net ___________________________________

2 1

Numeric Conversions Library added to CVS
by Fernando Cacciola 24 Jun '04

24 Jun '04

Hi All, In preparation for the upcoming 1.32 release I added this library to CVS. The code and docs have been changed according to the extensive review results. I still need to extend the documentation adding examples and motivating cases though, which I plan to do before the release. I haven't yet changed "boost/cast.hpp" to use the new stuff, I will as soon as I see the code stablilized among different compilers. In the meantime, new users can use "boost/numeric/conversion/cast.hpp" which contains the new version of numeric_cast<> Best Fernando Cacciola SciSoft

2 1

RE: [boost] (no subject)
by Michiel Salters 24 Jun '04

24 Jun '04

Would BOOST_STATIC_ASSERT( (T*) 0 ) work for you ? Regards, Michiel Salters. > -----Original Message----- > From: boost-bounces(a)lists.boost.org > [mailto:boost-bounces@lists.boost.org]On Behalf Of Robert Ramey > Sent: donderdag 3 juni 2004 22:29 > To: boost(a)lists.boost.org > Subject: [boost] (no subject) > > > BOOST_STATIC_ASSERT - > > On occasion I find it convenient to use: > > BOOST_STATIC_ASSERT(false) > > In templated code that should be unreachable. However, its > doesn't work > with compilers that are too smart for their own good. In > order to make this > work I need something like: > > BOOST_STATIC_ASSERT(boost::false_<T>::value) > > Where boost::false<T> is a type that yields false for any type T. > > Am I correct here? Where should such a code snippet be > placed? Could it be > added to mpl, type_trait or what? > > Robert Ramey > > > > _______________________________________________ > Unsubscribe & other changes: > http://lists.boost.org/mailman/listinfo.cgi/boost > This e-mail and any attachment is for authorised use by the intended recipient(s) only. It may contain proprietary material, confidential information and/or be subject to legal privilege. It should not be copied, disclosed to, retained or used by, any other party. If you are not an intended recipient then please promptly delete this e-mail and any attachment and all copies and inform the sender. Thank you.

1 0

Any scheduled date for Boost 1.32?
by Joaquín Mª López Muñoz 24 Jun '04

24 Jun '04

Aleksey talked about June 28th: http://lists.boost.org/MailArchives/boost/msg62871.php but seems like there has been no activity wrt to releasing Boost 1.32 since. Is that date still valid? I guess it is not, for the one week remaining is probably to little time to arrange everything. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

7 7

Boost.Python / Graph library problem after cvs update
by Ralf W. Grosse-Kunstleve 24 Jun '04

24 Jun '04

With the latest Boost CVS compilation of boost/libs/python/src/object/inheritance.cpp with the old IRIX MIPSpro compiler (EDG 238) fails for this code in boost/boost/graph/properties.hpp: namespace detail { template<typename VertexBundle, typename EdgeBundle> type_traits::yes_type is_vertex_bundle_helper(VertexBundle*); template<typename VertexBundle, typename EdgeBundle> type_traits::no_type is_vertex_bundle_helper(EdgeBundle*); template<typename VertexBundle, typename EdgeBundle, typename Bundle> struct is_vertex_bundle { BOOST_STATIC_CONSTANT(bool, value = ((sizeof(is_vertex_bundle_helper<VertexBundle, EdgeBundle>((Bundle*)0)) == sizeof(type_traits::yes_type)))); }; } The error is: cc-1278 CC: ERROR File = /txusr/rwgrosse/hot/boost/boost/graph/properties.hpp, Line = 363 No instance of overloaded function "boost::detail::is_vertex_bundle_helper" matches the argument list. The argument types are: (Bundle *). BOOST_STATIC_CONSTANT(bool, value = ((sizeof(is_vertex_bundle_helper<VertexBundle, EdgeBundle>((Bundle*)0)) ^ I tried to rearrange the code a bit: namespace detail { template<typename VertexBundle, typename EdgeBundle> struct is_vertex_bundle_helper { static type_traits::yes_type get(VertexBundle*); static type_traits::no_type get(EdgeBundle*); }; template<typename VertexBundle, typename EdgeBundle, typename Bundle> struct is_vertex_bundle { typedef is_vertex_bundle_helper<VertexBundle, EdgeBundle> helper_t; BOOST_STATIC_CONSTANT(bool, value = ((sizeof(helper_t::get((Bundle*)0)) == sizeof(type_traits::yes_type)))); }; } This still compiles with other compilers (gcc 3.4 and EDG 245), but not with the old EDG 238: cc-1108 CC: ERROR File = /txusr/rwgrosse/hot/boost/boost/graph/properties.hpp, Line = 368 The indicated expression must have pointer-to-function type. BOOST_STATIC_CONSTANT(bool, value = ((sizeof(helper_t::get((Bundle*)0)) == sizeof(type_traits::yes_type)))); ^ It doesn't even compile if I simplify the code like this: cc-1108 CC: ERROR File = /txusr/rwgrosse/hot/boost/boost/graph/properties.hpp, Line = 371 The indicated expression must have pointer-to-function type. static const std::size_t value1 = sizeof(helper_t::get((Bundle*)0)); ^ 1 error detected in the compilation of "/txusr/rwgrosse/hot/boost/libs/python/sr I am lost here. Suggestions for workarounds are very much appreciated. It used to compile with the CVS from a couple of days ago. It is important to us to get the IRIX build working again. Thanks in advance, Ralf P.S.: inheritance.cpp compiles if I simply set BOOST_STATIC_CONSTANT(bool, value = false); Therefore I was hopeful that the problem can be fixed by rearranging the code fragments shown above. __________________________________ Do you Yahoo!? Yahoo! Mail - 50x more storage than other providers! http://promotions.yahoo.com/new_mail

3 5

Boost.Threads inconsistency question
by Michael Glassford 23 Jun '04

23 Jun '04

The Boost.Threads documentation states that the ScopedTimedLock concept is a refinement of the ScopedTryLock concept; however, the boost::timed_mutex::scoped_timed_lock class, which is supposed to be a model of the ScopedTimedLock concept, doesn't define the various try_* methods. In your opinion, should the documentation be changed to state that the ScopedTimedLock concept is a refinement of the ScopedLock (rather than ScopedTryLock) concept, or should the boost::timed_mutex::scoped_timed_lock class implement the various try_* methods? (FYI: a similar situation applies to boost::recursive_timed_mutex::scoped_timed_lock and boost::timed_read_write_mutex::scoped_timed_lock). Mike

2 3

problem with boost::thread
by Janusz Piwowarski 23 Jun '04

23 Jun '04

Hello. After latest cvs update, i've got errors like: gcc-C++-action bin\boost\libs\thread\build\boost_thread.dll\mingw\debug\threading-multi\con dition.obj In file included from d:/sources/boost/libs/thread/src/condition.cpp:18: d:/sources/boost/libs/thread/src/timeconv.inl: In function `void <unnamed>::to_time(int, boost::xtime&)': d:/sources/boost/libs/thread/src/timeconv.inl:24: error: template-argument ` boost::<anonymous enum>' uses anonymous type d:/sources/boost/libs/thread/src/timeconv.inl: In function `void <unnamed>::to_duration(boost::xtime, int&)': d:/sources/boost/libs/thread/src/timeconv.inl:92: error: template-argument ` boost::<anonymous enum>' uses anonymous type d:/sources/boost/libs/thread/src/timeconv.inl: In function `void <unnamed>::to_microduration(const boost::xtime&, int&)': d:/sources/boost/libs/thread/src/timeconv.inl:114: error: template-argument ` boost::<anonymous enum>' uses anonymous type "g++" -c -Wall -ftemplate-depth-100 -DBOOST_THREAD_BUILD_DLL=1 -g -O0 -f no-inline -mthreads -mthreads -mno-cygwin -I"bin\boost\libs\thread\build" -I"d:\sources\boost" -o "bin\boost\libs\thread\build\boost_thread.dll\mingw\debug\threading-multi\co ndition.obj" "d:\sources\boost\libs\thread\build\../src/condition.cpp" Error lines in timeconv.inl file contains: assert(res == boost::TIME_UTC) where res is int, and boost::TIME_UTC is enum. When i changed it to assert(res == static_cast<int>(boost::TIME_UTC)); it starts to compile. But I don't understand what's happend, there aren't changes in boost::thread. Any ideas? WinXP, mingw 3.3.1 Regards, Janusz

3 5

shared_ptr with dynamic_cast
by Yuval Ronen 23 Jun '04

23 Jun '04

Hi, I'm new to boost, so this post might seem silly to some of you, and I apologize if this is the case. I have a tiny performance suggestion: The c'tor template<class Y> shared_ptr(shared_ptr<Y> const & r, detail::dynamic_cast_tag): px(dynamic_cast<element_type *>(r.px)), pn(r.pn) { if(px == 0) // need to allocate new counter -- the cast failed { pn = detail::shared_count(); } } should be changed to: template<class Y> shared_ptr(shared_ptr<Y> const & r, detail::dynamic_cast_tag): px(dynamic_cast<element_type *>(r.px)), pn(px ? r.pn : detail::shared_count()) { } The difference is when the dynamic_cast fails and returns NULL. In such cases the existing code copies the shared_count object, including mutex locking, only to discover later that it was unnecessary (the 'if(px == 0)' statement). The suggested code saves this copy of the shared_count object, which also saves some mutex lockings. Hope I'm not talking nonsense, Yuval

2 1

min/max, reloaded
by Eric Niebler 23 Jun '04

23 Jun '04

I have ripped out the std_min/std_max functions. They were a less-than-perfect solution to the problems caused by the min/max macros defined by some platform headers. I have fixed all the places in the Boost affected by this change, and I have also updated the coding guidelines. For your references, the guidelines are reproduced here: Make sure your code compiles in the presence of the min() and max() macros. Some platform headers define min() and max() macros which cause some common C++ constructs to fail to compile. Some simple tricks can protect your code from inappropriate macro substitution: If you want to call std::min() or std::max(): If you do not require argument-dependent look-up, use (std::min)(a,b). If you do require argument-dependent look-up, you should: #include <boost/minmax.hpp> Use BOOST_USING_STD_MIN(); to bring std::min() into the current scope. Use min BOOST_PREVENT_MACRO_SUBSTITUTION (a,b); to make an argument-dependent call to min(a,b). If you want to call std::numeric_limits<int>::max(), use (std::numeric_limits<int>::max)() instead. If you want to call a min() or max() member function, instead to doing obj.min(), use (obj.min)(). If you want to declare or define a function or a member function named min or max, then you must use the BOOST_PREVENT_MACRO_SUBSTITUTION macro. Instead of writing int min() { return 0; } you should write int min BOOST_PREVENT_MACRO_SUBSTITUTION () { return 0; } This is true regardless if the function is a free (namespace scope) function, a member function or a static member function, and it applies for the function declaration as well as the function definition. Thanks. -- Eric Niebler Boost Consulting www.boost-consulting.com

3 4

Boost.Config defect macro proposal
by Joaquín Mª López Muñoz 23 Jun '04

23 Jun '04

Some months ago I proposed to include a defect macro to detect some defficiencies by several compilers regarding the ability to handle pointers to data members as template parameters. The name we came up with is BOOST_NO_POINTER_TO_MEMBER_TEMPLATE_PARAMETERS I include a little test case that successfully detects the bug in three out of the four compilers checked to show the problem * MSVC 6.5 (MSKB article ##249045), * MSVC 7.0 (***) * ICC 7.0/7.1 for Windows (support issue #207321), * VisualAge 6.0 for AIX (internal defect #288539.) The compiler marked with (***) does fail with the test, but only under certain compiler settings that I've not been able to isolate properly. When last discussed, it was argued that a new defect macro would only make sense if some lib needed it: now Boost.MultiIndex can take advantage of it (actually, the lib assumes the macro even if not currently supported by Boost.Config), and the problem has turned out to be more prevalent than the original MSVC-constrained case hinted at. Is it OK to add this to Boost.Config? Comment? Thank you, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo *** BEGIN TEST CODE*** #include <iostream> struct pair { int x,y; pair(int x_,int y_):x(x_),y(y_){} }; template<int pair::* PtrToPairMember> struct foo { int bar(pair& p){return p.*PtrToPairMember;} }; int main() { pair p(0,1); foo<&pair::x> fx; foo<&pair::y> fy; if(fx.bar(p)!=0||fy.bar(p)!=1)std::cout<<"KO"<<std::endl; else std::cout<<"OK"<<std::endl; return 0; } ***END TEST CODE***

4 5

Generalized Iterator Ranges
by Dale Muchow 23 Jun '04

23 Jun '04

Here is a paper I wrote discussing the notion of generalizing an iterator defined range. It includes the proposal and definition of a new concept, Range. It was written as a masters research paper for graduate work I did at North Dakota State University. http://www.lycanth.com/dmuchow/GeneralizedIteratorRanges.doc.zip _________________________________________________________________ >From will you? to I do, MSN Life Events is your resource for Getting Married. http://lifeevents.msn.com/category.aspx?cid=married

2 1

[Graph] Bundled properties, take 2
by Douglas Paul Gregor 23 Jun '04

23 Jun '04

Good evening, I've just checked in version 2 of the "bundled properties" patch for the BGL, which allows one to stick various vertex/edge properties into a class to be stored within adjacency_list/adjacency_matrix. Accessing these properties is easier and more convenient. This patch completes support for bundled properties. Both of the major graph types are supported, bundled properties play nice with other property maps (get/put support added), and bundled properties work with graph adaptors. The documentation now strongly urges users to adopt bundled properties instead of property lists :) Doug

2 1

RE: [boost] Child processes
by Glen Knowles 23 Jun '04

23 Jun '04

> I don't know how java deals with this but on posix platforms > a sub-process holds some resources that have to be claimed > back by the parent process. > This includes (but is not restricted to) the result of the > process, i.e. > its return value. In case you are familiar with (posix) > threads: there you have to join a thread after it terminated. > It's conceptually the same thing here. > If you find yourself joining posix's threads only for this reason you should consider setting the detachstate attribute to PTHREAD_CREATE_DETACHED instead. Glen

1 0

RE: [boost] Re: static sized strings
by Reece Dunn 22 Jun '04

22 Jun '04

John Nagle wrote: >Reece Dunn wrote: >>John Nagle wrote: >>The problems arise in the interation with basic_string_impl and how to >>implement swap and functions that require constructing a string object. >Why do you need to construct a string object to swap? >Just swap one character at a time. There were 3 things I was cxonsidering when moving to the non-virtual implementation: [1] How do I pass the buffer and capacity to the implementation while allowing both fixed_string_base and fixed_string access to the basic_string interface? I have chosen to route the data through one of the basic_string constructors, requiring a const_cast. This is the best approach AFAICS. [2] How do I implement the swap function? The solution I arrived at is the one you suggest: to swap the data character-by-character. What you have to consider when doing this is that the strings don't exceed capacity, resulting in additional logic. [3] How do I approach the substr function and the + operators? Although it is now possible to construct a fixed_string_base object from a fixed_string object, you will run into problems when constructing from a temporary (because the fixed_string temporary will have been destroyed, invalidating the buffer). Given this, the implementation of these functions are still in fixed_string and thus not accessible to [w]char_string. I have replaced the old implementation with this one in the sandbox if you want to take a look. Also, feel free to adapt it to your version if you want. Regards, Reece _________________________________________________________________ It's fast, it's easy and it's free. Get MSN Messenger today! http://www.msn.co.uk/messenger

2 2

Re: [boost] Re: static sized strings
by Reece Dunn 22 Jun '04

22 Jun '04

Rob Stewart wrote: >From: "Reece Dunn" > > John Nagle wrote: > > >Reece Dunn wrote: > > >>John Nagle wrote: > > >>The problems arise in the interation with basic_string_impl and how to > > >>implement swap and functions that require constructing a string >object. > > >Why do you need to construct a string object to swap? > > >Just swap one character at a time. > > > > [2] How do I implement the swap function? The solution I arrived at is >the > > one you suggest: to swap the data character-by-character. What you have >to > >Unfortunately, that makes swap() O(N), but it does allow it to be >nothrow. Unfortunately. To swap the impl members would make it O(1), but would lead to unpredictable behaviour since the two strings swap pointers to their fixed_string buffers. The approach I use is the best I could find. > > consider when doing this is that the strings don't exceed capacity, > > resulting in additional logic. > >That should fail, shouldn't it? Yes, that would mean a swap() >that throws, but the strings aren't really swapped if you only >swap some characters. The same is true though of all the other functions (e.g. assign): what happens if the string doesn't fit? >I'm not sure which is worse: a swap() that throws or only >partially swapping. The former violates exception safety >guarantee assumptions made by other code, but the latter means >that swap() may not really swap, which violates semantics. I have gone for a clip to capacity design for all the fixed_string functions. Thus: fixed_string< 5 > str; str.assign( "Hello there!" ); // str == "Hello" Any error handling policy that is implemented has it's own advantages and disadvantages. Another problem with using exceptions is adapting C code: there may not be any try-catch blocks in the code, resulting in unhandled exceptions. The clip strategy is not ideal either, but I believe it is the best approach considering the code it is abstracting: you will usually have a buffer large enough for the application you are using it for (filenames/paths, command line strings, URLs, etc.) One possibility is making the error handling a policy class so it can be adapted to suit the users needs with the current behaviour as default. Regards, Reece _________________________________________________________________ It's fast, it's easy and it's free. Get MSN Messenger today! http://www.msn.co.uk/messenger

2 1

RE: [boost] [test] [minmax] failure on gcc 2.95
by Rozental, Gennadiy 21 Jun '04

21 Jun '04

> As shown in http://tinyurl.com/3xdyq, > Boost.Test fails to build on gcc 2.95 with stlport. The error > message is: > > /boost/head-regression/boost/boost/minmax.hpp: In function > `const size_t & boost::std_min<size_t>(const size_t &, const > size_t &)': > > /boost/head-regression/boost/libs/test/build/../src/test_tools > .cpp:375: instantiated from here > /boost/head-regression/boost/boost/minmax.hpp:26: `min' > undeclared (first use this function) > > Is it possible that authors of either Boost.Test or > boost/minmax.hpp take care of this error? I'd prefer it to be addressed on minmax.hpp level. After all it's the header responsible for min and max. Gennadiy.

3 3

Typo in boost/graph/properties.hpp
by Janusz Piwowarski 20 Jun '04

20 Jun '04

Hello, I'm attaching patch, as in subject. Also, there isn't undefined variable x in boost/graph/graph_test.hpp (test_readable_vertex_property_graph and test_vertex_property_graph templates). I have no idea what it is. Regards, Janusz

2 1

threads
by val salamakha 20 Jun '04

20 Jun '04

Dear William E. Kempf, I installed the latest version of the boost-1.31.0 on Win xp pro with vc7.1 and tried to use the thread library. During the first build of several samples, MSVS(vc71) gave me a warning about the errors. However I ignored the errors and select option to proceed(the same result is in other case). It seems to me the samples work correctly in spite of errors and warning located below my message. I had no warning or errors on the next build of the same sample at all. Would you please tell me what is going on? And how do I fix it? Thanks Valery Salamakha VC71_ROOT\include\stdexcept(14): see declaration of 'std::logic_error' c:\Boost\include\boost-1_31\boost\thread\exceptions.hpp(28) : see declaration of 'boost::lock_error' c:\Boost\include\boost-1_31\boost\thread\thread.hpp(78): warning C4251: 'boost::thread_group::m_threads' : class 'std::list<_Ty>' needs to have dll-interface to be used by clients of class 'boost::thread_group' with [ _Ty=boost::thread * ] c:\Boost\include\boost-1_31\boost\thread\mutex.hpp(36): warning C4275: non dll-interface class 'boost::noncopyable' used as base for dll-interface class 'boost::mutex' c:\Boost\include\boost-1_31\boost\noncopyable.hpp(22) : see declaration of 'boost::noncopyable' c:\Boost\include\boost-1_31\boost\thread\mutex.hpp(35) : see declaration of 'boost::mutex' c:\Boost\include\boost-1_31\boost\thread\thread.hpp(38): warning C4275: non dll-interface class 'boost::noncopyable' used as base for dll-interface class 'boost::thread' c:\Boost\include\boost-1_31\boost\thread\thread.hpp(67): warning C4275: non dll-interface class 'boost::noncopyable' used as base for dll-interface class 'boost::thread_group' c:\Boost\include\boost-1_31\boost\noncopyable.hpp(22) : see declaration of 'boost::noncopyable' c:\Boost\include\boost-1_31\boost\thread\mutex.hpp(114): warning C4275: non dll-interface class 'boost::noncopyable' used as base for dll-interface class 'boost::timed_mutex' c:\Boost\include\boost-1_31\boost\noncopyable.hpp(22) : see declaration of 'boost::noncopyable' c:\Boost\include\boost-1_31\boost\thread\mutex.hpp(113) : see declaration of 'boost::timed_mutex' c:\Boost\include\boost-1_31\boost\thread\mutex.hpp(74): warning C4275: non dll-interface class 'boost::noncopyable' used as base for dll-interface class 'boost::try_mutex' c:\Boost\include\boost-1_31\boost\noncopyable.hpp(22) : see declaration of 'boost::noncopyable' c:\Boost\include\boost-1_31\boost\thread\mutex.hpp(73) : see declaration of 'boost::try_mutex' c:\Boost\include\boost-1_31\boost\thread\exceptions.hpp(29): warning C4275: non dll-interface class 'std::logic_error' used as base for dll-interface class 'boost::lock_error' c:\Boost\include\boost-1_31\boost\thread\exceptions.hpp(35): warning C4275: non dll-interface class 'std::runtime_error' used as base for dll-interface class 'boost::thread_resource_error' c:\Program Files\Microsoft Visual Studio .NET 2003\Vc7\include\stdexcept(136) : see declaration of 'std::runtime_error' c:\Boost\include\boost-1_31\boost\thread\exceptions.hpp(34) : see declaration of 'boost::thread_resource_error' __________________________________ Do you Yahoo!? Yahoo! Mail - Helps protect you from nasty viruses. http://promotions.yahoo.com/new_mail

5 10

RE: [boost] Re: static sized strings (struct hack)
by Reece Dunn 20 Jun '04

20 Jun '04

John Nagle wrote: >Reece Dunn wrote: >>John Nagle wrote: >>> I think we're back to using an abstract base class. >>>The hacks to get around it introduce worse problems. >>I would agree. I have been trying to find a way around the problem and >>have (sortof) by having a base class: >> >> template< typename CharT > >> class string_base >> { >> private: >> size_t len, cap; // length & capacity >> CharT * buf; // data buffer >> public: >> string_base( CharT * b, size_t c, size_t l ): >> len( l ), cap( c ), buf( b ){} >> // non-virtual implementation >> }; >> >> template< size_t n, typename CharT > >> class fixed_string: public string_base >> { >> private: >> CharT data[ n + 1 ]; >> public: >> fixed_string(): string_base( data, n + 1 ){} >> }; >That's a much better approach than the previous one. >It's sound C++, and it's simple. >All the operations go in string_base. fixed_string >need only allocate space. Where do you hit a problem? The problems arise in the interation with basic_string_impl and how to implement swap and functions that require constructing a string object. Both string_base and fixed_string must operate through basic_string_impl to allow basic_string operations. I suppose this should be done in a heirarchy similar to the current one, having swap virtual (you don't want to swap internal pointers!) and using the current system for the object construction functions, but it may be possible to have substr virtual, I'm not sure yet. I shall have a go at this and report back when I have a working implementation. Regards, Reece _________________________________________________________________ Stay in touch with absent friends - get MSN Messenger http://www.msn.co.uk/messenger

2 1

[Boost-bugs] [ boost-Bugs-976241 ] Compiler error for tokenizer on Solaris
by SourceForge.net 20 Jun '04

20 Jun '04

Bugs item #976241, was opened at 2004-06-20 13:51 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=976241&group_i… Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Tom Aratari (stosys) Assigned to: Nobody/Anonymous (nobody) Summary: Compiler error for tokenizer on Solaris Initial Comment: When trying to upgrade to boost 1_31, Forte 8.0 (CC: Sun C++ 5.5 Patch 113817-03 2003/10/14) gives the following error for the code snip: typedef boost::tokenizer<boost::char_separator<char> > tokenizer; boost::char_separator<char> seperator (sDroppedDelimiters, sKeptDelimiters, boost::keep_empty_tokens); tokenizer tokens( sString, seperator ); for (tokenizer::iterator tok_iter = tokens.begin(); tok_iter != tokens.end(); ++tok_iter) vInVector.push_back( *tok_iter ); Copiler error: "/home/dev/cm/THIRD_PARTY/boost/include/boost/iterat or/iterator_facade.hpp", line 623: Error: Could not find a match for boost::iterator_core_access::equal<boost::iterator_core _access::Facade1, boost::iterator_core_access::Facade2>(const boost::token_iterator<boost::char_separator<char, std::char_traits<char>>, const char*, std::string>, const boost::token_iterator<boost::char_separator<char, std::char_traits<char>>, const char*, std::string>, boost::is_convertible<boost::token_iterator<boost::char _separator<char, std::char_traits<char>>, const char*, std::string>, boost::token_iterator<boost::char_separator<char, std::char_traits<char>>, const char*, std::string>>). "MDSStringHelpers.cxx", line 183: Where: While instantiating "boost::operator! =<boost::token_iterator<boost::char_separator<char, std::char_traits<char>>, const char*, std::string>, std::string,boost::forward_traversal_tag, const std::string &, int, boost::token_iterator<boost::char_separator<char, std::char_traits<char>>, const char*, std::string>, std::string, boost::forward_traversal_tag, const std::string &, int>(const boost::iterator_facade<boost::token_iterator<boost::cha r_separator<char, std::char_traits<char>>, const char*, std::string>, std::string, boost::forward_traversal_tag, const std::string &, int>&, const boost::iterator_facade<boost::token_iterator<boost::cha r_separator<char, std::char_traits<char>>, const char*, std::string>, std::string, boost::forward_traversal_tag, const std::string &, int>&)". "MDSStringHelpers.cxx", line 183: Where: Instantiated from non-template code. Has anyone else complianed about this? Thanks Tom ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=976241&group_i… ------------------------------------------------------- This SF.Net email is sponsored by The 2004 JavaOne(SM) Conference Learn from the experts at JavaOne(SM), Sun's Worldwide Java Developer Conference, June 28 - July 1 at the Moscone Center in San Francisco, CA REGISTER AND SAVE! http://java.sun.com/javaone/sf Priority Code NWMGYKND _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

Another BoostBook/Doxygen bug?
by Angus Leeming 18 Jun '04

18 Jun '04

Is it possible to get the BoostBook/Doxygen documentation system to include my commentary? This is the header file #include <boost/child/detail/pipe_mode.hpp> namespace boost { namespace child { /// A stateless class providing constants and typenames. struct pipes_base { /// A type used to specify how to communciate with the child process. typedef detail::pipe_mode pipe_mode; /// Write to the child's standard input stream. static const pipe_mode child_stdin = pipe_mode(1); /// Read from the child's standard output stream. static const pipe_mode child_stdout = pipe_mode(2); /// Read from the child's standard error stream. static const pipe_mode child_stderr = pipe_mode(4); /// Redirect the child's stderr to its stdout. static const pipe_mode redirect_child_stderr = pipe_mode(8); /// No pipes are to be used. static const pipe_mode no_pipes = pipe_mode(16); }; } // namespace child } // namespace boost And below is the generated documentation. See how all the descriptions of the constants have dissappeared. Also see how the typedef has been 'modified'. Regards, Angus Struct pipes_base boost::child::pipes_base ? A stateless class providing constants and typenames. Synopsis struct pipes_base { // types typedef unspecified pipe_mode; // A type used to specify how to communciate with the child process. static const pipe_mode child_stdin; static const pipe_mode child_stdout; static const pipe_mode child_stderr; static const pipe_mode redirect_child_stderr; static const pipe_mode no_pipes; };

2 3

[Test] Link problems
by David B. Held 18 Jun '04

18 Jun '04

unit_test_log.o: In function `boost::unit_test::unit_test_log::unit_test_log[not-in-charge]()': /usr/include/c++/3.3.2/bits/stl_heap.h:221: undefined reference to `boost::unit_test::ut_detail::msvc65_like_log_formatter::msvc65_like_log_for matter[in-charge] (boost::unit_test::unit_test_log const&)'unit_test_log.o: In function `void std::__adjust_heap<__gnu_cxx::__normal_iterator<std::pair<boost::unit_test:: basic_cstring<char const>, boost::unit_test::output_format>*, std::vector<std::pair<boost::unit_test::basic_cstring<char const>, boost::unit_test::output_format>, std::allocator<std::pair<boost::unit_test::basic_cstring<char const>, boost::unit_test::output_format> > > >, int, std::pair<boost::unit_test::basic_cstring<char const>, boost::unit_test::output_format>, boost::unit_test::fixed_mapping<boost::unit_test::basic_cstring<char const>, boost::unit_test::output_format, boost::unit_test::case_ins_less<char const> >::p2>(__gnu_cxx::__normal_iterator<std::pair<boost::unit_test::basic_cstrin g<char const>, boost::unit_test::output_format>*, std::vector<std::pair<boost::unit_test::basic_cstring<char const>, boost::unit_test::output_format>, std::allocator<std::pair<boost::unit_test::basic_cstring<char const>, boost::unit_test::output_format> > > >, int, int, std::pair<boost::unit_test::basic_cstring<char const>, boost::unit_test::output_format>, boost::unit_test::fixed_mapping<boost::unit_test::basic_cstring<char const>, boost::unit_test::output_format, boost::unit_test::case_ins_less<char const> >::p2)': /usr/include/c++/3.3.2/bits/stl_heap.h:197: undefined reference to `boost::unit_test::ut_detail::msvc65_like_log_formatter::msvc65_like_log_for matter[in-charge] (boost::unit_test::unit_test_log const&)' unit_test_log.o: In function `boost::unit_test::unit_test_log::set_log_format(boost::unit_test::basic_cst ring<char const>)': /usr/local/boost/libs/test/src/unit_test_log.cpp:381: undefined reference to `boost::unit_test::ut_detail::msvc65_like_log_formatter::msvc65_like_log_for matter[in-charge](boost::unit_test::unit_test_log const&)' /usr/local/boost/libs/test/src/unit_test_log.cpp:383: undefined reference to `boost::unit_test::ut_detail::xml_log_formatter::xml_log_formatter[in-charge ](boost::unit_test::unit_test_log const&)' collect2: ld returned 1 exit status Do I need the latest CVS snapshot or what? This worked a few days ago, so I don't know what happened. I'm using the unit test framework. Dave --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com) Version: 6.0.701 / Virus Database: 458 - Release Date: 6/7/2004

2 2

[CVS] Problem
by David B. Held 18 Jun '04

18 Jun '04

cvs update: Updating boost/format/detail cvs update: failed to create lock directory for `/cvsroot/boost/boost/boost/form at/detail' (/cvsroot/boost/boost/boost/format/detail/#cvs.lock): No space left o n device cvs update: failed to obtain dir lock in repository `/cvsroot/boost/boost/boost/ format/detail' cvs [update aborted]: read lock failed - giving up Looks like an SF issue to me. Is this going to get fixed by itself, or should someone send them a note? Dave --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com) Version: 6.0.701 / Virus Database: 458 - Release Date: 6/7/2004

3 2

Re: [boost] program_options with mingw
by Janusz Piwowarski 18 Jun '04

18 Jun '04

Janusz Piwowarski wrote: > BTW, i successfully compile program_options library and examples with > stlport 4.6.2; but my program, where i use boost::thread, don't want to > link. Sorry, i check it now - examples also don't link. Regards, Janusz

2 2

program_options with mingw
by Janusz Piwowarski 18 Jun '04

18 Jun '04

Hello, I attach a patch that allows use of program_options with mingw compiler. There isn't support for utf-8 conversion - maybe it is possible to convert without use of wstring? Regards, Janusz

3 5

Boost.Test
by Jagmohan S Nanaware 18 Jun '04

18 Jun '04

Hi, Is it possible to just carve out Boost.test package separately from entire Boost? regards, Jagmohan

2 1

Documentation
by David B. Held 18 Jun '04

18 Jun '04

Ok, if the Boost style documentation is too simple, and docs like Spirit are too cute, what is a nice, happy median? If we're going to demand uniformity in licensing, should we also demand more uniformity in documentation? I think a single documentation style across Boost would make it even easier to learn new libraries. I recently found it very difficult to find the information I wanted about the Boost.Test library, as well as Boost.Preprocessor. What can be done about these issues? Dave --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com) Version: 6.0.701 / Virus Database: 458 - Release Date: 6/7/2004

8 20

physical quantities
by Andy Little 17 Jun '04

17 Jun '04

The next version of my physical quantities libary pqs-1-01-04 is available on my site at: http://www.servocomm.freeserve.co.uk/Cpp/pqs-1-01-04/download.html The original type has now been augmented by another. The original type has now been renamed as a 'ct-quantity' representing a physical quantity whose units cannot be modified at run-time. The other type is the 'rt-quantity', whose units can be modified at run-time. The two types are of course compatible and the rt-quantity in particular is useful for further derivation, for instance into a physical quantity whose units can be set and interrogated via strings ie "mm, kgf" etc of which there is an example in the examples directory. The first question many will ask about such a library is : "How does the run-time speed/memory performance compare with using inbuilt types?." That is an important question, but to me not the most important one. (The answer is that this is implementation dependent and the current implementation is not optimal) Having used the library for some time its power seems to lie in the fact that it models a concept quite accurately from a programmers point of view. IOW what you can do with the type is restricted (by the compiler) to (some subset of) the entity that it models. The reason that this is powerful is difficult to define, but can be summed up in the saying: " a picture is worth a thousand words" I now see more clearly what those who wanted to see currency conversion and number of apples per kumquat or whatever where driving at. However these are not physical-quantities. C++ does have the ability to express those concepts, but they lie outside the remit of the concept that this library models. Nontheless such concepts would be useful. So in a network model a byte, packet etc would be a concept which would be modelled by a C++ type. Strongly enforcing the rules by which entities interact is satisfying , I guess, because it clarifies the mental picture of a program. Modelling everything by a double or an int (should number_of_bytes_received be convertible to double ... probably not etc) means everything is mush. So on a personal note designing the library has been very rewarding. As I spend much time GUI programming, it strikes me that the next useful concepts are those of model-space, view-space, paper-space etc. Here a point in space would be represented by different types which could only exist in the relevent space, but have the intelligence to perform transforms from one space to another. Similarly where one is modelling (say) magnetic flux density at a point x, y, z , the role of the view-space would be to convert form the entity in model-space to 'some representation ' in the view-space or the paper-space. The obvious candidates for the types in model-space being the ct-quantity of course. regards Andy Little

2 3

Using the Boost license
by Geoff Leyland 17 Jun '04

17 Jun '04

Hi, I have a couple of small libraries I'm "releasing" to a few other people (well, anybody really, but so far only a few). Can I use the BSL on my software even though it's not part of boost? Do I have to make any changes? thanks for your time, Geoff

2 2

RE: [boost] Re: static sized strings (non-virtual implementation)
by Reece Dunn 17 Jun '04

17 Jun '04

John Nagle wrote: >That's a much better approach than the previous one. >It's sound C++, and it's simple. >All the operations go in string_base. fixed_string >need only allocate space. I have now checked in a working implementation of the approach I suggested. It uses a trick to pass the information to the implementation via the basic_string_impl class and has a complicated implementation of swap (non-virtual :)!). The only functions not available to [w]char_string are substr and +, but these are available in fixed_string itself. I have also fixed the problems with fsstring.hpp and Borland, since Borland may make strcpy, etc macro functions to its intrinsic versions (__strcpy__, etc.) Regards, Reece _________________________________________________________________ Want to block unwanted pop-ups? Download the free MSN Toolbar now! http://toolbar.msn.co.uk/

1 0

type_traits for checking derived type
by D-Swat 17 Jun '04

17 Jun '04

Hi, some code: template <typename DerivedT> class A { BOOST_STATIC_ASSERT((boost::is_convertible<A<DerivedT>*, B*>::value)); [...] }; class B : public A { }; I want to check if the template parameter really specifies a derived type. But the assert is always false. How can i solve this? bye

5 5

Re: Boost Digest, Vol 756, Issue 1
by Eric Ford 17 Jun '04

17 Jun '04

> The next version of my physical quantities library pqs-1-01-04 is > available on my site at: > > http://www.servocomm.freeserve.co.uk/Cpp/pqs-1-01-04/download.html > ... Andy, Thank you for your work on this very important area of development. From just quickly looking at the examples, it appears that you choose to use different types for quantities that have the same dimensions but different units. I don't think that is a good idea. You can search the archives for the discussions several of us had about similar issues, mostly a few years ago. If you still disagree, I'd like to hear why. Perhaps, you could summarize the main similarities and difference between your library and other similar libraries. For example, there's Walter Brown's SIUnits, as well as a couple of drafts that have been uploaded to the boost vault. I know I posted ebf_units a while back to give people something to work from. And I believe there were one or two others there as well. Thanks, Eric

2 1

applied patch to boost::tuple
by Toon Knapen 17 Jun '04

17 Jun '04

I just applied the patch below to boost/tuple/detail/tuple_basic.hpp to port it to IBM/VisualAge. I tried to contact Jaako Jarvi but the email address listed in the copyright statement is not valid anymore ;-( Index: tuple_basic.hpp =================================================================== RCS file: /cvsroot/boost/boost/boost/tuple/detail/tuple_basic.hpp,v retrieving revision 1.23 retrieving revision 1.24 diff -u -r1.23 -r1.24 --- tuple_basic.hpp 28 Oct 2003 09:42:43 -0000 1.23 +++ tuple_basic.hpp 17 Jun 2004 07:01:13 -0000 1.24 @@ -43,6 +43,8 @@ #include "boost/type_traits/cv_traits.hpp" #include "boost/type_traits/function_traits.hpp" +#include "boost/detail/workaround.hpp" // needed for BOOST_WORKAROUND + namespace boost { namespace tuples { @@ -97,12 +99,22 @@ template<class RET, class HT, class TT > inline static RET get(const cons<HT, TT>& t) { +#if BOOST_WORKAROUND(__IBMCPP__,==600) + // vacpp 6.0 is not very consistent regarding the member template keyword + // Here it generates an error when the template keyword is used. + return get_class<N-1>::get<RET>(t.tail); +#else return get_class<N-1>::BOOST_NESTED_TEMPLATE get<RET>(t.tail); +#endif } template<class RET, class HT, class TT > inline static RET get(cons<HT, TT>& t) { +#if BOOST_WORKAROUND(__IBMCPP__,==600) + return get_class<N-1>::get<RET>(t.tail); +#else return get_class<N-1>::BOOST_NESTED_TEMPLATE get<RET>(t.tail); +#endif } }; @@ -194,11 +206,17 @@ typename element<N, cons<HT, TT> >::type >::non_const_type get(cons<HT, TT>& c BOOST_APPEND_EXPLICIT_TEMPLATE_NON_TYPE(int, N)) { - return detail::get_class<N>::BOOST_NESTED_TEMPLATE +#if BOOST_WORKAROUND(__IBMCPP__,==600 ) + return get_class<N>:: +#else + return get_class<N>::BOOST_NESTED_TEMPLATE +#endif get< typename access_traits< typename element<N, cons<HT, TT> >::type - >::non_const_type>(c); + >::non_const_type, + HT,TT + >(c); } // get function for const cons-lists, returns a const reference to @@ -209,11 +227,17 @@ typename element<N, cons<HT, TT> >::type >::const_type get(const cons<HT, TT>& c BOOST_APPEND_EXPLICIT_TEMPLATE_NON_TYPE(int, N)) { +#if BOOST_WORKAROUND(__IBMCPP__,==600) + return detail::get_class<N>:: +#else return detail::get_class<N>::BOOST_NESTED_TEMPLATE +#endif get< typename access_traits< typename element<N, cons<HT, TT> >::type - >::const_type>(c); + >::const_type, + HT,TT + >(c); } // -- the cons template --------------------------------------------------

2 1

RE: [boost] Boost.Test
by Roman Yakovenko 17 Jun '04

17 Jun '04

Jagmohan wrote: > Is it possible to just carve out Boost.test package > separately from entire > Boost? Yes, bcp utility is your friend. >From bcp documentation: "The bcp utility is a tool for extracting subsets of Boost, it's useful for Boost authors who want to distribute their library separately from Boost, and for Boost users who want to distribute a subset of Boost with their application." Roman --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com) Version: 6.0.707 / Virus Database: 463 - Release Date: 6/15/2004

1 0

RE: [boost] Re: static sized strings (struct hack)
by Reece Dunn 17 Jun '04

17 Jun '04

John Nagle wrote: > I think we're back to using an abstract base class. >The hacks to get around it introduce worse problems. I would agree. I have been trying to find a way around the problem and have (sortof) by having a base class: template< typename CharT > class string_base { private: size_t len, cap; // length & capacity CharT * buf; // data buffer public: string_base( CharT * b, size_t c, size_t l ): len( l ), cap( c ), buf( b ){} // non-virtual implementation }; template< size_t n, typename CharT > class fixed_string: public string_base { private: CharT data[ n + 1 ]; public: fixed_string(): string_base( data, n + 1 ){} }; The problems with this revolve around swapping/construction/copying and interfacing with (in my case) basic_string_impl. I cannot find a way around these problems without sacrificing something. > Take a look at my approach at >http://www.animats.com/source/index.html > >That's a straightforward approach. The only >fundamental objection is that you take a virtual function >call overhead on some operations. That's the same with both approaches. Both designs are fundamentally the same and I don't see a way around this. It would be interesting to do a comparison with the 3 approaches (raw strcpy, etc on a char[ n ] buffer; your approach and mine) in virtual and non-virtual situations to compare performance. >What needs to be done to that? Are you aiming at supporting basic_string operations? If so, the class needs more work (all the find functions, for instance). If, however, you are just going for C-string replacement it is fine. One point on naming: the wide-character operations are wcscpy (strcpy), wcscat (strcat), wcscmp (strcmp), wcslen (strlen) and [v]swprintf (sprintf). >Should I check it into the Boost sandbox, and >if so, how? Comments, please. Thanks. Go for it! You need a sourceforge account with CVS write access to the boost-sandbox. There is documentation at the sourceforge site for setting it up and pointers to the various tools. You will need to contact an administrator for write access once you have the sourceforge stuff setup. Regards, Reece _________________________________________________________________ Express yourself with cool new emoticons http://www.msn.co.uk/specials/myemo

3 3

Two bugs generating docs using bjam --v2
by Angus Leeming 16 Jun '04

16 Jun '04

I have been following Douglas Gregor's prescriptions on how to generate boostbook docs, outlined on the boost web pages. All works beautifully, so many thanks. However, I find that generating reference docs using bjam and doxygen results in a couple of errors in the docs. I don't know whether the problem lies in bjam or in doxygen, but thought you should have a heads up. This is all with boost-jam-3.1.9-1 doxygen-1.3.4-1 Example 1 A header file containing: template <typename DataT> class process_base { protected: process_base(); process_base(process_base const &); }; results in docs: template<typename DataT> class process_base { public: // construct/copy/destruct process_base(); process_base(process_base const }; Note the change from 'protected' to 'public'. Example 2. This class: struct pprocess_data { /// Type used for file descriptors. typedef int fd_t; /// Pipe used to write to child process' stdin. fd_t wpipe; /// Two pipes to read from child process' stdout and stderr. fd_t rpipe[2]; }; results in these docs: struct pprocess_data { // types typedef int fd_t; // Type used for file descriptors. // public member functions fd_t wpipe; fd_t rpipe; }; Note that the 'rpipe' is no longer an array. Also, shouldn't the 'public member functions' comment be supressed? bjam warning messages are: Cannot handle sectiondef with kind=private-type Cannot handle sectiondef with kind=private-attrib Cannot handle sectiondef with kind=related Cannot handle sectiondef with kind=protected-type Cannot handle sectiondef with kind=protected-attrib I can supply header files and jamfile if required. Regards, Angus

2 2

[bind] Patch that enables pass-by-value
by Lars Rune Nøstdal 16 Jun '04

16 Jun '04

Hi, I'm a new user of this library, so not sure if this is a good idea or the best way to do this. void f(int x) { cout << "f(int): " << x << endl; } int x = 0; bind(f, _1)(x); //bind(f, _1)(1); // Does not work. bind(f, _1)(val<int>(1)); // But this does after patching. This enables the user to pass-by-value if he specifies it explicitly, here is the patch: Index: boost/bind.hpp =================================================================== RCS file: /cvsroot/boost/boost/boost/bind.hpp,v retrieving revision 1.36 diff -u -c -d -r1.36 bind.hpp *** boost/bind.hpp 8 Jun 2004 13:43:03 -0000 1.36 --- boost/bind.hpp 15 Jun 2004 19:13:43 -0000 *************** *** 27,32 **** --- 27,33 ---- #include <boost/type.hpp> #include <boost/bind/arg.hpp> #include <boost/detail/workaround.hpp> + #include <boost/val.hpp> // Borland-specific bug, visit_each() silently fails to produce code Index: boost/bind/bind_template.hpp =================================================================== RCS file: /cvsroot/boost/boost/boost/bind/bind_template.hpp,v retrieving revision 1.4 diff -u -c -d -r1.4 bind_template.hpp *** boost/bind/bind_template.hpp 7 Mar 2004 16:39:15 -0000 1.4 --- boost/bind/bind_template.hpp 15 Jun 2004 19:13:43 -0000 *************** *** 27,32 **** --- 27,38 ---- BOOST_BIND_RETURN l_(type<result_type>(), f_, a, 0); } + template<class A1> result_type operator()(val<A1> a1) + { + list1<A1> a(a1); + BOOST_BIND_RETURN l_(type<result_type>(), f_, a, 0); + } + template<class A1> result_type operator()(A1 & a1) { list1<A1 &> a(a1); *************** *** 39,44 **** --- 45,56 ---- BOOST_BIND_RETURN l_(type<result_type>(), f_, a, 0); } + template<class A1, class A2> result_type operator()(val<A1> a1, val<A2> a2) + { + list2<A1, A2> a(a1, a2); + BOOST_BIND_RETURN l_(type<result_type>(), f_, a, 0); + } + template<class A1, class A2> result_type operator()(A1 & a1, A2 & a2) { list2<A1 &, A2 &> a(a1, a2); *************** *** 51,56 **** --- 63,74 ---- BOOST_BIND_RETURN l_(type<result_type>(), f_, a, 0); } + template<class A1, class A2, class A3> result_type operator()(val<A1> a1, val<A2> a2, val<A3> a3) + { + list3<A1, A2, A3> a(a1, a2, a3); + BOOST_BIND_RETURN l_(type<result_type>(), f_, a, 0); + } + template<class A1, class A2, class A3> result_type operator()(A1 & a1, A2 & a2, A3 & a3) { list3<A1 &, A2 &, A3 &> a(a1, a2, a3); *************** *** 63,68 **** --- 81,92 ---- BOOST_BIND_RETURN l_(type<result_type>(), f_, a, 0); } + template<class A1, class A2, class A3, class A4> result_type operator()(val<A1> a1, val<A2> a2, val<A3> a3, val<A4> a4) + { + list4<A1, A2, A3, A4> a(a1, a2, a3, a4); + BOOST_BIND_RETURN l_(type<result_type>(), f_, a, 0); + } + template<class A1, class A2, class A3, class A4> result_type operator()(A1 & a1, A2 & a2, A3 & a3, A4 & a4) { list4<A1 &, A2 &, A3 &, A4 &> a(a1, a2, a3, a4); *************** *** 75,80 **** --- 99,110 ---- BOOST_BIND_RETURN l_(type<result_type>(), f_, a, 0); } + template<class A1, class A2, class A3, class A4, class A5> result_type operator()(val<A1> a1, val<A2> a2, val<A3> a3, val<A4> a4, val<A5> a5) + { + list5<A1, A2, A3, A4, A5> a(a1, a2, a3, a4, a5); + BOOST_BIND_RETURN l_(type<result_type>(), f_, a, 0); + } + template<class A1, class A2, class A3, class A4, class A5> result_type operator()(A1 & a1, A2 & a2, A3 & a3, A4 & a4, A5 & a5) { list5<A1 &, A2 &, A3 &, A4 &, A5 &> a(a1, a2, a3, a4, a5); *************** *** 87,92 **** --- 117,128 ---- BOOST_BIND_RETURN l_(type<result_type>(), f_, a, 0); } + template<class A1, class A2, class A3, class A4, class A5, class A6> result_type operator()(val<A1> a1, val<A2> a2, val<A3> a3, val<A4> a4, val<A5> a5, val<A6> a6) + { + list6<A1, A2, A3, A4, A5, A6> a(a1, a2, a3, a4, a5, a6); + BOOST_BIND_RETURN l_(type<result_type>(), f_, a, 0); + } + template<class A1, class A2, class A3, class A4, class A5, class A6> result_type operator()(A1 & a1, A2 & a2, A3 & a3, A4 & a4, A5 & a5, A6 & a6) { list6<A1 &, A2 &, A3 &, A4 &, A5 &, A6 &> a(a1, a2, a3, a4, a5, a6); *************** *** 99,104 **** --- 135,146 ---- BOOST_BIND_RETURN l_(type<result_type>(), f_, a, 0); } + template<class A1, class A2, class A3, class A4, class A5, class A6, class A7> result_type operator()(val<A1> a1, val<A2> a2, val<A3> a3, val<A4> a4, val<A5> a5, val<A6> a6, val<A7> a7) + { + list7<A1, A2, A3, A4, A5, A6, A7> a(a1, a2, a3, a4, a5, a6, a7); + BOOST_BIND_RETURN l_(type<result_type>(), f_, a, 0); + } + template<class A1, class A2, class A3, class A4, class A5, class A6, class A7> result_type operator()(A1 & a1, A2 & a2, A3 & a3, A4 & a4, A5 & a5, A6 & a6, A7 & a7) { list7<A1 &, A2 &, A3 &, A4 &, A5 &, A6 &, A7 &> a(a1, a2, a3, a4, a5, a6, a7); *************** *** 111,116 **** --- 153,164 ---- BOOST_BIND_RETURN l_(type<result_type>(), f_, a, 0); } + template<class A1, class A2, class A3, class A4, class A5, class A6, class A7, class A8> result_type operator()(val<A1> a1, val<A2> a2, val<A3> a3, val<A4> a4, val<A5> a5, val<A6> a6, val<A7> a7, val<A8> a8) + { + list8<A1, A2, A3, A4, A5, A6, A7, A8> a(a1, a2, a3, a4, a5, a6, a7, a8); + BOOST_BIND_RETURN l_(type<result_type>(), f_, a, 0); + } + template<class A1, class A2, class A3, class A4, class A5, class A6, class A7, class A8> result_type operator()(A1 & a1, A2 & a2, A3 & a3, A4 & a4, A5 & a5, A6 & a6, A7 & a7, A8 & a8) { list8<A1 &, A2 &, A3 &, A4 &, A5 &, A6 &, A7 &, A8 &> a(a1, a2, a3, a4, a5, a6, a7, a8); *************** *** 123,128 **** --- 171,182 ---- BOOST_BIND_RETURN l_(type<result_type>(), f_, a, 0); } + template<class A1, class A2, class A3, class A4, class A5, class A6, class A7, class A8, class A9> result_type operator()(val<A1> a1, val<A2> a2, val<A3> a3, val<A4> a4, val<A5> a5, val<A6> a6, val<A7> a7, val<A8> a8, val<A9> a9) + { + list9<A1, A2, A3, A4, A5, A6, A7, A8, A9> a(a1, a2, a3, a4, a5, a6, a7, a8, a9); + BOOST_BIND_RETURN l_(type<result_type>(), f_, a, 0); + } + template<class A1, class A2, class A3, class A4, class A5, class A6, class A7, class A8, class A9> result_type operator()(A1 & a1, A2 & a2, A3 & a3, A4 & a4, A5 & a5, A6 & a6, A7 & a7, A8 & a8, A9 & a9) { list9<A1 &, A2 &, A3 &, A4 &, A5 &, A6 &, A7 &, A8 &, A9 &> a(a1, a2, a3, a4, a5, a6, a7, a8, a9); *** /dev/null Thu Jan 1 01:00:00 1970 --- boost/val.hpp Tue Jun 15 22:00:29 2004 *************** *** 0 **** --- 1,35 ---- + #ifndef BOOST_VAL_HPP_INCLUDED + #define BOOST_VAL_HPP_INCLUDED + + // val.hpp - Usefull helper functions + // + // Copyright (C) 2004 Lars Rune Nøstdal (larsnostdal(a)organizer.net) + // + /* + 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) + */ + + + namespace boost { + + template<typename T> + struct val { + val(T t) + :value(t) + { + } + + operator T&() + { + return(value); + } + + private: + T value; + }; // val + + } // namespace boost + + #endif // #ifndef BOOST_VAL_HPP_INCLUDED Thanks, Lars Rune Nøstdal

3 3

[tuple] problem with global tuples::get() in vacpp 6.00
by Joaquín Mª López Muñoz 16 Jun '04

16 Jun '04

Seems like Visual Age is having trouble deducing some implicit template parms inside tuples::get(). This is currently breaking Boost.MultiIndex and a test of Boost.Iterator. Please find below a very simple and totally conformant fix. This has not actually been tested with vacpp, but I checked it does not break anything with some other compilers. 1. Could anybody check locally if this solves the aforementioned problems in vacpp? 2. If 1 is positive, can I commit this to the CVS? Anyone sees a problem? Thank you, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo **************DIFF************** 201c201,203 < >::non_const_type>(c); --- > >::non_const_type, > HT,TT > >(c); 216c218,220 < >::const_type>(c); --- > >::const_type, > HT,TT > >(c);

4 11

Geometric Algebra Library
by Jaap Suter 16 Jun '04

16 Jun '04

Hi, This is a follow-up to my original email from June 9th, see: http://tinyurl.com/3defq [again crossposted to oo-numerics and boost-developers] After this email, several people expressed interest in my geometric algebra library. Unfortunately I cannot address each email individually, so thanks to everybody that replied. First, I want to introduce a new feature I added this week.. It's what I like to call the "auto_element" feature. Within the Clifford framework it works like a "typeof" or "auto" feature. Consider the following: typedef algebra<float, 4, 1> conformal_space; element<list_c<int, 0, 2>, conformal_space> a; element<list_c<int, 1, 2, 4>, conformal_space> b; some_type c = left_contraction(a, b) * outer_product(some_vector, some_bi_vector); People familiar with Clifford algebra know that sometimes it is hard to decude what grades appear in the resulting element of a complicated expression. E.g., in the above example, who can tell me what grades appear in the left_contraction of a conformal-spinor and an element that has grade 1, 2 and 4. Let alone if you multiply that with the outer_product of some vector and some bivector. In other words, what is the type of c? Most other libraries solve this by just using a full multivector (consisting of 32 floats) in this case, which is often redundant. In fact, perhaps the above expression results in just a single scalar. That's a lot of calculation and storge for just one number then. This library allows you to write: auto_element(conformal_space, c, left_contraction(a, b) * outer_product(some_vector, some_bi_vector) ); [indention weird, because of the line-ending limit] which will declare an multi-vector of a type that contains the bare-minimum of grades necessary to capture all the information available in the expression. This has big performance improvements, but more interesting, it makes generic programming with arbitrary elements of an algebra a lot of fun. You don't have to know what types are involved in an expression anymore, but still get all the benefits of static type-checking and the associated performance analysis. Who said C++ was statically typed? :) By the way, for those wondering how I did it, obviously auto_element is a macro that does some (compile-time) stuff. It's not that hard, but a technique I hadn't seen before (let me know if it does exist somewhere else, or if there's a better way of doing this). Come to think of it, other libraries that involve dimensional-types (matrix libraries, etc.) could possible benefit from this as well. Anyway, enough about that... I have now uploaded a package to http://www.jaapsuter.com containing all the header files, some of my unit-tests, and the MSVC 7.1 project file. For reasons outside of my control I cannot upload all of the unit-tests yet. This will be resolved shortly. If you consider porting this to GCC, I would still recommend trying to compile the project in MSVC first and play around with it. It's some really heavy code internally. Hopefully (this is for you to judge) the client-side (see the unit-tests) are very friendly though. So please browse the tests before you dive into the implementation. Comments are welcome. There is still some bugs with certain expressions (as a consequence of not being able to deal with unsorted grade-lists), this will be fixed shortly. I am working on the library on-going, but I am hoping somebody will join. Then, somebody mentioned the interoperability with std::complex and Hubert Holin's Quaternion and Octonion library. I have some tests that test whether Clifford and these libraries behave the same (and inter-operate). As for implementing these types in terms of a geometric algebra? It depends. Sometimes it's worthwhile to specialize and keep things simple (think about scoped_ptr not being implemented in terms of a policy_ptr). But then again, if you have a clifford library in your project already anyway, you might as well use it for complex numbers, quaternions, etcetera. Otherwise, using clifford to provide these basic components is probably overkill. Regards, Jaap Suter

2 1

Geometric Algebra Library
by Jaap Suter 16 Jun '04

16 Jun '04

Hi, [crossposted to oo-numerics and boost-developers] About 20 months back, I asked if there was any interest in a geometric or Clifford algebra library written in C++. Despite some positive replies, I got the impression that there were not a lot of people in the Boost community who saw any practical uses for such library. Back then I had a rudimentary proof-of-concept for a Clifford algebra library that used meta-programming techniques to gain significant performance benefits over other existing libraries (Gaigen, nKlein, CLU, etcetera). Over the past few months I have put a lot more work into this library. The bulk of the work consisted of adding more unit-tests, proving many of the theorems in some of the papers by David Hestenes et al. I also added expression templates to improve performance. To give an idea of what the library is capable of: #include <boost/math/clifford/clifford.hpp> #include <boost/mpl/list_c.hpp> #include <cassert> using namespace boost::math::clifford; using namespace boost::mpl; typedef algebra<4, 1> conformal_model; typedef blade<float, 0, conformal_model> scalar; typedef blade<float, 1, conformal_model> vector; typedef blade<float, 5, conformal_model> pseudo_scalar; typedef blade<float, 2, conformal_model> bi_vector; // same as: // typedef element<float, list_c<int, 1>, conformal_model> bi_vector; typedef list_c<int, 0, 2> spinor_grades; typedef element<float, spinor_grades, conformal_model> spinor; typedef list_c<int, 0, 1, 2, 3, 4, 5> multi_vector_grades; typedef element<float, multi_vector_grades, conformal_model> multi_vector; int main() { assert(sizeof(scalar) == sizeof(float)); assert(sizeof(vector) == 5 * sizeof(float)); assert(sizeof(bi_vector) == 10 * sizeof(float)); assert(sizeof(pseudo_scalar) == sizeof(float)); assert(sizeof(spinor) == 11 * sizeof(float)); assert(sizeof(multi_vector) == 32 * sizeof(float)); vector e_plus; e_plus[3] = 1.0; vector e_min; e_min[4] = 1.0; e_star = e_min - e_plus; e_star *= -std::sqrt(2.0); e_star /= 2.0f; e [noalias] = e_plus * std::sqrt(2.0) - e_star; bi_vector E = outer_product(e, e_star); // geometric product between bi_vector and vector multi_vector v = E * e_star; // geometric product between two vectors, generating a spinor vector a, b; spinor s = a * b; // doing a spinor rotation vector c; c [noalias] = reverse(s) * a * s; } Each product always does the bare minimum of additions, multiplications and subtractions to calculate the result on the left-hand-side of an expression. Thus, if you do the full geometric product of two multi_vectors but assign it to a scalar, it will only do those calculations that are involved in grade 0. Also, unlike other existing libraries, no dynamic allocations are being done ever. Currently, the following operations are supported, between any two random elements of an algebra (blades and composite multi_vectors): geometric_product = operator * inner_product outer_product fat_dot_product left_contraction right_contraction scalar_product of course, all the normal operations (scalar multiplication, addition of elements, etcetera) are supported, as well as reversion, involution and conjugates. Adding more operators is trivial. They can either be implemented in terms of existing operators, or by implementing an appropriate grade-predicate. For example, this is what the implementation of the outer_product looks like: struct outer_product_predicate { template <class ResultGrade, class LhsGrade, class RhsGrade> struct apply { typedef typename mpl::if_ < typename mpl::equal_to < ResultGrade, typename mpl::plus<LhsGrade,RhsGrade>::type >::type, mpl::true_, mpl::false_ >::type type; }; }; BOOST_MATH_CLIFFORD_PRODUCT_IMPL( outer_product, impl::outer_product_predicate ) which for somebody that knows the definition of the outer_product is easy to understand. I have unit-tests for 2, 3 4 and 5 dimensional algebras, but more is possible if your compiler supports it. Currently I have only tested the library on MSVC 7.1. I tried 7.0 but couldn't get it to work (excessive use of MPL). GCC and Intel compiled it at one point, but because I only use MSVC I dropped support. Of course, if anybody is interested I'd be trying other compilers again. You will need a compiler that does aggresive inlining though. On MSVC I am using the force_inline feature to get the release performance I need. Anyway, let me know if anybody is interested, and I'll put together a package to upload somewhere. Cheers, Jaap

7 6

[Boost-bugs] [ boost-Support Requests-973424 ] boost::optional<enum> fails with /CLR
by SourceForge.net 15 Jun '04

15 Jun '04

Support Requests item #973424, was opened at 2004-06-15 11:00 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=207586&aid=973424&group_i… Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: boost::optional<enum> fails with /CLR Initial Comment: ----- #include <boost\optional.hpp> #using <mscorlib.dll> #include <tchar.h> using namespace System; enum Numbers { Zero, One, Two, Three }; // This is the entry point for this application int _tmain(void) { boost::optional<Numbers> num; return 0; } ----- optional.hpp(347): error C2300: 'System::Enum' : class does not have a destructor called '~T' I'm using boost 1.31.0; this fails in both VC7.0 and VC7.1. Removing "#using <mscorlib.dll>" and "using namespace System;" gets rid of the compiler error, but then you can't use things like System::String* Thanks, Dan sourceforge.net(a)jdanielsmith.org ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=207586&aid=973424&group_i… ------------------------------------------------------- This SF.Net email is sponsored by The 2004 JavaOne(SM) Conference Learn from the experts at JavaOne(SM), Sun's Worldwide Java Developer Conference, June 28 - July 1 at the Moscone Center in San Francisco, CA REGISTER AND SAVE! http://java.sun.com/javaone/sf Priority Code NWMGYKND _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

Re: Announcing a New C++ Zine
by Chuck Allison 15 Jun '04

15 Jun '04

brlbo> This is very impressive, but from the standpoint of the reader it brlbo> appears very much to be a direct competitor to CUJ's Experts' Forum. Do brlbo> you think there is room for both initiatives? Don't get me wrong, I do brlbo> hope there is, but I'm afraid there might not be. brlbo> Cheers, brlbo> Nicola Musatti If you look at the members of the Editorial Board, please keep in mind that we all have been discussing the kind of Zine *they* would like to see, in the hopes that such a thing would be of value to other C++ enthusiasts. This makes it, IMO, very different than CUJ. I can say no more about this here, but it will be different than CUJ indeed. There is room for both venues (some people strongly prefer print), but I think Boost folks will prefer what will appear over time in The C++ Source. If I (and the Board) didn't, we wouldn't waste our time. Having been instrumental in both publications, I know the difference. The fact that *for now* no one is getting paid should lend some credibility to the effort (but see below for more on that). In addition, anyone can contribute, not just "experts". This is an important distinction. (Besides, even Andrei Alexendrescu was an unknown until Scott Meyers "discovered" him. Latent experts need a venue to precede their notoriety). brlbo> If there's only room for one, I would prefer the one that is explicitly brlbo> peer reviewed, myself. I understand that programming in C++ is brlbo> an engineering pursuit, and not an academic/scientific one, but I brlbo> don't see that as a reason to hold it to a lesser standard. brlbo> Dave (Held) It won't be an academic journal, only peer reviewed. The articles will be written by and for C++ practitioners. The reviewing makes for better content, clearly. I see it sort of a publication equivalent of Boost - a place for peer-reviewed articles instead of software. FYI, the funds at CUJ dwindled so terribly (note the current minimized page count and disappearance of certain columns, letters, etc.) that I had to depend on the gracious kindness of my colleagues to review articles gratis. I don't know what the current arrangements are there (I have reason to believe that no one reviews articles there except the editor-in-chief, but that will have to be a private discussion), but the only people reviewing articles at CUJ besides myself for 2002-2003 were David Abrahams, Bjorn Karlsson, and Kevlin Henney. I managed to get a (very) few pennies for only one of them. When the holding company fired everyone but me and folded production into the DDJ machine, I left. That was October 2003. I tested the waters for a new Zine, a place with quality you can trust, by emailing those whose names appear on the Editorial Board of The C++ Source. The response was overwhelmingly positive - I can provide you moving quotes for the value of an online, peer-reviewed Zine from these experts we revere. The fact that things incubated until now shows our careful and good intentions. It is important to me that you (the Boost Community) understand this. brlbo> Actually I like the idea that people should get paid for their efforts, brlbo> while at the same time I do very much appreciate the efforts of those who brlbo> don't get paid such as the Boost developers in putting out free software. brlbo> My suggestion for a subscription to the C++ Zine was to help those who were brlbo> willing to put out the effort of writing articles, and developing software brlbo> based on them, to get paid. (Eddie) A valid point, with which I agree, but they *will* get paid, just not immediately. We have some advertising lined up and some other hopefuls. I think we'll get to the point where the remuneration will be worthwhile. We ourselves are professionals, and want to get paid, and don't want to slight anyone. The difference between The C++ Source and other venues is that we are not owned by a holding company needing to make Wall Street happy, and who from an uninformed distance may fire an entire long-standing family of fruitful employees to fill investors' pockets. [The people in Lawrence, Kansas, who made CUJ what it is over the last 20 years, were all given their walking papers - I mean, who needs *them*, after all?!] Hats off to the pioneers who have donated initial articles and other contributions to this new endeavor. Now that we've all had a chance to express opinions (thank you!), may I once again just invite you to read and contribute to The C++ Source, a peer-reviewed Zine created by and for people such as yourselves. Please send proposals, articles, and other offers of service to me at chuck(a)freshsources.com. Thank you! -- Best regards, Chuck Allison

1 0

[Boost-bugs] [ boost-Bugs-973310 ] jam_src build scripts need como --c
by SourceForge.net 15 Jun '04

15 Jun '04

Bugs item #973310, was opened at 2004-06-15 10:16 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=973310&group_i… Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Larry Evans (cppljevans) Assigned to: Nobody/Anonymous (nobody) Summary: jam_src build scripts need como --c Initial Comment: Without the como --c option, the command: build.sh como results in several .c files. For example: "execunix.c", line 225: error: identifier "vfork" is undefined if ((pid = vfork()) == 0) ^ Also, on debian, PATH_MAX is undefined in pwd.c. Output of como -c --list pwd.l pwd.c shows: N#include <limits.h> L 1 "/usr/lib/gcc-lib/i386-linux/2.95.4/include/limits.h" 1 N/* This administrivia gets added to the beginning of limits.h N if the system has its own version of limits.h. */ N N/* We use _GCC_LIMITS_H_ because we want this not to match N any macros that the system's limits.h uses for its own purposes. */ N#ifndef _GCC_LIMITS_H_ /* Terminated in limity.h. */ N#define _GCC_LIMITS_H_ N N#ifndef _LIBC_LIMITS_H_ S/* Use "..." so that we find syslimits.h only in this same directory. */ S#include "syslimits.h" N#endif indicating that syslimits.h is skipped. Maybe that's part of the problem. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=973310&group_i… ------------------------------------------------------- This SF.Net email is sponsored by The 2004 JavaOne(SM) Conference Learn from the experts at JavaOne(SM), Sun's Worldwide Java Developer Conference, June 28 - July 1 at the Moscone Center in San Francisco, CA REGISTER AND SAVE! http://java.sun.com/javaone/sf Priority Code NWMGYKND _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

Re: Re: Geometric Algebra Library
by Johannes Brunen 15 Jun '04

15 Jun '04

Hi, Jaap Suter wrote: >> Despite some >> positive replies, I got the impression that there were not a lot >> of people in the Boost community who saw any practical uses for >> such library. Ken Hagan wrote: > For a full geometric algebra, I suspect the target market is going > to be limited to a few thousand people worldwide, This may currently be correct. However, IMHO GA will gain a lot of importance. E.g. I'm working in the CAD industry and we are beginning to be aware of GA's strength against the classic mathematical toolset. I see a time comming that you learn GA in high school. Every physics student will be learning GA once it has found its way to the theoretical courses. Thereafter GA will gain room in the engineering fields. > most of whom have > never heard of boost and are unwilling to learn C++. I don't share this opinion. C++ has its place in the world, and a lot of applications which are a target to GA are programmed in C++. I think that people are willing to learn C++ if they see that the language and its tools (like boost) can help them to solve their problems (e.g. GA, CAD, robotics,...) better than other languages and tools. This was exactly the way I found myself at this place. > I wrote some GA classes for the 3D case about a decade ago, and I'm > still using them, but they are a very minor part of my work and I've > no reason to "upgrade" to a boost version, no matter how yummy it looks. > I'd like to be more positive, but I have to be honest. If you are pleased with your tools that is fine. But there are other people which could benefit a lot from a well shaped GA package. And more importantly, there will be new applications written which have to decide about the tools they use to solve there math. They probably won't write a new GA package and will stick with the classic tools. However, if available they may make the transition to a boost GA package. > However, you may be asking the wrong question. There are reasonable > arguments for using only one library for all your geometric algebra > and the demand for complex numbers is demonstrably large enough to > justify including it in the language standard. At first I wrote 'I second that!', but I have a problem with the part about complex numbers. GA is not a replacement for std::complex. > Given that GA is a superset of these, could your library replace > these two? It would need to be syntactically compatible, since we > can't break existing clients of std::complex, but since all such > libraries try to follow standard mathematical notation this might > not be too difficult. And IMHO GA should not try to supersede the classic tools since there still will be demand for them. I think they can perfectly coexists. People shoud choose the tools which best serve their needs. Finally, I strongly encourage Jaap Suter as well as Paul Leopardi (http://lists.boost.org/MailArchives/boost-users/msg06695.php , http://glucat.sourceforge.net/) to bring their libraries into the boost review process. With kind regards Johannes

3 2

Request for small test in CW 9.2
by Joaquín Mª López Muñoz 15 Jun '04

15 Jun '04

During the porting of my library, I found the following compiler bug in CW 8.3: **BEGIN PROGRAM** #include <iostream> struct foo { foo(){} foo(const foo&){} ~foo() { std::cout<<"~foo"<<std::endl; } }; template<typename T> struct A { static void bar() { const foo& f=foo(); std::cout<<"inside A::bar"<<std::endl; } }; struct B { static void bar() { const foo& f=foo(); std::cout<<"inside B::bar"<<std::endl; } }; int main() { std::cout<<"calling A::bar"<<std::endl; A<int>::bar(); std::cout<<"calling B::bar"<<std::endl; B::bar(); return 0; } **END PROGRAM** *Without* enabling the option "ISO C++ Template Parser", everything works dandy and the program output is: calling A::bar inside A::bar ~foo calling B::bar inside B::bar ~foo But if I enable the "ISO C++ Template Parser", the output becomes: calling A::bar ~foo inside A::bar calling B::bar inside B::bar ~foo Which is AFAICS a flagrant bug (note that ~foo() is called before A::bar() scope ends.) Fortunately, I know how to patch this in CW 8.3 with some pragmas. I'd be grateful if someone with access to CW 9.2 can check whether the error persists in this newer version of the compiler, so as to extend (or not) the patch to cover it as well. Remember, the problem only shows when the "ISO C++ Template Parser" is turned on. Thanks, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

3 3

[program_options] vc6 and vc7: explicit function template arguments
by Vladimir Prus 15 Jun '04

15 Jun '04

Hello, it appears that both vc6 and vc7 don't understand explicit function template arguments, like this: value<string>()->implicit() where 'value' is a function. Anybody can suggest a workaround? One possible approach would be to make 'value' a class which overloaded operator->, but that's a lot of work. TIA, Volodya

2 2

CVS problem
by Janusz Piwowarski 15 Jun '04

15 Jun '04

Hello, >From yesterday evening to now, there's agurtovoy's lock in /cvsroot/boost/boost/boost/python/converter. Regards, Janusz

2 2

RE: [boost] Re: Announcing a New C++ Zine
by Glen Knowles 15 Jun '04

15 Jun '04

>From: David Abrahams [mailto:dave@boost-consulting.com] >>>>>Has William reappeared? >>>> >> As last resort, his phone number is listed ;-) > >But I forgot what state he lives in. >From http://www.boost.org/people/william_kempf.htm Bill Kempf lives in Omaha, NE with his wife Bonnie, his cat Dexter and his two Chinchillas, Chimney and Minuet. He married on Oct. 30, 1999 where he and his wife held a Halloween costume reception. If that doesn't give you an idea of what kind of guy he is, nothing will. Glen

2 1

Re: Announcing a New C++ Zine
by Chuck Allison 14 Jun '04

14 Jun '04

Jeff Flinn wrote: > Has William reappeared? Actually, I haven't heard from him for a while. This is not the final list. I will soon do a final query of those who want their names to remain on the Editorial Board (and of course, others can be added). The list I sent contains those who have participated in the forming of The C++ Source since last October. You might want to ping him with a private message. I should add here that I forgot to mention in my original post that for now, contributing to The C++ Source is a "labor of love". None of us are getting paid. As we get sufficient advertising, we will share the wealth. We are starting small, but I predict a gradual swelling until this becomes a mainstay for the majority of C++ developers. Someone has suggested a subscription basis, but with today's Internet culture, I think we'll do the most good if we keep it free. That can change, but for now, that's the way it is. After all, Boosters are very familiar with this model :-). -- Chuck Allison

7 12

Announcing a New Online C++ Zine
by Chuck Allison 14 Jun '04

14 Jun '04

Hello Boosters, David Abrahams suggested I could send you an announcement on this list. For some time now (since last October, actually) a group of C++ luminaries have been discussing the virtues and possibilities of a peer-reviewed source for the C++ community. We have decided on the name "The C++ Source", and a preliminary page is available for viewing at http://www.artima.com/cppsource. The idea is to have seasoned C++ professionals review submissions to ensure that the publications are of high quality and of interest. There will also be tutorials, news, lots of stuff. The Editorial Board currently is: David Abrahams J. Stephen Adamczyk Andrei Alexandrescu Matthew Austern Pete Becker Walter Bright Steve Clamage Greg Colvin Jim Coplien Stephen Dewhurst Howard Hinnant Bjorn Karlsson William Kempf Andrew Koenig Martha Masinton Scott Meyers Thomas Plum Dan Saks Jerry Schwarz Jeremy Siek Bjarne Stroustrup Herb Sutter Matthew Wilson Leor Zolman (Like, wow!) I am writing to invite you to consider writing for The C++ Source. In fact, the first installments to appear later this month include an article by Booster Bjorn Karlsson. The chances that anything of interest to you will be of interest to the C++ community at large, and will make a positive contribution to daily C++ development. If you have any ideas, proposals, or suggestions, please email me at chuck(a)freshsources.com. Thanks! -- Best regards, -- Chuck Allison

5 5

RE: [boost] Re: Documentation
by Reece Dunn 14 Jun '04

14 Jun '04

John Nagle wrote: >Robert Ramey wrote: >>As far as writing documentation is concerned I found the the "standard" >>boost position at: >> >>C:\boost_1_31_0\more\writingdoc\index.html > > I'm having trouble reading your C: drive. Try replacing "C:\boost_1_31_0" with either http://www.boost-consulting.com/boost or the directory where your copy of Boost is located, e.g.: http://www.boost-consulting.com/boost/more/writingdoc/index.html HTH Regards, Reece _________________________________________________________________ It's fast, it's easy and it's free. Get MSN Messenger today! http://www.msn.co.uk/messenger

1 0

RE: [boost] Documentation
by Reece Dunn 14 Jun '04

14 Jun '04

David B. Held wrote: >Ok, if the Boost style documentation is too simple, and docs like >Spirit are too cute, what is a nice, happy median? Have you looked at the BoostBook generated docs :). Let me know what you think of the current L&F: I have updated this a while ago to try and bridge the gap between the two looks (the docs now have Spirit-style navigation). See http://boost.sourceforge.net/regression-logs/cs-win32_metacomm/doc/html/ind… for the new-stle docs. >If we're going >to demand uniformity in licensing, should we also demand more >uniformity in documentation? I agree on this. At the moment, we have the docs written in HTML, those in BoostBook format (like Boost.Any and the BBv2 docs) and the Spirit docs which have their own format. As far as I understand it, the BoostBook tool is relatively new and has a learning curve, so it will take some time to migrate the docs to this format. As for the Spirit docs, they have their own sourceforge area as well as being a part of Boost, so forcing them to change doc format wouldn't be fair. However, since the Spirit docs are in a special text format that is "compiled" into HTML using Spirit, it should be easy to create a BoostBook back-end and have the docs in boost in this format and the ones on the sourceforge area in the existing format. With this in mind, it might be beneficial to create a HTML to BoostBook converter (possibly using Spirit) to allow easier migration to the BoostBook format. >I think a single documentation style >across Boost would make it even easier to learn new libraries. I >recently found it very difficult to find the information I wanted about >the Boost.Test library, as well as Boost.Preprocessor. What can >be done about these issues? I think the BoostBook format would go a long way to resolving these issues, once the docs are all in this uniform format. Regards, Reece _________________________________________________________________ Express yourself with cool new emoticons http://www.msn.co.uk/specials/myemo

6 6

config tests breaking change imminent
by John Maddock 14 Jun '04

14 Jun '04

Following our recent discussion on file naming conventions, I've submitted a Sourceforge support request to have all the *.cxx files in libs/config/test renamed to *.ipp. When this change takes place the config tests will be broken until further notice (but probably only for a day or two). Regards, John.

2 1

Re:[boost] Re: Re: config and .cxx extensions
by Robert Ramey 14 Jun '04

14 Jun '04

Jeff Flinn wrote: > If it's VisualStudio, you can add the extensions to the registry to act > like headers or source(compilable) files. I would bet most others have a > similar facility. Please tell us how to do that. I looked for this and couldn't find it. I would like to tell my Visual.Net IDE to treat *.ipp file like *.hpp and *.cpp for editing purposes. Robert Ramey

3 2

Re: Documentation
by Robert Ramey 14 Jun '04

14 Jun '04

As far as writing documentation is concerned I found the the "standard" boost position at: C:\boost_1_31_0\more\writingdoc\index.html To be very helpful. I think it goes a long way to providing a common look and feel the boost docs. By providing a skeleton document for a boost library it also saves a lot of work. I tried to follow it as closely as possible for the boost serialization library. I think the discussions around boost documentation should focus on how this "document" document (meta-document?) should be updated. So it might a) Be a little more specific re tutorial and reference documentation sections. This is not quite as easy as one would first think as the requirements for formatting/tables of overloads are different from from function calls, etc. b) Suggest a common navigation facility. I actually liked the navigation pane used by the BOOST_PP library and have incorporated something similar in the new serialization library documentation. I find it very helpful. Robert Ramey

2 1

[Boost-bugs] [ boost-Bugs-972406 ] Tokenizer.hpp doesn't work with BOOST_ENABLE_ASSERT_HANDLER
by SourceForge.net 14 Jun '04

14 Jun '04

Bugs item #972406, was opened at 2004-06-13 22:35 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=972406&group_i… Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Tokenizer.hpp doesn't work with BOOST_ENABLE_ASSERT_HANDLER Initial Comment: Using boost-1.31.0 Tokenizer.hpp has #include <cassert> on line 23 - this prevents a custom assert function from working properly when trying to use BOOST_ENABLE_ASSERT_HANDLER. It looks like token_iterator.hpp and token_functions.hpp also do the same thing. It would be nice if these used the common boost assert mechanism instead of directly #including <cassert>. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=972406&group_i… ------------------------------------------------------- This SF.Net email is sponsored by the new InstallShield X. >From Windows to Linux, servers to mobile, InstallShield X is the one installation-authoring solution that does it all. Learn more and evaluate today! http://www.installshield.com/Dev2Dev/0504 _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

Re: BGL: Shadow Warnings
by Perry Kundert 14 Jun '04

14 Jun '04

The -Wshadow warnings also affect the "spirit" parser. Attached is a patch that fixes up a number of quite verbose warnings about shadowing variables... David A. Greene wrote: > Jeremy Siek wrote: > >> Hi David, <snip> > > The option seems to be a little flaky in that it flags some things > that I don't think it should, but it's still a good debugging tool. > >> I'm currently extremely busy with school work, so it may take a while >> for me to get to this. If you want to send me a patch to fix these >> problems I'd be thankful. > > > I feel your pain. :) I'll see what I can do, but no guarantees. > > -Dave > --- boost_1_31_0-stock/boost/spirit/core/impl/match.ipp 2004-01-19 16:15:55.000000000 -0700 +++ boost_1_31_0/boost/spirit/core/impl/match.ipp 2004-06-09 09:05:20.000000000 -0600 @@ -17,12 +17,12 @@ : len(-1), val() {} template <typename T> - inline match<T>::match(std::size_t length) - : len(length), val() {} + inline match<T>::match(std::size_t length_) + : len(length_), val() {} template <typename T> - inline match<T>::match(std::size_t length, ctor_param_t val_) - : len(length), val(val_) {} + inline match<T>::match(std::size_t length_, ctor_param_t val_) + : len(length_), val(val_) {} template <typename T> inline bool @@ -64,11 +64,11 @@ inline match<nil_t>::match() : len(-1) {} - inline match<nil_t>::match(std::size_t length) - : len(length) {} + inline match<nil_t>::match(std::size_t length_) + : len(length_) {} - inline match<nil_t>::match(std::size_t length, nil_t) - : len(length) {} + inline match<nil_t>::match(std::size_t length_, nil_t) + : len(length_) {} inline bool match<nil_t>::operator!() const --- boost_1_31_0-stock/boost/spirit/core/non_terminal/parser_id.hpp 2004-01-19 16:15:55.000000000 -0700 +++ boost_1_31_0/boost/spirit/core/non_terminal/parser_id.hpp 2004-06-09 09:17:33.000000000 -0600 @@ -100,7 +100,7 @@ : parser_id(reinterpret_cast<std::size_t>(this)); } - void set_id(parser_id id) { tag = id; } + void set_id(parser_id id_) { tag = id_; } private: --- boost_1_31_0-stock/boost/spirit/core/non_terminal/rule.hpp 2004-01-19 16:15:55.000000000 -0700 +++ boost_1_31_0/boost/spirit/core/non_terminal/rule.hpp 2004-06-09 09:42:46.000000000 -0600 @@ -157,8 +157,8 @@ return ptr.get(); } - rule(abstract_parser_t const* ptr) - : ptr(ptr) {} + rule(abstract_parser_t const* ptr_) + : ptr(ptr_) {} scoped_ptr<abstract_parser_t> ptr; }; --- boost_1_31_0-stock/boost/spirit/core/non_terminal/impl/rule.ipp 2004-01-19 16:15:55.000000000 -0700 +++ boost_1_31_0/boost/spirit/core/non_terminal/impl/rule.ipp 2004-06-09 09:43:51.000000000 -0600 @@ -224,7 +224,7 @@ template <typename ParserT, typename ScannerT, typename AttrT> struct concrete_parser : abstract_parser<ScannerT, AttrT> { - concrete_parser(ParserT const& p) : p(p) {} + concrete_parser(ParserT const& p_) : p(p_) {} virtual ~concrete_parser() {} virtual typename match_result<ScannerT, AttrT>::type --- boost_1_31_0-stock/boost/spirit/core/scanner/scanner.hpp 2004-01-19 16:15:56.000000000 -0700 +++ boost_1_31_0/boost/spirit/core/scanner/scanner.hpp 2004-06-09 09:44:41.000000000 -0600 @@ -240,22 +240,22 @@ bool at_end() const { - typedef typename PoliciesT::iteration_policy_t iteration_policy_t; - return iteration_policy_t::at_end(*this); + typedef typename PoliciesT::iteration_policy_t iteration_policy_t_; + return iteration_policy_t_::at_end(*this); } value_t operator*() const { - typedef typename PoliciesT::iteration_policy_t iteration_policy_t; - return iteration_policy_t::filter(iteration_policy_t::get(*this)); + typedef typename PoliciesT::iteration_policy_t iteration_policy_t_; + return iteration_policy_t_::filter(iteration_policy_t_::get(*this)); } scanner const& operator++() const { - typedef typename PoliciesT::iteration_policy_t iteration_policy_t; - iteration_policy_t::advance(*this); + typedef typename PoliciesT::iteration_policy_t iteration_policy_t_; + iteration_policy_t_::advance(*this); return *this; } --- boost_1_31_0-stock/boost/spirit/dynamic/stored_rule.hpp 2004-01-19 16:15:56.000000000 -0700 +++ boost_1_31_0/boost/spirit/dynamic/stored_rule.hpp 2004-06-09 09:45:53.000000000 -0600 @@ -109,8 +109,8 @@ private: #endif - stored_rule(shared_ptr<abstract_parser_t> const& ptr) - : ptr(ptr) {} + stored_rule(shared_ptr<abstract_parser_t> const& ptr_) + : ptr(ptr_) {} shared_ptr<abstract_parser_t> ptr; }; --- boost_1_31_0-stock/boost/spirit/core/non_terminal/subrule.hpp 2004-01-19 16:15:55.000000000 -0700 +++ boost_1_31_0/boost/spirit/core/non_terminal/subrule.hpp 2004-06-09 09:48:16.000000000 -0600 @@ -209,7 +209,7 @@ subrule_list< subrule_parser<ID2, DefT2, ContextT2>, nil_t> > - operator,(subrule_parser<ID2, DefT2, ContextT2> const& rhs) const + operator,(subrule_parser<ID2, DefT2, ContextT2> const& rhs_) const { return subrule_list< self_t, @@ -219,7 +219,7 @@ *this, subrule_list< subrule_parser<ID2, DefT2, ContextT2>, nil_t>( - rhs, nil_t())); + rhs_, nil_t())); } typename DefT::embed_t rhs; @@ -257,10 +257,10 @@ parse_main(ScannerT const& scan) const { typedef typename parser_result<self_t, ScannerT>::type result_t; - result_t result; + result_t result_; impl::parse_subrule<result_t, ScannerT, ID>:: - do_(result, scan); - return result; + do_(result_, scan); + return result_; } template <typename ScannerT> --- boost_1_31_0-stock/boost/spirit/symbols/symbols.hpp 2004-01-19 16:15:57.000000000 -0700 +++ boost_1_31_0/boost/spirit/symbols/symbols.hpp 2004-06-09 09:49:14.000000000 -0600 @@ -114,13 +114,13 @@ { typedef typename ScannerT::iterator_t iterator_t; iterator_t first = scan.first; - typename SetT::search_info result = SetT::find(scan); + typename SetT::search_info result_ = SetT::find(scan); - if (result.data) + if (result_.data) return scan. create_match( - result.length, - symbol_ref_t(*result.data), + result_.length, + symbol_ref_t(*result_.data), first, scan.first); else

2 1

BOOST_DEBUG like macros: current state overview
by Pavel Vozenilek 13 Jun '04

13 Jun '04

Some time ago I suggested to add support for BOOST_DEBUG and BOOST_NDEBUG macros into guidelines. I searched how individual libraries (1.31) handle debug support: ------------------------------------- * lexical_cast - uses assert() * dynamic_bitset - uses assert() * filesystem - uses assert() * graph - uses assert() * interval - uses assert() * thread - uses assert() * tokenizer - uses assert() * random - uses assert() * lambda - uses assert() * multi_array - uses assert() * signals - uses assert() * format - uses BOOST_ASSERT() * function - uses BOOST_ASSERT() * variant - uses BOOST_ASSERT * optional - uses BOOST_ASSERT * smart_ptr - uses BOOST_ASSERT and macro with somewhat misleading name BOOST_SP_ENABLE_DEBUG_HOOKS * concept_check - uses NDEBUG directly * ublas - uses its own macro BOOST_UBLAS_CHECK depending on NDEBUG. Documented * python - uses its own macro BOOST_PYTHON_INDEXING_CHECK_INVARIANT depending on NDEBUG and also NDEBUG directly. Not documented * regex - uses assert() based on BOOST_REGEX_DEBUG and jm_assert (macro too). Uses also BOOST_REGEX_DEBUG directly. No dependence on NDEBUG. Not documented. * spirit - uses macro BOOST_SPIRIT_ASSERT depending on assert() as well as handful of other library specific debug macros. Well documented. Circular Buffer, Multi Index Container and likely Serialization contain (documented) extensive support for debug mode with their specifi macros and different level modes. ------------------------------------- Documentation usually doesn't mention if/how debug support is implemented. Maybe common macros would make life of Boost user easier. /Pavel

2 2

config and .cxx extensions
by David Abrahams 13 Jun '04

13 Jun '04

Is there a good reason that the config library needs to use a "creative" choice of file extensions rather than the boost standard of ".*pp"? -- Dave Abrahams Boost Consulting http://www.boost-consulting.com

7 14

Can anyone help with this one?
by Thomas Don Aratari 12 Jun '04

12 Jun '04

Hello, I'm trying to upgrade my boost to 1_31 but I keep getting the following tokenizer error. I am using Forte 8.0 (CC: Sun C++ 5.5 Patch 113817-03 2003/10/14). Here is the code snip: (passing in sString to be tokenized) typedef boost::tokenizer<boost::char_separator<char> > tokenizer; boost::char_separator<char> seperator(sDroppedDelimiters, sKeptDelimiters, boost::keep_empty_tokens); tokenizer tokens( sString, seperator ); for (tokenizer::iterator tok_iter = tokens.begin(); tok_iter != tokens.end(); ++tok_iter) vInVector.push_back( *tok_iter ); "/home/dev/cm/THIRD_PARTY/boost/include/boost/iterator/iterator_facade.hpp", line 623: Error: Could not find a match for boost::iterator_core_access::equal<boost::iterator_core_access::Facade1, boost::iterator_core_access::Facade2>(const boost::token_iterator<boost::char_separator<char, std::char_traits<char>>, const char*, std::string>, const boost::token_iterator<boost::char_separator<char, std::char_traits<char>>, const char*, std::string>, boost::is_convertible<boost::token_iterator<boost::char_separator<char, std::char_traits<char>>, const char*, std::string>, boost::token_iterator<boost::char_separator<char, std::char_traits<char>>, const char*, std::string>>). "MDSStringHelpers.cxx", line 183: Where: While instantiating "boost::operator!=<boost::token_iterator<boost::char_separator<char, std::char_traits<char>>, const char*, std::string>, std::string, boost::forward_traversal_tag, const std::string &, int, boost::token_iterator<boost::char_separator<char, std::char_traits<char>>, const char*, std::string>, std::string, boost::forward_traversal_tag, const std::string &, int>(const boost::iterator_facade<boost::token_iterator<boost::char_separator<char, std::char_traits<char>>, const char*, std::string>, std::string, boost::forward_traversal_tag, const std::string &, int>&, const boost::iterator_facade<boost::token_iterator<boost::char_separator<char, std::char_traits<char>>, const char*, std::string>, std::string, boost::forward_traversal_tag, const std::string &, int>&)". "MDSStringHelpers.cxx", line 183: Where: Instantiated from non-template code. Any ideas how to fix or has anyone else seen this? Thanks Tom

1 0

Re: New C++ Zine (Print version?)
by Chuck Allison 12 Jun '04

12 Jun '04

Hello Dave, Saturday, June 12, 2004, 11:01:35 AM, you wrote: brlbo> "Chuck Allison" <chuck(a)freshsources.com> wrote in message brlbo> news:15110019883.20040611130022@freshsources.com... >> [...] >> David Abrahams suggested I could send you an announcement >> on this list. For some time now (since last October, actually) a >> group of C++ luminaries have been discussing the virtues and >> possibilities of a peer-reviewed source for the C++ community. brlbo> Is it likely there will be a print edition in the future? If so, is there a brlbo> timetable for it's appearance? brlbo> Dave We have discussed having a periodic (annual?) print anthology (a la C++ Gems), but of course, we haven't even launched yet, so we're getting ahead of ourselves. With sufficient success/resources, the answer is "yes". -- Best regards, Chuck

1 0

Re: Announcing a New C++ Zine
by Chuck Allison 12 Jun '04

12 Jun '04

Hello Alexander, I'm sorry, but that page is just a sample page. Bjarne's article is not an official posting. We haven't launched yet. If you want to discuss the content of Bjarne's comments, you can email him directly, but it has nothing to do with The C++ Source. Sorry if I didn't make it clear that that page was just a sample. I meant to. Saturday, June 12, 2004, 11:01:35 AM, you wrote: brlbo> Chuck Allison wrote: brlbo> [...] >> viewing at http://www.artima.com/cppsource. The idea is to have brlbo> Quoting from http://www.artima.com/intv/elegance.html. Few comments brlbo> follow. brlbo> <quote author=Bjarne Stroustrup> brlbo> I don't put in specific features for concurrency, because you can put brlbo> them in a library. brlbo> </quote> brlbo> You can't do that without threaded memory model, to begin with. brlbo> <quote> brlbo> C was designed with the principle that you should be able to write brlbo> its standard library in the language itself. That same principle brlbo> guided the design of C++. brlbo> </quote> brlbo> Show me the the standard C++ impl of atomic<> for a rather simple brlbo> thing like brlbo> class swap_based_mutex_for_windows { // noncopyable brlbo> atomic<int> m_lock_status; // 0: free, 1/-1: locked/contention brlbo> auto_reset_event m_retry_event; // "slow" bin sema/gate brlbo> public: brlbo> // ctor/dtor [w/o lazy event init] brlbo> void lock() throw() { brlbo> if (m_lock_status.swap(1, msync::acq)) brlbo> while (m_lock_status.swap(-1, msync::acq)) brlbo> m_retry_event.wait(); brlbo> } brlbo> bool trylock() throw() { brlbo> return !m_lock_status.swap(1, msync::acq) ? brlbo> true : !m_lock_status.swap(-1, msync::acq); brlbo> } brlbo> bool timedlock(absolute_timeout const & timeout) throw() { brlbo> if (m_lock_status.swap(1, msync::acq)) { brlbo> while (m_lock_status.swap(-1, msync::acq)) brlbo> if (!m_retry_event.timedwait(timeout)) brlbo> return false; brlbo> } brlbo> return true; brlbo> } brlbo> void unlock() throw() { brlbo> if (m_lock_status.swap(0, msync::rel) < 0) brlbo> m_retry_event.set(); brlbo> } brlbo> }; brlbo> regards, brlbo> alexander. -- Best regards, Chuck

1 0

Re: static sized strings (struct hack)
by Bill Seymour 12 Jun '04

12 Jun '04

Rob Stewart: > > From: John Nagle <nagle(a)animats.com> > > > From: "Reece Dunn" <msclrhd(a)hotmail.com> > > > > >> class fs_base > > >> { > > >> size_t len; > > >> szie_t capacity; // needed for buffer-safe operations > > >> CharT str[ 1 ]; > > >> // string manipulation functions > > >> > > >> fs_base( size_t c ): capacity( c ){} > > >> }; > > >> > > >> template< size_t n > > > >> class fixed_string: public fs_base > > >> { > > >> CharT data[ n ]; > > >> fixed_string(): fs_base( n ){} > > >> }; > > > > Are you assuming that "data[n]" physically follows > > "str[1]" in memory, and that "data[n]" can be addressed > > by subscripting "str[1]" out of range? ... > > Oh, right. It was C99 that blessed the struct hack. Oh well. > Well, yes; but the struct hack is not what the code above tries to do. What C99 says is that you can malloc sizeof(fs_base) plus some extra, then address str[2] to str[whatever up to malloc'd size]. Even in C99 (and even if C understood the C++-specific stuff in the above), there is no relationship between fs_base::str and fixed_string::data (except that they don't overlap). --Bill Seymour

2 1

More Math Functions
by Paul A Bristow 12 Jun '04

12 Jun '04

|-----Original Message----- |From: boost-bounces(a)lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf |Of Tom Brinkman |Sent: 03 June 2004 00:54 |To: boost(a)lists.boost.org |Subject: [boost] Boost Mathematicians |What is the current status of all Boost mathmatical, |statistical and econometric libraries currently in |development? |The collection of boost math libraries that are |currently included in the library are world-class and |provide a wonderful foundation to build-upon. |However, many areas of advanced statistical and |mathmatical inference are not currently being \addressed by any of the boost libraries. I have been off-line for some time, but have now caught up with this discussion a bit. Strongly support your views and need these things yesterday ;-) Apart from messing about with Microsoft Windows problems, I have been preparing a formal proposal for C and C++ Standard Library TR-2 of a list of Math 'Special' Functions (additional to those from Walter Brown which have been accepted into TR-1). This list will include all the usual statistical suspects - including Student's t, Chi sqr, and F, so that at last it will be possible easily write C++ to provide the probability that means of two series of measurements differ. (The key function is the incomplete beta; it is also the most difficult to write well). Fortunately I have persuaded Stephen Moshier, author of the Cephes function library (in C) to make this available under Boost licence terms. So implementors will have no excuse to hide behind (the reason why these functions were omitted by Walter Brown). It should be possible to produce a working (and I believe rather good) implementation with little more than renaming the functions. This might be submitted for a Boost library. I hope to expose a revised draft to the rigours of Boost and C++.std newsgroup Real Soon Now. Paul Paul A. Bristow Prizet Farmhouse, Kendal UK LA8 8AB +44 1539 561830 07714 33 02 04 pbristow(a)hetp.u-net.com

1 0

Paul Mensonides:
by Vesa Karvonen 12 Jun '04

12 Jun '04

[boost] Re: Some remarks on PP docs Date: Fri, 11 Jun 2004 16:36:19 +0300 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Paul Mensonides: >Chaos, as opposed to Order, intentionally encourages better >understanding of the actual language being used (which is not Chaos, but >the preprocessor) rather than trying to hide it as much as possible. I've discussed this with you earlier, but I'd still like to point out that the intention behind the design of Order has not been to "hide as much as possible" or to discourage "better understanding", but rather to *provide* a language that definitely *is* easy to understand and convenient to use. A person unfamiliar with Boost.PP should be able to learn to use something like Order and use it for productive, even non-trivial, work (which is usually C or C++ code generation) in significantly shorter period of time than it takes to learn how to do similar things with Boost.PP (or Chaos). I also noticed other, IMO, misleading comments on Order [vs Chaos], but I don't have the time to comment on those at the moment. -Vesa Karvonen _________________________________________________________________ The new MSN 8: advanced junk mail protection and 2 months FREE* http://join.msn.com/?page=features/junkmail

2 1

Re: Some remarks on PP docs
by Vesa Karvonen 12 Jun '04

12 Jun '04

David Abrahams: >I'm writing an appendix on the PP lib for the MPL book today. I think >that'll demonstrate that it's possible to provide a reasonable gentle >and high-level introduction without exposing too many ugly details. That would be great! >- Fundamental PP Abstractions > - Macros > - Non function > - Function macros > - Tokens > - Sequences of tokens not including un-parenthesized commas Data structures are an important topic and their representation isn't fundamentally PP *library* specific. You might want to present the information on the representation of data structures (and simple macros like a projection operator for tuples and some sequences operations) here when you discuss fundamental PP abstractions. I would also probably discuss how to implement primitives like IF and WHILE using preprocessor macros at this point. The purpose being to show that the preprocessor is capable of significant computation. I would also emphasize that the purpose of explaining the techniques is not that people would roll their own versions, but simply to deepen their understanding of the preprocessor. >Well, if you really have a conforming C99 preprocessor, you could use >Paul M's Chaos, which I think is both easier to use and *way* more >efficient than the current Boost PP. >From what I know, Chaos is essentially an extended Boost.PP (meaning that Chaos is essentially a combinator library), with a single recursion backend (enabled by stricter requirements on preproprecessor conformance), which makes it more orthogonal. However, Chaos still shares many problems with Boost.PP, the main issues being that code will be highly verbose and very intricate. The verbosity and intricacy probably do not matter that much when one only performs simple repetition using the canned library macros. -Vesa Karvonen _________________________________________________________________ Protect your PC - get McAfee.com VirusScan Online http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963

3 5

Some remarks on PP docs
by David Abrahams 12 Jun '04

12 Jun '04

techniques.html: It is usually okay to use a standard macro name like BOOST_PP_DEF for this kind of code because the macro is both defined and undefined in the immediate site of its use. I was really confused by the use of the word "standard". This would be clearer: It is usually okay to reuse a single generic macro name like BOOST_PP_DEF throughout your code because the macro is both defined and undefined very close to its point of use. Although I don't know why you'd want to advocate that over using a descriptive name. ------ A clearer divider between examples would be a *huge* help visually. An <hr> would be enough, for example. Example - Use BOOST_PP_EMPTY as an unused parameter in local macro instantiations. #define BOOST_PP_DEF(cv) /* ... */ \ template<class base> \ cv() typename implement_subscript_using_begin_subscript<base>::value_type& \ implement_subscript_using_begin_subscript<base>::operator[](index_type i) cv() { \ return base::begin()[i]; \ } \ /**/ ?? Where is BOOST_PP_EMPTY used in this example? I think I know what you mean, but really, you need to show it! How: BOOST_PP_EMPTY() expands to nothing and can be used as an unused parameter. Note: BOOST_PP_EMPTY with the () never gets expanded. This sounds self-contradictory. Just above you said it expands (to nothing)! The () is necessary to invoke a function-like macro. No duh; I think stating the obvious that way only adds confusion. Caveat: You cannot safely use concatenation while using BOOST_PP_EMPTY(). That's way too vague and general. I certainly can use concatenation and BOOST_PP_EMPTY "together", for many reasonable definitions of that word! I think you need to be more specific, or strike it. ------ The BOOST_PP_ENUM_PARAMS example could benefit greatly from a side-by-side format in a table showing the expansion on the right. In fact, that would help all the examples, but in particular if you're just getting acquainted with the library at this point you may not have any idea what some of those macros do. You're advocating that people use them here, but unless the reader has some idea of what they generate, it's lost on her. Showing not-even-correct details of BOOST_PP_REPEAT's implementation doesn't help here. I'd strike it. Furthermore, BOOST_PP_ENUM_PARAMS and its variations use BOOST_PP_REPEAT. BOOST_PP_COMMA_IF(I) expands to a comma if I != 0. BOOST_PP_INC(I) essentially expands to "I+1," and BOOST_PP_DEC(I) essentially expands to "I-1.". I'd strike that too. You haven't said a word about BOOST_PP_INC/DEC yet, so the reader is left wondering why you're giving their implementation details. ----- Example - Use BOOST_PP_REPEAT and a token look-up function to eliminate categorical repetition. Is this really better than iterating over a SEQ of categories in any way other than efficiency? ----- Example - Use BOOST_PP_REPEAT to avoid O(n*n) repetition. It's unclear to me how that example avoids O(n*n) repetition. It certainly seems to have that complexity, and that appears to be intrinsic to the code it generates. Maybe you mean Example - Use BOOST_PP_REPEAT for O(n*n) repetition. Or something? ----- BOOST_PP_IF enables convenient generation of lists using BOOST_PP_REPEAT. This statement, without an example, is too vague to be helpful. ----- Implementation details of BOOST_PP_IF don't help: How: BOOST_PP_IF is defined for the entire repeat range (psuedo code): #define BOOST_PP_IF(c, THEN, ELSE) BOOST_PP_IF ## c(THEN, ELSE) #define BOOST_PP_IF0(THEN, ELSE) ELSE #define BOOST_PP_IF1(THEN, ELSE) THEN #define BOOST_PP_IF1(THEN, ELSE) THEN ^ especially since they appear to be wrong. I think the point is that BOOST_PP_IF works on first arguments other than 0 or 1. If so, you should just say that it works on numeric arguments up to N (whatever N is). --------- Example: Use arithmetic, logical, and comparison operations when necessary. With no commentary, and no generated code, this example is really useless. I mean, of course you'd use arithmetic, logical, and comparison operations "when neccessary". -- Dave Abrahams Boost Consulting http://www.boost-consulting.com

4 6

RE: [boost] Re: Documentation
by Reece Dunn 11 Jun '04

11 Jun '04

David Abrahams wrote: >"Reece Dunn" <msclrhd(a)hotmail.com> writes: > > David Abrahams wrote: > >>"Reece Dunn" <msclrhd(a)hotmail.com> writes: > >> > David B. Held wrote: > > It should be fairly easy to adapt the ReST/SpiritDoc/whatever > > translation phase to generate BoostBook instead of HTML. > >Yeah, especially since docutils (ReST) already contains a DocBook >generating backend. It can also be done with XSLT from the ReST XML >generator. But ReST doesn't contain ways to represent many of the >C++-specific logical elements of BoostBook, IIUC. These could always be added in by the author after the BoostBook files have been generated, if you are planning to migrate from ReST/SpiritDocs to BoostBook. This was the idea, to give the user a tool/toolset to help migrate to the BoostBook format. > >> > As far as I understand it, the BoostBook tool is relatively new and > >> > has a learning curve, so it will take some time to migrate the docs >to > >> > this format. > >> > >>And it requires writing in XML :-( or translating to it :-|. > > > > XML is essentially a stricter version of HTML. > >I thought the main thing was that it is extensible. It is. You can have any element and attribute structure you want; this is how it is extensible. What I was referring to is that XML emposes stricter formatting rules than HTML, requiring attributes to be quoted and all tags to have corresponding closing tags (the open/close tag being a special case). This might be new to people familiar only with HTML and so may make mistakes, resulting in an invalid XML file. Automating this conversion process will help ensure a valid XML file to work from. > > The main problem I see is porting the existing HTML-based docs to > > BoostBook. The others can be generated using a BoostBook generator > > (not sure how easy it will be for each format). > >There's no advantage to translating into BoostBook, AFAICT, unless >we're going to stick in its special logical elements. We can always >just use a common .css if you just want a similar look. I thought one of the ideas behind BoostBook was to have a documentation format that will eventually become Boost-wide. If this is the case, then having tools like what I'm suggesting will help speed up the migration process. If not, then what you are suggesting is also fine. Regards, Reece _________________________________________________________________ It's fast, it's easy and it's free. Get MSN Messenger today! http://www.msn.co.uk/messenger

1 0

Thread lib (good reason for static)
by Peter Danford 11 Jun '04

11 Jun '04

[This is from an email about the impact of not having a static Threads lib available anymore. I wanted to post this here to see if anyone else has similar experiences since I have only seen posts about the problem of distributing RTL dlls so far - not computation time impact.] Hello, I was reading some some of the posts about your thread implementation and the removal of the static RTL option. I understand the technical reason for this, but I wanted to submit another compelling reason (for me) for the need for static RTL linkage even if this means loosing some of the features under win32. Some of the software I develop deals with different types of analysis (such as scientific and financial). The runs can take as much as 20 hours to complete. If I do nothing but change to link with dynamic RTL, the run time is increased on average of 35%. This means and additional 7 hours of run time! So dynamic RTL is really undesirable. Do you see any way of making a more limited static Boost.threads available in the next Boost release? [Above I say "limited" because some of the features of the Thread lib must be implemented via dll to work under win32.] Peter --------------------------------- Do you Yahoo!? Friends. Fun. Try the all-new Yahoo! Messenger

10 46

RE: [boost] Re: Documentation
by Reece Dunn 11 Jun '04

11 Jun '04

David Abrahams wrote: >"Reece Dunn" <msclrhd(a)hotmail.com> writes: > > David B. Held wrote: > >>If we're going to demand uniformity in licensing, should we also > >>demand more uniformity in documentation? > > > > I agree on this. At the moment, we have the docs written in HTML, > > those in BoostBook format (like Boost.Any and the BBv2 docs) and the > > Spirit docs which have their own format. > >And others; we used ReST for the iterator library. It should be fairly easy to adapt the ReST/SpiritDoc/whatever translation phase to generate BoostBook instead of HTML. > > As far as I understand it, the BoostBook tool is relatively new and > > has a learning curve, so it will take some time to migrate the docs to > > this format. > >And it requires writing in XML :-( or translating to it :-|. XML is essentially a stricter version of HTML. The main problem I see is porting the existing HTML-based docs to BoostBook. The others can be generated using a BoostBook generator (not sure how easy it will be for each format). I have a Spirit-based HTML parser that does basic correction (not as good as HTMLTidy) that is event based (like SAX for XML) and can be used to generate XHTML. It should be possible to adapt this to generate a BoostBook document that can be used as the basis for migrated docs. The SpiritDoc processor tool is freely available and should be easy to migrate to BoostBook output. Other generators can be produced for ReST, etc. NOTE: The output of these should be seen as a basis for the actual docs as they won't be able to properly detect things like the licence info, author name or library name/category; these will need to be edited by the document provider. (It all depends on how this information is encoded in the base text. If there is a markup pattern, then it should be possible to identify this and extract the information.) Let me know if I should take a look into seeing how feasible this is. Having a common document format will help maintain a consistent navigation/look. Also, it should be possible to generate frames as an alternate look by editing the BoostBook stylesheets and with a little wizardry it should be possible ot turn this on or off, depending on your preferences like it is currently possible to select Spirit or DocBook navigation styles. Regards, Reece _________________________________________________________________ Want to block unwanted pop-ups? Download the free MSN Toolbar now! http://toolbar.msn.co.uk/

2 1

feature request: file lock
by Jordi Vilar 11 Jun '04

11 Jun '04

Hi, I propose the inclussion of the following set of private members to the boost::filesystem::fstream class: private: void do_lock(); bool do_trylock(); bool do_timedlock(const xtime& xt); void do_unlock(); void do_lock(cv_state& state); void do_unlock(cv_state& state); this will enable additional classes: namespace boost { namespace filesystem { class scooped_lock; class scooped_try_lock; class scoped_timed_lock; } } with an interface like boost::thread::scooped_lock and sccoped_try_lock. What do you think about this? If you want to proceed and need help, please let me know, I can provide an implementation for Windows (NT and above) and posix (I'm currently working on this functionality). Cordially, Jordi Vilar

1 0

program_options and optional
by Neal D. Becker 11 Jun '04

11 Jun '04

Seems natural to use boost::optional with program_options. Has anyone tried this? For example, consider this: int main (int argc, char** argv) { namespace po = boost::program_options; optional<double> x; po::options_description desc("Allowed options"); desc.add_options() ("help", "produce help message") ("x", po::value<double>()->notifier (var(x)=_1)) ; To set the optional<double> x, this uses boost::lambda. Is there a more direct approach?

2 1

Re:[boost] [serialization18] conflict definition of "is_abstract" with type traits library(in cvs)
by Robert Ramey 11 Jun '04

11 Jun '04

Allen Yao wrote: > The file is_abstract.hpp in serialization18 and is_abstract.hpp in type > traits library (in cvs) have conflict definitions of "boost::is_abstract". > May Ramey fix this. For now, I just comment out the latter in order to use > serialization18. I am aware of this. serialization #18 is meant to be compatible with boost 1.31. >In addition, I am confused with the ".ipp" files in libs/serialization/src/ >in serialization18. It is strange to write >#include <libs/serialization/src/basic_binary_oprimitive.ipp> // for serialization18 >in user code instead of >#include <boost/serialization/basic_binary_oprimitive.ipp> // for serialization17 >I wonder why these files can not be just named ".hpp" It is my practice to distinguish between header files containing declarations to be included by "users" of the library (*.hpp) from function implementations (*.cpp) and template implementations (*.ipp). I moved the *.ipp files to the src directory because they seemed no need for library users to ever include them when building with the library. Since then it has occurred to me that they may be included when one makes a new archive when deriving from an existing one. Accordingly, these *.ipp files will be moved to boost/archive/impl in the next version. This system is helpful to me - I don't know what other peoples views are on this. > when will we see the serialization library in boost cvs, please? I have made changes to address all issues raised in the recent review. I'm now making changes to permit builds on all the compilers I have. I hope to upload a version compatible with 1.31 "real soon now". I will then build against my cvs tree. Then I will request authorization to check in. It will take a little time. Robert Ramey

1 0

MSVC 7.1 and BOOST_NO_MEMBER_TEMPLATE_FRIENDS
by Maxim Yegorushkin 11 Jun '04

11 Jun '04

I think the following condition in visualc.hpp is incorrect #if _MSC_VER <= 1310 # define BOOST_NO_MEMBER_TEMPLATE_FRIENDS #endif I've checked that MSVC 7.1 supports memeber template syntax. And, AFAIR, MSVC 7.0 supports it too, but I haven't got it to check. Should the condition for BOOST_NO_MEMBER_TEMPLATE_FRIENDS macro here and in other places in visualc.hpp be changed to #if _MSC_VER < 1300? Or am I missing something? -- Maxim Yegorushkin

2 1

Re: Some remarks on PP docs
by Vesa Karvonen 11 Jun '04

11 Jun '04

Dave Abrahams: >I am not even trying to cover the whole PP library in this appendix, >much less the topic of PP metaprogramming in general. [...] [...] >... but, thanks for the suggestions. I don't mean to sound >ungrateful, but I'm really trying to limit this to a small-scale >practical overview of the things you need to know in order to get >started with the PP library. I see your point, but... >"Understanding the preprocessor and PP metaprogramming" is beyond the >scope of the book. ...while understanding all the consequences of the PP design is obviously not necessary for basic PP metaprogramming, I think that it is almost impossible to be able to use the PP (and the Boost.PP library) profitably (beoyond trivial use of macros like ENUM_PARAMS and REPEAT) without having a fairly good understanding of the capabilities and limitations of the PP. -Vesa Karvonen _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail

2 1

RE: [boost] Geometric Algebra Library
by Johannes Brunen 11 Jun '04

11 Jun '04

Hi Jaap, fine to hear that you are still working on your GA library. I'm eager to see such a library in the boost pool. So I'm very interested in the library. One point however, Paul Leopardi is still working on GluCat and I have the impression that he is also targeting boost. It would be fine if you could bundle together your efforts in oder to get the best of each GA libraries. With best regards, Johannes

1 0

[serialization18] conflict definition of "is_abstract" with type traits library(in cvs)
by Allen Yao 11 Jun '04

11 Jun '04

The file is_abstract.hpp in serialization18 and is_abstract.hpp in type traits library (in cvs) have conflict definitions of "boost::is_abstract". May Ramey fix this. For now, I just comment out the latter in order to use serialization18. In addition, I am confused with the ".ipp" files in libs/serialization/src/ in serialization18. It is strange to write #include <libs/serialization/src/basic_binary_oprimitive.ipp> // for serialization18 in user code instead of #include <boost/serialization/basic_binary_oprimitive.ipp> // for serialization17 I wonder why these files can not be just named ".hpp" Ramey, when will we see the serialization library in boost cvs, please? Thank you:)

1 0

[thread] Thread specific pointer cleanup handlers
by Malcolm Noyes 11 Jun '04

11 Jun '04

During my 'research' into different ways to implement thread specfic storage (tss) on Win32, I needed to implement custom cleanup handlers. The thread_dev branch allows for a custom cleanup handler on the basis of 'one cleanup handler per global object instance'. This is *not* the same as 'one cleanup handler per tss object instance' since with tss there is of course one object instance per thread. Consider: void no_cleanup(int*) { // do nothing } thread_specific_ptr p(no_cleanup); int main(int, char*[]) { int some_number = 42; // leaving aside why someone might want to do this, it's // the mechanincs that we're interested in! p.reset(&some_number); // fine p.reset(new int(0)); // leak - 'p' has no cleanup! return 0; } The theoretical alternative would be to allow (enforce?) a different cleanup handler per thread object, e.g.: void no_cleanup(int*) { // do nothing } void delete_cleanup(int* pd) { delete pd; } thread_specific_ptr p; int main(int, char*[]) { int some_number = 42; // this time call reset with a specfic handler for this thread //object instance p.reset(&some_number, no_cleanup); // fine p.reset(new int(0), delete_cleanup); // ok now, will call delete return 0; } My feeling is that boost::thread should only allow the first form and document that the use above leads to unspecified behaviour (it may not be a memory leak, we don't know what the cleanup handler may do). My only reason for this however is that allowing the latter case is probably not a frequent use and makes the implementation much complicated. Does anyone think the latter is required ? Malcolm Malcolm Noyes

1 0

[Test] Linking
by David B. Held 11 Jun '04

11 Jun '04

What is the canonical way to link the Boost.Test library? Is it better to just include the sources in the project, or to try to link to a built library? Dave --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com) Version: 6.0.701 / Virus Database: 458 - Release Date: 6/7/2004

2 1

boost::transform_iterator and boost::lambda functors
by Maxim Yegorushkin 10 Jun '04

10 Jun '04

Is there a way to make a boost::lambda functor adaptable, that is to make it define result_type? There is a ret<> function template that lets one specify the result type, but the returned functor still does not have result_type typedef. I've encountered the problem trying to use boost::transform_iterator with a boost::lambda functor: std::vector<int> intVect; boost::make_transform_iterator(intVect.begin(), boost::lambda::_1 / 2); transform_iterator<> does not compile comlaining the functor does not have result_type. As a workaround I had to write something like: template<class R, class T> struct result_type_wrapper : T { typedef R result_type; result_type_wrapper(T const& t) : T(t) {} }; template<class R, class T> inline result_type_wrapper<R, T> result_type(T const& t) { return t; } boost::make_transform_iterator(intVect.begin(), result_type<int>(boost::lambda::_1 / 2)); Am I missing something? Is there a way to avoid using result_type_wrapper<>? -- Maxim Yegorushkin

4 6

Re: Some remarks on PP docs
by Vesa Karvonen 10 Jun '04

10 Jun '04

David B. Held: >It's hard enough getting one's head around the PP lib without having to >be an expert in it already. [...] >It's a shame, because there's a lot of code that would benefit from the >PP lib that almost certainly isn't because of the difficult learning >curve. Learning Boost.Preprocessor is like learning a rather verbose and intricate programming language. It is not really surprising that it can be difficult to learn, although the documentation, at least the parts that I wrote, could certainly be improved. It is possible to implement a language using the C99 (or even the less capable C++97) preprocessor that would be much less verbose and intricate and would be significantly easier to use (see http://groups.yahoo.com/group/boost/files/Order/ for details), but it would come at some cost in efficiency (on some compilers the cost would probably be prohibitive and on some compilers the cost is insignificant). -Vesa Karvonen _________________________________________________________________ Protect your PC - get McAfee.com VirusScan Online http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963

2 2

Re: Some remarks on PP docs
by Vesa Karvonen 10 Jun '04

10 Jun '04

>techniques.html: Since I initially wrote the document, I might as well comment. >I was really confused by the use of the word "standard". This would >be clearer: > > It is usually okay to reuse a single generic macro name like > BOOST_PP_DEF throughout your code because the macro is both defined > and undefined very close to its point of use. Yeah, there is probably a better way to convey the idea. >Although I don't know why you'd want to advocate that over using a >descriptive name. Because those macros are essentially [used like] lambda expressions: ad hoc, short, local functions that you usually do not even want to name. There is also an additional benefit of using a single generic name. If you forget to write the #undef, you will more likely get a warning (or an error) from the preprocessor. #undefining local macros helps to avoid macro replacement related problems. >A clearer divider between examples would be a *huge* help visually. >An <hr> would be enough, for example. Looking at an old revision in CVS, this used to be the case. >?? Where is BOOST_PP_EMPTY used in this example? I think I know what >you mean, but really, you need to show it! Looking at old revisions in CVS, it used to be there (use of BOOST_PP_EMPTY). > Note: BOOST_PP_EMPTY with the () never gets expanded. > >This sounds self-contradictory. Just above you said it expands (to >nothing)! Again, looking old revisions in CVS, it used to read "without". > The () is necessary to invoke a function-like macro. > >No duh; I think stating the obvious that way only adds confusion. Perhaps. The point is to point out the reason why the macro does not get expanded. The idea of passing the "name" of a function like macro as a parameter may not be obvious to all. > Caveat: You cannot safely use concatenation while using >BOOST_PP_EMPTY(). > >That's way too vague and general. I certainly can use concatenation >and BOOST_PP_EMPTY "together", for many reasonable definitions of that >word! I think you need to be more specific, or strike it. Agreed. >The BOOST_PP_ENUM_PARAMS example could benefit greatly from a >side-by-side format in a table showing the expansion on the right. There used to be a page that contained all the examples of the tutorial after preprocessing (and formatting). You could then simply click the title of the example to see the preprocessed code. >Showing not-even-correct details of BOOST_PP_REPEAT's implementation >doesn't help here. I'd strike it. You are probably right. I suppose when I wrote that, I wanted to give an idea to the reader how such macros might be actually be implementable (so that it doesn't seem as magical as it otherwise might). Looking back, I think that it was a mistake, because I have seen several people inventing their own REPEAT-style macros rather than using the generic macros in the library. Although, it might be the case even if the tutorial were different (nothing would have prevented those same people from looking at the actual implementation and learning the same information). >Furthermore, > > BOOST_PP_ENUM_PARAMS and its variations use BOOST_PP_REPEAT. > BOOST_PP_COMMA_IF(I) expands to a comma if I != 0. BOOST_PP_INC(I) > essentially expands to "I+1," and BOOST_PP_DEC(I) essentially > expands to "I-1.". > >I'd strike that too. You haven't said a word about BOOST_PP_INC/DEC >yet, so the reader is left wondering why you're giving their >implementation details. I agree that the comment should be removed. I think that the comment has probably been more relevant at some stage (CVS would probably reveal it if this was the case), but the context was lost during editing. That ''BOOST_PP_DEC(I) essentially expands to "I-1"'' is hardly an implementation detail. >Is this really better than iterating over a SEQ of categories in any >way other than efficiency? At the time when the example was written, SEQ had not yet been invented and even lists were not as efficient and convenient as they are today. Unfortunately, the example was never updated. Today, I would generally advocate using a sequence (or some other data structure). > Example - Use BOOST_PP_REPEAT to avoid O(n*n) repetition. > >It's unclear to me how that example avoids O(n*n) repetition. The point is to avoid manual, source code time, repetition and replace it with automated, preprocessing time, repetition. The code that you will edit after using REPEAT will be only O(1) (and not O(n*n)). It is the same as using a high level language to avoid programming in machine language. Sure, the compiler translates the high level code to machine language (well, not exactly, but close enough), but this doesn't mean that (because of the translation) you would not be avoiding programming in machine language as you seem to suggest. > Example - Use BOOST_PP_REPEAT for O(n*n) repetition. > >Or something? That might be a better way to convey the idea. > BOOST_PP_IF enables convenient generation of lists using > BOOST_PP_REPEAT. > >This statement, without an example, is too vague to be helpful. I agree. >Implementation details of BOOST_PP_IF don't help: > > How: BOOST_PP_IF is defined for the entire repeat range (psuedo code): > #define BOOST_PP_IF(c, THEN, ELSE) BOOST_PP_IF ## c(THEN, ELSE) > > #define BOOST_PP_IF0(THEN, ELSE) ELSE > #define BOOST_PP_IF1(THEN, ELSE) THEN > #define BOOST_PP_IF1(THEN, ELSE) THEN > ^ >especially since they appear to be wrong. Again, looking at an old version in CVS, this used to be correct. >I think the point is that BOOST_PP_IF works on first arguments other >than 0 or 1. If so, you should just say that it works on numeric >arguments up to N (whatever N is). That is probably a better way to put it. Again, the idea was to show how IF might actually be implemented (to dispell the magic), but it was probably a mistake. > Example: Use arithmetic, logical, and comparison operations when > necessary. > >With no commentary, and no generated code, this example is really >useless. I mean, of course you'd use arithmetic, logical, and >comparison operations "when neccessary". Looking at an old [...], there used to be a comment: "The PREPROCESSOR library supports saturated arithmetic, logical and comparison operations on decimal integer literals in the range [0,BOOST_PP_LIMIT_MAG]. Suppose that you want to generate a numbered lists with a special element inserted at a desired position. For example: E0, E1, S, E2. Consider the following example:" The point of the example was really just to let the reader know that the library does contain macros for arithmetic, logic, etc... The example is admittedly weak and only designed to use some of the mentioned classes of macros. -Vesa Karvonen _________________________________________________________________ The new MSN 8: advanced junk mail protection and 2 months FREE* http://join.msn.com/?page=features/junkmail

2 1

Re:[boost] Some remarks on PP docs
by Robert Ramey 10 Jun '04

10 Jun '04

David Abrahams wrote ..... While your at it, it would be really helpful to have a section for each compiler indicating which BOOST_PP... macros they don't support. I would hope this just be started and as users (like me) could just send in notes according to their experience. Here's the first line: BOOST_PP_CAT doesn't work with VC 6. Robert Ramey

1 0

Re: [boost] Geometric Algebra Library
by Tim Stevenson 10 Jun '04

10 Jun '04

Hi Jaap, I'm very interested in something like your library. I've only just started to wrap my head around geometric algebra and I've been confining myself so far to just playing with simple problems on paper to see how it removes special boundary case handling for some simple algorithms. The computational complexity of the higher dimensions has always concerned me but it sounds like you are doing a lot of compile-time optimisation to save wasted calculations at run-time. In a few months I'm planning to devote a considerable amount of time to investigating Geometric Algebra in a lot more detail and your library sounds like a good tool to "play" with. I use both VC++ and GCC and I would be willing to devote some time to investigate porting your library to the latest version of GCC. Tim.

1 0

Re: [boost] Problem with mpl::iter_fold_if.hpp in vacpp 6.0
by Toon Knapen 10 Jun '04

10 Jun '04

Joaquín Mª López Muñoz wrote: > Hi Toon, maybe we have advanced a little, since, if I'm ont wrong, the > error triggers at the second argument of the ctor. I've applied a > similar patch to this as well. Could you please try the attached file? This seems to solve the problem in the multi_index library ;-) but now compilation is aborted due to errors encountered while including the tuple library in the multi_index library ;-( See the compiler-messages in attachment: ...found 1065 targets... ...updating 72 targets... xlc-C++-action /home/tk/cvstop/DO/bin/boost/libs/multi_index/test/test_basic.test/vacpp/debug/test_basic.o "/home/tk/ext_projects/boost/boost_tknapen/boost/boost/mpl/set/aux_/item.hpp", line 82.25: 1540-0095 (W) The friend function declaration "operator/" will cause an error when the enclosing template class is instantiated with arguments that declare a friend function that does not match an existing definition. The function declares only one function because it is not a template but the function type depends on one or more template parameters. "/home/tk/ext_projects/boost/boost_tknapen/boost/boost/mpl/set/aux_/item.hpp", line 83.25: 1540-0095 (W) The friend function declaration "operator%" will cause an error when the enclosing template class is instantiated with arguments that declare a friend function that does not match an existing definition. The function declares only one function because it is not a template but the function type depends on one or more template parameters. "/home/tk/ext_projects/boost/boost_tknapen/boost/boost/tuple/detail/tuple_basic.hpp", line 214.12: 1540-0711 (S) Too few template arguments have been specified. "/home/tk/ext_projects/boost/boost_tknapen/boost/boost/tuple/detail/tuple_basic.hpp", line 211.1: 1540-0700 (I) The previous message was produced while processing "boost::tuples::get<1,boost::multi_index::identity<employee>,boost::tuples::cons<std::less<employee>,boost::tuples::null_type> >(const cons<boost::multi_index::identity<employee>,boost::tuples::cons<std::less<employee>,boost::tuples::null_type> > &)". "/home/tk/ext_projects/boost/boost_tknapen/boost/boost/multi_index/ordered_index.hpp", line 451.10: 1540-0700 (I) The previous message was produced while processing "boost::multi_index::detail::ordered_index<boost::multi_index::identity<employee>,std::less<employee>,boost::multi_index::detail::ordered_index<boost::multi_index::member<employee,std::basic_string<char,std::char_traits<char>,std::allocator<char> >,&employee::name>,std::less<std::basic_string<char,std::char_traits<char>,std::allocator<char> > >,boost::multi_index::detail::ordered_index<boost::multi_index::member<employee,int,&employee::...". "/home/tk/ext_projects/boost/boost_tknapen/boost/boost/multi_index_container.hpp", line 130.12: 1540-0700 (I) The previous message was produced while processing "boost::multi_index::multi_index_container<struct employee,struct boost::multi_index::indexed_by<boost::multi_index::ordered_unique<boost::multi_index::identity<employee>,boost::multi_index::detail::null_arg,boost::multi_index::detail::null_arg>,boost::multi_index::ordered_non_unique<boost::multi_index::tag<name,by_name,boost::mpl::void_,boost::mpl::void_,boost::mpl::void_,boost::mpl::void_,boost::mpl::void_,boost::mpl::void_,boost::mpl...". "../../../libs/multi_index/test/test_basic.cpp", line 40.25: 1540-0700 (I) The previous message was produced while processing "test_basic()". "/home/tk/ext_projects/boost/boost_tknapen/boost/boost/tuple/detail/tuple_basic.hpp", line 214.12: 1540-0711 (S) Too few template arguments have been specified. "/home/tk/ext_projects/boost/boost_tknapen/boost/boost/tuple/detail/tuple_basic.hpp", line 211.1: 1540-0700 (I) The previous message was produced while processing "boost::tuples::get<0,boost::multi_index::identity<employee>,boost::tuples::cons<std::less<employee>,boost::tuples::null_type> >(const cons<boost::multi_index::identity<employee>,boost::tuples::cons<std::less<employee>,boost::tuples::null_type> > &)". "/home/tk/ext_projects/boost/boost_tknapen/boost/boost/multi_index/ordered_index.hpp", line 450.9: 1540-0700 (I) The previous message was produced while processing "boost::multi_index::detail::ordered_index<boost::multi_index::identity<employee>,std::less<employee>,boost::multi_index::detail::ordered_index<boost::multi_index::member<employee,std::basic_string<char,std::char_traits<char>,std::allocator<char> >,&employee::name>,std::less<std::basic_string<char,std::char_traits<char>,std::allocator<char> > >,boost::multi_index::detail::ordered_index<boost::multi_index::member<employee,int,&employee::...". "/home/tk/ext_projects/boost/boost_tknapen/boost/boost/multi_index_container.hpp", line 130.12: 1540-0700 (I) The previous message was produced while processing "boost::multi_index::multi_index_container<struct employee,struct boost::multi_index::indexed_by<boost::multi_index::ordered_unique<boost::multi_index::identity<employee>,boost::multi_index::detail::null_arg,boost::multi_index::detail::null_arg>,boost::multi_index::ordered_non_unique<boost::multi_index::tag<name,by_name,boost::mpl::void_,boost::mpl::void_,boost::mpl::void_,boost::mpl::void_,boost::mpl::void_,boost::mpl::void_,boost::mpl...". "../../../libs/multi_index/test/test_basic.cpp", line 40.25: 1540-0700 (I) The previous message was produced while processing "test_basic()". "/home/tk/ext_projects/boost/boost_tknapen/boost/boost/tuple/detail/tuple_basic.hpp", line 214.12: 1540-0711 (S) Too few template arguments have been specified. "/home/tk/ext_projects/boost/boost_tknapen/boost/boost/tuple/detail/tuple_basic.hpp", line 211.1: 1540-0700 (I) The previous message was produced while processing "boost::tuples::get<1,boost::multi_index::member<employee,std::basic_string<char,std::char_traits<char>,std::allocator<char> >,&employee::name>,boost::tuples::cons<std::less<std::basic_string<char,std::char_traits<char>,std::allocator<char> > >,boost::tuples::null_type> >(const cons<boost::multi_index::member<employee,std::basic_string<char,std::char_traits<char>,std::allocator<char> >,&employee::name>,boost::tuples::cons<std::less<std:...". "/home/tk/ext_projects/boost/boost_tknapen/boost/boost/multi_index/ordered_index.hpp", line 451.10: 1540-0700 (I) The previous message was produced while processing "boost::multi_index::detail::ordered_index<boost::multi_index::member<employee,std::basic_string<char,std::char_traits<char>,std::allocator<char> >,&employee::name>,std::less<std::basic_string<char,std::char_traits<char>,std::allocator<char> > >,boost::multi_index::detail::ordered_index<boost::multi_index::member<employee,int,&employee::age>,std::less<int>,boost::multi_index::detail::sequenced_index<boost::multi_index::detail::index_bas...". "/home/tk/ext_projects/boost/boost_tknapen/boost/boost/multi_index/ordered_index.hpp", line 443.5: 1540-0700 (I) The previous message was produced while processing "boost::multi_index::detail::ordered_index<boost::multi_index::identity<employee>,std::less<employee>,boost::multi_index::detail::ordered_index<boost::multi_index::member<employee,std::basic_string<char,std::char_traits<char>,std::allocator<char> >,&employee::name>,std::less<std::basic_string<char,std::char_traits<char>,std::allocator<char> > >,boost::multi_index::detail::ordered_index<boost::multi_index::member<employee,int,&employee::...". "/home/tk/ext_projects/boost/boost_tknapen/boost/boost/multi_index_container.hpp", line 130.12: 1540-0700 (I) The previous message was produced while processing "boost::multi_index::multi_index_container<struct employee,struct boost::multi_index::indexed_by<boost::multi_index::ordered_unique<boost::multi_index::identity<employee>,boost::multi_index::detail::null_arg,boost::multi_index::detail::null_arg>,boost::multi_index::ordered_non_unique<boost::multi_index::tag<name,by_name,boost::mpl::void_,boost::mpl::void_,boost::mpl::void_,boost::mpl::void_,boost::mpl::void_,boost::mpl::void_,boost::mpl...". "../../../libs/multi_index/test/test_basic.cpp", line 40.25: 1540-0700 (I) The previous message was produced while processing "test_basic()". "/home/tk/ext_projects/boost/boost_tknapen/boost/boost/tuple/detail/tuple_basic.hpp", line 214.12: 1540-0711 (S) Too few template arguments have been specified. "/home/tk/ext_projects/boost/boost_tknapen/boost/boost/tuple/detail/tuple_basic.hpp", line 211.1: 1540-0700 (I) The previous message was produced while processing "boost::tuples::get<0,boost::multi_index::member<employee,std::basic_string<char,std::char_traits<char>,std::allocator<char> >,&employee::name>,boost::tuples::cons<std::less<std::basic_string<char,std::char_traits<char>,std::allocator<char> > >,boost::tuples::null_type> >(const cons<boost::multi_index::member<employee,std::basic_string<char,std::char_traits<char>,std::allocator<char> >,&employee::name>,boost::tuples::cons<std::less<std:...". "/home/tk/ext_projects/boost/boost_tknapen/boost/boost/multi_index/ordered_index.hpp", line 450.9: 1540-0700 (I) The previous message was produced while processing "boost::multi_index::detail::ordered_index<boost::multi_index::member<employee,std::basic_string<char,std::char_traits<char>,std::allocator<char> >,&employee::name>,std::less<std::basic_string<char,std::char_traits<char>,std::allocator<char> > >,boost::multi_index::detail::ordered_index<boost::multi_index::member<employee,int,&employee::age>,std::less<int>,boost::multi_index::detail::sequenced_index<boost::multi_index::detail::index_bas...". "/home/tk/ext_projects/boost/boost_tknapen/boost/boost/multi_index/ordered_index.hpp", line 443.5: 1540-0700 (I) The previous message was produced while processing "boost::multi_index::detail::ordered_index<boost::multi_index::identity<employee>,std::less<employee>,boost::multi_index::detail::ordered_index<boost::multi_index::member<employee,std::basic_string<char,std::char_traits<char>,std::allocator<char> >,&employee::name>,std::less<std::basic_string<char,std::char_traits<char>,std::allocator<char> > >,boost::multi_index::detail::ordered_index<boost::multi_index::member<employee,int,&employee::...". "/home/tk/ext_projects/boost/boost_tknapen/boost/boost/multi_index_container.hpp", line 130.12: 1540-0700 (I) The previous message was produced while processing "boost::multi_index::multi_index_container<struct employee,struct boost::multi_index::indexed_by<boost::multi_index::ordered_unique<boost::multi_index::identity<employee>,boost::multi_index::detail::null_arg,boost::multi_index::detail::null_arg>,boost::multi_index::ordered_non_unique<boost::multi_index::tag<name,by_name,boost::mpl::void_,boost::mpl::void_,boost::mpl::void_,boost::mpl::void_,boost::mpl::void_,boost::mpl::void_,boost::mpl...". "../../../libs/multi_index/test/test_basic.cpp", line 40.25: 1540-0700 (I) The previous message was produced while processing "test_basic()". xlC -c -I/home/tk/ext_projects/boost/boost_tknapen/boost -qNOOPTimize -qnoinline -g -qfullpath -qnotempinc -qfuncsect -qeh -qrtti -I"/home/tk/cvstop/DO/bin/boost/libs/multi_index/test" -I"/home/tk/ext_projects/boost/boost_tknapen/boost" -o "/home/tk/cvstop/DO/bin/boost/libs/multi_index/test/test_basic.test/vacpp/debug/test_basic.o" "../../../libs/multi_index/test/test_basic.cpp" ...failed xlc-C++-action /home/tk/cvstop/DO/bin/boost/libs/multi_index/test/test_basic.test/vacpp/debug/test_basic.o... ...skipped <@boost!libs!multi_index!test/test_basic.test/vacpp/debug>test_basic for lack of <@boost!libs!multi_index!test/test_basic.test/vacpp/debug>test_basic.o... xlc-C++-action /home/tk/cvstop/DO/bin/boost/libs/multi_index/test/test_capacity.test/vacpp/debug/test_capacity.o "/home/tk/ext_projects/boost/boost_tknapen/boost/boost/mpl/set/aux_/item.hpp", line 82.25: 1540-0095 (W) The friend function declaration "operator/" will cause an error when the enclosing template class is instantiated with arguments that declare a friend function that does not match an existing definition. The function declares only one function because it is not a template but the function type depends on one or more template parameters. "/home/tk/ext_projects/boost/boost_tknapen/boost/boost/mpl/set/aux_/item.hpp", line 83.25: 1540-0095 (W) The friend function declaration "operator%" will cause an error when the enclosing template class is instantiated with arguments that declare a friend function that does not match an existing definition. The function declares only one function because it is not a template but the function type depends on one or more template parameters. "/home/tk/ext_projects/boost/boost_tknapen/boost/boost/tuple/detail/tuple_basic.hpp", line 214.12: 1540-0711 (S) Too few template arguments have been specified. "/home/tk/ext_projects/boost/boost_tknapen/boost/boost/tuple/detail/tuple_basic.hpp", line 211.1: 1540-0700 (I) The previous message was produced while processing "boost::tuples::get<0,boost::multi_index::identity<employee>,boost::tuples::cons<std::less<employee>,boost::tuples::null_type> >(const cons<boost::multi_index::identity<employee>,boost::tuples::cons<std::less<employee>,boost::tuples::null_type> > &)". "/home/tk/ext_projects/boost/boost_tknapen/boost/boost/multi_index/ordered_index.hpp", line 450.9: 1540-0700 (I) The previous message was produced while processing "boost::multi_index::detail::ordered_index<boost::multi_index::identity<employee>,std::less<employee>,boost::multi_index::detail::ordered_index<boost::multi_index::member<employee,std::basic_string<char,std::char_traits<char>,std::allocator<char> >,&employee::name>,std::less<std::basic_string<char,std::char_traits<char>,std::allocator<char> > >,boost::multi_index::detail::ordered_index<boost::multi_index::member<employee,int,&employee::...". "/home/tk/ext_projects/boost/boost_tknapen/boost/boost/multi_index_container.hpp", line 130.12: 1540-0700 (I) The previous message was produced while processing "boost::multi_index::multi_index_container<struct employee,struct boost::multi_index::indexed_by<boost::multi_index::ordered_unique<boost::multi_index::identity<employee>,boost::multi_index::detail::null_arg,boost::multi_index::detail::null_arg>,boost::multi_index::ordered_non_unique<boost::multi_index::tag<name,by_name,boost::mpl::void_,boost::mpl::void_,boost::mpl::void_,boost::mpl::void_,boost::mpl::void_,boost::mpl::void_,boost::mpl...". "../../../libs/multi_index/test/test_capacity.cpp", line 22.16: 1540-0700 (I) The previous message was produced while processing "test_capacity()". "/home/tk/ext_projects/boost/boost_tknapen/boost/boost/tuple/detail/tuple_basic.hpp", line 214.12: 1540-0711 (S) Too few template arguments have been specified. "/home/tk/ext_projects/boost/boost_tknapen/boost/boost/tuple/detail/tuple_basic.hpp", line 211.1: 1540-0700 (I) The previous message was produced while processing "boost::tuples::get<1,boost::multi_index::identity<employee>,boost::tuples::cons<std::less<employee>,boost::tuples::null_type> >(const cons<boost::multi_index::identity<employee>,boost::tuples::cons<std::less<employee>,boost::tuples::null_type> > &)". "/home/tk/ext_projects/boost/boost_tknapen/boost/boost/multi_index/ordered_index.hpp", line 451.10: 1540-0700 (I) The previous message was produced while processing "boost::multi_index::detail::ordered_index<boost::multi_index::identity<employee>,std::less<employee>,boost::multi_index::detail::ordered_index<boost::multi_index::member<employee,std::basic_string<char,std::char_traits<char>,std::allocator<char> >,&employee::name>,std::less<std::basic_string<char,std::char_traits<char>,std::allocator<char> > >,boost::multi_index::detail::ordered_index<boost::multi_index::member<employee,int,&employee::...". "/home/tk/ext_projects/boost/boost_tknapen/boost/boost/multi_index_container.hpp", line 130.12: 1540-0700 (I) The previous message was produced while processing "boost::multi_index::multi_index_container<struct employee,struct boost::multi_index::indexed_by<boost::multi_index::ordered_unique<boost::multi_index::identity<employee>,boost::multi_index::detail::null_arg,boost::multi_index::detail::null_arg>,boost::multi_index::ordered_non_unique<boost::multi_index::tag<name,by_name,boost::mpl::void_,boost::mpl::void_,boost::mpl::void_,boost::mpl::void_,boost::mpl::void_,boost::mpl::void_,boost::mpl...". "../../../libs/multi_index/test/test_capacity.cpp", line 22.16: 1540-0700 (I) The previous message was produced while processing "test_capacity()". "/home/tk/ext_projects/boost/boost_tknapen/boost/boost/tuple/detail/tuple_basic.hpp", line 214.12: 1540-0711 (S) Too few template arguments have been specified. "/home/tk/ext_projects/boost/boost_tknapen/boost/boost/tuple/detail/tuple_basic.hpp", line 211.1: 1540-0700 (I) The previous message was produced while processing "boost::tuples::get<1,boost::multi_index::member<employee,std::basic_string<char,std::char_traits<char>,std::allocator<char> >,&employee::name>,boost::tuples::cons<std::less<std::basic_string<char,std::char_traits<char>,std::allocator<char> > >,boost::tuples::null_type> >(const cons<boost::multi_index::member<employee,std::basic_string<char,std::char_traits<char>,std::allocator<char> >,&employee::name>,boost::tuples::cons<std::less<std:...". "/home/tk/ext_projects/boost/boost_tknapen/boost/boost/multi_index/ordered_index.hpp", line 451.10: 1540-0700 (I) The previous message was produced while processing "boost::multi_index::detail::ordered_index<boost::multi_index::member<employee,std::basic_string<char,std::char_traits<char>,std::allocator<char> >,&employee::name>,std::less<std::basic_string<char,std::char_traits<char>,std::allocator<char> > >,boost::multi_index::detail::ordered_index<boost::multi_index::member<employee,int,&employee::age>,std::less<int>,boost::multi_index::detail::sequenced_index<boost::multi_index::detail::index_bas...". "/home/tk/ext_projects/boost/boost_tknapen/boost/boost/multi_index/ordered_index.hpp", line 443.5: 1540-0700 (I) The previous message was produced while processing "boost::multi_index::detail::ordered_index<boost::multi_index::identity<employee>,std::less<employee>,boost::multi_index::detail::ordered_index<boost::multi_index::member<employee,std::basic_string<char,std::char_traits<char>,std::allocator<char> >,&employee::name>,std::less<std::basic_string<char,std::char_traits<char>,std::allocator<char> > >,boost::multi_index::detail::ordered_index<boost::multi_index::member<employee,int,&employee::...". "/home/tk/ext_projects/boost/boost_tknapen/boost/boost/multi_index_container.hpp", line 130.12: 1540-0700 (I) The previous message was produced while processing "boost::multi_index::multi_index_container<struct employee,struct boost::multi_index::indexed_by<boost::multi_index::ordered_unique<boost::multi_index::identity<employee>,boost::multi_index::detail::null_arg,boost::multi_index::detail::null_arg>,boost::multi_index::ordered_non_unique<boost::multi_index::tag<name,by_name,boost::mpl::void_,boost::mpl::void_,boost::mpl::void_,boost::mpl::void_,boost::mpl::void_,boost::mpl::void_,boost::mpl...". "../../../libs/multi_index/test/test_capacity.cpp", line 22.16: 1540-0700 (I) The previous message was produced while processing "test_capacity()". "/home/tk/ext_projects/boost/boost_tknapen/boost/boost/tuple/detail/tuple_basic.hpp", line 214.12: 1540-0711 (S) Too few template arguments have been specified. "/home/tk/ext_projects/boost/boost_tknapen/boost/boost/tuple/detail/tuple_basic.hpp", line 211.1: 1540-0700 (I) The previous message was produced while processing "boost::tuples::get<0,boost::multi_index::member<employee,std::basic_string<char,std::char_traits<char>,std::allocator<char> >,&employee::name>,boost::tuples::cons<std::less<std::basic_string<char,std::char_traits<char>,std::allocator<char> > >,boost::tuples::null_type> >(const cons<boost::multi_index::member<employee,std::basic_string<char,std::char_traits<char>,std::allocator<char> >,&employee::name>,boost::tuples::cons<std::less<std:...". "/home/tk/ext_projects/boost/boost_tknapen/boost/boost/multi_index/ordered_index.hpp", line 450.9: 1540-0700 (I) The previous message was produced while processing "boost::multi_index::detail::ordered_index<boost::multi_index::member<employee,std::basic_string<char,std::char_traits<char>,std::allocator<char> >,&employee::name>,std::less<std::basic_string<char,std::char_traits<char>,std::allocator<char> > >,boost::multi_index::detail::ordered_index<boost::multi_index::member<employee,int,&employee::age>,std::less<int>,boost::multi_index::detail::sequenced_index<boost::multi_index::detail::index_bas...". "/home/tk/ext_projects/boost/boost_tknapen/boost/boost/multi_index/ordered_index.hpp", line 443.5: 1540-0700 (I) The previous message was produced while processing "boost::multi_index::detail::ordered_index<boost::multi_index::identity<employee>,std::less<employee>,boost::multi_index::detail::ordered_index<boost::multi_index::member<employee,std::basic_string<char,std::char_traits<char>,std::allocator<char> >,&employee::name>,std::less<std::basic_string<char,std::char_traits<char>,std::allocator<char> > >,boost::multi_index::detail::ordered_index<boost::multi_index::member<employee,int,&employee::...". "/home/tk/ext_projects/boost/boost_tknapen/boost/boost/multi_index_container.hpp", line 130.12: 1540-0700 (I) The previous message was produced while processing "boost::multi_index::multi_index_container<struct employee,struct boost::multi_index::indexed_by<boost::multi_index::ordered_unique<boost::multi_index::identity<employee>,boost::multi_index::detail::null_arg,boost::multi_index::detail::null_arg>,boost::multi_index::ordered_non_unique<boost::multi_index::tag<name,by_name,boost::mpl::void_,boost::mpl::void_,boost::mpl::void_,boost::mpl::void_,boost::mpl::void_,boost::mpl::void_,boost::mpl...". "../../../libs/multi_index/test/test_capacity.cpp", line 22.16: 1540-0700 (I) The previous message was produced while processing "test_capacity()". xlC -c -I/home/tk/ext_projects/boost/boost_tknapen/boost -qNOOPTimize -qnoinline -g -qfullpath -qnotempinc -qfuncsect -qeh -qrtti -I"/home/tk/cvstop/DO/bin/boost/libs/multi_index/test" -I"/home/tk/ext_projects/boost/boost_tknapen/boost" -o "/home/tk/cvstop/DO/bin/boost/libs/multi_index/test/test_capacity.test/vacpp/debug/test_capacity.o" "../../../libs/multi_index/test/test_capacity.cpp" ...failed xlc-C++-action /home/tk/cvstop/DO/bin/boost/libs/multi_index/test/test_capacity.test/vacpp/debug/test_capacity.o... ...skipped <@boost!libs!multi_index!test/test_capacity.test/vacpp/debug>test_capacity for lack of <@boost!libs!multi_index!test/test_capacity.test/vacpp/debug>test_capacity.o... xlc-C++-action /home/tk/cvstop/DO/bin/boost/libs/multi_index/test/test_comparison.test/vacpp/debug/test_comparison.o "/home/tk/ext_projects/boost/boost_tknapen/boost/boost/mpl/set/aux_/item.hpp", line 82.25: 1540-0095 (W) The friend function declaration "operator/" will cause an error when the enclosing template class is instantiated with arguments that declare a friend function that does not match an existing definition. The function declares only one function because it is not a template but the function type depends on one or more template parameters. "/home/tk/ext_projects/boost/boost_tknapen/boost/boost/mpl/set/aux_/item.hpp", line 83.25: 1540-0095 (W) The friend function declaration "operator%" will cause an error when the enclosing template class is instantiated with arguments that declare a friend function that does not match an existing definition. The function declares only one function because it is not a template but the function type depends on one or more template parameters.

3 2

uBLAS regression tests
by Vladimir Prus 10 Jun '04

10 Jun '04

Hello, currently uBLAS regression tests are defined in status/Jamfile directly. Will it be OK if I move them to libs/numeric/ublas? The reason I'd need that is that Boost.Build V2 version of uBLAS tests that was contributed by Michael Stevens lives in libs/numeric/ublas, and with the current setup its hard for me to automatically verify that V1 and V2 test results are the same. - Volodya

2 1

[bind] vc6 problem
by Vladimir Prus 10 Jun '04

10 Jun '04

Hello, when I try to compiler the following code snippet on vc6 I get a lot of errors: #include <locale> #include <boost/bind.hpp> void aux(const std::codecvt<wchar_t, char, mbstate_t>& cvt) { boost::bind(boost::mem_fn(&std::codecvt<wchar_t, char, mbstate_t>::in), &cvt, _1, _2, _3, _4, _5, _6, _7); } The errors are: vc-C++ ..\..\..\bin\boost\libs\program_options\build\libboost_program_options.lib\msvc\debug\convert.obj convert.cpp H:\Work\boost-rc\libs\program_options\build\../src/convert.cpp(14) : error C2780: 'class boost::_bi::?$bind_t@ABVtemplate-parameter-BAB@V?$dm@$DBAB@$DBAC@@_mfi@boost@@V?$list1@V?$value@$DBAB@@_bi@boost@@@_bi@3@ __cdecl boost::bind(R T::*,A1)' : expects 2 arguments - 9 provided H:\Work\boost-rc\boost/bind.hpp(1487) : see declaration of 'bind' H:\Work\boost-rc\libs\program_options\build\../src/convert.cpp(14) : error C2780: 'class boost::_bi::bind_t<R,struct boost::_mfi::cmf8<R,T,B1,B2,B3,B4,B5,B6,B7,B8>,class boost::_bi::list9<class boost::_bi::value<R>,class boost::_bi::value<R>,class boost::_bi::value<R>,class boost::_bi::value<R>,class boost::_bi::value<R>,class boost::_bi::value<R>,class boost::_bi::value<R>,class boost::_bi::value<R>,class boost::_bi::value<R> > > __cdecl boost::bind(R (__thiscall T::*)(B1,B2,B3,B4,B5,B6,B7,B8) const,A1,A2,A3,A4,A5,A6,A7,A8,A9)' : expects 10 arguments - 9 provided H:\Work\boost-rc\boost/bind/bind_mf_cc.hpp(223) : see declaration of 'bind' H:\Work\boost-rc\libs\program_options\build\../src/convert.cpp(14) : error C2780: 'class boost::_bi::bind_t<R,struct boost::_mfi::mf8<R,T,B1,B2,B3,B4,B5,B6,B7,B8>,class boost::_bi::list9<class boost::_bi::value<R>,class boost::_bi::value<R>,class boost::_bi::value<R>,class boost::_bi::value<R>,class boost::_bi::value<R>,class boost::_bi::value<R>,class boost::_bi::value<R>,class boost::_bi::value<R>,class boost::_bi::value<R> > > __cdecl boost::bind(R (__thiscall T::*)(B1,B2,B3,B4,B5,B6,B7,B8),A1,A2,A3,A4,A5,A6,A7,A8,A9)' : expects 10 arguments - 9 provided H:\Work\boost-rc\boost/bind/bind_mf_cc.hpp(212) : see declaration of 'bind' H:\Work\boost-rc\libs\program_options\build\../src/convert.cpp(14) : error C2784: 'class boost::_bi::bind_t<R,struct boost::_mfi::cmf7<R,T,B1,B2,B3,B4,B5,B6,B7>,class boost::_bi::list8<class boost::_bi::value<R>,class boost::_bi::value<R>,class boost::_bi::value<R>,class boost::_bi::value<R>,class boost::_bi::value<R>,class boost::_bi::value<R>,class boost::_bi::value<R>,class boost::_bi::value<R> > > __cdecl boost::bind(R (__thiscall T::*)(B1,B2,B3,B4,B5,B6,B7) const,A1,A2,A3,A4,A5,A6,A7,A8)' : could not deduce template argument for '<Unknown>' from 'struct boost::_mfi::cmf7<int,class std::codecvt<unsigned short,char,int>,int &,char const *,char const *,char const * &,unsigned short *,unsigned short *,unsigned short * &>' H:\Work\boost-rc\libs\program_options\build\../src/convert.cpp(14) : error C2784: 'class boost::_bi::bind_t<R,struct boost::_mfi::mf7<R,T,B1,B2,B3,B4,B5,B6,B7>,class boost::_bi::list8<class boost::_bi::value<R>,class boost::_bi::value<R>,class boost::_bi::value<R>,class boost::_bi::value<R>,class boost::_bi::value<R>,class boost::_bi::value<R>,class boost::_bi::value<R>,class boost::_bi::value<R> > > __cdecl boost::bind(R (__thiscall T::*)(B1,B2,B3,B4,B5,B6,B7),A1,A2,A3,A4,A5,A6,A7,A8)' : could not deduce template argument for '<Unknown>' from 'struct boost::_mfi::cmf7<int,class std::codecvt<unsigned short,char,int>,int &,char const *,char const *,char const * &,unsigned short *,unsigned short *,unsigned short * &>' H:\Work\boost-rc\libs\program_options\build\../src/convert.cpp(14) : error C2780: 'class boost::_bi::bind_t<R,struct boost::_mfi::cmf6<R,T,B1,B2,B3,B4,B5,B6>,class boost::_bi::list7<class boost::_bi::value<R>,class boost::_bi::value<R>,class boost::_bi::value<R>,class boost::_bi::value<R>,class boost::_bi::value<R>,class boost::_bi::value<R>,class boost::_bi::value<R> > > __cdecl boost::bind(R (__thiscall T::*)(B1,B2,B3,B4,B5,B6) const,A1,A2,A3,A4,A5,A6,A7)' : expects 8 arguments - 9 provided H:\Work\boost-rc\boost/bind/bind_mf_cc.hpp(175) : see declaration of 'bind' H:\Work\boost-rc\libs\program_options\build\../src/convert.cpp(14) : error C2780: 'class boost::_bi::bind_t<R,struct boost::_mfi::mf6<R,T,B1,B2,B3,B4,B5,B6>,class boost::_bi::list7<class boost::_bi::value<R>,class boost::_bi::value<R>,class boost::_bi::value<R>,class boost::_bi::value<R>,class boost::_bi::value<R>,class boost::_bi::value<R>,class boost::_bi::value<R> > > __cdecl boost::bind(R (__thiscall T::*)(B1,B2,B3,B4,B5,B6),A1,A2,A3,A4,A5,A6,A7)' : expects 8 arguments - 9 provided H:\Work\boost-rc\boost/bind/bind_mf_cc.hpp(164) : see declaration of 'bind' H:\Work\boost-rc\libs\program_options\build\../src/convert.cpp(14) : error C2780: 'class boost::_bi::bind_t<R,struct boost::_mfi::cmf5<R,T,B1,B2,B3,B4,B5>,class boost::_bi::list6<class boost::_bi::value<R>,class boost::_bi::value<R>,class boost::_bi::value<R>,class boost::_bi::value<R>,class boost::_bi::value<R>,class boost::_bi::value<R> > > __cdecl boost::bind(R (__thiscall T::*)(B1,B2,B3,B4,B5) const,A1,A2,A3,A4,A5,A6)' : expects 7 arguments - 9 provided H:\Work\boost-rc\boost/bind/bind_mf_cc.hpp(151) : see declaration of 'bind' And so on. Any ideas what I can do to workaround this? The code itself works fine on every other compiler. - Volodya

2 2

RE: [boost] Re: Thread lib (good reason for static)
by Hurd, Matthew 09 Jun '04

09 Jun '04

> Behalf Of scott > Assume use of a technique like the following (think this has been > presented as "object shim"?); > > T & > anastasia() > { > static T *p = new T; > return *p; > } > > as a means of dealing with global construction issue, i.e. instead > of expressions like "anastasia.data_member" the usage is > "anastasia().data_member". Also assume that some of these global > objects (i.e. shims) deploy mutexes for MT reasons. What happens > when there is more that one thread running around making calls > to shims? Instantiation of the global itself becomes an MT issue. That's what the double-checked locking pattern for singletons is for. Regards, Matt Hurd. _______________ Matt Hurd +61.2.8226.5029 hurdm(a)sig.com Susquehanna _______________ 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 3

regression test tools ported to vacpp
by Toon Knapen 09 Jun '04

09 Jun '04

The regression test tools are finally ported to vacpp version 6 and the regression test status will again be updated every day at 6am CET (unless new changes break the compilation again). Please don't hesitate to contact me when you want some help porting your boost library to the IBM/VisualAge platform. toon

3 5

CVS temporarily disabled
by David Abrahams 09 Jun '04

09 Jun '04

http://sourceforge.net/docman/display_doc.php?docid=2352&group_id=1#1086711… ( 2004-06-08 09:17:17 - Project CVS Service ) As of 2004-06-08 at 09:16 Pacific, developer CVS services have been disabled for some unplanned maintenance. We do not currently have an ETA for the duration of this outage but we do hope to minimize it as much as possible. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com

1 0

RE: [boost] Re: Thread lib (good reason for static)
by Hurd, Matthew 09 Jun '04

09 Jun '04

> Behalf Of Eric Niebler > Sent: Wednesday, 9 June 2004 9:15 AM > To: boost(a)lists.boost.org > Subject: [boost] Re: Thread lib (good reason for static) > > Hurd, Matthew wrote: > >>Behalf Of scott > >>Assume use of a technique like the following (think this has been > >>presented as "object shim"?); > >> > >>T & > >>anastasia() > >>{ > >> static T *p = new T; > >> return *p; > >>} > >> > >>as a means of dealing with global construction issue, i.e. instead > >>of expressions like "anastasia.data_member" the usage is > >>"anastasia().data_member". Also assume that some of these global > >>objects (i.e. shims) deploy mutexes for MT reasons. What happens > >>when there is more that one thread running around making calls > >>to shims? Instantiation of the global itself becomes an MT issue. > > > > > > That's what the double-checked locking pattern for singletons is for. > > > > Regards, > > > > Matt Hurd. > > > No, the double-checked locking pattern is only good as the subject of > talks describing why it's not good for anything. > > http://www.nwcpp.org/Downloads/2004/DCLP_notes.pdf Thanks. They are good notes. I'm aware of the portability issues. Doesn't mean you can't have valid platform specific singleton implementations that use the double checked locking pattern. The performance of the approach is too important to give up. Locking is slow. There are a lot of things you can't do portability in C++ which is one rationale for having libraries :-) Regards, Matt Hurd. _______________ Matt Hurd +61.2.8226.5029 hurdm(a)sig.com Susquehanna _______________ 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.

1 0

boost::any question
by Trey Jackson 08 Jun '04

08 Jun '04

All, I just started looking at boost::any, pretty nice. I looked at the implementation, and it uses (as you know) a pointer to an object (w/virtual methods) on the heap, and typeid to determine if conversion is possible. I understand the memory implications (a new object copied on heap). But I'd like to get a better handle on performance, namely: I'm unfamiliar with typeid - and how it's implemented. Does anyone have good pointers to how typeid is generally implemented? Or even specifically: I'm using gcc3.x on RH Linux. I'd just like to avoid/guarantee I'm not going to be hit by some O(N) look-up for using typeid a lot. thanks, TJ -- Trey Jackson tjackson(a)ichips.intel.com "Her hair glistened in the rain like nose hair after a sneeze." -- Chuck Smith, Woodbridge

3 3

Problem with mpl::iter_fold_if.hpp in vacpp 6.0
by Joaquín Mª López Muñoz 08 Jun '04

08 Jun '04

Regression tests show the following at different locations: "/home/tk/boost_regression/boost/boost/mpl/iter_fold_if.hpp", line 104.11: 1540-0038 (S) The name "typename result_::state" is not a type. I don't know how easy to fix this can be (for those who know the internals of MPL). Currently, the problem breaks uBLAS and multi_index. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

3 4

Problem building bjam executable
by Bart Garst 08 Jun '04

08 Jun '04

I'm trying to build the bjam executable by running build.bat from the boost/tools/build/jam_src directory. Here's what I get: C:\BOOST\TOOLS\BUILD\JAM_SRC>build.bat vc7 ### ### "Unknown toolset: vc7" ### ### You can specify the toolset as the argument, i.e.: ### .\build.bat msvc ### ### Toolsets supported by this script are: borland, como, gcc, gcc-nocygwin, intel-win32, metrowerks, mingw, msvc, vc7 ### I also tried running vcvars32 prior to build.bat and got this: C:\BOOST\TOOLS\BUILD\JAM_SRC>"e:\program files\microsoft visual studio .net\vc7\bin\vcvars32" C:\BOOST\TOOLS\BUILD\JAM_SRC>"E:\Program Files\Microsoft Visual Studio .NET\Common7\Tools\"vsvars32.bat Setting environment for using Microsoft Visual Studio .NET tools. (If you also have Visual C++ 6.0 installed and wish to use its tools from the command line, run vcvars32.bat for Visual C++ 6.0.) C:\BOOST\TOOLS\BUILD\JAM_SRC>build.bat vc7 Setting environment for using Microsoft Visual Studio .NET tools. (If you also have Visual C++ 6.0 installed and wish to use its tools from the command line, run vcvars32.bat for Visual C++ 6.0.) The system is Windows NT 4.0 SP6. I'm using a fresh cvs checkout of the entire boost source tree. I'd appreciate any help I can get with this. Thx, Bart

3 4

[assignment library post review]
by Thorsten Ottosen 08 Jun '04

08 Jun '04

Dear All, The post review version can be downloaded from http://tinyurl.com/38c7d Since the review this has changed: 1. insert()/assign() functions has been renamed to reflect which function that is called. So now push_back() is used for vector etc. 2. One header for each standard container. 3. New functions to allow for direct initialization: vector<int> v = list_of(1)(2)(3)(4)(5); map<string,int> m = map_list_of( "Foo", 1 )( "Bar", 2 ); 4. New heavily improved documentation 5. Support for arbitrary functions s.t. new types can benefit from the syntax easily. 6. removal of all half-backed stuff that nobody wanted 7. arguments are forwarded by value instead of const-reference. Reference is a pain to deal with when it comes to string literals. 8. A real test-suite has been added 9. portability has suffered a bit, but that can be solved later. Any comments about docs/implementation are welcome. There is one major isssue we must resolve: What should we call this library. Here are some choices: 1. Initialization library 2. Assignment library 3. Populate library 4. List library I personally would like Boost.List because the library is all about making list for use in various context. best regards Thorsten

3 3

[prereview request][fsm]
by Andreas Huber 07 Jun '04

07 Jun '04

Dear Boosters I think boost::fsm has finally reached a state that is worthy of a formal review. The .zip can be found here: http://boost-sandbox.sf.net/fsm.zip The docs are also available online: http://boost-sandbox.sf.net/libs/fsm As always: Feedback is highly welcome. Regards, Andreas

20 187

[spirit] rule<> and copying
by Thorsten Ottosen 07 Jun '04

07 Jun '04

Hi, I've been using spirit for some config-file parsing. I have some questions: 1. why can we not copy a rule<> ? 2. if we shouldn't copy a rule, why is copying not disabled? It has been a source of errors in my code that I forgot & on my return value. br Thorsten

8 23

token_iterator comments, suggestions
by Gennadiy Rozental 07 Jun '04

07 Jun '04

Hi, For long time in my daytime projects I was using my class token_iterator designed based on old iterator_adaptor design (adopted for old compilers). Now when need arose for such functionality in Boost.Test. I looked in direction of boost::token_iterator. After some struggle I end up adopting my version to new design. Here some of comments and issues that made me opt so. 1. token_iterator follows in a sense a Policy-based design (PBD). Where TokenizerFunc is a Policy that implements most of the functionality. The problem here IMO (unfortunately you see it now quite frequently), that I do not see a reason to use such a design. PBD makes sense it your generic component do a lot of work, provide common interface, combine several independent policies. In this case most what token_iterator does is just a forwarding (it become especially clear if you switch to use input_iterator_adaptor). It wouldn't be that bad, but PBD in this case causes significant usability inconvenience. Instead of plain and simple: token_iterator it( "a:b", ":" ); I have to write something like: token_iterator<char_delimiters_separator<char> > it( char_delimiters_separator<char>( ":" ), "a:b" ). All of that just because we have separate notion of Tokenizer function. IMO it too big price to pay. My suggestion is to get rid of the TokenizerFunction notion. Just implement many different iterators with the same scope of interest: tokenization. We will need to find proper names for iterators and instead of TokenizerFunc model description we may have page explaining how to write custom token iterators (if necessary, which I doubt). 2. token_iterator deals with begin/end iterators. I understand that in some rare cases there is need to iterate over range of iterators (BTW, std::input_iterator gonna be bad example - did you ever tried to use token_iterator over it?). But in most case we want to tokenize a string. And in most cases it either std::string or [char|wchar_t] const*. The fact that Iterator is a template parameter makes token_iterator usage quite inconvenient. In most cases the only template parameter that is required is IMO character type. My suggestion: lets have 2 different types if token iterators: one to iterate over string and separate to iterate over range of iterators. 3. I found it confusing in many cases how delimiters gets specified in token_iterator: token_iterator( "...", ":", " " ) Which string represent dropped delimiters, which kept? And what if I just want empty tokens? I need to write token_iterator( "...", "", "", keep_empty_tokens ) What are these two empty strings doing here?My suggestion is to use named parameters scheme. Like this: token_iterator( "...", dropped_delimiters = ":", kept_delimiters = " " ); 4. 2 Tokenizer functions use Traits as *policy* parameter. What actually is required in Compare predicate, that may or may not be implemented using char_traits. While std::basic_string references inside tokenizer function implementation should refer to traits by name std::char_traits 5. What if I want to use isspace as kept delimiters policy? There is no way to specify that. IMO delimiter policy should be separated (as runtime policy). 6. You use iterator_category as a selector of assigner. It's better to use traversal instead 7. In many places you use #if !defined(BOOST_MSVC) || BOOST_MSVC > 1300 typename #endif use BOOST_DEDUCED_TYPENAME instead 8. What is the purpose of token_iterator_generator. I do not see a need for one with new iterator facade design. 9. Why would we need all the access methods? Iterator base()const{return begin_;} Iterator end()const{return end_;}; TokenizerFunc tokenizer_function()const{return f_;} Type current_token()const{return tok_;} bool at_end()const{return valid_;} I couldn't imagine why do we need them. 10 Token iterator asserts in attempts to dereference or iterate end iterator. I don't believe it's correct. In many cases (mostly in design that assumes some optional tokens in the end) it's much more convenient this does not happened. My suggestion is to return empty token on dereference and stay quite on iteration. 11. In simpler design there won't be need in template copy constructor for token_iterator 12. Documentation need to be updated IMO, cause even as things stands now it dies not represent the best practice moved from type generators usage. 13. Files under libs/tokenizer lacks any structure required by boost standards. 14. There is no real test suite only some small examples supplied. 15. Why escaped_list_separator was named this way. It seems strange to emphasize in a name the fact that it use escape symbols, while major separations is that it is CSV list iterator - and this is how I would name it I implemented string_token_iterator and range_token_iterator for use in Boost.Test. See here (in a couple hours) http://tinyurl.com/28db9 for implementation and here http://tinyurl.com/287uk for test suite. Regards, Gennadiy.

5 16

Serializer and when to stop
by Darren Cook 07 Jun '04

07 Jun '04

I'm using boost::serializer between two programs: the first creates the data then serializes it, the second loads that data in and analyzes it. When I had just 420 data samples it all worked fine: I create a vector<Sample> in memory, serialized it and loaded it in the other side. When I moved to 7000 data samples the first program, the creator, sucked all the memory from the machine and then some. So I moved to serializing each data sample as it was created. To read it back in I changed my code from this: std::ifstream input_file(fname,std::ios::binary); boost::archive::binary_iarchive archive(input_file); std::vector<Sample> samples; archive>>samples; input_file.close(); Into this: std::ifstream input_file(fname,std::ios::binary); boost::archive::binary_iarchive archive(input_file); std::vector<Sample> samples; samples.reserve(8000); while(!input_file.eof()){ Sample s; archive>>s; samples.push_back(s); } input_file.close(); But every time it fails with an assert [1]. This seems to be when it has reached end of file. I cannot know in advance how many data samples I'll write to disk, so it seems I have three options: A: Make a special "zero" version of Sample to mark end of file B: At end of program 1 write the number of samples to a special file, and read that in before starting the above loop, so I know when to stop. C: Alter the serializer class to throw exception instead of an assert; I can then catch it and carry on. What is the best way? Is adding a terminator byte to boost::serializer an option (i.e. so I don't have to make a terminator version of each data structure I want to serialize). Incidentally my above loop does a copy of each sample as it adds it to the vector. Is the above code going to be common enough to make it worth including into boost::serializer as a helper function, which could then be optimized with in-place construction or something clever like that? (And then it could handle the termination handling itself as well.) Darren [1]: /usr/local/src/boost_1_31_0/boost/archive/basic_binary_iprimitive.hpp:119: void boost::archive::basic_binary_iprimitive<Archive, IStream>::load_binary(void*, unsigned int) [with Archive = boost::archive::binary_iarchive, IStream = std::basic_istream<char, std::char_traits<char> >]: Assertion `count == static_cast<size_t>(is.gcount())' failed.

2 1