[C / C++] Portable library to measure time
Julek
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?
Victor Bazarov
> 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
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask
BGB / cr88192
"Julek" <jule...@go2.pl> wrote in message
news:90319dc1-1978-46f1...@z41g2000yqz.googlegroups.com...
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.
Richard
Julek <jule...@go2.pl> spake the secret code
<90319dc1-1978-46f1...@z41g2000yqz.googlegroups.com> thusly:
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."
--
"The Direct3D Graphics Pipeline" -- DirectX 9 draft available for download
<http://legalizeadulthood.wordpress.com/the-direct3d-graphics-pipeline/>
Legalize Adulthood! <http://legalizeadulthood.wordpress.com>
Richard
"BGB / cr88192" <cr8...@hotmail.com> spake the secret code
<hckadt$h06$1...@news.albasani.net> thusly:
>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.
James Kanze
> "Julek" <julek...@go2.pl> wrote in message
> news:90319dc1-1978-46f1...@z41g2000yqz.googlegroups.com...
> > 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...
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.
--
James Kanze
Dann Corbit
379373...@z41g2000yqz.googlegroups.com>, jule...@go2.pl says...
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
Phil Carmody
> Reply-To: (Richard) legaliz...@mail.xmission.com
> [Please do not mail me a copy of your followup]
What's that header supposed to imply, then?
Has surnameless Richard (you know, the one who posts drivel) morphed
in the last week or so?
Phil
--
Any true emperor never needs to wear clothes. -- Devany on r.a.s.f1
Keith Thompson
> legaliz...@mail.xmission.com (Richard) writes:
>> Reply-To: (Richard) legaliz...@mail.xmission.com
>
>> [Please do not mail me a copy of your followup]
>
> What's that header supposed to imply, then?
Perhaps it's added automatically by his news software.
--
Keith Thompson (The_Other_Keith) ks...@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
Nick Keighley
> On Nov 1, 3:45 pm, "BGB / cr88192" <cr88...@hotmail.com> wrote:
> > "Julek" <julek...@go2.pl> wrote in message
> >news:90319dc1-1978-46f1...@z41g2000yqz.googlegroups.com...
> > > 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...
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.
> > 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.
the poor bloody maintainer DOES though!
> > 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
> > ...
puke. I hate ifdefs.
> > 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.
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.
James Kanze
wrote:
> On 2 Nov, 10:18, James Kanze <james.ka...@gmail.com> wrote:
[...]
> > 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.
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).
[...]
> > 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.
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.
--
James Kanze