- Boost - lists.boost.org

Tribool missing title in docs
by Jeff Garland 22 Jul '04

22 Jul '04

Doug -- Maybe you've already noticed, but the Tribool title isn't showing up in the generated docs table of contents... http://www.boost.org/regression-logs/cs-win32_metacomm/doc/html/libraries.h… Jeff

2 1

Re:Re: [boost] Regression Tests, Boost.Serialization
by Robert Ramey 22 Jul '04

22 Jul '04

Jeff Garland wrote: >> Houston, we have a problem. >> >> I had a few GB of disk space left a few days ago. >> Now, I'm unable to run all the tests. I could >> drop one of the gcc-3.4 versions. However, I'd >> still be short by ~10GB after that. It's a fact - running the bjam serialization test is going to consume 20 GB. If the test machine doesn't have it the best is just to remove the serialization test from the status jamfile for that machine. Actually I think it would be unusual for a machine used for testing boost not to have this much free space available. So I would hope it only affects martin's tests. >It would be nice if we could drop serialization on compilers that just >aren't going to work. Having looked at the test results on all the compilers the only ones that I really wonder about are HP, and for now Comeau. All tests run with MSVC 6.0 and borland will fail without spirit 1.61 being installed. This is because spirit 1.61 is needed to build the libraries. So if the library build fails then all the tests are skipped. They are marked "fail" which is a little misleading - "skipped" might be better. >This is where we were hoping to be able to allow regression levels like >'basic' and 'torture' that would provide standard ways of controlling the >number of tests. But none of this is currently available. All in all I think the testing program is working well and in reasonable time. I need this to shake out issues with each platform. It just takes the resources that it takes. So far I've only been through two test cycles so it's premature to panic. >As for what we should do now, it would be nice to have an answer to the >question I posed this morning: is serialization going into 1.32 or are we >cutting it out in the final release: I want to keep working to finish regardless of which release it becomes a part of. >If we are cutting it out the we can just remove it from status bjam now.... But that would mean that progress would be stopped on getting this done. Robert Ramey

7 8

RE: [boost] Re: Lock unification [move]
by Batov, Vladimir 22 Jul '04

22 Jul '04

Yes, I fully agree with your argument against >> basic_lock(mutex_type&, const elapsed_time&, defer_type); That suggestion was OTOH and clearly messy and bad. Although the point I tried to make was that the interface appeared somewhat inconsistent -- I can create a deferred blocking lock but not a deferred "try" lock. However, I now clearly see that I was thinking in terms of separate classes "scoped, try, timed". That is not true anymore. After thinking about it some more (I know, I should have done it from the start :-) ), I like the proposed interface. Essentially, scoped_lock(mutex_type& m, detail::defer_lock_type); is a constructor in its own right as (unlike the other three) it does not create a specific (blocking, try, timed) lock. The more I think about it, the more I like it. > -----Original Message----- > From: boost-bounces(a)lists.boost.org [mailto:boost-bounces@lists.boost.org] > On Behalf Of Howard Hinnant > Sent: Thursday, 22 July 2004 11:19 AM > To: boost(a)lists.boost.org > Subject: [boost] Re: Lock unification [move] > > On Jul 21, 2004, at 7:16 PM, Batov, Vladimir wrote: > > > Howard, > > > > Thank you for taking on the task of shaping up the interface. That > > activity is of great importance. A few comments. > > > > explicit scoped_lock(mutex_type& m); > > scoped_lock(mutex_type& m, detail::defer_lock_type); > > scoped_lock(mutex_type& m, detail::try_lock_type); > > scoped_lock(mutex_type& m, const elapsed_time& elps_time); > > > > The problem (as I can see it) with the set above is that "deferred", > > "tried" and "timed" appear to be alternatives or mutually exclusive. > > However, "deferred" and, say, "try" functionalities are orthogonal. > > That > > is, as one might need to defer a blocking lock > > > > scoped_lock l(m, deferred); > > > > one might need a deferred try_lock as well. Therefore, as we are trying > > to provide one universal lock, it appears we have to have something > > complex like > > > > basic_lock(mutex_type&, const elapsed_time&, defer_type); > > > > that would address all the lock variability/configurability. > > I'm not seeing that the combination of time and defer always make sense: > > time defer description > --------------------------------------------------- > 0 yes interpret as don't lock > 0 no interpret as try-lock > finite yes no interpretation > finite no lock if you can get it in time > infinite yes no interpretation > infinite no interpret as lock > > Some of the combinations don't appear to have clear meanings. > > Even more importantly, the underlying mutex might not support time. > Below is a list of mutex functionality that I have so far identified in > the spec. Recursion is ignored for this discussion (it isn't relevant > to locks, and thus not relevant to mutex interface, only to mutex > implementation details): > > Mutex interface: > ---------------- > > void lock(); > void unlock(); > > bool try_lock(); > > bool timed_lock(const elapsed_time&); > > void lock_sharable(); > void unlock_sharable(); > > bool try_lock_sharable(); > > bool timed_lock_sharable(const elapsed_time&); > > void lock_upgradable(); > void unlock_upgradable(); > > bool try_lock_upgradable(); > > bool timed_lock_upgradable(const elapsed_time&); > > void unlock_and_lock_sharable(); > > void unlock_and_lock_upgradable(); > void unlock_upgradable_and_lock(); > > void try_unlock_upgradable_and_lock(); > > The spaces between signatures are relevant. They represent groupings > where I believe it is reasonable for a mutex to support a group of > signatures, but exclude other groups. For example, it is very > reasonable for a mutex to support lock and unlock but not try_lock. Or > perhaps lock, unlock and try_lock, but not timed_lock. If a lock > constructor forces the semantics of "deferred lock" to call > m_.timed_lock(elps_time), then a compile time error results if the > mutex does not support timed_lock(), even though timed_lock isn't > needed to support "deferred lock" (no mutex interface is required to > support deferred lock). So I'm very reluctant to have a lock function > that calls two mutex functions that can reasonably be expected to not > be implemented in the same mutex. > > -Howard > > _______________________________________________ > Unsubscribe & other changes: > http://lists.boost.org/mailman/listinfo.cgi/boost

