[chrono] New Features + Bug fixes + Updated documentation
Hi, I'm pleased to annonce the new version of the Boost.Chrono library. Even if the library is not yet ready for review I wanted to share it with you. The library can be downloaded from the vault http://www.boostpro.com/vault/index.php?action=downloadfile&filename=chrono.zip&directory=System& and the documentation is online on the sandbox http://svn.boost.org/svn/boost/sandbox/chrono/libs/chrono/doc/html. For the moment I'm not able to test it on Windows and Mac platforms. Could you check if there are some regressions on Windows or on Mac platforms? Of course, any comments or suggestions are welcome. If there is a volontary review manager that can start inspecting the library s/he is also welcome :). This library is based on the Beman's boostified version of the probe of concept of Howard. Many thanks to Howard the originator of the library and to Beman to start the boostification. Next follows the contents of the library and the updates of the new version Version 0.1.0, April 29, 2009 Beman's boostified version Features: * The C++0x Standard Library's class common_type. * The C++0x Standard Library's compile-time rational arithmetic. * The C++0x Standard Library's time utilities, including: * Class template duration * Class template time_point * Clocks: * system_clock * monotonic_clock * high_resolution_clock * Class template timer, with typedefs: * system_timer * monotonic_timer * high_resolution_timer * Process clocks and timers: * process_clock, capturing real, user-CPU, and system-CPU times. * process_timer, capturing elapsed real, user-CPU, and system-CPU times. * run_timer, convenient reporting of process_timer results. Version 0.2.0, December 8, 2009 + New Features + Bug fixes + Updated documentation Features: * Added ratio construction and assignment from an equivalent ratio (LWG 1281. CopyConstruction and Assignment between ratios having the same normalized form) * Added nested ratio typedef type (LWG 1281. CopyConstruction and Assignment between ratios having the same normalized form) * Added BOOST_CHRONO_HAS_CLOCK_MONOTONIC macro to state if monotonic_clock is provided on a platform. * Added duration operator% (LWG 934. duration is missing operator%) * Complete duration operator* and operator/ Implementation: * Use INTMAC_C to name intmax_t constants instead of LL. * Separate chrono.cpp on # files win/chrono.cpp, mac/chrono.cpp and posix/chrono.cpp to make easier the maintenance on different platforms. * Separate process_clock.cpp on # files win/process_clock.cpp, mac/process_clock.cpp and posix/process_clock.cpp to make easir the maintenace on different platforms. * Added the error_code prototype for monotonic_clock::now for mac/chono.cpp * Fully implement mac/chrono.cpp with error handling. * Take care on POSIX systems when CLOCK_MONOTONIC is not defined. Documentation: * The documentation is written now using quick-book using as base "N2661 - A Foundation to Sleep On". Fixed Bugs * operator/ was ambiguous: Disambiguate duration operator/ * CLOCK_MONOTONIC is not defined with cygwin/gcc 3.4: Disable code when BOOST_CHRONO_HAS_CLOCK_MONOTONIC is not defined. * result of metafunctions ratio_multiply and ratio_divide were not normalized ratios: Use of the nested ratio typedef type on ratio arithmetic operations. * Copy constructor from similar duration masked the defaulted operations: Added duration defaulted implementations Note that the comon_type class should be integrated by Boost.TypeTraits, class ratio will be proposed as a standalone library Boost.Ratio, and the Timer and Process clock part could be proposed as an update of Boost.Timer. Best regards, _____________________ Vicente Juan Botet Escribá
vicente.botet wrote:
Version 0.1.0, April 29, 2009 Beman's boostified version Features:
My immediate thought is that the list contains non-Chrono content that should be provided in other libraries.
* The C++0x Standard Library's class common_type. * The C++0x Standard Library's compile-time rational arithmetic. * The C++0x Standard Library's time utilities, including:
I assume that common_type and compile-time rational arithmetic are necessary for Chrono, but they should not be documented as part of it and need to be reviewed separately. _____ Rob Stewart robert.stewart@sig.com Software Engineer, Core Software using std::disclaimer; Susquehanna International Group, LLP http://www.sig.com IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.
Stewart, Robert wrote:
vicente.botet wrote:
Version 0.1.0, April 29, 2009 Beman's boostified version Features:
My immediate thought is that the list contains non-Chrono content that should be provided in other libraries.
* The C++0x Standard Library's class common_type. * The C++0x Standard Library's compile-time rational arithmetic. * The C++0x Standard Library's time utilities, including:
I assume that common_type and compile-time rational arithmetic are necessary for Chrono, but they should not be documented as part of it and need to be reviewed separately.
Hi, this is exactly what I have proposed in the mail. See the last sentence:
Note that the common_type class should be integrated by Boost.TypeTraits, class ratio will be proposed as a standalone library Boost.Ratio, and the Timer and Process clock part could be proposed as an update of Boost.Timer.
Best, Vicente -- View this message in context: http://old.nabble.com/-chrono--New-Features-%2B-Bug-fixes-%2B-Updated-docume... Sent from the Boost - Dev mailing list archive at Nabble.com.
----- Original Message ----- From: "vicente.botet" <vicente.botet@wanadoo.fr> To: <boost@lists.boost.org>; <boost-users@lists.boost.org> Sent: Tuesday, December 08, 2009 11:46 PM Subject: [boost] [chrono] New Features + Bug fixes + Updated documentation Hi, I'm pleased to annonce the new version of the Boost.Chrono library. Even if the library is not yet ready for review I wanted to share it with you. The library can be downloaded from the vault http://www.boostpro.com/vault/index.php?action=downloadfile&filename=chrono.zip&directory=System& and the documentation is online on the sandbox http://svn.boost.org/svn/boost/sandbox/chrono/libs/chrono/doc/html. For the moment I'm not able to test it on Windows and Mac platforms. Could you check if there are some regressions on Windows or on Mac platforms? Of course, any comments or suggestions are welcome. _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost Hi, Tom Tan has reported me a lot of errors on Windows platform. * Replace INTMAC_C by BOOST_INTMAC_C. * Define BOOST_CHRONO_HAS_CLOCK_MONOTONIC when BOOST_CHRONO_WINDOWS_API * Commenting invalid operator declarations * Take care of Boost min/max recommendations These errors have been corrected on the sandbox revision (58287) There is yet an error with gcc-4.4.0 ./boost/chrono/chrono.hpp:945: error: declaration of 'typedef class boost::chrono::duration<long long int, boost::ratio<1ll, 10000000ll> > boost::chrono::system_clock::duration' ./boost/chrono/chrono.hpp:458: error: changes meaning of 'duration' from 'class boost::chrono::duration<long long int, boost::ratio<1ll, 10000000ll> >' Note that the line numbers will be no more significant. It corresponds to the following namespace chrono { template <class Rep, class Period> class duration {...} class BOOST_CHRONO_DECL system_clock { public: typedef BOOST_SYSTEM_CLOCK_DURATION duration; ... }; } where #ifdef BOOST_CHRONO_WINDOWS_API // The system_clock tick is 100 nanoseconds # define BOOST_SYSTEM_CLOCK_DURATION duration<boost::int_least64_t, ratio<BOOST_INTMAX_C(1), BOOST_INTMAX_C(10000000)> > #else # define BOOST_SYSTEM_CLOCK_DURATION boost::chrono::nanoseconds #endif There is also a lot of warnings, between them /boost/boost/type_traits/is_convertible.hpp: At global scope: /boost/boost/type_traits/is_convertible.hpp: In instantiation of 'const bool boost::detail::is_convertible_basic_impl<boost::chrono::duration<timeval_demo::xtime, boost::ratio<1ll, 1000000ll> >&, boost::chrono::duration<timeval_demo::xtime, boost::ratio<1ll, 1000000ll> > >::value': /boost/boost/type_traits/is_convertible.hpp:295: instantiated from 'const bool boost::detail::is_convertible_impl<boost::chrono::duration<timeval_demo::xtime, boost::ratio<1ll, 1000000ll> >, boost::chrono::duration<timeval_demo::xtime, boost::ratio<1ll, 1000000ll> > >::value' /boost/boost/type_traits/is_convertible.hpp:418: instantiated from 'boost::is_convertible<boost::chrono::duration<timeval_demo::xtime, boost::ratio<1ll, 1000000ll> >, boost::chrono::duration<timeval_demo::xtime, boost::ratio<1ll, 1000000ll> > >' /boost/boost/utility/enable_if.hpp:36: instantiated from 'boost::enable_if<boost::is_convertible<boost::chrono::duration<timeval_demo::xtime, boost::ratio<1ll, 1000000ll> >, boost::chrono::duration<timeval_demo::xtime, boost::ratio<1ll, 1000000ll> > >, void>' C:\cygwin\sandbox\chrono\libs\chrono\example\timeval_demo.cpp:189: instantiated from here /boost/boost/type_traits/is_convertible.hpp:136: warning: suggest parentheses around && within || Any hint? Thanks, Vicente
On Dec 11, 2009, at 3:37 AM, vicente.botet wrote:
There is yet an error with gcc-4.4.0
./boost/chrono/chrono.hpp:945: error: declaration of 'typedef class boost::chrono::duration<long long int, boost::ratio<1ll, 10000000ll> > boost::chrono::system_clock::duration' ./boost/chrono/chrono.hpp:458: error: changes meaning of 'duration' from 'class boost::chrono::duration<long long int, boost::ratio<1ll, 10000000ll> >'
Note that the line numbers will be no more significant. It corresponds to the following
namespace chrono {
template <class Rep, class Period> class duration {...}
class BOOST_CHRONO_DECL system_clock { public: typedef BOOST_SYSTEM_CLOCK_DURATION duration; ... }; }
where
#ifdef BOOST_CHRONO_WINDOWS_API // The system_clock tick is 100 nanoseconds # define BOOST_SYSTEM_CLOCK_DURATION duration<boost::int_least64_t, ratio<BOOST_INTMAX_C(1), BOOST_INTMAX_C(10000000)> > #else # define BOOST_SYSTEM_CLOCK_DURATION boost::chrono::nanoseconds #endif
Try qualifying "duration" with "chrono::" in BOOST_SYSTEM_CLOCK_DURATION: # define BOOST_SYSTEM_CLOCK_DURATION chrono::duration<boost::int_least64_t, ... -Howard
Hi, ----- Original Message ----- From: "Howard Hinnant" <howard.hinnant@gmail.com> To: <boost@lists.boost.org> Sent: Friday, December 11, 2009 5:20 PM Subject: Re: [boost] [chrono] New Features + Bug fixes + Updateddocumentation
On Dec 11, 2009, at 3:37 AM, vicente.botet wrote:
There is yet an error with gcc-4.4.0
./boost/chrono/chrono.hpp:945: error: declaration of 'typedef class boost::chrono::duration<long long int, boost::ratio<1ll, 10000000ll> > boost::chrono::system_clock::duration' ./boost/chrono/chrono.hpp:458: error: changes meaning of 'duration' from 'class boost::chrono::duration<long long int, boost::ratio<1ll, 10000000ll> >'
Note that the line numbers will be no more significant. It corresponds to the following
namespace chrono {
template <class Rep, class Period> class duration {...}
class BOOST_CHRONO_DECL system_clock { public: typedef BOOST_SYSTEM_CLOCK_DURATION duration; ... }; }
where
#ifdef BOOST_CHRONO_WINDOWS_API // The system_clock tick is 100 nanoseconds # define BOOST_SYSTEM_CLOCK_DURATION duration<boost::int_least64_t, ratio<BOOST_INTMAX_C(1), BOOST_INTMAX_C(10000000)> > #else # define BOOST_SYSTEM_CLOCK_DURATION boost::chrono::nanoseconds #endif
Try qualifying "duration" with "chrono::" in BOOST_SYSTEM_CLOCK_DURATION:
# define BOOST_SYSTEM_CLOCK_DURATION chrono::duration<boost::int_least64_t, ...
This could help if the warning was for windows API, but unfortunately it was reported be gcc-4.4.0 and also by gcc-4.3.4 :( Best, Vicente
On Dec 11, 2009, at 12:04 PM, vicente.botet wrote:
Hi, ----- Original Message ----- From: "Howard Hinnant" <howard.hinnant@gmail.com> To: <boost@lists.boost.org> Sent: Friday, December 11, 2009 5:20 PM Subject: Re: [boost] [chrono] New Features + Bug fixes + Updateddocumentation
On Dec 11, 2009, at 3:37 AM, vicente.botet wrote:
There is yet an error with gcc-4.4.0
./boost/chrono/chrono.hpp:945: error: declaration of 'typedef class boost::chrono::duration<long long int, boost::ratio<1ll, 10000000ll> > boost::chrono::system_clock::duration' ./boost/chrono/chrono.hpp:458: error: changes meaning of 'duration' from 'class boost::chrono::duration<long long int, boost::ratio<1ll, 10000000ll> >'
Note that the line numbers will be no more significant. It corresponds to the following
namespace chrono {
template <class Rep, class Period> class duration {...}
class BOOST_CHRONO_DECL system_clock { public: typedef BOOST_SYSTEM_CLOCK_DURATION duration; ... }; }
where
#ifdef BOOST_CHRONO_WINDOWS_API // The system_clock tick is 100 nanoseconds # define BOOST_SYSTEM_CLOCK_DURATION duration<boost::int_least64_t, ratio<BOOST_INTMAX_C(1), BOOST_INTMAX_C(10000000)> > #else # define BOOST_SYSTEM_CLOCK_DURATION boost::chrono::nanoseconds #endif
Try qualifying "duration" with "chrono::" in BOOST_SYSTEM_CLOCK_DURATION:
# define BOOST_SYSTEM_CLOCK_DURATION chrono::duration<boost::int_least64_t, ...
This could help if the warning was for windows API, but unfortunately it was reported be gcc-4.4.0 and also by gcc-4.3.4 :(
Try a preprocess (-E) and make sure system_clock looks the way you think it should. This could be a configuration error. I just copy/pasted your sandbox chrono.hpp into a test file and compiled it fine using gcc-4.4.0. -Howard
----- Original Message ----- From: "Howard Hinnant" <howard.hinnant@gmail.com> To: <boost@lists.boost.org> Sent: Friday, December 11, 2009 6:21 PM Subject: Re: [boost] [chrono] New Features + Bug fixes + Updateddocumentation
On Dec 11, 2009, at 12:04 PM, vicente.botet wrote:
Hi, ----- Original Message ----- From: "Howard Hinnant" <howard.hinnant@gmail.com> To: <boost@lists.boost.org> Sent: Friday, December 11, 2009 5:20 PM Subject: Re: [boost] [chrono] New Features + Bug fixes + Updateddocumentation
On Dec 11, 2009, at 3:37 AM, vicente.botet wrote:
There is yet an error with gcc-4.4.0
./boost/chrono/chrono.hpp:945: error: declaration of 'typedef class boost::chrono::duration<long long int, boost::ratio<1ll, 10000000ll> > boost::chrono::system_clock::duration' ./boost/chrono/chrono.hpp:458: error: changes meaning of 'duration' from 'class boost::chrono::duration<long long int, boost::ratio<1ll, 10000000ll> >'
Note that the line numbers will be no more significant. It corresponds to the following
namespace chrono {
template <class Rep, class Period> class duration {...}
class BOOST_CHRONO_DECL system_clock { public: typedef BOOST_SYSTEM_CLOCK_DURATION duration; ... }; }
where
#ifdef BOOST_CHRONO_WINDOWS_API // The system_clock tick is 100 nanoseconds # define BOOST_SYSTEM_CLOCK_DURATION duration<boost::int_least64_t, ratio<BOOST_INTMAX_C(1), BOOST_INTMAX_C(10000000)> > #else # define BOOST_SYSTEM_CLOCK_DURATION boost::chrono::nanoseconds #endif
Try qualifying "duration" with "chrono::" in BOOST_SYSTEM_CLOCK_DURATION:
# define BOOST_SYSTEM_CLOCK_DURATION chrono::duration<boost::int_least64_t, ...
This could help if the warning was for windows API, but unfortunately it was reported be gcc-4.4.0 and also by gcc-4.3.4 :(
Try a preprocess (-E) and make sure system_clock looks the way you think it should. This could be a configuration error. I just copy/pasted your sandbox chrono.hpp into a test file and compiled it fine using gcc-4.4.0.
Oh, I see. Tom Tam could be building on MinGW with gcc-4.4.0. I have sent him a mail to request your suggestion. BTW, gcc-4.3.4 didn't had the error on cygwin. Thanks, Vicente P.S. I think that I will need to install MinGW on my PC.
Hi, ----- Original Message ----- From: "vicente.botet" <vicente.botet@wanadoo.fr> To: <boost@lists.boost.org> Sent: Friday, December 11, 2009 11:34 PM Subject: Re: [boost] [chrono] New Features + Bug fixes + Updateddocumentation
----- Original Message ----- From: "Howard Hinnant" <howard.hinnant@gmail.com> To: <boost@lists.boost.org> Sent: Friday, December 11, 2009 6:21 PM Subject: Re: [boost] [chrono] New Features + Bug fixes + Updateddocumentation
Try a preprocess (-E) and make sure system_clock looks the way you think it should. This could be a configuration error. I just copy/pasted your sandbox chrono.hpp into a test file and compiled it fine using gcc-4.4.0.
Oh, I see. Tom Tam could be building on MinGW with gcc-4.4.0. I have sent him a mail to request your suggestion.
BTW, gcc-4.3.4 didn't had the error on cygwin.
Thanks, Vicente
P.S. I think that I will need to install MinGW on my PC.
Hi, I have installed MinGW with gcc4.4.0 and you were right. You suggestion solve the issue. I suppose that gcc_4.4.0 report an error that preceding version should report before, and that this is not a gcc-4.4.0 regression. I have also installed MSVC and I have an issue with the ratio_fail_test1.cpp test. MSVC report a warning instead of an error. compile-c-c++ ..\..\..\bin.v2\libs\chrono\test\ratio_fail_test1.test\msvc-9.0express\debug\asynch-exceptions-on\ratio_fail_test1.obj ratio_fail_test1.cpp C:\cygwin\boost_1_41_0\boost/ratio.hpp(217) : warning C4307: '*' : integral constant overflow C:\cygwin\boost_1_41_0\boost/ratio.hpp(394) : see reference to class template instantiation 'boost::detail::ll_mul<X,Y>' being compiled with [ X=0x7fffffffffffffff, Y=0x3fffffffffffffff ] ratio_fail_test1.cpp(12) : see reference to class template instantiation 'boost::ratio_multiply<R1,R2>' being compiled with [ R1=R1, R2=R2 ] C:\cygwin\boost_1_41_0\boost/ratio.hpp(217) : warning C4307: '*' : integral constant overflow C:\cygwin\boost_1_41_0\boost/ratio.hpp(395) : see reference to class template instantiation 'boost::detail::ll_mul<X,Y>' being compiled with [ X=0x3ffffffffffffff8, Y=0x7ffffffffffffff0 ] call "C:\Program Files\Microsoft Visual Studio 9.0\VC\vcvarsall.bat" x86 >nul cl /Zm800 -nologo @"..\..\..\bin.v2\libs\chrono\test\ratio_fail_test1.test\msvc-9.0express\debug\asynch-exceptions-on\ratio_fail_test1.obj.rsp" ...failed compile-c-c++ ..\..\..\bin.v2\libs\chrono\test\ratio_fail_test1.test\msvc-9.0express\debug\asynch-exceptions-on\ratio_fail_test1.obj... ...removing ..\..\..\bin.v2\libs\chrono\test\ratio_fail_test1.test\msvc-9.0express\debug\asynch-exceptions-on\ratio_fail_test1.obj ...removing outdated ..\..\..\bin.v2\libs\chrono\test\ratio_fail_test1.test\msvc-9.0express\debug\asynch-exceptions-on\ratio_fail_test1.test I have added [ compile-fail ratio_fail_test1.cpp : <warnings-as-errors>on ] and all is right. Is there another way to make MSVC report an error when there is an integral constant overflow? Thanks a lot Howard for your help, Vicente
On Dec 12, 2009, at 5:22 AM, vicente.botet wrote:
I have also installed MSVC and I have an issue with the ratio_fail_test1.cpp test. MSVC report a warning instead of an error.
compile-c-c++ ..\..\..\bin.v2\libs\chrono\test\ratio_fail_test1.test\msvc-9.0express\debug\asynch-exceptions-on\ratio_fail_test1.obj ratio_fail_test1.cpp C:\cygwin\boost_1_41_0\boost/ratio.hpp(217) : warning C4307: '*' : integral constant overflow C:\cygwin\boost_1_41_0\boost/ratio.hpp(394) : see reference to class template instantiation 'boost::detail::ll_mul<X,Y>' being compiled with [ X=0x7fffffffffffffff, Y=0x3fffffffffffffff ] ratio_fail_test1.cpp(12) : see reference to class template instantiation 'boost::ratio_multiply<R1,R2>' being compiled with [ R1=R1, R2=R2 ] C:\cygwin\boost_1_41_0\boost/ratio.hpp(217) : warning C4307: '*' : integral constant overflow C:\cygwin\boost_1_41_0\boost/ratio.hpp(395) : see reference to class template instantiation 'boost::detail::ll_mul<X,Y>' being compiled with [ X=0x3ffffffffffffff8, Y=0x7ffffffffffffff0 ]
call "C:\Program Files\Microsoft Visual Studio 9.0\VC\vcvarsall.bat" x86 >nul cl /Zm800 -nologo @"..\..\..\bin.v2\libs\chrono\test\ratio_fail_test1.test\msvc-9.0express\debug\asynch-exceptions-on\ratio_fail_test1.obj.rsp"
...failed compile-c-c++ ..\..\..\bin.v2\libs\chrono\test\ratio_fail_test1.test\msvc-9.0express\debug\asynch-exceptions-on\ratio_fail_test1.obj... ...removing ..\..\..\bin.v2\libs\chrono\test\ratio_fail_test1.test\msvc-9.0express\debug\asynch-exceptions-on\ratio_fail_test1.obj ...removing outdated ..\..\..\bin.v2\libs\chrono\test\ratio_fail_test1.test\msvc-9.0express\debug\asynch-exceptions-on\ratio_fail_test1.test
I have added
[ compile-fail ratio_fail_test1.cpp : <warnings-as-errors>on ]
and all is right.
Is there another way to make MSVC report an error when there is an integral constant overflow?
The intent is to have ll_mul cause an error with the C++0x feature "static_assert" instead of relying on the compiler to do it. This line: static char test[a_x <= max / a_y]; is meant to fail at compile time if there is an overflow during multiplication. I suggest you insert the boost macro version of static_assert (I'm not sure what the syntax is). It has probably already been tuned to work well on MSVC. If you do this throughout, everywhere I've got a commented out static_assert, and arrays of char, I think you'll get what you're looking for. Sorry, I should've done this in the first place. -Howard
Hi, ----- Original Message ----- From: "Howard Hinnant" <howard.hinnant@gmail.com> To: <boost@lists.boost.org> Sent: Saturday, December 12, 2009 2:40 PM Subject: Re: [boost] [chrono] New Features + Bug fixes + Updateddocumentation
On Dec 12, 2009, at 5:22 AM, vicente.botet wrote:
I have also installed MSVC and I have an issue with the ratio_fail_test1.cpp test. MSVC report a warning instead of an error.
I have added
[ compile-fail ratio_fail_test1.cpp : <warnings-as-errors>on ]
and all is right.
Is there another way to make MSVC report an error when there is an integral constant overflow?
The intent is to have ll_mul cause an error with the C++0x feature "static_assert" instead of relying on the compiler to do it. This line:
static char test[a_x <= max / a_y];
is meant to fail at compile time if there is an overflow during multiplication. I suggest you insert the boost macro version of static_assert (I'm not sure what the syntax is). It has probably already been tuned to work well on MSVC. If you do this throughout, everywhere I've got a commented out static_assert, and arrays of char, I think you'll get what you're looking for. Sorry, I should've done this in the first place.
I have replaced the use of static_assert by BOOST_STATIC_ASSERT and added a conditional compilation on BOOST_CHRONO_USES_STATIC_ASSERT and now this works as expected. Do you think it is worth removing the dependency to Boost.StaticAssert? Thanks again, Vicente
On Dec 13, 2009, at 12:50 PM, vicente.botet wrote:
Hi, ----- Original Message ----- From: "Howard Hinnant" <howard.hinnant@gmail.com> To: <boost@lists.boost.org> Sent: Saturday, December 12, 2009 2:40 PM Subject: Re: [boost] [chrono] New Features + Bug fixes + Updateddocumentation
On Dec 12, 2009, at 5:22 AM, vicente.botet wrote:
I have also installed MSVC and I have an issue with the ratio_fail_test1.cpp test. MSVC report a warning instead of an error.
I have added
[ compile-fail ratio_fail_test1.cpp : <warnings-as-errors>on ]
and all is right.
Is there another way to make MSVC report an error when there is an integral constant overflow?
The intent is to have ll_mul cause an error with the C++0x feature "static_assert" instead of relying on the compiler to do it. This line:
static char test[a_x <= max / a_y];
is meant to fail at compile time if there is an overflow during multiplication. I suggest you insert the boost macro version of static_assert (I'm not sure what the syntax is). It has probably already been tuned to work well on MSVC. If you do this throughout, everywhere I've got a commented out static_assert, and arrays of char, I think you'll get what you're looking for. Sorry, I should've done this in the first place.
I have replaced the use of static_assert by BOOST_STATIC_ASSERT and added a conditional compilation on BOOST_CHRONO_USES_STATIC_ASSERT and now this works as expected.
Do you think it is worth removing the dependency to Boost.StaticAssert?
No, I think use of boost's static_assert is fine. Over time that will migrate to the C++0X static_assert without this code needing to change. -Howard
participants (4)
-
Howard Hinnant -
Stewart, Robert -
Vicente Botet Escriba -
vicente.botet