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