@SGaist Thank you for the time you spent!

@Vinoth-Rajendran4
Further to @Christian-Ehrlicher, in other words that means you need to delete the statement Hello* obj = new Hello;! Your calling code will go new Hello, and that will execute your constructor and return the created instance, you don't want another new Hello anywhere inside your Hello class as it stands.

Thank you @Konstantin-Tokarev .

Will look into the link provided by you.

Old thread and I should know better than to chime in, but everyone is entitled to my opinion. Also, I had this very issue posed to me the other day in our embedded domain.

If you are dealing with existing CAN devices that expect network transport of IEEE floating point numbers then you have to go with what is expected and my comments are moot. However, if you have control over the endpoints in your networking of devices then you should NOT transport floating point numbers as such across a network. AUTOSAR, MISRA, and JPL coding standards all recognize why this is a bad idea.

Our engineer is designing a microcontroller based controller and he did the union/float thing to represent data being exchanged. I quickly got him on-board to use scaled integers instead, which are more the standard in the automotive CAN arena. There are some legacy devices that use fixed precision ASCII representations of floating point numbers, such as NMEA/GPS, so that is also an option where bandwidth is not a concern.

Some points to consider regarding transport of native floating point numbers:

different or adhoc endian format of devices devices that require native types to start on processor word sized boundaries devices that emulated floating point operations (no FPU)

Anyway, just something to think about.

@JonB said in Stack/Heap/smart pointers question.:

the size of an object which is to be allocated on the stack must be known at compile time, there is no workaround for this, it's an architectural "issue".

Now, you know I always read what you write with interest, my friend! But I don't understand why you pick this out as a "stricture" of stack allocation?

For the purpose of pedagogy. There's a gnu extension which allows you a stack based array with a runtime constant as size, as well, but it's not standard.

What about alloca(), which has been there since year dot in Unix, and I see is still supported by gcc and in msvc (_alloca())?

Did not mention it, and specifically avoided it, because the memory isn't freed when you leave the current scope, it's freed when the stack frame's popped. This is rather dangerous and can be messy. And in the C++ world *alloc() functions are discouraged in most cases. If you want an array of objects and you take the memory block through alloca you need to do a placement new on top of it to follow C++ semantics, so your constructors are called, and finally you need to manually invoke the destructors before exiting. This isn't ideal in the world of RAII.

I'm not suggesting people go out and start using it, but it does not require a compile-time constant argument, so how does this relate to your "architectural" claim above?

Not too well. I was specifically thinking of push and pop. Granted, alloca will move the top of the stack frame, and as with any integer that can be done at runtime, but it's a bad idea generally. In fact this is what the compiler does when you do a regular stack allocation - it moves the stack pointer the size of the object off the stack frame pointer (i.e. move the esp register in relation to the ebp register), with the exception that it validates the consistency at compile time (and static code analysis can be easily supported). Also the meaning is clearer, as you know the memory is local. With alloca you can pass the pointer to somewhere else, and without realizing that pointer's data block can get invalidated the moment you leave the current stack frame. It's not for the faint of heart.

@sierdzio said in compiler optimization:

I have no idea if it matters in this case, though.

A great deal. QString has an additional indirection through the d_ptr and this is the great wall of china standing in front of the optimizations the compiler could possibly make.

@JKSH thank you!

@Engelard this involves Windows API functions which find the window from the cursor point, possibly with WindowFromPoint which returns an HWND. From that HWND you can resolve the parent process with GetProcessHandleFromHwnd .

At the core of Windows applications is the message loop within which it calls a callback function, or window procedure, to handle event messages. There's a function called SetWinEventHook which allows intercepting certain window messages in a given range.

Now, if fraps can get the HWND of your app it can either intercept the WM_PAINT message to get a device context to draw over the top of the content, or it could create a child window displaying the FPS. But those are guesses.

Other than what I've speculated on, if you want to find out what's actually happening, you could use OllyDbg to reverse engineer the program.

@SGaist said in Statistics c++:

histogram from the frequencies of cats running through a street by moonless night

I have been scouring the internet for this! 😉

@JonB said in Simple big-looped program break down:

Doesn't "doubling" mean "the next power of 2"?

Yeah. I'm not at the top of my game, so you can probably safely ignore me.

@Please_Help_me_D said in General question about arrays and I/o:

I need to extract {4, 2, 3}

You will need to do it by yourself. There is nothing for that neither in Qt nor in C++ stdlib. Even if there would be it would do nothing else as iterating over {4, 2, 3} in a loop. So, I doubt you can optimise here much.

@KroMignon said in QList and smart pointers:

auto obj=QSharedPointer<MyCustomObj>(new MyCustomObj, &QObject::deleteLater);

Your post interested me. I read some articles on this and I get the idea that you should not mix ownership methods. QObject based system uses parent/child to express ownership. So if you use smart pointers you should not use the parent/child ownership. I explored your custom deleter strategy with std smart pointers:

{ // smart pointers combined with custom deleter for use with QObject based objects using namespace std; shared_ptr<QObject> ptr(new QObject, [](QObject* p){ p->deleteLater(); }); unique_ptr<QObject,function<void(QObject*)>> ptr2(new QObject, [](QObject* p){ p->deleteLater(); }); }

I am filing this away for future use. Thanks for sharing.

Hi and welcome to devnet,

Where is your threading code ?
What do you do in it ?
Are you creating widgets in that thread ? If that's the case then it's wrong. Widgets creation and manipulation should be done in the QApplication thread i.e the main thread

@kshegunov said in Returning unique_ptr and preventing move:

The typical problem being that returning the unique_ptr transfers ownership.

I am confused then. I thought he had trouble doing this. I didnt understand that he didnt want it to move.

@Exotic_Devel said in Setters with and without this pointer.:

@J-Hilk said in Setters with and without this pointer.:

But why would you insist on always writing this-> this isn't Python !

Habit I acquired when I started using Java. :)

Ah, my condolences!
😉

The only way I see to write this "genericly" would be to have some virtual QVariant getValue() const and virtual QVariant setValue(QVariant v) in your base class and implement it in Derived.
This way you wouldn't have to do any casting, simply b2->setValue(b1->getValue()).
The implementation in Derived would do the cast to T via QVariant's value().

@Exotic_Devel In the link I posted is a full list of implicitly shared classes: list of classes. What I said applies to all of them and yes, QMap is one of them.