- Boost - lists.boost.org

Attn: Eric Niebler - Xpressive
by Dan 05 Jul '04

05 Jul '04

I downloaded the xpressive files and had a look through the files. I'm interested. I'd like to put xpressive to work in a real parsing application (it's the early stages of development so I'm confident we will work through any issues well before release). I've been getting a vague idea of how things work through the tests, and I may find more in the source files, but what I really need is a quick explanation of the basics. If you haven't already, I'd seriously recommend writing a quick start guide and placing it with the project files. If you have some documentation, I'd love to get access to that but otherwise just a brief explanation of the basics will suffice for now. It is my hopes that xpressive will make development and maintenance of our application easier and that our use of the library will help shape xpressive's development in a positive fashion. -Dan

2 1

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

Re: Boost Mathematicians
by Michael Stevens 05 Jul '04

05 Jul '04

On Saturday 03 July 2004 16:54,David Abrahams <dave(a)boost-consulting.com> > Jeremy and I have just completed a re-evaluation of uBlas based on > what's in uBlas' own CVS repository, having not discovered that until > recently (you should have that info on uBlas' Boost page!) We have > some major complaints with uBlas' design. The list is long, and the > issues run deep enough that we don't believe that uBlas is a suitable > foundation for the work we want to do. This is very interesting. Thanks for writing this up and posting. I can't address all the issues. However those which I can I will endeavor to give you and the Boost community my feedback on. First of all I am currently making sure Boost is updated with the latest uBLAS development version. This already has updated documentation which points to all the correct locations for discussions, CVS and Wiki. This should make it much easier for users to find the correct locations if the stable version in Boost does not meet their needs. To facilitate the development of solutions I will place many of the points into the uBLAS bug tracker on SF. > Interface Design > ---------------- > > * Not grounded in Generic Programming. The concept taxonomies, to the > extent they exist, are weak, and poorly/incorrectly documented. > Aspects of the design that should be generic are not (e.g. only > certain storage containers are supported, rather than supplying > storage concept requirements). No linear algebra concepts (vector > space, field, etc.) The library is so out-of-conformance with our > expectations for Generic Programming that this one item by itself > is probably enough to make it unsuitable for us. This is a big issue. I believe we need to split the documentation issues from the design issues. Documentation is high on the priority list of many uBLAS users and developers. Most new users start with a requirement for a C++ matrix and BLAS library with nice syntax, efficiency and documentation! The need for clearly defined and documented concepts comes for most people a little latter when extensibility becomes an issue. The storage concept is not as bad as it appears. The concept although not documented is sufficiently well defined that creating a new model is unproblematic. At present the concepts are documented by their models :-) > No linear algebra concepts (vector space, field, etc.) I not sure if these concepts really need to be defined. They are already well described in many mathematical text books and in Wikipedia. Almost all the major reference works on BLAS and Matrices simply state elements are either Real or Complex and are therefore implicitly a field. Of course a C++ linear algebra library should be generic enough to work with any type which is a numeric approximation to a field. > > * Redundant specification of element type in matrix/vector storage. Not sure what is meant here, can you elaborate ? > * size1 and size2 should be named num_rows and num_columns or > something memnonic > > * iterator1 and iterator2 should be named column_iterator and > row_iterator or something memnonic. I think many uBLAS users have come to appreciate the brevity of naming. I think the concensus in the Boost review was as long as they were used consistenty these names are acceptable. > * prod should be named operator*; this is a linear algebra library > after all. Oh, there has been much ink spent on this! Joerg argues against operator* for two reasons I think. a) operator* brings an expectation of commutativity and this is not the case in linear algebra b) The are many products (inner,outer,element) and there should be a clarity of naming. > * begin() and end() should never violate O(1) complexity expectations. > > * insert(i,x) and erase(i) names used inconsistently with standard library. Agreed. > * Matrix/Vector concept/class interfaces are way too "fat" and need to > be minimized (e.g. rbegin/rend *member* functions should be > eliminated). Interesting. Certainly the fatness is a worry. I think rbegin/rend need to stay as members as this is part of the Reversible Container concept. > * The slice interface is wrong; stride should come last and be > optional; 2nd argument should be end and not size; then a separate > range interface could be eliminated. For std::slice (valarray) compatibility stride should be last. Not sure why this was not picked up on a long time ago!! valarray (and uBLAS) use size (not end) for good reason however. I also think it would be a mistake to drop range. slices can be degenerate (zero stride) and this has a runtime cost which range does not need to share. > * No support for unorderd sparse formats -- it can't be made to fit > into the uBlas framework. Interesting. I guess this requires some thinking time for a sensible discussion. > Implementation > -------------- > > * Expressions that require temporaries are not supported by uBLAS > under release mode. They are supported under debug mode. For > example, the following program compiles under debug mode, but not > under release mode. > > std::cout << prod (prod(v, m), m) << std::endl; > } > > The workaround to make it compile under release mode is to > explicitly insert the creation of a temporary: > > std::cout << prod (vector<double>(prod(v, m)), m) << std::endl; > > There should be no such surprises when moving from debug to > release. Debug mode should use expression templates, too, as the > differences can cause other surprises. This was changed by Joerg after the last stable release to Boost. I will check there has been no regression. The fix propagates an expression complexity that is statically checked. This check explictly prevents the creation of nested products!! Therefore the correct code is now that with the explicit temporary or with one of the parameterized prod's. The change is aimed at the user. They must clearly express the evaluation and storage complexity of the expressions. The change of semantics between debug/release builds is unfortunate. The partial disabling of the expression templates in debug mode is currently the default and a config macro. With current compiler technology this prevents debuggers crashing and users scrolling through type names that are pages long. In a perfect environment the default would be the opposite. > * Should use iterator_adaptor. There is a ton of boilerplate iterator > code in the uBLAS that needs to be deleted. Agreed 100%. A well used iterator_adaptor would shorten uBLAS definitions to about 30% of their current size !! > * Should use enable_if instead of CRTP to implement operators. uBLAS > avoids the ambiguity problem by only using operator* for > vector-scalar, matrix-scalar ops, but that's only a partial > solution. Its expressions can't interact with objects from other > libraries (e.g. multi-array) because they require the intrusive CRTP > base class. Interesting solution. Agreed, the current implementation is closed to other objects because of the intrusive base class. Sadly uBLAS was designed before enable_if. Any pointers to compile/runtime effects of the enable_if solution? We would however lose the static type checking that argument matching with the CRTP base class gives us. At this point I think we land in a deep philosophical argument as to the strengths and weaknesses of generic progreamming %-) > * Certain operations, especially on sparse matrices and vectors, and > when dealing with matrix_row and matrix_column proxies have the > wrong complexity. Functions such as begin() and end() are suppose > to be constant time. I see calls to find1 and find2, which look like > expensive functions (they each contain a loop). Agreed. The implementation with findN is simple but expensive. I am not sure why Joerg choose this route. > Testing > ------- > * There should be a readme describing the organization of the tests. > > * Tests should not print stuff that must be manually inspected for > correctness. > > * Test programs should instead either complete successfully > (with exit code 0) or not (and print why it failed). Agreed. If anyone submits a patch it would be included very quickly! > * Abstraction penalty tests need to compare the library with tuned > fortran BLAS and ATLAS, not naive 'C' implementation. There was some very good work on this about a year ago. Sadly the results are no longer accessable on the web. Since the loss to Intel of the KAI compiler it is hard to see any library archiving really exceptional results in this regard. > Documentation > ------------- > > * In really bad shape. Redundant boilerplate tables make the head > spin rather than providing useful information. > > * Needs to be user-centered, not implementation centered. > > * Need a good set of tutorials. Agreed. > Compilers > --------- > > * Simple example doesn't compile with gcc 3.3. Got it to compile by > #if'ing out operator value_type() in vector_expression.hpp. Strange gcc-3.3.3 is my primary compiler. Can you specify the problem more exactly. Which gcc-3.3 subversion is causing the problem? Thanks, Michael ___________________________________ Michael Stevens Systems Engineering Navigation Systems, Estimation and Bayesian Filtering http://bayesclasses.sf.net ___________________________________

