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

RE: [boost] lexical_cast reviewed
by Michiel Salters 16 Jul '04

16 Jul '04

> -----Original Message----- > From: boost-bounces(a)lists.boost.org > [mailto:boost-bounces@lists.boost.org]On Behalf Of Jason > Sent: vrijdag 16 juli 2004 11:03 > To: boost(a)lists.boost.org > Subject: [boost] lexical_cast reviewed > > SOURCE CODE: > #include <sstream> > using namespace std; > class lexical_cast { > public: > template <typename Source> lexical_cast( const Source & source ) { > ss << source; > } > > template <typename Target> operator Target() { > Target target; > ss >> target; > return target; > } > private: > stringstream ss; > }; Not really lexical_cast, but useful nevertheless. Perhaps we could call it lexical_auto_cast. It could be more efficient to store a string instead, but I'm not sure. Regards, Michiel Salters 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.

2 1

[1.32 release] Branch for release postponed -- Plea for help
by Aleksey Gurtovoy 16 Jul '04

16 Jul '04

Branch for release scheduled for today, July 16, will NOT be performed. The two main showstoppers are an unsatisfactory state of the main trunk (http://tinyurl.com/25ar3) and a further delayed MPL check-in. It's going to take at least a couple more days for me to deal with the latter, and it would be really appreciated if during that time somebody would volunteer to work on clearing up the regression picture; the more volunteers, the better! Many library maintainers are already doing a good job at it, but the previous experience shows that whole thing can be made significantly more efficient if people who have local access to particular compilers failing on particular libraries [of their interest] took a look at those failures and reported back the results of their finding/posted patches/ checked in fixes. If each of us with a little bit of familiarity with the codebase/free time on their hands would take care of only a single failure, it would already make an enormous difference. Needless to say, everyone who contributes to this is going to be acknowledged when the release is out. (And a warm "thank you" to everybody who is already investing their time and energy into this!) -- Aleksey Gurtovoy MetaCommunications Engineering

4 4

Optional patch
by Hugo Duncan 16 Jul '04

16 Jul '04

The following clears the unexpected failure for optional on borland-5.6.4 Index: optional.hpp =================================================================== RCS file: /cvsroot/boost/boost/boost/optional/optional.hpp,v retrieving revision 1.1 diff -w -u -r1.1 optional.hpp --- optional.hpp 7 Jul 2004 15:10:03 -0000 1.1 +++ optional.hpp 16 Jul 2004 13:11:36 -0000 @@ -347,7 +347,7 @@ reference_const_type dereference( internal_type const* p, is_reference_tag ) const { return p->get() ; } reference_type dereference( internal_type* p, is_reference_tag ) { return p->get() ; } - void destroy_impl ( is_not_reference_tag ) { get_ptr_impl()->T::~T() ; m_initialized = false ; } + void destroy_impl ( is_not_reference_tag ) { get_ptr_impl()->internal_type::~internal_type() ; m_initialized = false ; } void destroy_impl ( is_reference_tag ) { m_initialized = false ; } // If T is of reference type, trying to get a pointer to the held value must result in a compile-time error.

2 1

[multi_array] problems with metacomm reports?
by Joaquín Mª López Muñoz 16 Jul '04

16 Jul '04

Please see http://tinyurl.com/57s3l If you click on most of the red-marked tests, you'll find that the output seems to show that they actually pass!! Is there something wrong with the report generation tool? Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

2 1

RE: [boost] [config] _WIN32 question
by Ferdinand Prantl 16 Jul '04

16 Jul '04

Hi Volodya, > From: boost-bounces(a)lists.boost.org > [mailto:boost-bounces@lists.boost.org] On Behalf Of Vladimir Prus > [snip] > Does it mean I have to use the same conditional? Which > compilers define __WIN32__ or WIN32, but don't define _WIN32? > Shouldn't there be a single BOOST_WINDOWS macros to help in > this cases? The macro _WIN32 was originally hard-coded into the Microsoft compiler to recognize the platform. The other vendors took it the same way, but maybe because of rapid development in the early ages there are more underscored versions available... Here we are macros *32*, as they are defined: Borland: __WIN32__ _WIN32 Digital Mars: _WIN32 GCC (MinG/W and Cygwin with -mno-cygwin): __MINGW32__ WIN32 _WIN32 __WIN32 __WIN32__ Metrowerks: _WIN32 Microsoft: _WIN32 The macro WIN32 is meant to be a user-definable option how to enforce a WIN32 code if a compiler does not define _WIN32. Cygwin platform in POSIX mode is not a WIN32-compatible platform (no headers, no libraries), and thus their macros should mark a POSIX code, not Windows: GCC (Cygwin in POSIX mode): __CYGWIN__ __CYGWIN32__ > FWIW, filesystem defines such macro internally: > > # if !defined( BOOST_WINDOWS ) && !defined( BOOST_POSIX ) > # if defined(_WIN32) || defined(__WIN32__) || defined(WIN32) > || defined(__CYGWIN__) > # define BOOST_WINDOWS > # else > # define BOOST_POSIX > # endif > # endif I like the single BOOST_XXX macro idea for all libraries, I would only delete __CYGWIN__, which defines POSIX compatibility. And if you like, it is possible to do something like this to be complete: BOOST_WIN32 : _WIN32 || WIN32 BOOST_WIN64 : _WIN64| WIN64 BOOST_WINDOWS : BOOST_WIN32 || BOOST_WIN64 Ferda > - Volodya

2 1

[1.32 release] TODO list synchronization
by Aleksey Gurtovoy 16 Jul '04

16 Jul '04

As we are coming closer to the branch-for-release date, I'd like to inquire developers working towards the release about the current status of their corresponding TODO items below. Simply replying to this message and saying "Done", "Not done, will be done by date X", "Abandoned" or whatever you wish to say on each of the items would be more than fine. > Circular Buffer > /////////////// > > Pavel Vozenilek writes: > > I asked Jan Galdun and he will try to make circular_buffer available > for 1.32. > > > Date-Time > ///////// > > Jeff Garland writes: > > And while I'm on the subject date-time plans for release, the only 'major > issue' for this release is whether we are switching to boost-book for this > release. We would like to, but if we don't make it we will do it for the next > release. > > > Iterators > ///////// > > David Abrahams writes: > > There are a couple of things that ideally I would like to handle, but > which I am not promising (yet): > > 1. Minor adjustments to code in the iterators library > 2. Iterators library doc fixes > > > MPL > /// > > New version of the library will be checked in the main trunk before July 11. Not done yet; July 15 is the new target. > > > Multi-Index > /////////// > > Joaquín Mª López Muñoz writes: > > 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. > > > Numeric Conversions > /////////////////// > > Fernando Cacciola writes: > > 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<> > > > Program Options > /////////////// > > Vladimir Prus writes: > > 1. Add markup for the current failures on Windows. I've done all workarounds I > planned. > 2. Finally get some results on gcc2.95-stlport. I expect that the library > should work there, but due to Boost.Test failure I don't have any results. > 3. Try to make Sun compiler happy. I'm comitted a workaround some time ago, > but tests on Solaris were not run since then. > 4. Check dynamic linking on Windows. > > > Serialization > ///////////// > > Robert Ramey writes: > > 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. > > > String Algorithms > ///////////////// > > Pavol Droba writes: > > I have few outstanding issues to fix, but they are mostly related to > the documentation. I think, I can manage it. > > As it seems, that the Range library will not make it to this release, > I will use the internal versions of facilities that are currently in the string_algo lib. > > So my todo list is as follows: > > 1) Finish the documentation > - Add functions list > - Add exception specifications > - Cleanup > > 2) Fix examples > 3) If there will be time, improve find_iterator > 4) Fix possible regressions. > > > Questions: > - I have posted some requestes/bugs on the boost-doc list. What is the status > of this. Will they be fixed before release? > > - According to metacom's tables regex is failing on comeau a so string_algo regex > test. Is this a setup or regex problem? > > - There is an problem with Intel compiler, split tests are failing and I cannot figureout > why. The message is very vague. Could somebody with an access to this platform, > try to debug the cause of the problem? > > - In regards to the older compiler support. I cannot resonably support compilers, that I > don't have an access to. Therefor if somebody is interested to use string_algo library > with one of such compilers, I will need an active help with porting. > > > uBLAS > ///// > > Michael Stevens writes: > > 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 in advance, -- Aleksey Gurtovoy MetaCommunications Engineering

10 26

lexical_cast reviewed
by Jason 16 Jul '04

16 Jul '04

after fidling around with template functions i discovered you could write lexical_cast without any template arguments _required_. Also I neat little C-Style cast although no one is probably interested in using that. Anyways the syntax is as followed for both: // lexical cast improved: string str = lexical_cast( 3.1415f ); int i = lexical_cast( "12345" ); // C-style cast fun! string str = (cstyle_cast)3.1415f; int i = (cstyle_cast)"12345"; I would say that anyone already using lexical_cast would'nt have a problem with the improved one. Let me know what you guys think and if we should implement that. -Jason SOURCE CODE: #include <sstream> using namespace std; class cstyle_cast { public: template <typename Source> cstyle_cast( const Source & source ) { ss << source; } template <typename Target> operator Target() { Target target; ss >> target; return target; } private: stringstream ss; }; class lexical_cast { public: template <typename Source> lexical_cast( const Source & source ) { ss << source; } template <typename Target> operator Target() { Target target; ss >> target; return target; } private: stringstream ss; }; int main() { string str1 = (cstyle_cast)3.141592f; string str2 = lexical_cast(3.141592f); }

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

ublas/traits.hpp not standalone
by Neal D. Becker 16 Jul '04

16 Jul '04

ublas/traits.hpp forgot to include some headers. Here is what happens: g++ -c -x c++ /usr/include/boost/numeric/ublas/traits.hpp /usr/include/boost/numeric/ublas/traits.hpp:1428: error: ISO C++ forbids declaration of `forward_iterator_base' with no type /usr/include/boost/numeric/ublas/traits.hpp:1428: error: template-id ` forward_iterator_base<std::forward_iterator_tag, I, T>' used as a declarator /usr/include/boost/numeric/ublas/traits.hpp:1428: error: syntax error before `; ' token /usr/include/boost/numeric/ublas/traits.hpp:1436: error: ISO C++ forbids declaration of `bidirectional_iterator_base' with no type /usr/include/boost/numeric/ublas/traits.hpp:1436: error: template-id ` bidirectional_iterator_base<std::bidirectional_iterator_tag, I, T>' used as a declarator /usr/include/boost/numeric/ublas/traits.hpp:1436: error: syntax error before `; ' token /usr/include/boost/numeric/ublas/traits.hpp:1443: error: ISO C++ forbids declaration of `bidirectional_iterator_base' with no type /usr/include/boost/numeric/ublas/traits.hpp:1443: error: template-id ` bidirectional_iterator_base<boost::numeric::ublas::sparse_bidirectional_iterator_tag, I, T>' used as a declarator /usr/include/boost/numeric/ublas/traits.hpp:1443: error: syntax error before `; ' token /usr/include/boost/numeric/ublas/traits.hpp:1451: error: ISO C++ forbids declaration of `random_access_iterator_base' with no type /usr/include/boost/numeric/ublas/traits.hpp:1451: error: template-id ` random_access_iterator_base<std::bidirectional_iterator_tag, I, T>' used as a declarator /usr/include/boost/numeric/ublas/traits.hpp:1451: error: syntax error before `; ' token /usr/include/boost/numeric/ublas/traits.hpp:1458: error: ISO C++ forbids declaration of `random_access_iterator_base' with no type /usr/include/boost/numeric/ublas/traits.hpp:1458: error: template-id ` random_access_iterator_base<boost::numeric::ublas::packed_random_access_iterator_tag, I, T>' used as a declarator /usr/include/boost/numeric/ublas/traits.hpp:1458: error: syntax error before `; ' token /usr/include/boost/numeric/ublas/traits.hpp:1465: error: ISO C++ forbids declaration of `random_access_iterator_base' with no type /usr/include/boost/numeric/ublas/traits.hpp:1465: error: template-id ` random_access_iterator_base<boost::numeric::ublas::dense_random_access_iterator_tag, I, T>' used as a declarator /usr/include/boost/numeric/ublas/traits.hpp:1465: error: syntax error before `; ' token

1 1

Re: [boost] Regression Tests, Boost.Serialization
by Reece Dunn 16 Jul '04

16 Jul '04

Martin Wille wrote: >Robert Ramey wrote: >>Jeff Garland wrote: >>>>Houston, we have a problem. >>[snip] >>It's a fact - running the bjam serialization test is going to consume 20 >>GB. > >The disk requirements can be changed. Stripping the test binaries >and removing the .o files already has been mentioned. Another >chance lies in merging similar (in terms of instantiated templates) >tests into one binary. It might also be beneficial to allow finer grained results within a test file. Let's say I have a test file stl_containers.cpp that tests std::vector, std::list, etc. Now, if a compiler has a problem with one of these (e.g. std::map) - if I understand the regression test system correctly - it will mark this test as failed in the regression results and a user would assume that all the stl_containers would be unusable! What I would like is to be able to group sets of tests (like in the unit tests), but to show a breakdown of those tests (e.g. for std::vector, std::deque, etc.) so that if one of these groups fail, the user can see that specific container doesn't work for a perticular compiler/platform. Regards, Reece _________________________________________________________________ Express yourself with cool new emoticons http://www.msn.co.uk/specials/myemo

1 0