[C / C++] Portable library to measure time

J

Julek

Is there any simple library that can return a systemtime in a
resolution of max. 10ms, working on both Windows XP and modern Linux?
time() works on both but has a resolution of 1s. There is
GetSystsmTime on Windows with 10ms resolution, there are probably also
some functions for Linux - but maybe there is some library works on
both these OSes?
 
V

Victor Bazarov

Julek said:
Is there any simple library that can return a systemtime in a
resolution of max. 10ms, working on both Windows XP and modern Linux?

Nothing can be better than the underlying OS unless you have a special
way of going to the hardware that the OS doesn't do. So, dig into the
OS APIs and find out.
time() works on both but has a resolution of 1s. There is
GetSystsmTime on Windows with 10ms resolution, there are probably also
some functions for Linux - but maybe there is some library works on
both these OSes?

Maybe or maybe not. Why don't you write one?

V
 
B

BGB / cr88192

Julek said:
Is there any simple library that can return a systemtime in a
resolution of max. 10ms, working on both Windows XP and modern Linux?
time() works on both but has a resolution of 1s. There is
GetSystsmTime on Windows with 10ms resolution, there are probably also
some functions for Linux - but maybe there is some library works on
both these OSes?

don't use a library for what you can trivially do yourself...
using libs in this case does little more than create external dependencies
for which any potential users of said code may be forced to deal with later.

a lib is good if it is known to be commonly or near universally available,
is already in use of a project, or represents a non-trivial amount of work,
but otherwise I feel use of libs is ill-advised, as it may create
portability issues (and people trying to dig around online to find "X
obscure library no one has heard of", or figuring out how to do likewise by
looking at the code and figuring out what the API calls do...)..


now, maybe of some help:
#ifdef linux
....
gettimeofday(...);
....
#endif

or, maybe even:
#if defined(linux) || defined(__BSD__) || defined (__MACOSX__) || ...
....
gettimeofday(...);
....
#endif



my personal suggestion is to create a function, or maybe collection of them,
which provide a consistent interface to OS-specific behaviors, and keep any
OS specific parts confined to these functions.
 
R

Richard

[Please do not mail me a copy of your followup]

Julek <[email protected]> spake the secret code
Is there any simple library that can return a systemtime in a
resolution of max. 10ms, working on both Windows XP and modern Linux?
time() works on both but has a resolution of 1s. There is
GetSystsmTime on Windows with 10ms resolution, there are probably also
some functions for Linux - but maybe there is some library works on
both these OSes?

See Boost.DateTime
<http://www.boost.org/doc/libs/1_40_0/doc/html/date_time/posix_time.html>

"Defines a non-adjusted time system with nano-second/micro-second
resolution and stable calculation properties."
 
R

Richard

[Please do not mail me a copy of your followup]

"BGB / cr88192" <[email protected]> spake the secret code
don't use a library for what you can trivially do yourself...
[...]
my personal suggestion is to create a function, or maybe collection of them,
which provide a consistent interface to OS-specific behaviors, and keep any
OS specific parts confined to these functions.

In other words: reinvent someone else's library.
 
J

James Kanze

don't use a library for what you can trivially do yourself...

That's ridiculous. You're job is to provide the best possible
solution at the lowest possible cost. Reinventing something
that is already available should only be done when there is a
very good reason for not using what is available. (Copyright
restrictions come to mind---some projects can't use GPL, for
example.)
using libs in this case does little more than create external
dependencies for which any potential users of said code may be
forced to deal with later.

If you're using a third party library, users never see it.
a lib is good if it is known to be commonly or near
universally available, is already in use of a project, or
represents a non-trivial amount of work, but otherwise I feel
use of libs is ill-advised, as it may create portability
issues (and people trying to dig around online to find "X
obscure library no one has heard of", or figuring out how to
do likewise by looking at the code and figuring out what the
API calls do...)..
now, maybe of some help:
#ifdef linux
...
gettimeofday(...);
...
#endif
or, maybe even:
#if defined(linux) || defined(__BSD__) || defined (__MACOSX__) || ...
...
gettimeofday(...);
...
#endif

