hello, i’m new to programming in i’m trying to solve this exercise in C, basically it’s the amount of passed hours between the start of a game and it’s end, if the game started at 16 and ended at 2 the result is a game with 10 hours(in different days) i know i can to it more manually, but i wanted to somehow use the <time.h> to learn how to use a header etc, can someone help me?, thank you all

  • tunetardis@lemmy.ca
    3·
    1 year ago

    The arbitrary values at the beginning of the program is the reason you want to measure a difference rather than an absolute time. Like you don’t want to simply go (double)clock() / CLOCKS_PER_SEC at the end of the program. That would only work if you knew for certain that the clock started at 0 on program launch. Some operating systems may ensure this. Others may only zero it when the CPU is booted, for example. So it’s just not safe to work with absolute times, but differences between time stamps should still behave consistently across platforms.

    Now, the problem with time() and friends is they represent the kind of time displayed by your computer. In most cases, this should work fine, but occasionally, the OS may adjust this time for a number of reasons. It may be jumping ahead or back due to daylight savings, for example, or adding/losing some seconds as it syncs the computer clock to an NTP server someplace. What you want to use to avoid such shenanigans in measuring time elapsed is a steady clock which ticks along regardless of what the OS decides to do. I think clock() is your best bet for that in plain C? (It also may have a higher resolution than time(), though that’s not super important if you’re only worried about counting hours.)

    • Juniper@skein.city
      1·
      1 year ago

      Using clock() solely for delta values is absolutely a valid approach, as stated. The issue is that clock_t may not be large enough of some systems to safely keep you from an overflow, especially with arbitrary values. Additionally, some systems will include the time children processes were alive in subsequent clock() calls, furthering possible confusion. These are reasons why I would avoid clock() in favor of time(), even though your concerns are absolutely valid.

      At the end of the day you have to determine which style of unpredictability you want to work around. Dealing with the times(), clock(), and clock_gettime() class of functions opens you up to managing what the kernel considers time passed, and what is accumulated vs what is not. While using time() can have shifts in time according to upstream NTP servers, as well as daylight savings time.

      I would also make the argument that if an NTP server is adjusting your time, it is most likely more accurate than what your internal clock (CMOS or otherwise) was counting, and is worth following.

      • tunetardis@lemmy.ca
        2·
        1 year ago

        Okay, I’ve read up on this a bit an you raise some valid points.

        For whatever reason, posix has decided that CLOCKS_PER_SEC must be exactly 1000000 on every system that wants to comply. That doesn’t leave much room on a 32-bit system for maximum clock duration. It will wrap around well before the 10 hours the OP was giving by example.

        The other is I gather on some systems, clock() may be measuring the uptime of a particular process, which is not necessarily the same as real world time in multicore environments. (Fwiw I’m on a Mac where I don’t think it works that way? You would need some special apis to get that kind of info.)

        I’m trying to think of the last time I programmed straight C and used time.h and the like. It was probably in developing scientific instrumentation? iirc the clock in that case was keyed to the VBL refresh of the display, meaning CLOCKS_PER_SEC would have been something like 60 Hz. And I doubt time() would have yielded any useful value. I wonder what the OP’s use case is?