This reserves all the memory space required for a QBluetoothLocalDevice object on the local stack. It then calls the constructor of the class to initialise any parts of that memory as specified in the class (see answers by @k5054). The variable localDevices holds the address of the object (even though it does not appear to be a pointer).
2. Create an object on the dynamic heap, and return a pointer to it.
QBluetoothLocalDevice *localDevices_new = new QBluetoothLocalDevice();
In this case the memory is requested from the heap, the constructor called to initialise it, and its address returned and saved in the pointer localDevices_new.
The end result is much the same in both cases, apart from the location and lifetime of the two objects. In case 1 the object only exists within the function where it is created; it is automatically destroyed when the function ends. In case 2 the object exists until it is destroyed by the delete statement, or the program terminates.
But as suggested elswhere, this is basic C++, which you should have learned and understood long before you charged down this rabbit hole that you currently find yourself in.
The question cannot be answered in "plain english" because it require concepts that only exist in programming. So as the other answers suggest one would need to understand what a 'local variable' is and what a 'heap' is for any answer to make sense.
This blog post[^] suggests that it should be no worse than QueryPerformanceCounter, but that's not what I'm seeing.
Anyone with insights?
My translation of what you are asking:
peterchen should have asked:
QueryProcessCycleTime uses the RDTSC instruction. QueryPerformanceCounter historically also used the RDTSC instruction. Why aren't they giving similar outputs?
As you probably already know the TSC is superceeded by the HPET. There are a dozen reasons why RDTSC provides inaccurate results. The Meltdown/Spectre mitigations were probably the nail in the coffin so to speak.
As you probably already know the TSC is superceeded by the HPET.
Not actually true though, QPC is based on HPET only when necessary, which is basically if you have a CPU that does not have Invariant TSC (and you don't, unless your CPU is from the mid 2000's). QPC is based on the TSC on every reasonable computer.
The fact that C/C++ is a staticly-typed language has nothing to do with static member functions. In turn these have very little to do with static functions in general. They are just 3 different uses for the same word.
Member 14968771 wrote:
If I have a C+_+ class and the function is defined as "static" - what is so different from function which is NOT defined as NOT static ?
Regular member functions have one extra hidden parameter, the "this" pointer, that points to the object on which they are called. Static member functions don't have this hidden parameter and are very much like any regular function except for some scoping rules.
"Static", like "object" and "module" are a very abused words in programming.
First you tried something without 'static' in place and it worked.
Second you put 'static' somewhere and now it doesn't work. The console output does not show up.
Not really a lot of information there. So the following are some possibilities for that behavior.
- You recompiled, it failed, and then when you ran something it did not find the binary. So it didn't actually run.
- You recompiled, it worked (because someone has some 'clever' code) and it failed with an exception. But you did not see that exception output or ignored it.
- You recompiled, it worked (because someone has some 'clever' code) and that other code worked. But you did not see any output because the actual method that was called, which is a different one, does not do console output.
You are describing a case where you have an existing application flow: Serial port to POS.
And you want to put monitoring place to see what that serial traffic looks like. So you don't want to replace or modify the existing code but rather just see what is happening.
So you should google for the following
windows serial port intercept
That said however I would suggest that if the POS code is under your control that the POS code itself should be modified to provide the same sort of monitoring. Log files (search for libraries) can both be used to control and collect such data.