C / C++ / MFC

for(i=0;i<n;i++)
{
    p=(struct cellule *)malloc(sizeof(struct cellule));
    scanf("%d",&(*p).a);
    if(i==0)
        liste = p;
    else
        (*q).suivant=p;
    q=p;
}
q->suivant = NULL; // Mark the last entry as having no follower

void affichage (struct cellule *liste){
    if (liste ==NULL) // this just needs to check for the end of the list
    {
        return; // no more entries
    }
    affichage(liste->suivant); // process the next entry in the list
    printf(" %d ",liste->a);   // on return print the current entry's value
}

class C {
public:
    int n;
    C() { n = 0; } // class constructor;
};

C c;  // declares an object of type C 
C *pc; // declares an pointer to an object of type C. 
       // The pointer does not point to any object.
       // Until it is instantiated, accessing *pc is undefined
C *pc2 = new C();  // declares a pointer to an object of type C
                   // A new object of type C is created on the stack
                   // and the object constructor is called
                   // the object will remain valid until a 
                   // corresponding delete is performed 

QBluetoothLocalDevice test;

QBluetoothLocalDevice

QBluetoothLocalDevice

class C {
public:
   int n;
   C() { n = -1; }
}

int main()
{
    C c;  // C:C() gets called here, assigning -1 to n;
    std::cout << c.n << '\n'; // will print -1
}

class C {
public:
   int n;
};

int main()
{
   C c; // compiler provided constructor called
   std::cout << c.n << '\n'; // This generates a warning with -Wall (gcc) that n is unititalized
}

Member 14968771 wrote:

Do I have to look thru the QBluetoothLocalDevice class documentation to find which method makes the "test" to contain all the hardware info?

QBluetoothLocalDevice localDevices;

QBluetoothLocalDevice *localDevices_new =  new QBluetoothLocalDevice();

Member 14968771 wrote:

This is a test
in few words of plain English ,

As quoted at QueryProcessCycleTime function (realtimeapiset.h) - Win32 apps | Microsoft Learn[^]:

The number of CPU clock cycles used by the threads of the process. This value includes cycles spent in both user mode and kernel mode.

2716
2793
2768
2617
2977
2708
2686
2795
2731
2651

2703
2891
52734
2611
2623
2613
2611
2609
2608
2592

CPallini wrote:

Absolute rubbish laddie!

peterchen wrote:

This blog post[^] suggests that it should be no worse than QueryPerformanceCounter, but that's not what I'm seeing.
Anyone with insights?

peterchen should have asked:

QueryProcessCycleTime uses the RDTSC instruction. QueryPerformanceCounter historically also used the RDTSC instruction. Why aren't they giving similar outputs?

Randor wrote:

As you probably already know the TSC is superceeded by the HPET.