3 4

Re: Boost Mathematicians
by Michael Stevens 05 Jul '04

05 Jul '04

Oppps I forgot the last section of David's posting. On Saturday 03 July 2004 16:54,David Abrahams <dave(a)boost-consulting.com> > > Other then the many forms of blocking (other then banded) uBLAS supports all > > these in its design. > I believe that a design with really good support for blocking can't be > easily grafted onto an existing design that doesn't have it. Now I understand. Blocking in the context of evaluation rather then sparsity/ shape. Yes this is a good point. Blocking evaluation requires significant contribution from the Expression Template mechanism that is not present in uBLAS. > > 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. > > No, and I have some ideas for addressing that. A improved iterator concept that allows succinct coding and runtime efficiency would be a big step forward. > > > Since uBLAS is already in Boost and has a well established and clean user > > syntax it would seem strange to ignore it. > > Yeah, I stopped ignoring it long enough to determine for sure that we > should probably ignore it :(. No sure what to say here! > > > 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. > > We have some problems with the syntax too, as you can see from the > above. That said, if the design of MTL makes sparing use of members > and instead relies on free functions, you should be able to make > uBlas syntax adapters ;-) Can't fault the logic here :-) All the best, Michael -- ___________________________________ Michael Stevens Systems Engineering Navigation Systems, Estimation and Bayesian Filtering http://bayesclasses.sf.net ___________________________________

