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

Another spirit compile problem using HP aC++
by DY, JERRY U (SBCSI) 14 Jul '04

14 Jul '04

Here's another problem while compiling with aC++. This has been reported to the HP aC++ team, but in the meantime, I'm posting this fix to the list for review and for future users of Spirit for aC++. BTW, I'm a little afraid to commit changes to the repository, so quick question: If I end up committing changes that need to be backed out, can I delete that version that I committed easily? Thanks! boost/spirit/core/primitives/impl/match.ipp:101 ===old=== inline void match<nil_t>::swap(match& other) { std::swap(len, other.len); } ===new=== inline void match<nil_t>::swap(match<nil_t>& other) { std::swap(len, other.len); } -Jerry

3 2

uBLAS developers meeting ?
by Toon Knapen 14 Jul '04

14 Jul '04

I was discussing with Michael Stevens about organising a uBLAS developers meeting. And thus we decided to ask the community if 1) there would be any interest, 2) which topics people would like to discuss 3) what format would best fit, 4) and finally where and when. As for the topics (item 2), I think following list are certainly candidates: Evaluation of the design of uBLAS and discussion of future design Evaluation of the efficieny of uBLAS Syntax and ET engine Evaluation of the documentation and how to go from there. Restating the main goals of uBLAS Organisation of ublas project. overview of applications using uBLAS. As for the format I think most important are having intense discussions on the topics above. Presentations (by volunteers) could serve to initiate the dicussion on specific topics. Where and when to organise it probably depends on the interest from the developers. It seems like many active ublas-dev members are at most a few 100km from Cologne (Germany) so getting this group together could be easy in a small timeframe. But it is probably easier to discuss the 'where and when' once we have more information about 'who' would like to attend. toon

1 0

[Signals][Patch] test/ordering_test.cpp
by Juergen Hunold 14 Jul '04

14 Jul '04

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi ! the test in ordering_test.cpp does not use the BOOST_SIGNALS_NAMESPACE #define and therefore breaks if BOOST_SIGNALS_NAMESPACE is #defined to something else (for Qt-compatibilty, for example). The attached patch corrects this. Yours, Jürgen - -- * Dipl.-Math. Jürgen Hunold ! Institut für Verkehrswesen, Eisenbahnbau * voice: ++49 511 762-2529 ! und -betrieb, Universität Hannover * fax : ++49 511 762-3001 ! Appelstrasse 9a, D-30167 Hannover * hunold(a)ive.uni-hannover.de ! www.ive.uni-hannover.de -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFA9C9gljbJ/LLrxrYRAm35AJ9nHAPPumz4xPnPa0ZjQLlfiCkaTACgx1ys o/5GVsumKIOkGkYYoeHjVco= =aTJg -----END PGP SIGNATURE-----

2 1

RE: [boost] Re: compiling spirit parser using aC++
by DY, JERRY U (SBCSI) 14 Jul '04

14 Jul '04

Just tried and it compiled past this. More errors though. Thanks! -Jerry -----Original Message----- From: boost-bounces(a)lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Joel de Guzman Sent: Tuesday, July 13, 2004 5:16 PM To: boost(a)lists.boost.org Subject: Re: [boost] Re: compiling spirit parser using aC++ David Abrahams wrote: > Try this: > > typedef typename extract_int_<(MaxDigits >= 0)>::template > apply<Radix, MinDigits, MaxDigits, Accumulate> extractor; > extractor::f(scan,n,count); Forgot the return: return extractor::f(scan,n,count); Applied in the CVS. Thanks!

1 0

typeof
by Arkadiy Vertleyb 14 Jul '04

14 Jul '04

Hi everybody, Please find at http://groups.yahoo.com/group/boost/files/typeof.zip (and in the Spirit repository, TYPEOF_DEV branch) a new version of my typeof emulation library. This version has the documentation, as well as support for the following has been added: - arrays; - function pointers; - pointers to member functions; - pointers to data members. Any comments are welcome. I would also again greatly appreciate if anybody could try to compile the test with any compiler except VC7.1 (which I have), GCC and Metrowerks (which have native typeof support), or any compiler that does not support partial template specialization (which would not compile this anyway). Best regards, Arkadiy

6 35

compiling spirit parser using aC++
by DY, JERRY U (SBCSI) 14 Jul '04

14 Jul '04

