Qt Creator 4.6 Beta Released
blog.qt.io
blog.qt.io
What we would like
* Programmable, discoverable, UIs. I should be able to click a UI element and know what function it calls, or what method it uses.
* Keybindings support, and programmable/configurable keybindings
* A repl, with support for aforementioned
* Ncurses UI using same code base
Right now, we're a long way off from doing python UI's in a way that doesn't feel hacky to the python zealots (like me).
But as far for the rest, FWIW, everything you describe seems to be a thing in Blender's UI (including the ability to right click on every actionable element and see what Python function it calls), which probably is kinda expected considering that it was built around Python. Sadly the Blender UI is not something you can use outside of Blender since it is tightly coupled with the rest of the application. There are some attempts to recreate it as a reusable library (e.g. Blendish), but they only go as far as to recreate the look.
A tui can use the same keyboard shortcuts, a lot of the same structure, but tender differently.
For me this is a huge deal and I wish we saw more of it. There's openSUSE tooling that does this, it looks and behaves similarly on the terminal as it does on the GUI, I was mind blown by this and fully appreciate that level of detail.
This is classic noise drowning out the signal - if existing or future paying customers of Qt want something different, they'll let Qt know - after all paying customers pay for support that buys them a direct line with the builder(s).
I don't miss IntelliJ really, and I've had it as my go-to IDE for like 7 years. Even the VIM mode works good enough.
QtCreator also feels much snappier when typing in general.
The one good thing of CLion in my eyes is its detection of unused includes. But QtC is overall superior for C++ dev experience, especially when you factor in all the static analysis (clang-analyzer is integrated), profiling support (how nice is it to see small percentages next to your lines of code ! ), pretty debugging, etc.
Both support CMake but QtCreator supports CMake's server mode API which is the recommended way onwards: https://cmake.org/cmake/help/v3.10/manual/cmake-server.7.htm...
FWIW CLion also has built-in static analysis.
That's... not how moc works at all. Moc parse your header files and generates additional cpp files from it which contain boilerplate for reflection and signals. So no static analyzer has any problem parsing Qt code... (I use cppcheck, coverity, clang-analyzer, clang-tidy)
The "special" Qt keywords like signal, slot, etc... are just trivial macros:
https://github.com/qt/qtbase/blob/5.10/src/corelib/kernel/qo...
"signals" is just defined as "public", "slots" and "emit" as nothing. Your compiler compiles your source as-is.
If you really don't like moc, there's a way to get its features natively with C++14 compilers (and uglier macros) : https://github.com/woboq/verdigris
You don't explicitly say so, but your answer suggests that your project uses Qt heavily. QtCreator is great for Qt projects - fine. That doesn't say much about it in general though. Other IDEs handling a Qt-heavy project less well than QtCreator says nothing about them other than that they can afford to ignore Qt.
Thanks for the link to verdigris. It's certainly less offensive than Moc, but if you're forced to use Qt you may as well use Moc.
I haven't played with QtCreator lately. Clion has, over the past couple years, become my favorite C++ IDE on Linux because it can consume my hand-written cross-platform CMakeLists.txt and give me a nice experience, and because the debugger is really good IMO.
But VSCode and CQuery is the (only?) serious competitor. Particularly if you like more lightweight, terminal stuff. Last time I checked CQuery it was not robust. But I am so glad seeing it is becoming more mature.
- Find References on a function doesn't differentiate between overloads
- no way to sort or filter warnings by type
- Find results window doesn't horizontally scroll or wrap, it just truncates (on mac)
- mouse hover over a column separator preparing to drag, and the separator pops away as a titlebar takes it's place - this is UX 101 - you don't move the thing you know the user is trying to click!
- can't restrict Find to a sub-project, top level project or nothing.
- Qt Creator doesn't do a good job detecting when a build scripts should be refreshed even when a project is built, which causes compilation/linking problems.
- Qt creator doesn't support setting a centralized widget stylesheet to define and update the stylesheet properties of any widget.
- it only supports profiling in linux (valgrind)
- its refactoring features are relaticely limited
- support for static analysis via clang feels like a rush job
But none of those languages have Qt. Of course, there's stuff like PyQt which is nice, but it's not got the status that C++ has in Qt land. Really what I'd love is if Qt would add first-class support for one of those newer languages. Rust maybe? I reckon it's a enormous, maybe simply unfeasible undertaking, but first-class Rust support, so I can fire up Qt Creator and start coding Qt apps in Rust would be fantastic. It would suddenly increase the usefulness of Rust by enormous amounts and it would keep Qt relevant.
Does anyone know if the Qt people are evaluating other languages? Are they worried, commercially, about C++'s demise?
Regarding gamedev: Unity itself is still written in C++ and Unreal Engine uses it even more. AAA games are written mostly in C++ with Lua/C#/Python for scripting.
There are still a lot of other reasons to use C++, too.
None of the options you mention, other than possibly Rust,is actually appropriate for game engines, systems programming, or embedded, due to the garbage collector. There are still plenty of good reasons to use C++, not just Qt.
EDIT question to Unity devs more experienced than I am: how frequent is it to "escape hatch" from C# to C++ game logic, in your experience? In what kind of game?
Had the occasion to watch a conference from a Dev in my company that would get rid of a lot of the overhead added by the Mono Behaviour in Unity. Getting better performances at the cost of less usability. In that case, one wonder why event bother using Unity?
C# in Unity can be blistering fast despite the GC if written correctly, and going to C++ still requires about as much (if not more) effort and knowledge as writing C# in a GC friendly way
I agree that I was wrong about gamedev, in the sense that popular game engines are also, currently, written in C++ (so play a role in keeping C++ alive by legacy, just like Qt does)
Even soft real-time can be difficult with a GC in my experience. You end up doing all kinds of hacks to workaround the GC.
I remember reading a paper about the IBM implementation (I assume that it turned into WebSphere). If I remember correctly, you still need to do some memory management like allocations up front compared to a "normal" Java program. Those guidelines seem a lot like what game programmers in Java end up doing.
I remember in college for a project that a team did a ping-pong playing robot in Java. It worked fine for maybe ~15 seconds then suddenly froze for a GC pause.
The GC is optional. It's also configurable and there is a realtime garbage collector, too.
Finally there's also region based memory management.
Some people might have some GitHub repos with games and game engines written in Nim.
Some people might have even shipped some second tier game written in Nim.
Then again, hobbyists will use anything.
But virtually nobody had used or uses Nim to create any kind of game or game engine that is behind any successful game in the real world.
I need to remind people that Minecraft, a hugely popular game in the "real world", was originally written in Java. Not the kind of language you'd expect a game from. (I will agree that Java is probably not the right tool for the job though ^^').
This is the kind of thing where nobody will use it, until someone does. And proves the viability of the language. Nim has the potential to be a good gamedev language, but lacks the maturity.
Wishful thinking doesn't have a place in discussions on the technical merits of a technology.
It's like everyone is stating that the bugati veyron is the best car ever made and your only cobtribution to the discussion is making claims on how your flying car is way better.
Besides, flying cars are way better. We need to keep looking into the future, otherwise we'll be stuck with what shitty technology we currently have.
Rust doesn't have any sort of equivalent to ffast-math yet. :( I think their version (with 'fast' floating point types) would be nicer than the program-wide flags you get in C++ through the usual C++ compilers.
In general numerical-heavy code doesn't seem to be high on Rust's priority list (the math libraries are still fairly anemic). This is a shame, I would love to use Rust in anger!
As for a library ffast-math, it's mostly that we rarely hear people asking for it. I think that many people who want to do numerics stuff are waiting on the above; once it lands, I think more people will start writing libraries. Time will tell!
We're supposed to interpret other comments in the most charitable way, but a charitable interpetation is not at all possible when one says that C# is a usable solution for systems and embedded programming, that Nim is mature, or go is used in games and is a good idea to use for embedded.
Even combining all of the above languages would not reach the breadth and maturity of C++ in the target domains.
It might only be one engine but it’s a juggernaut in the industry
Unity devs could have gone full way and implemented a compiler backend themselves.
Instead they decided to take advantage of the SDK present in every target platform they support.
C++ once upon a time, also got compiled by generating C code.
It's terrible. Not being able to write native code is a tremendous weakness of the engine. Not to mention that since you're writing a "fake" C#, you don't get the full runtime (can't use reflection, can't use coalescing null features, etc).
IL2CPP is no different from CFront.
Unityscript is the Js clone they have/had (they’ve been pushing for C# to be the main language).
You can use null coalescing.
You can use all of Reflection bar platform restrictions on AOT ie. iOS (don’t recommend it in a game though...)
You can use a async/await.
You’re writing “real” C# with Unity, either with a custom Mono runtime or IL2CPP, neither of which turns your C# into “fake” C#
And Unity3D is “terrible” enough to serve 700 million players.
Then learn the settings and limitations for your target platform.
Just because you don’t know how to use Unity doesn’t make it doesn’t have features it does.
Look, just because I abhor Unity doesn't mean you have to take it personally.
Now you’re waving your hands and saying “So what I was wrong, Unreal has code, it has the best code”?
I think we’re done here.
Sorry, you were pretty much wrong in every claim. None of the options you've mentioned are actually stable with the exception of C#, which you already acknowledged that were wrong to mention.
Then don't misquote me. I didn't say any of that, except perhaps implying that Nim is mature. Ok right, and Go is great for embedded. I worked in embedded systems for years. 80% of the software ran on little arm boards that ran a decent OS (eg QNX, Linux, etc). Go would've saved so much trouble there. There's this weird HN filter bubble attitude that if it's more than 20MHz or does not ship with a 15 year old GCC fork, then it's not embedded, but that's bullshit. Go is a fantastic option for a very large amount of embedded software, and I'd wager what's left after that is perfectly served by tiny C programs running on little atmels.
I explicitly singled out C# for gamedev. Look, I'm trying to make a general argument that a few large still-good legacy libraries (such as Qt) are the only reason C++ is still standing. I must admit it feels a little like you're trying to misunderstand me on purpose because you don't like the message.
Yes, Qt is the only pure C++ cross platform GUI with high quality tooling.
However on Windows there is still UWP, mostly written in C++.
What is happening is a shift of focus, instead of doing a full app 100% in C++.
C++ gets used where it is best, low level high performance library code, with higher level code being written in a safer language.
So while the app developer might stick with Swift, Java, Kotlin, Web browser, .NET, there is still a C++ layer underneath.
For example, Metal shaders are written in C++14.
Also IoT has given a big push to C++, Arduinos, ESP286, ESP32 kind of devices are mostly developed in C++.
So yeah, there are still a couple of decades of C++ on native GUIs, if nothing else, pushing pixels around.
Sure. But what about, e.g., gtk?
Also they are mostly focused on being a good UNIX toolkit.
Back in the 80 and early 90's, languages like C, Turbo Pascal, Basic,.... where the scripting languages, with the core implemented in Assembly.
Then the ladder moved up and they started to be used to implement the engines.
Same happened with C vs C++.
Now we are on the C++ vs GC languages phase.
C++ won't be gone from the pixel pusher and real time audio layers for a long time, but the other layers willl eventually use something else.
A talk at FOSDEM 2018 about that is here https://fosdem.org/2018/schedule/event/rust_qt_binding_gener...
That's not how the industry sees it. Almost nobody does those things in Rust, Go, Nim and C# (except if you mean second tier not AAA games done in Unity and co).
And by nobody I mean less than 1% of those that deliver those kinds of solutions use those languages.
No C++ isn't unproductive. Go and C# is NOT FAST OR SUITABLE FOR GAME DEV (AAA in particular but even lighter games. You'll pry manual memory management from me from my cold dead hands). Maybe you mention C# because it "powers" Unity? Guess what, it compiles to C++ through the IL backend. Other languages haven't figured out cross-platform. And I don't mean Mac and PC. I mean Mac, PC, iPhone, Android, Linux, Playstation, Xbox, etc. People keep writing about C++'s demise, but I don't see them writing LCP constraint solvers in other languages successfully. I will submit that of the things you mentioned, Rust and Nim are closer to the target since, at least, they don't run on this slow as molasses runtime (slow in game terms), but they are extreeeeeeemely immature, and you're talking on porting very complex problems. No thanks, I'll take the thing that has an actual standards committee where I can determine exactly how to control or tweak things at whim.
Basically, this type of comment is always a cheap shot to get upvotes but simultaneously always misinformed and from someone without actual game development experience.
There are many valid uses for C++, however using IL2CPP as an example, well that is just an implementation detail of their C# compiler.
If Unity would be willing to spend the money, they could have implemented a compiler backed instead.
With GC languages, one just needs to learn about value and reference types, and which language features might implicitly allocate. Which can be helped via static analysis.
Regarding .NET specifically, there are quite a few ways of doing manual memory management, although not as fine grained as C++, which many devs seem to be completely unaware of.
In both scenarios, using a profiler is a must have for anyone caring about performance.
And lets be real, unless one is competing with AAA level games, there is a big spectrum of game styles that don't need the ultimate hardware performance, just good enough for an enjoyable game experience.
This is of course, far from the ease of official vendor support.
"A hundred companies" is both good and bad, of course: that's a drop in the bucket compared to C++. It's also not nothing.