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?
Julek writes: > 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?
Julek wrote: > 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
> 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
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.
Julek <julek...@go2.pl> spake the secret code <90319dc1-1978-46f1-81f5-37937305d...@z41g2000yqz.googlegroups.com> thusly:
>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?
"BGB / cr88192" <cr88...@hotmail.com> spake the secret code <hckadt$h0...@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.
On Nov 1, 3:45 pm, "BGB / cr88192" <cr88...@hotmail.com> wrote:
> "Julek" <julek...@go2.pl> wrote in message > news:90319dc1-1978-46f1-81f5-37937305da3e@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.
In article <90319dc1-1978-46f1-81f5- 37937305d...@z41g2000yqz.googlegroups.com>, julek...@go2.pl says...
> 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?
#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;
legalize+jee...@mail.xmission.com (Richard) writes: > Reply-To: (Richard) legalize+jee...@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
>> [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"
On 2 Nov, 10:18, James Kanze <james.ka...@gmail.com> wrote:
> On Nov 1, 3:45 pm, "BGB / cr88192" <cr88...@hotmail.com> wrote: > > "Julek" <julek...@go2.pl> wrote in message > >news:90319dc1-1978-46f1-81f5-37937305da3e@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:
> 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.
On Nov 5, 10:18 am, Nick Keighley <nick_keighley_nos...@hotmail.com> 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.
|
