Use <chrono>, ffs. And yes, it does call QPC internally on Windows.

Simple example:

#include <chrono>

class Timer {
public:
  Timer() { prev = now(); }

  //get seconds elapsed since last getDT (or construction)
  float getDT() {
    auto cur = now();
    std::chrono::duration<float> seconds = cur - prev;
    prev = cur;
    return seconds.count();
  }

private:
  static std::chrono::time_point<std::chrono::high_resolution_clock> now() {
    return std::chrono::high_resolution_clock::now();
  }

  std::chrono::time_point<std::chrono::high_resolution_clock> prev;

};

If you look over the docs, there are a lot of units for represent various durations and points in time, etc. You can cast between units to do conversions in a moderately human-readable way.

Quoting articles that are 10+ yrs old really helps no one. Honestly if they didn't patch their hardware (and yes in most cases patches of some sorted existed) it is their problem. Do not code for the fringe cases unless that is your market.

If you're using C++11 or higher do exactly as Khatharr shows and move on with your life. This is a pretty solved problem, that this thread is so long scares me.

Quoting articles that are 10+ yrs old really helps no one. Honestly if they didn't patch their hardware (and yes in most cases patches of some sorted existed) it is their problem. Do not code for the fringe cases unless that is your market.

If you're using C++11 or higher do exactly as Khatharr shows and move on with your life. This is a pretty solved problem, that this thread is so long scares me.

The article aren't the problem, neither using the Win API directly or using the std::chrono, the problem is that it is impossible to track what's wrong without any sample of code.

* flies away like a penguin *

Actually they are a problem as some people might think they still matter. Yes, the OP did nothing to help himself by providing no code and then blaming everything but himself. But at the same time, a few people stated that QPC was bad or not to use it. That is not the case though. That was what I referring too.

I've never seen a thread be so divided, it seems like half are pro QPC and half are against. In any case this is my WinMain loop:

resetEntry:
 
    CreateEngineWindow();
    GameEngineInitialization();
 
    while (TRUE)
    {
        // test if there is a message in queue, if so get it and remove it from the queue
        if (PeekMessage(&msg, NULL, 0, 0, PM_REMOVE))
        {
 
            if (msg.message == WM_QUIT)
                break;
 
 
            TranslateMessage(&msg);
            DispatchMessage(&msg);
 
        }
      else
      {
           LARGE_INTEGER currentTime;
           QueryPerformanceCounter(&currentTime);
           Timer.deltaTime = float( (currentTime.QuadPart - Timer.lastTime.QuadPart) / Timer.frequency.QuadPart);
 
           //for first run
           if (Timer.deltaTime > 3)
                Timer.deltaTime = 0;
 
           int code = GameEngineUpdate();
 
           if (code == APPUPDATE_RESET)
           {
              ApplicationSettings();
              GameEngineShutdown();

              goto resetEntry;
           }
 
           QueryPerformanceCounter(&Timer.lastTime);
     }
 
}

This is it:

LARGE_INTEGER currentTime;
QueryPerformanceCounter(&currentTime);
Timer.deltaTime = float(currentTime.QuadPart - Timer.lastTime.QuadPart) / Timer.frequency.QuadPart;

That's at frame start at frame end I call QPC(&Timer.lastTime).

double prevTimeInSeconds = timeInSeconds;
timeInSeconds = ((double)now.QuadPart)/((double)freq.QuadPart);
float delta = (float)(timeInSeconds - prevTimeInSeconds);

What's the difference between when I convert to float before the division or after? The frequency is in the range of 2 million, the actual double double difference between times are about 6k usually so in most cases it's doing something like float(6k) / double double(freq), the result should be something like 0.00x way less than float capacity.

So I just want to be clear that we came to some conclusion here. I have to always give up one core no matter what I do to use QPC. So on my quad core machine I'm only left with 6 physical threads? How is this possible?

Edit: But how would that even work? If I'm timing a non active thread and my main code is on other core then the qpc will still return an invalid result.

Edit: OK after some more reading, I think Microsoft is saying QPC should not be used for inter-core timing. The examples they give is just timing within the thread, I'm guessing mostly for codebenching purposes. The proper way seems to be using timeGetTime. I'm not sure why you guys are saying that it's low resolution for game code. It could go down to 1ms, my update code must be at least 16ms that would give me 60hz refresh. For 30hz refresh I could need as much as 32ms.

Edit: I already mentioned this but the reason I'm not using timeGetTime is because it's returning zero for delta.