- Boost - lists.preview.boost.org

[Boost-bugs] [ boost-Bugs-993272 ] xtime_cmp: use comparison not subtraction
by SourceForge.net 18 Jul '04

18 Jul '04

Bugs item #993272, was opened at 2004-07-18 15:21 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=993272&group_i… Category: timer Group: None Status: Open Resolution: None Priority: 5 Submitted By: Philip Hodges (phhodges) Assigned to: Beman Dawes (beman_dawes) Summary: xtime_cmp: use comparison not subtraction Initial Comment: Subtraction of integral types is prone to arithmetic overflow. It is not well-behaved for implementing comparison unless we first cast both operands to a wider integral type or assert that they fall in a narrower range. Choose comparison order to slightly favour future timeouts, or imminent timeouts in the same second? Patch provided "as is" without express or implied warranty. It may contain any number of intended and unintended flaws. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=993272&group_i… ------------------------------------------------------- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

Re: [boost] Re: [threads] Compilation problems on CW and others...
by Robert Ramey 18 Jul '04

18 Jul '04

Rene Rivera wrote: >Robert Ramey wrote: >> While your looking at CW, might you find the time to look a little bit into >> the serialization library build problems. The error message is pretty >> bizarre so I don't think it can be addressed without having CW installed on >> ones machine. vOK, I'll try... Should I look for anything in specific? Or is it a >general health issue? It's a (one?) very bizarre error building of the libraries(2). This prevents running of any tests. If this were fixed and the libraries built the test can run and we can take a look and see where we stand on this. Thanks a lot. Robert Ramey

1 0

mpl::at_c as lambda
by Scott Graham 18 Jul '04

18 Jul '04

Hi Is it possible to make mpl::at_c lambda-able? For example, the following (dumb) code works as I would expect, but changing "at<_, int_<0> >" at // XXX to "at_c<_, 0>" does not. BOOST_MPL_AUX_LAMBDA_SUPPORT is not in the at_c struct, which is why it doesn't work I assume, but I don't know enough about mpl to know if it can be added (nor how, if so). ---------- #include <boost/mpl/count_if.hpp> #include <boost/mpl/vector.hpp> #include <boost/mpl/vector_c.hpp> #include <boost/mpl/equal_to.hpp> #include <boost/mpl/at.hpp> #include <boost/mpl/int.hpp> int main() { using namespace boost::mpl; typedef vector < vector_c<int, 9>, vector_c<int, 0>, vector_c<int, 6>, vector_c<int, 0> >::type v; BOOST_STATIC_ASSERT((count_if < v, equal_to < int_<0>, at<_, int_<0> > // XXX > >::type::value == 2)); } ---------- thanks, scott

2 1

Uncaught exception in testfacet_dll
by Victor A. Wagner Jr. 18 Jul '04

18 Jul '04

I'm getting a "stop the script" error when running the test for testfacet_dll (VC7.1) it pops up a requestor telling me the program terminated unexpectedly, and (unfortunately) waits for a human reply (which causes my scheduled run to stop after 4 hours (it starts at 0300 local)), so I'm not getting the rest of the tests run. I chased it down to a std:exception w/ what() == bad cast I'm refining where the error occurs. with the following patches to testfacet.cpp: RCS file: /cvsroot/boost/boost/libs/date_time/test/gregorian/testfacet.cpp,v retrieving revision 1.14 diff -w -r1.14 testfacet.cpp 11c11 < --- > #include <exception> 39a40,41 > try > { 264a267,268 > try > { 265a270,272 > } > catch(std::exception& e) {check(e.what(), false);} > catch(...) {check("some unknown exception found", false);} 317d323 < 319d324 < 321c326,328 < --- > catch(std::exception& e) {check(e.what(), false);} > catch(...) {check("some unknown exception found", false);} > } ======================================================================== I get the following output when I run it from the command line C:\Projects\boost\status>..\bin\boost\libs\date_time\test\testfacet_dll.test\vc7.1\debug\testfacet_dll Pass :: check german short month: Okt Pass :: check german short month: Okt Pass :: check ymd: 01.Okt.2002 Pass :: ostream low level check string:01.Okt.2002 global: C Pass :: no registered facet here Pass :: facet registered here Pass :: check string imbued ostream: 2002-Okt-01 Pass :: check string imbued ostream: +unbegrenztheit Pass :: check string imbued ostream: +unbegrenztheit Pass :: check string imbued ostream: NichtDatumzeit Pass :: check any old ostream: 2002-Oct-01 Pass :: check date order: 01.10.2002 Pass :: check date order: 2002 Okt 01 Pass :: check date order: Oktober 01 2002 Pass :: check date period: [Oktober 01 2002/Oktober 03 2002] Pass :: date_duration stream out Pass :: date_duration stream out Pass :: partial date stream out Pass :: nth kday of month Pass :: first kday of month Pass :: last kday of month Pass :: first kday after Pass :: first kday after 26 Jun second Fri of Sep first Sat of May last Mon of Aug Thu after Tue before FAIL :: bad cast FAIL :: Stream in month FAIL :: bad cast C:\Projects\boost\status> ================================================================================== the log appears to show that this test PASSED tho..... execute-test ..\bin\boost\libs\date_time\test\testfacet_dll.test\vc7.1\debug\testfacet_dll.run 1 file(s) copied. **passed** ..\bin\boost\libs\date_time\test\testfacet_dll.test\vc7.1\debug\testfacet_dll.test ================================================================================== I'm working on getting some better "catch unknown exception" code put together so it can be added readily to tests to keep this from happening in the future. Victor A. Wagner Jr. http://rudbek.com The five most dangerous words in the English language: "There oughta be a law"

