June 2004 - Boost - lists.stage.boost.cppalliance.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

7 19

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.

2 2

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

1 0

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 4

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 ___________________________________

10 60

[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

3 4

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.

1 0

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).

1 0

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

1 0

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

6 20