And you say that using a lib will create portability issues?
What happens when you encounter a new OS? (And of course,
conditional compilation can quickly make the code completely
unreadable.)
my personal suggestion is to create a function, or maybe
collection of them, which provide a consistent interface to
OS-specific behaviors, and keep any OS specific parts confined
to these functions.

In other words, write a library that someone else has already
written.

Sometimes it's necessary---there can be a number of reasons not
to use an existing library. But you shouldn't rewrite it unless
it is necessary for some reason.
 
D

Dann Corbit

Is there any simple library that can return a systemtime in a
resolution of max. 10ms, working on both Windows XP and modern Linux?
time() works on both but has a resolution of 1s. There is
GetSystsmTime on Windows with 10ms resolution, there are probably also
some functions for Linux - but maybe there is some library works on
both these OSes?

This is (undoubtably) the most famous portable time library:
ftp://elsie.nci.nih.gov/pub/

Here is Bernstein's libtai (be aware that Posix IGNORES leap seconds):
http://cr.yp.to/libtai.html

Here is a Windows flavored gettimeofday():

#include <windows.h>
/* FILETIME of Jan 1 1970 00:00:00. */
static const unsigned long long epoch = 116444736000000000ULL;

/*
* timezone information is stored outside the kernel so tzp isn't used
anymore.
*
* Note: this function is not for Win32 high precision timing purpose.
See
* elapsed_time().
*/
int
gettimeofday(struct timeval * tp, struct timezone * tzp)
{
FILETIME file_time;
SYSTEMTIME system_time;
ULARGE_INTEGER ularge;

GetSystemTime(&system_time);
SystemTimeToFileTime(&system_time, &file_time);
ularge.LowPart = file_time.dwLowDateTime;
ularge.HighPart = file_time.dwHighDateTime;

tp->tv_sec = (long) ((ularge.QuadPart - epoch) / 10000000L);
tp->tv_usec = (long) (system_time.wMilliseconds * 1000);

return 0;
}

HTH
 
N

Nick Keighley

wrapper the 3rd party lib so different libraries present the same
abstraction (interface) to the application code. Software Engineering
101.
That's ridiculous.  You're job is to provide the best possible
solution at the lowest possible cost.  

"lowest possible /lifetime/ cost"
Reinventing something
that is already available should only be done when there is a
very good reason for not using what is available.  (Copyright
restrictions come to mind---some projects can't use GPL, for
example.)

as someone who is lumbered with some unsupported 3PLs there can be
other reasons. Some 3PLs cost money. Sometimes a lot of money.
If you're using a third party library, users never see it.

the poor bloody maintainer DOES though!


puke. I hate ifdefs.

And you say that using a lib will create portability issues?
What happens when you encounter a new OS?  (And of course,
conditional compilation can quickly make the code completely
unreadable.)

yep


In other words, write a library that someone else has already
written.

Sometimes it's necessary---there can be a number of reasons not
to use an existing library.  But you shouldn't rewrite it unless
it is necessary for some reason.

wrapper it. For instance we have a socket interface library that hides
the differences between Windows and Unix (originally HP-Unix) sockets.
Personnally I'd like to rewrite it so there was more shared code and
less ifdefs but it does do the job.
 
J

James Kanze

On 2 Nov, 10:18, James Kanze <[email protected]> wrote:

[...]
as someone who is lumbered with some unsupported 3PLs there
can be other reasons. Some 3PLs cost money. Sometimes a lot of
money.

And some are of such low quality that you can't allow them. Or
you're unsure of future support, or portability (from
experience, a lot of so-called portable libraries don't work
with Sun CC).

[...]
wrapper it.

If it's an essential part of your application, always. Even if
the library in question is the standard library. Wrappered, and
you have the chance of replacing it, if e.g. it causes
performance problems.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,743
Messages
2,569,478
Members
44,899
Latest member
RodneyMcAu

Latest Threads

Top