Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Newsgroups | comp.lang.c |
| Subject | Re: CLOCKS_PER_SEC |
| Date | 2016-10-13 11:29 -0700 |
| Organization | None to speak of |
| Message-ID | <lninswje6a.fsf@kst-u.example.com> (permalink) |
| References | <nto3cm$ps$1@dont-email.me> <lnr37kjl7y.fsf@kst-u.example.com> <44h98g5iii.fsf@be-well.ilk.org> |
Lowell Gilbert <lgusenet@be-well.ilk.org> writes:
> Keith Thompson <kst-u@mib.org> writes:
>> BartC <bc@freeuk.com> writes:
>>> CLOCKS_PER_SEC determines how the result of the clock() function is
>>> interpreted.
>>>
>>> But it seems to be defined as macro in time.h.
>>>
>>> Any ideas on how to determine that value when calling clock() as foreign
>>> function from another language? I want to avoid OS-specific functions
>>> unless they are available on both Windows and Linux.
>>>
>>> (At the moment, CLOCKS_PER_SEC seems to be usually 1000 on Windows and
>>> 1000000 on Linux. I suppose I could detect abnormally large values of
>>> clock() and infer it that way, but I think there will be some overlap in
>>> the set of valid results.)
>>
>> Write a C function that returns the value of the macro, and call that
>> function from the foreign language. Depending on your build system, you
>> can probably do this at configuration time rather than at run time.
>
> Or write a wrapper that returns the equivalent in nanoseconds.
Assuming that 1/CLOCKS_PER_SEC is a whole number of nanoseconds.
(I don't object to making the assumption, I'm just pointing out
that it is one.)
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
Back to comp.lang.c | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
CLOCKS_PER_SEC BartC <bc@freeuk.com> - 2016-10-13 14:49 +0100
Re: CLOCKS_PER_SEC Keith Thompson <kst-u@mib.org> - 2016-10-13 08:57 -0700
Re: CLOCKS_PER_SEC Keith Thompson <kst-u@mib.org> - 2016-10-13 09:07 -0700
Re: CLOCKS_PER_SEC BartC <bc@freeuk.com> - 2016-10-13 23:18 +0100
Re: CLOCKS_PER_SEC BartC <bc@freeuk.com> - 2016-10-13 23:30 +0100
Re: CLOCKS_PER_SEC Keith Thompson <kst-u@mib.org> - 2016-10-13 16:27 -0700
Re: CLOCKS_PER_SEC raltbos@xs4all.nl (Richard Bos) - 2016-10-16 10:02 +0000
Re: CLOCKS_PER_SEC Keith Thompson <kst-u@mib.org> - 2016-10-16 11:32 -0700
Re: CLOCKS_PER_SEC Lowell Gilbert <lgusenet@be-well.ilk.org> - 2016-10-13 12:19 -0400
Re: CLOCKS_PER_SEC Keith Thompson <kst-u@mib.org> - 2016-10-13 11:29 -0700
Re: CLOCKS_PER_SEC Lowell Gilbert <lgusenet@be-well.ilk.org> - 2016-10-13 14:39 -0400
Re: CLOCKS_PER_SEC Keith Thompson <kst-u@mib.org> - 2016-10-13 12:03 -0700
Re: CLOCKS_PER_SEC supercat@casperkitty.com - 2016-10-14 07:47 -0700
Re: CLOCKS_PER_SEC Anton Shepelev <anton.txt@g{oogle}mail.com> - 2016-10-14 16:21 +0300
Re: CLOCKS_PER_SEC Keith Thompson <kst-u@mib.org> - 2016-10-14 08:41 -0700
Re: CLOCKS_PER_SEC Anton Shepelev <anton.txt@g{oogle}mail.com> - 2016-10-14 18:56 +0300
Re: CLOCKS_PER_SEC Barry Schwarz <schwarzb@dqel.com> - 2016-10-14 09:49 -0700
Re: CLOCKS_PER_SEC Keith Thompson <kst-u@mib.org> - 2016-10-14 11:14 -0700
Re: CLOCKS_PER_SEC supercat@casperkitty.com - 2016-10-14 11:32 -0700
Re: CLOCKS_PER_SEC Jerry Stuckle <jstucklex@attglobal.net> - 2016-10-14 11:56 -0400
Re: CLOCKS_PER_SEC Anton Shepelev <anton.txt@g{oogle}mail.com> - 2016-10-14 19:53 +0300
Re: CLOCKS_PER_SEC supercat@casperkitty.com - 2016-10-14 09:57 -0700
Re: CLOCKS_PER_SEC BartC <bc@freeuk.com> - 2016-10-14 18:18 +0100
Re: CLOCKS_PER_SEC Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-10-16 02:55 -0700
csiph-web