ITT: bloated reinvent the wheel garbage

ITT: bloated reinvent the wheel garbage

Attached: 1200px-Qt_logo_2016.svg[1].png (1200x880, 33K)

Other urls found in this thread:

github.com/qt/qtbase/blob/5.12/src/corelib/kernel/qobject_p.h
twitter.com/SFWRedditGifs

yeah but it's 90s bloat like winamp which means like 20 mb

so, which is the original wheel?

It was a good idea in theory, but "cross platform" is a lie. Making something that feels native on all platforms and doesn't bug out in the edge cases is a nearly impossible task.

based.
Long live GTK and fuck stallman

Qt's slot system came in real handy before C++11 slurped in all the core libboost functions.

How exactly does it help, though? How are signals and slots different than just having a vector or something? I never really understood that.

because every c++ systems designer must reimplement the same 5 or so features that every single other systems dev also did.

I don't really see how that justifies making this a new, non-standard language feature when it can easily be implemented into the language itself.
Unless It's for QTs shitty interface builder so it can easily find out which slots a class has. But that could also be easily solved by just having them be a certain type.

They aren't, the design predates function objects in C++.

How so? Wasn't it always possible to just override the () operator? And even if not, you could just use any other function name. It's not like the user ever directly calls this code.

>yeah but it's 90s bloat like winamp which means like 20 mb
Im-fucking-plying. Qt5 is like 4 gigabytes.

Yes, but that would have been cumbersome to have to make a new class for that each time. The point of signals and slots is to bind arbitrary QObject methods to each other.

It works fine.
That is normal size for toolkit dev

Attached: as per description in OP.jpg (700x454, 21K)

imagine using a fucking FOOT

But then it could have been solved via a vector of member function pointers, even though the syntax would have been dreadful, right?

Sort of, in Qt it's actually a linked list, see this file: github.com/qt/qtbase/blob/5.12/src/corelib/kernel/qobject_p.h
It also supports binding signals/slots by string id. These string to method mappings are generated moc at compile time and are still not possible in base C++ without adding ugly macros to your class.

>matching methods aka things called often and frequently to a string
>in a linked list
muh tism hurts

No, that's not how it works. The matching is done before insertion. It's a linked list because connecting and disconnecting signals should not be worse than O(1).

It's rare that you even bind two methods to a single slot. In the average case, this is really fast and memory efficient.

It's pretty cool how Qt has able to fix so many of early C++'s shortcomings via macros and moc. It's almost a bit like Objective-C++ with its messages.
But also a shame how C++ is now able to do most of these things by itself and you now have even more ways to do the same thing, most of which are incompatible with C++ standard way to do things.
When actual metaclasses get implemented, QObject will be even stranger.

They would just deprecate moc.

When? Why? That would break all legacy Qt code and make it necessary to rewrite almost everything. I highly doubt they'll ever do that.

They don't care about breaking legacy code between major versions

like for example?

Cleaner and easier to use. Plus, it's fully supported and used thorough the framework.

ScrollAreas behave differently between OSX and Windows. That's one I've encountered in the past day. So I have to have to write platform specific code anyways.

It's not the same for QueuedConnection, which adds the signal to the event loop, allowing you to connect safely across threads

I kekked

Yeah, if you install the IDE, docs, examples and all dev files with support for everything under the sun.