June 2004 - Boost - lists.boost.org

Problems compiling regex with gcc3 on aix and hpux
by Goetz Isenmann 28 Jun '04

28 Jun '04

Hi! I get ugly warnings (they look dangerous to me) when I compile boost/regex on AIX and HP-UX with gcc. On Linux and FreeBSD everything is fine. For example /usr/local/gcc-3.3.3/bin/g++ -c -I. libs/regex/src/cregex.cpp compiles without any complains. On aix43 and hpux11 this gives me the attached warning messages. The order of the messages is slightly different on both platforms, but after sorting the output is identical. I use boost-1.31.0 and see no differences with and without boost-1.31.0-regex-patch-20040503. -- Goetz Isenmann

2 3

Provisional schedule for Boost-1.33
by John Maddock 28 Jun '04

28 Jun '04

Booster's: It's apparent that several of us will just miss the 1.32 deadlines, and I'm sure some people will be concerned when their code will get released as a result, so provisionally I'd like to propose a schedule for 1.33 so we all know where we are. Unless someone else would like to volunteer (and please don't be shy in doing so!), then I guess that means I've just volunteered to manage the release.... Regards, John Maddock. Provisional 1.33 release schedule: ~~~~~~~~~~~~~~~~~~~~~~ Mon 30th August 2004 [1]: ~~~~~~~~~~~~~~~~ Deadline for additions and changes (other than patches to known issues, and docs) to core Boost libraries [2]. Deadline for the addition of new libraries to cvs unless they pass all tests with the core compiler set [3]. Mon 13th September 2004: ~~~~~~~~~~~~~~~~~~ Deadline for additions and changes (other than patches to regressions, and docs) to all Boost libraries. Deadline for all new library additions. Mon 27th September 2004: ~~~~~~~~~~~~~~~~~~ Branch for release, no changes to the release branch without the release managers permission (except for docs). Mon 4th October 2004: ~~~~~~~~~~~~~~~~ First release candidate published, actual release will be as soon as possible thereafter. Notes: ~~~~ 1) There should be a few reminders of this deadline in the weeks beforehand. 2) The core Boost libraries are those that other Boost libraries heavily depend upon: bind config (unless change is restricted to a single compiler, and can be tested with all effected versions of that compiler before commit). enable_if. integer. iterators (the construction framework subset only). mpl operators preprocessor smart_ptr's static_assert test type_traits. 3) The core compiler set includes those compilers that are known to be highly conforming, and for which no failures will normally be expected: gcc 3.3 or later on Linux. Visual C++ 7.1 on Win32. Intel C++ 8 on Win32 or Linux.

1 0

Re: 1.32 release prepar
by Robert Ramey 28 Jun '04

28 Jun '04

Last time we ended up making a release candidate which isolated a couple of final issues. Maybe this is a symptom and maybe it points in the direction of an interesting idea. New code is checked in and tested in the development tree just as it is now. Regression testing and everything remains exactly as it is. Code that documents all test failures and is considered ready for release is moved to the Release Candidate tree. The exact same regression testing setup used on the development tree is used here. Presumably, it would be run much less as things would only be checked in when thought to be perfect which is an infrequent occurrence. Developers develop against the Release Candidate tree. When they have something they like, the check into the Main Development tree as they do now. Traffic on the main development tree is the same as it is now. The Release Candidate Tree should be ready for "shipment" at any convenient time. This basically should consist of assignation of a version number to the tree state. It would not be or scheduled event dramatic event. It could happen as frequently as is convenient. Of course a test failure on the RC tree would be dramatic event. The check in causing such an event could be cast from the RC Tree (Heaven) back into the Main Development Tree (Purgatory) and the author would suffer the attendant embarrassment. Hopefully this would be an infrequent event. I realize that I haven't personally had a library go through the release process so feel free to ignore this idea. Robert Ramey

2 1

[config] about BOOST_NO_POINTER_TO_MEMBER_TEMPLATE_PARAMETERS
by Joaquín Mª López Muñoz 28 Jun '04

28 Jun '04

In config/intel.hpp, this defect macro is defined as follows #if defined(__ICL) && (__ICL <= 710) # define BOOST_NO_POINTER_TO_MEMBER_TEMPLATE_PARAMETERS #endif The macro should be defined *only* for Intel C++ 7.1 or older for Windows 32-bit. So my questions are: 1. Is the definition correct in light of what I said above? 2. What's the meaning of all those different macros __ICC, __ICL and __ECC? I've googled for them but found nothing conclusive. Thanks Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

