July 2004 - Boost - lists.boost.org

Problem about build regex under win32 using stlpot5.0
by huangliang 12 Jul '04

12 Jul '04

Recently I begin to use stlport in my programs, and I want to build boost regex under win32 using vc6 and stlport 5.0. But when I build them,the following errors occurs: C:\lib\boost-1.30.2\libs\regex\build>set MSVCDIR= D:\Program Files\Microsoft Visual Studio\VC98\Bin C:\lib\boost-1.30.2\libs\regex\build>set STLPORT_PATH=E:/HuangLiang/c++stl/STLport-5.0-1031 C:\lib\boost-1.30.2\libs\regex\build>nmake -fvc6-stlport.mak cl /nologo /MT /W3 /GX /O2 /GB /GF /Gy /IE:/HuangLiang/c++stl/STLport-5.0-1031\stlport /I..\..\..\ /D_MT /DWIN32 /DNDEBUG /D_MBCS /D_LIB /YX /FD /c -Fpvc6-stlport/boost_regex_vc6-stlport_mss/boost_regex_vc6-stlport_mss.pch -Fo./vc6-stlport/boost_regex_vc6-stlport_mss/ -Fdvc6-stlport/boost_regex_vc6-stlport_mss.pdb ../src/cpp_regex_traits.cpp cpp_regex_traits.cpp ../src/cpp_regex_traits.cpp(662) : error C2660: 'isspace' : function does not take 2 parameters ../src/cpp_regex_traits.cpp(662) : fatal error C1903: unable to recover from previous error(s); stopping compilation After I searched msdn, I found that isspace have been defined at 2 places: isspace template<class E> bool isspace(E c, const locale& loc) const; The template function returns use_facet< ctype<E> >(loc). is(ctype<E>:: space, c). and in ctype.h. I remember when I compile regex using vc6 without stlport, no same errors occured. I need some help about what has happened with me. Thank you !

2 1

VC 7.1: unable to bind specialized member function template
by Stefan Slapeta 12 Jul '04

12 Jul '04

Hi all, this code sample produces a compiler error on VC 7.1. It seems that boost::bind isn't able to get the right type for the specialization of the member function template [&Test::g<Type1, Type2>]. Is there a good workaround? (The only one I could find so far is to 'hide' the function template as normal member function in a class template.) Intel 8.0 compiles ok! #include <boost/bind.hpp> #include <boost/function.hpp> class Test { public: template <typename Type1, typename Type2> void f(Type1 one, Type2 two) { boost::function<void (Type1, Type2)> bf = boost::bind(&Test::g<Type1, Type2>, this, one, two); } template <typename Type1, typename Type2> void g(Type1, Type2) { } }; int main() { Test t; t.f(0, 0); }

2 3

[Boost-bugs] [ boost-Bugs-989168 ] intrusive_ptr may cause dungling ptr access
by SourceForge.net 12 Jul '04

12 Jul '04

Bugs item #989168, was opened at 2004-07-11 20:04 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=989168&group_i… Category: smart_ptr Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Peter Dimov (pdimov) Summary: intrusive_ptr may cause dungling ptr access Initial Comment: I think intrusive_ptr may cause dungling ptr access in multithreaded environment. Currently, it's constructor is: intrusive_ptr(T * p, bool add_ref = true) : p_(p) /* the object may be deleted by other thread because this thread does not increment reference counter yet. */ { if(p_ != 0 && add_ref) intrusive_ptr_add_ref(p_); /* this may occur dungling ptr operation. */ } We can avoid this problem by "addref-before-use" policy. intrusive_ptr(T * p, bool add_ref = true) { if(p != 0 && add_ref) intrusive_ptr_add_ref(p_); /* other thread never delete the object */ p_ = p; } ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=989168&group_i… ------------------------------------------------------- This SF.Net email sponsored by Black Hat Briefings & Training. Attend Black Hat Briefings & Training, Las Vegas July 24-29 - digital self defense, top technical experts, no vendor pitches, unmatched networking opportunities. Visit www.blackhat.com _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

Yet more math functions - a draft TR2 proposal
by Paul A Bristow 12 Jul '04

12 Jul '04

I posted a note previous with modest reponse. In the hope that a better link will provoke some more reaction, I am reposting. 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. It is accessible at: http://tinyurl.com/357a6 be grateful if some CVS whizz would copy it to the sandbox as I know that many are unable to access the files 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 Paul A Bristow Prizet Farmhouse, Kendal, Cumbria UK LA8 8AB +44 1539 561830 +44 7714 330204 mailto: pbristow(a)hetp.u-net.com

3 2

RE: [boost] Re: Boost.Threads: Do we need all those mutexes?
by Batov, Vladimir 11 Jul '04

11 Jul '04

