[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[lmi] Safe to assume std::uint64_t is available?

From: Greg Chicares
Subject: [lmi] Safe to assume std::uint64_t is available?
Date: Sun, 5 Jun 2016 17:09:35 +0000
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Icedove/38.8.0

Vadim--Does the patch below seem good to you? (Here, apparently the
borland workaround was preferable to the code we were using for gcc.)

I hesitate only because the exact-width integer types are optional
[18.4.1]. This section of the code is for msw only; would any C++11
(or more modern) compiler targeting msw really fail to provide uint64_t?

--- ./timer.hpp2016-06-05 15:52:14.593750000 +0000
+++ a00/timer.hpp2016-06-05 16:59:46.000000000 +0000
@@ -34,15 +34,8 @@
     // Compilers for this platform use various types for its high-
     // resolution timer, but they use the same platform API, so
     // it's sufficient to use the same 64-bit integer type for all.
-    //
-    // Type double can't be used, even though it be the right size:
-    // arithmetic performed on this type requires that it be integral.
-    //
-#   ifndef __BORLANDC__
-    typedef unsigned long long int elapsed_t;
-#   else // __BORLANDC__
-    typedef unsigned __int64 elapsed_t;
-#   endif // __BORLANDC__
+#   include <cstdint>
+    typedef std::uint64_t elapsed_t;
 #else // Unknown platform.
 #   include <ctime>
     typedef std::clock_t elapsed_t;


reply via email to

[Prev in Thread] Current Thread [Next in Thread]