1 0

RE: [boost] Re: Boost.Test problem
by Rozental, Gennadiy 22 Jul '04

22 Jul '04

> > My personal preference is fully qualified reference > everywhere. And I > > don't see how other solution is any better. > > Whatever... Just fix the thing! That's great! First you say don't do a thing, than - why you did not do it yet. I had enough headache with things that were "sure thing". I did not touch anything I am not 100% sure about. Gennadiy.

2 1

RE: [boost] Re: Lock unification [move]
by Batov, Vladimir 22 Jul '04

22 Jul '04

I second that. > -----Original Message----- > From: boost-bounces(a)lists.boost.org [mailto:boost-bounces@lists.boost.org] > On Behalf Of David Abrahams > Sent: Thursday, 22 July 2004 9:16 AM > To: boost > Subject: [boost] Re: Lock unification [move] > > Howard Hinnant <hinnant(a)twcny.rr.com> writes: > > > <nod> How's: > > > > scoped_lock lk1(m, defer_lock); // not locked > ^^^^ ^^^^ > > Redundant. "deferred" is better. > > -- > Dave Abrahams > Boost Consulting > http://www.boost-consulting.com > > _______________________________________________ > Unsubscribe & other changes: > http://lists.boost.org/mailman/listinfo.cgi/boost

1 0

Boost under QNX 6.2.1
by Dave Wolfe 21 Jul '04

21 Jul '04

I recently tried to d/l boost_1_31_0 and compile a short test program (appended below) on QNX 6.2.1. My first attempt to compile with: % make bindtest CPPFLAGS=-I/home/projects/boost_1_31_0 resulted in a yard+ of errors that I was able to quiet by adding '-ftemplate-depth-32' to CPPFLAGS. But I still got the error: g++ -I. -ftemplate-depth-32 bindtest.cpp -o bindtest /tmp/ccIdnnhy.o: In function `boost::bad_function_call::bad_function_call(void)': /tmp/ccIdnnhy.o(.boost::bad_function_call::gnu.linkonce.t.(void)+0x29): undefined reference to `runtime_error::runtime_error(basic_string<char, string_char_traits<char>, __default_alloc_template<false, 0> > const &)' collect2: ld returned 1 exit status make: *** [bindtest] Error 1 After quite a lot of mucking about, I discovered that I had to define CXX to 'QCC' and comment out the following line in boost/config/compiler/gcc.hpp: #ifndef __EXCEPTIONS //# define BOOST_NO_EXCEPTIONS #endif in order to compile successfully. So the appended test program works, at least. However, the complete boost tarball seems to have some problems. When I run bjam, the compiler keeps carping: g++: unrecognized option '-pthread' And there seem to be quite a few files with a basename longer than the QNX max of 48 charactes. I'm willing to help figure out how to get boost to compile better under QNX if someone can give me a little guidance as to how to proceed. Part of the problem may be that QNX 6.2.1 uses an STL implementation from Dinkum instead of the one that comes with gcc 2.95.3. If someone'll help direct my fingers where to go, I can probably sort some of this out... Cheers, - Dave P.S. If it's helpful to anyone, I can post a QNX 6.2.1 binary of bjam... -------- % uname -a QNX rtblnx1196 6.2.1 2003/01/18-02:12:22est x86pc x86 % gcc --version 2.95.3qnx-nto -------- // File: bindtest.cpp // Compile: make bindtest CXX=QCC CPPFLAGS="-I. -ftemplate-depth-32" #include <iostream> #include <string> #include <boost/bind.hpp> #include <boost/ref.hpp> #include <boost/function.hpp> using namespace std; typedef boost::function<void(void)> Callback; struct Dummy { void memberFunc( int num, const string& msg ) { cout << "memberFunc args: " << num << ", \"" << msg << "\"" << endl; } }; main( void ) { Dummy mydummy; Callback c = boost::bind( &Dummy::memberFunc, boost::ref(mydummy), 7, "is a lucky number..." ); c( ); // prints: "memberFunc args: 7, "is a lucky number..." return 0; }