What a wonderfully clean suggestion of having just one lock and (hopefully) just one mutex. IMHO having just one mutex class is even more important than having one lock as mutex represents something lockable that seems to always be the same. That is, I create a mutex and sometimes want to apply a blocking lock on it and sometimes I just want to try a lock. The functionality that implements various ways of locking is in locks. Although I can see the technical merits of having just one lock constructor, I still feel that having two explicit instead would be less ambiguous, friendlier towards the user and cleaner. Additionally, it'd keep the door open for possible optimization. Additionally, I'd expect the scoped_lock l(m, true) to be used much more often than scoped_lock l(m, false) Consequently, IMHO the first should get the preferential treatment. That is, to have an explicit and more efficient representation: scoped_lock::scoped_lock(Mutex&) Best, V. -----Original Message----- From: boost-bounces(a)lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Peter Dimov Sent: Sunday, 11 July 2004 10:47 PM To: boost(a)lists.boost.org Subject: Re: [boost] Re: Boost.Threads: Do we need all those mutexes? Michael Glassford wrote: > Peter Dimov wrote: >> After giving it some thought: >> >> - one lock class: tie; > > This seems both popular and reasonable. I presume it would be > templated on the mutex type? Seems entirely reasonable. Perhaps it's time to move to formal wording. template<class M> class scoped_lock { public: explicit scoped_lock( M & m, bool l = true ); // effects: if( l ) m.lock(); // post: locked() == l && mutex() == &m; ~scoped_lock(); // effects: if( locked() ) mutex()->unlock(); void lock(); // throws: lock_aready_locked if locked(); // effects: mutex()->lock(); // post: locked(); bool try_lock(); // throws: lock_aready_locked if locked(); // returns: mutex()->try_lock(); // post: locked() == (return value); bool timed_lock( xtime xt ); // throws: lock_aready_locked if locked(); // returns: mutex()->timed_lock( xt ); // post: locked() == (return value); void unlock(); // throws: lock_not_locked when !locked(); // effects: mutex()->unlock(); // post: !locked(); bool locked() const; Mutex * mutex() const; // returns: the associated mutex; operator unspecified-bool-type() const; // returns: locked(). }; I've added the mutex() accessor to support Andrei's lock idiom: void f() { scoped_lock lock( my_mutex ); f( lock ); } void f( scoped_lock & lock ) { // check for lock validity assert( lock.locked() && lock.mutex() == &my_mutex ); // proceed with operation } Now that we got rid of the excess locks, how about doing the same with the mutexes? class mutex // DefaultConstructible { private: void lock(); // pre: *this is not locked by the current thread // effects: blocks until *this is unlocked // post: *this is locked by the current thread bool try_lock(); // returns: true iff *this was unlocked // post: if *this was unlocked, *this is now locked by the current thread bool timed_lock( xtime xt ); // returns: true if *this is now locked by the current thread // effects: if *this is unlocked, returns immediately, otherwise blocks // until either *this is unlocked or xt has been reached // post: if *this was or became unlocked, *this is now locked by the // current thread void unlock(); // pre: *this is locked by the current thread // post: *this is unlocked }; The main potential issue here is mutex::timed_lock; try_lock doesn't seem controversial. It is true that Windows 95 does not have TryEnterCriticalSection, but an implementation can use Alexander Terekhov's alternative: http://lists.boost.org/MailArchives/boost/msg64648.php The mutex::timed_lock situation is a bit more complicated. POSIX labels pthread_mutex_timedlock as part of the Timeouts option, and I don't know whether this is because many implementations deliberatley do not provide timed locks, or because this is a relatively new addition to pthreads. Does someone know? My not-so-informed opinion at the moment is that we should provide timed_lock. I see that the current Boost.Threads implementation uses a mutex and a condition variable to implement a timed_lock-capable mutex, so we have a proof of concept that it can always be done, however there may be efficiency concerns. My line of thought is that since a mutex (usually) has a fast path user space portion and a slow path kernel space portion, with the timed_lock baggage not affecting the fast path, it seems reasonable to always require timed_lock (remember we're in "next standard mode" now, thinking severals years ahead). Thoughts? Some more random remarks regarding the state of Boost.Threads. Several files still seem to have incorrect line endings. This usually happens when checking in Windows line endings with a Unix CVS client. Please don't do that. I was somewhat surprised by the mutex/cv implementation. I expected a thin wrapper over pthreads, but this is not the case. At first sight it seems that the complexity is caused by the fact that boost::condition supports recursive mutexes that are locked more than once, whereas POSIX does not. I do not recall any discussions about this issue, and I'm not sure why this decision was made. It seems wrong (and the implementation seems buggy), but as usual, I may be missing something. _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

1 0

Re: [boost] [optional] outdated tests?
by JOAQUIN LOPEZ MU?Z 11 Jul '04

11 Jul '04

----- Mensaje original ----- De: Rene Rivera <grafik.list(a)redshift-software.com> Fecha: Domingo, Julio 11, 2004 6:13 pm Asunto: [boost] [optional] outdated tests? > Boost.Optional optional_test and optional_test_ref both have the > following error: Cannot open include file: > 'boost/detail/none.hpp': No > such file or directory. > > But only on the Win32 tests, and not on the Linux test. Not sure > what > the discrepancy is about but the file is definitely not there in > CVS. Linux test also fail, but, as discussed in a previous thread, the reports pages are not getting updated due to a XML-related problem. I think Aleksey fixed that, so hopefully the pages will update again soon. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

2 1

Fw: STLport & boost
by François Dumont 11 Jul '04

11 Jul '04

Hello I am currently actively contributing to STLport. One of my contribution is to make boost and STLport closer. I think STLport can gain a lot in using some of the boost libraries and then boost will be able to count on a robust std lib. For the moment I only use 2 libraries from boost, type_traits and call_traits. I have some issue when I include the boost headers from STLport. I was counting on the BOOST_STD_CONFIG macro to limit the damage but for some platforms this feature is just useless. Under Win32 there is a workaround implemented for MSVC compilers (win32.hpp:60) on the min and max template functions. This workaround require the inclusion of the algorithm standard header which make the STLport lib build process failed. According the comment this workaround has not really been validated so my questions are: - is it require for all MSVC++ versions? Doesn't VC.Net 2003 or even 2002 managed the described cases correctly? - Couldn't this workaround be implemented for the native library only and not when using STLport? STLport looks to me as the right place to handle this case. Bests Francois Dumont

11 24

Linux regressions
by John Maddock 11 Jul '04

11 Jul '04

There appear to be a few regressions in the Linux test results: 1) Several libraries are listed as failing with intel-linux-8 including config_test, regex, and python. However these do pass when tested on my own machine with the latest Intel binaries. Could this be a setup issue? For example if the compiler has recently been patched then you may need to clear out past builds before the tests will start passing again. 2) Test exec monitor is failing with gcc-2.96+STLPort which is causing quite a few other failures. 3) the test results look a little messed up somehow, and the failures listed in http://boost.sourceforge.net/regression-logs/cs-Linux.html don't match those in http://boost.sourceforge.net/regression-logs/cs-Linux/developer/. Definitely vacation time now... John.