3 4

RE: Boost.Threads: RW mutexes and locks.
by Batov, Vladimir 28 Jun '04

28 Jun '04

John Torjo wrote: > Batov, Vladimir wrote: >> >> class writer_lock : public boost::mutex::scoped_lock >> { >> typedef boost::mutex::scoped_lock super; >> >> public: >> >> writer_lock(rw_mutex& mutex) : super(mutex.mutex_), mutex_(mutex) >> { >> ++mutex_.num_writers_; // Make new readers wait. > ^^^^ > > just curios, shouldn't this be thread-safe? I believe it is thread-safe as writer_lock currently inherits from scoped_lock and, consequently, we get inside the writer_lock constructor after its base-class scoped_lock constructor. The base-class constructor does the synchronization.

1 0

store a boost::bind
by Nico Massi 27 Jun '04

27 Jun '04

Hi, Is it possible to store a boost::bind? boost::bind<int> x( f, _1, _2 ); int i = x( 3, 4 ); I get errors if i want to declare a variable of type boost::bind. The point is: I want to have an object that gets a boost::bind, stores it and executes it with the correct values to the time i want. How can i do this? Ciao

4 6

[1.32 Plan] Any date for new version of MPL
by JOAQUIN LOPEZ MU?Z 27 Jun '04

27 Jun '04

Any tentative date for the new version of MPL making it into the CVS? Specially if we stick to July 21st a the release date, I'm concerned that the new MPL will have us fixing regressions for quite a few weeks. OTOH, maybe the update is smooth enough and not many problems arise, but it'd be good to know. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

1 0

detail/atomic_count_gcc.hpp error
by Rene Jager 27 Jun '04

27 Jun '04

trying to do: boost::detail::atomic_count c(0); std::cout << long(c) << std::endl; with gcc 3.2.2 gives: /usr/include/boost/detail/atomic_count_gcc.hpp: In member function `boost::detail::atomic_count::operator long int() const': /usr/include/boost/detail/atomic_count_gcc.hpp:46: invalid conversion from ` const _Atomic_word*' to `volatile _Atomic_word*' in the following function: operator long() const { return __exchange_and_add(&value_, 0); } The problem can be solved by making the private member "_Atomic_word value_" mutable. renej ps I know I shouldn't use detail/* stuff directly... --

3 3

[Concept checking] Missing TrivialIteratorConcept
by Hervé Brönnimann 27 Jun '04

27 Jun '04

Hi just occured to Sylvain Pion and myself recently that the TrivialIteratorConcept is documented but not part of the code, and same for Mutable_TrivialIteratorConcept. It is also missing from the test suite (concept_check_test.cpp) and from the archetypes. This may be intentional or not, but probably either the concepts and archetypes should be added to the code, or removed from the documentation. A small and easy bugfix for 1.32? -- Herve'

2 1

A new way of sorting and searching
by Nic Roets 27 Jun '04

27 Jun '04

Often when I write searching or sorting code in C or C++, I'm frustrated that I have to make a new "callback type" compare function. E.g. when you want to sort a number of points in 2D space according to their distance from a reference point, it's tempting to do something like struct Pt { int x, y; }; static Pt center; // Global or static variable yuck. int PtDistToCenterCmp (Pt &a, Pt &b) { return Dist (a, center) - Dist (b, center); } main() { ... center.x = ...; center.y = ...; ... sort (...); ... } This type of solution has many problems. Reviewing the code for correctness is difficult because now you have to read half way through main, stop to find the definition of center, then continue with main, then find the definition of PtDistToCenterCmp, then continue with main. To solve this problem I suggest a new template class "sorter" : template<class t> struct sorter { // Qsort would require a stack here. Heapsort only a few variables. iterator a, b; sorter(iterator begin, iterator end); // Exuse my cpp if it's // incorrect int Operate (int cmpResult); }; Then it would be used like this : void main () { ... sorter<Pt> sortObj (..., ...); while (sortObj.Operate ( Dist (sortObj.a, center) - Dist (sortObj.b, center))) {} ... } IMHO this is much clearer. A binary searching template class can also be implemented in this way. -- Regards Nic Roets

3 2