2 1

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

05 Jul '04

According to the current Boost.Threads documentation timed_wait() does not require timed_lock (cut and pasted from http://www.boost.org/libs/thread/doc/condition.html#class-condition) template <typename ScopedLock> bool timed_wait(ScopedLock& lock, const xtime& XT); Looking at the code it does appear to require timed_lock either: template <typename L> bool timed_wait(L& lock, const xtime& xt) { if (!lock) throw lock_error(); return do_timed_wait(lock.m_mutex, xt); } What am I missing? BTW. How can I get to have look at the development branch? I went to http://cvs.sourceforge.net/viewcvs.py/boost/boost/development/ but found nothing threads-related. Thanks, V. -----Original Message----- From: boost-bounces(a)lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Michael Glassford Sent: Friday, 2 July 2004 4:35 AM To: boost(a)lists.boost.org Subject: [boost] Re: Boost.Threads: Do we need all those mutexes? Batov, Vladimir wrote: >>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. For what it's worth, heres a use case I just ran across illustrating why timed_lock should have a blocking lock() method and/or a blocking locked constructor: condition c; void f(mutex m) { mutex::scoped_timed_lock l(m, locked); //always want the lock here for(;;) { //do stuff c.timed_wait(l, next_wakeup_time()); //timed_wait requires a timed_lock } } Mike _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

2 1

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

[OT] Whether and how to obfuscate email addresses in posts, docs & code
by Andreas Huber 03 Jul '04

03 Jul '04

Dear Boosters What follows is OT, but since this post discusses a problem that I expect to hit boost contributors especially hard I think it is ok to post it here. If not, please let me know. **** lengthy obfuscation rationale begin **** Spammers routinely harvest email addresses from web pages and newsgroups. Viruses scan harddisks to find email addresses of potential new victims. Spammers have even started to use special viruses to install backdoors on computers and then later hijack the infected machines to send their junk to the email addresses found on the harddisk (see e.g. http://tinyurl.com/35usd) Boost contributors are especially vulnerable as their email address is published on the boost website and on the boost list. Moreover, their email address can be found on the harddisks of the thousands of people who use the boost distribution. Despite these vulnerabilities, very few obfuscate their address on the list and in the 1.31 distribution (I don't do so yet, either). Sure, virus scanners and spam filters alleviate the problem but they can never fully solve it. Spammers have become very sophisticated in making their junk pass filters. Although I'm employing multiple spam/virus filters (spamcop, gmx, yahoo) I'm currently getting about 10 unsolicited messages per day (up from about 3 per day a year ago) and I'm concerned what will happen once my address is stored on thousands of hard drives when/if my library is accepted into boost. Sure, I could simply disable my throw-away address and publish a new one as soon as spam/virus levels become unbearable but that also immediately cuts off users who have downloaded the distribution. Plus, this solves the problem only temporarily. So, the only real solution to considerably reduce email junk is to thwart automatic harvest and thus to obfuscate email addresses. I realize that even this offers no guarantee for not receiving spam/viruses as someone sending me email will often have my unobfuscated email address on his/her hard drive but it definitely reduces the number of locations where my address can be harvested considerably. **** lengthy obfuscation rationale end **** Questions: 1. How do other contributors deal with spam/viruses clogging up their in-boxes? Am I worrying about something that will never be a big deal? 2. What do other people think about a voluntary boost standard for obfuscating email addresses published in posts, docs & code? 3. If you think 2. is a good idea then what is a good way to obfuscate email addresses? Is the simple <at> & <dot> approach sufficient or do we need something that is less common (and thus prone to automation)? E.g. WHATah2003EVER(a)gmx.net with a remark to remove all capital letters? Regards, Andreas

4 7

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

Patch for linker problems wiith date_time
by Matthias Troyer 02 Jul '04

02 Jul '04

Dear Boosters, There are a few inline statements missing in the new version of the date_time library, causing multiple definitions and linkage problems. I have attached a diff. Matthias cvs diff -u boost/date_time/posix_time/date_duration_operators.hpp Index: boost/date_time/posix_time/date_duration_operators.hpp =================================================================== RCS file: /cvsroot/boost/boost/boost/date_time/posix_time/ date_duration_operators.hpp,v retrieving revision 1.1 diff -u -r1.1 date_duration_operators.hpp --- boost/date_time/posix_time/date_duration_operators.hpp 30 Jun 2004 00:11:11 -0000 1.1 +++ boost/date_time/posix_time/date_duration_operators.hpp 1 Jul 2004 14:31:57 -0000 @@ -17,39 +17,39 @@ /*** ptime operator functions ***/ // ptime & months - ptime operator+(const ptime& t, const boost::gregorian::months& m) + inline ptime operator+(const ptime& t, const boost::gregorian::months& m) { return t + m.get_offset(t.date()); } - ptime operator+=(ptime& t, const boost::gregorian::months& m) + inline ptime operator+=(ptime& t, const boost::gregorian::months& m) { // get_neg_offset returns a negative duration, so we add return t += m.get_offset(t.date()); } - ptime operator-(const ptime& t, const boost::gregorian::months& m) + inline ptime operator-(const ptime& t, const boost::gregorian::months& m) { // get_neg_offset returns a negative duration, so we add return t + m.get_neg_offset(t.date()); } - ptime operator-=(ptime& t, const boost::gregorian::months& m) + inline ptime operator-=(ptime& t, const boost::gregorian::months& m) { return t += m.get_neg_offset(t.date()); } // ptime & years - ptime operator+(const ptime& t, const boost::gregorian::years& y) + inline ptime operator+(const ptime& t, const boost::gregorian::years& y) { return t + y.get_offset(t.date()); } - ptime operator+=(ptime& t, const boost::gregorian::years& y) + inline ptime operator+=(ptime& t, const boost::gregorian::years& y) { return t += y.get_offset(t.date()); } - ptime operator-(const ptime& t, const boost::gregorian::years& y) + inline ptime operator-(const ptime& t, const boost::gregorian::years& y) { // get_neg_offset returns a negative duration, so we add return t + y.get_neg_offset(t.date()); } - ptime operator-=(ptime& t, const boost::gregorian::years& y) + inline ptime operator-=(ptime& t, const boost::gregorian::years& y) { // get_neg_offset returns a negative duration, so we add return t += y.get_neg_offset(t.date());

2 1