4 6

Re: [boost] Re: Pretty Good Initialization Library
by brangdon＠cix.compulink.co.uk 11 Jul '04

11 Jul '04

In-Reply-To: <cch4as$941$1(a)sea.gmane.org> andrewalex(a)hotmail.com (Andrei Alexandrescu $See Website for Email$) wrote (abridged): > I was worried more (only) about the order of evaluation. > > v += foo(), bar(); I don't think order of evaluation is sacred. However, I am also not keen on using comma for this. I'd rather use operator<<(). v << foo() << bar(); This is partly because comma is so small its easy to overlook, partly because it is used for so many other common things, and partly because I think the semantics of operator<<() fit better here. "Append these items to that stream or container, with conversion or formatting if appropriate." I would also be happy with: v << repeat(5) << 4; meaning: v << 4 << 4 << 4 << 4 << 4; and so forth. It doesn't bother me that: v = 1, 2, 3; has no direct equivalent. It becomes: v.clear(); v << 1 << 2 << 3; Presumably you'd be content with operator<<() in that it doesn't imply an order of evaluation. -- Dave Harris, Nottingham, UK

11 28

boost::function code size
by Vladimir Prus 11 Jul '04

11 Jul '04

Hello, I've became interested in how efficient code-size-wise boost::function is, so I wrote a small script which generates a function which calls boost::function object N times and finds the size of the generated function. The results are somewhat interesting and somewhat alarming (to me). On gcc 3.3 with -Os, each call to boost::function costs 147 bytes of code size. With -O3 it's about 166 bytes. On gcc 3.4 calls cost 203 bytes with -Os and between 220 and 240 with -O3. However, when boost::function is called 15 times, the inliner heuristics kick in and calls are no longer inlined -- meaning each call costs about 14 bytes. This is a good thing for 3.4, but still: 1. For 3.3 boost::function causes a serious code bloat. 2. Even for 3.4, I'm not sure how it will perform if calls are done in several modules. Or how the heuristics will work on non-trivial cases: if they use the % of size increase then on large modules boost::function inlining can cost much more. Given that, IIUC, boost::function has to do indirect call somewhere anyway, I'm not sure inlining is such a good idea. Maybe some of the methods should be declared out-of-line, so that compiler don't try to inline them? - Volodya

2 3