I'm trying to get spirit parser to compile in aC++, but aC++ errors on the following line. The problem apparently is that aC++ is not recognizing extract_int_ as a type, so a preceding typename keyword is required for it to compile. Hoping to get instruction on how to change this so that it won't break other compilers? Thanks! boost/spirit/core/primitives/impl/numerics.ipp:305 return extract_int_<(MaxDigits >= 0)>::template apply<Radix, MinDigits, MaxDigits, Accumulate>:: f(scan, n, count); fixed for aC++ is as follows, but may break other compilers??: return typename extract_int_<(MaxDigits >= 0)>::template apply<Radix, MinDigits, MaxDigits, Accumulate>:: f(scan, n, count); -Jerry

3 2

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

making cvs change for the first time
by DY, JERRY U (SBCSI) 13 Jul '04

13 Jul '04

After several hours of trying, I finally got cvs to checkout the boost module into my server. I'm still reading the book on cvs, since I've never used that before (we use ClearCase here). I would like to starting "checking in" some changes I have made over the last coupleof months from my local copy of the boost source (mostly to get it to compile using aC++) so before I do anything that might break something, I wanted to advertise what I plan to do so the kind and knowledgeable folks of this list can guide me appropriately. I'll start with the simplest of changes: boost/config/compiler/hp_acc.hpp:45 =====old========== #if (__HP_aCC <= 53800 ) # define BOOST_NO_MEMBER_TEMPLATE_KEYWORD #endif =====new========= #if (__HP_aCC >= 50000 ) && (__HP_aCC <= 53800 ) || (__HP_aCC < 31300 ) # define BOOST_NO_MEMBER_TEMPLATE_KEYWORD #endif commit command to run: cvs commit -m "updated so template keyword is used for aC++ 3.13 & above" hp_acc.hpp Thanks! -Jerry

1 0

RE: [boost] Re: [iterator_facade] postfix ++/--
by Glen Knowles 13 Jul '04

13 Jul '04

> From: David Abrahams > > iterator_facade now has to choose between *r++ = o being > valid and being a conforming TR1 input iterator (which > requires *r++ is of type T -- we have since declared that a > defect and *r++ need only be convertible to T). It makes > that choice by looking at the CategoryOrTraversal parameter: > iff it's convertible to std::output_iterator_tag, *r++ = o > will be valid. > > I am thinking it might be more appropriate to detect that *r > is a proxy, and only make *r++ = o valid in that case. Can > anyone think of a reason that a non-writable iterator > implementation would need to return a proxy from its operator*? I may be confused as what qualifies as a proxy, but there is the vector<bool> case. OTOH, if you're talking about needing to reach back into the container its probably fine. I can imagine a caching scheme that returns a week_ptr and goes back to the container to recreate it if its gone, but I don't think I'd want to do it. :) Glen

2 1

[iterator_facade] postfix ++/--
by David Abrahams 13 Jul '04

13 Jul '04

I'm getting ready to fix the issues we've discussed with postfix ++ (and by extension, --) in iterator_facade. Basically, the current implementation works for forward iterators but not for some input iterators: { self x = *this; ++*this; // <== here return x; } The problem is that for many input iterators, all copies reference the same element. The marked line increments the iterator, which causes the current element of the sequence to be skipped, so *a++ yields the /next/ element. To fix that, a++ needs to return a proxy type. When considering this stuff, please look at n1640 and not C++98 or TC1, as n1640 contains fixes for outright bugs that survived to TC1 as well. In particular, *a++ was required to return an input iterator's value_type until recently. If we don't know for certain that the iterator is a forward iterator and if *a returns something convertible to T const& (where T is the iterator's value type) it seems to me that we *must* assume that all copies of the iterator reference the same element, so the result of postfix ++ must be a proxy that contains a copy of *a. The new iterator framework is intended to support iterators with bidirectional traversal that are not conforming forward iterators (e.g. their operator* may return by-value). If an iterator is incrementable it is also dereferenceable, but the same doesn't hold for decrementability, so I'm not sure what to do about the result of postfix --. The best solution I can think of is that the actual decrement is delayed, and the iterator being decremented contains a flag that says "do an extra decrement before the next operation other than postfix decrement". That's a really bad solution, though: you can't really do a decrement in the destructor because it might throw, and such an iterator could easily have side-effects, so it'd be easy to get the iterator out-of-synch with expectations. Thoughts? -- Dave Abrahams Boost Consulting http://www.boost-consulting.com

3 9