2 4

[test] Broken Jamfile or missing files?
by Jeff Garland 17 Jul '04

17 Jul '04

When I run the regression tests on Linux I get a couple errors from the test library: don't know how to make boost_regression1/boost/libs/test/test/result_report_test.pattern don't know how to make boost_regression1/boost/libs/test/test/errors_handling_test.pattern Is the Jamfile broken or are there some files that need to be checked in? Jeff ps: This has been like this for at least the last 2-3 days....

3 2

[serialization] CW problems...
by Rene Rivera 17 Jul '04

17 Jul '04

Rene Rivera wrote: > Robert Ramey wrote: > >> While your looking at CW, might you find the time to look a little bit >> into >> the serialization library build problems. The error message is pretty >> bizarre so I don't think it can be addressed without having CW >> installed on >> ones machine. > > OK, I'll try... Should I look for anything in specific? Or is it a > general health issue? I'm looking at this and one of the basic problems is that you seem to assume a variety of things are available in the global namespace, specifically size_t and other std types. Those are easy to fix by specifying std::size_t. But I do have some questions... 1. Is using an unqualified size_t your intention? And therefore something else is broken? 2. There is a similar problem with mbstate_t, but in this case you attempt to do something special to handle it (from boost/archive/codecvt_null.hpp): #if BOOST_WORKAROUND(__BORLANDC__, <= 0x564) #ifndef _RWSTD_NO_NAMESPACE using std::codecvt; using std::min; #ifdef _RWSTD_NO_MBSTATE_T using std::mbstate_t; #endif #endif #elif defined(__COMO__) || defined(_MSC_VER) && _MSC_VER <= 1300 || defined(__BORLANDC__) typedef ::mbstate_t mbstate_t; #elif defined(BOOST_NO_STDC_NAMESPACE) typedef std::mbstate_t mbstate_t; namespace std{ using ::codecvt; } // namespace std #endif And then you go ahead to use an unqualified mbstate_t. This just doesn't work for CW. And I don't see how this would work for any library runtime that puts mbstate_t only in the std namespace. Could you explain what your intent is for this? -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com - 102708583/icq

1 0

Re:[boost] Re: [threads] Compilation problems on CW and others...
by Robert Ramey 17 Jul '04

17 Jul '04

While your looking at CW, might you find the time to look a little bit into the serialization library build problems. The error message is pretty bizarre so I don't think it can be addressed without having CW installed on ones machine. Thanks, Robert Ramey

2 1

Re:Re: [boost] Boost Serialization Tests Status
by Robert Ramey 17 Jul '04

17 Jul '04

Martin Wille wrote: >> c) I don't think that gcc 2.95 can be used with the serialization library. >> The error messages seem to indicate this gcc doesn't have templated streams >> and the serialization library requires them. Perhaps some combination of >> gcc 2.95 - stlPort might work. I will exclude markup to skip the vanilla >> gcc 2.5 tests. >That's correct. The standard library implementation shipped with gcc-2 >is very limit with respect to streams: no templates, no locales, etc. >I'll remove the intel-8 results again. This looks very much like there >were stale .o files from the time when I didn't have enough disk space. >gcc-2 is not supported by Spirit. I planning to make Spirit 1.6.1 >available for the tests. Note that so far I know that spirit is only required for borland, msvc 6 and msvc 7.0. It's NOT needed for gcc 3.x. It might well be required for Intel 7.1 - I don't know. Robert Ramey

3 2

Re:Re: [boost] Boost Serialization Tests Status
by Robert Ramey 17 Jul '04

17 Jul '04

>I was talking about gcc-2.95.3, which is not supported by Spirit 1.8 > (you wrote about testing Serialization against gcc 2.95.3-stlport). >Intel 7.1 works fine with Spirit. I checked in changes that should make the demo tests pass. This weekend I'm going to experiment some with msvc-stlport and gcc-stlport. Robert Ramey

1 0

graph/subgraph: end iterator dereferenced
by Guillaume Melquiond 17 Jul '04

17 Jul '04

Hi, Line 189 of subgraph.hpp is: return std::make_pair((*i).second, i != m_local_vertex.end()); Consequently iterator i is dereferenced even when it is equal to m_local_vertex.end(). So here comes a patch. When *i is not valid, the patch simply returns u_global (the closest vertex_descriptor available to the code), another value may make better sense (but since the value is not supposed to be used). Regards, Guillaume

2 2