1 0

counting_iterator_test.hpp fails on aC++
by DY, JERRY U (SBCSI) 21 Jul '04

21 Jul '04

I'm troubleshooting counting_iterator_test.hpp. In particular: FILE: counting_iterator_test.cpp class my_int2 { public: ... typedef std::bidirectional_iterator_tag iterator_category; }; FILE: counting_iterator.hpp template <class Incrementable, class CategoryOrTraversal, class Difference> struct counting_iterator_base { typedef typename detail::ia_dflt_help< CategoryOrTraversal , mpl::apply_if< is_numeric<Incrementable> , mpl::identity<random_access_traversal_tag> , iterator_traversal<Incrementable> > >::type traversal; ... } The class my_int2 is passed as parameter "Incrementable" to counting_iterator_base, but is failing the is_numeric test so my_int2 is just a bidirectional iterator (see mpl::apply_if above). If it passes the is_numeric test, then it's a random access traversal tag. The way it passes the is_numeric test is to specialize std::numeric_limits like so: template <> class std::numeric_limits<my_int2> { public: static bool const is_specialized = false; }; But I don't find that in the source. It appears that aC++ doing the right thing, but I know I'm wrong. Could somebody please help?? Thanks! -Jerry

1 0

RE: [boost] Re: Regression results for Intel 8 online
by Michael Stevens 21 Jul '04

21 Jul '04

Stefan thanks for you work and the reply On Wednesday 21 July 2004 10:15, "Stefan Slapeta" <stefan(a)slapeta.com> wrote: > Did you see the __declspec(dllimport)? Should this be ok? > > test21.obj : error LNK2019: unresolved external symbol > "__declspec(dllimport) public: __thiscall > std::complex<float>::complex<float>(class std::complex<float> const &)" etc. > > test21.obj : error LNK2019: unresolved external symbol I saw it but don't really know what to make of it! Essentially uBLAS just makes use of the system <complex> header. How this result in an unresolved symbol I don't know. My wild guess the they are normally for it the compiler runtime, and something has gone haywire! > "C:\Programme\Intel\CPP\Compiler80\Ia32\bin\icl" /Zm800 -nologo -GX -c > -DBOOST_UBLAS_USE_INTERVAL /Z7 /Od /Ob0 /GX /GR /MDd /Op /Zc:forScope > /Zc:wchar_t /Qwn5 /Qwd985 -Qoption,c,--arg_dep_lookup /Qansi_alias > -D_NATIVE_WCHAR_T_DEFINED /Qvc7.1 I am really guessing here as I don't have manuals! The /Z7 and /Qv7.1 look interesting. I think the /Z7 is specifying old style debug symbols which is a bit odd. I guess they are usually smaller then the "edit and continue" symbols. /Qv7.1 I assume is enabling VC 7.1 compatibility bugs and all. I guess this adds a few extra bugs of Intels own. I not sure why the default build options for boost have this in. Anyone know? Do you think it would be appropriate to do the regression testing in the compilers native mode? Thanks, Michael

2 1

RE: [boost] Re: What is it with boost and tinyurl?
by Rozental, Gennadiy 21 Jul '04

21 Jul '04

> > Too much trouble. I certainly wouldn't want to set that policy; it > > would just discourage posting links. > > Too much trouble? An extra Ctrl+V is too much trouble for > someone who doesn't mind opening tinyurl.com, pasting the > link there, copying the result, and pasting it back? Actually it's only one click http://tinyurl.com/#toolbar Gennadiy.

1 0

RE: Boost.Test problems (Was: [boost] Multiple link definitions o n Darwin tests)
by Rozental, Gennadiy 21 Jul '04

21 Jul '04

>A change to Boost.Test basically means all > tests will have to be recompiled on the testing machines. > This means test results will be available at a lower > frequency. A higher frequency is very desirable during the > release preparations. I did 1(one) update during this release preparation. It included mainly only license text update. I don't believe Boost.Test modification interfere with frequency of regression test run. Gennadiy.

1 0