Qt Creator 4.6 Beta Released(blog.qt.io)
blog.qt.io
Qt Creator 4.6 Beta Released
http://blog.qt.io/blog/2018/02/07/qt-creator-4-6-beta-released/
90 comments
I've always loved Qt Creator, I sometimes wish it would have first class citizen support for Python w/ Qt and other languages who bind Qt as well. Another language I would of loved to see even if it doesn't directly target Qt is D. Great IDE though, for the little C++ I've done, I've done it with Qt using Qt Creator. Otherwise I use PySide which I wish had firsthand support from them. Maybe Qt 5 could be a powerful Qt IDE that includes other languages that integrate well enough with Qt itself.
While I love Python, I think all UIs I've ever seen that are based on it feel pretty clumsy. The QML+JavaScript path Qt is taking makes more sense to me - still snappy, but it unifies the web, app, and desktop worlds.
There isn't really any UI code that follows the zen of python very well. Most of the python zealots I know are kind of ambivalent about UI's in general.
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).
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).
That last one is practically impossible for any but the most simple of applications. It is much easier to reuse a (graphical) UI between desktop and mobile than it is to reuse a GUI with a TUI. TUIs have core differences, from using character cells for positioning and only allowing characters for presenting the UI (i ignore stuff like sixel and regis since those aren't supported by most terminals), to only having a very small selection for colors (again ignoring things like terminals with 256 color support) and a very limited input (often special keys do not work, mouse may or may not work, etc). These things affect greatly the type of UIs you see in terminals - which is also why even today you rarely see terminal applications use the richer UIs that you could find in text based DOS applications in late 80s and early 90s.
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.
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.
Blenders UI is the example at least one python zealot gives.
A tui can use the same keyboard shortcuts, a lot of the same structure, but tender differently.
A tui can use the same keyboard shortcuts, a lot of the same structure, but tender differently.
> * Ncurses UI using same code base
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.
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.
Boa Constructor used to do a lot of that, back in the day, and was a pretty good way of making UI apps. I don't think it's still maintained now, unfortunately.
The wish-lists in this thread are numerous, and gripes against C++ are many. However, C++ & the multi-platform approach is very clearly working for Qt.
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).
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).
QtCreator is brilliant, I just wish the Qt company would stop trying to hide it away! It's getting harder and harder to find the download link on their website.
[deleted]
I hadn't even heard of it (well ok, wasn't doing C++, but still) but I'm generally amazed since I started using it.
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.
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.
Interesting. When I investigated it a few months ago I was frustrated that I could only find docs for QtCreator, and nothing about just dropping in headers and writing code.
Best C++ IDE ever. Clang code model does provide (about) the same level of tooling in C++ with Java.
People keep saying this about Qt Creator. I've used it as my main working IDE for about 3 years now and I strongly disagree. I find it's not even a very good piece of software, let alone the best IDE.
- 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.
- 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.
I would also add the following pet peeves:
- 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
- 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
To balance my above comment a little: QtCreator is great for free, and it’s existence is a huge boon to the community.
Have you tried https://www.jetbrains.com/clion/ ?
On the project I work on, QtCreator's indexing takes 15 seconds and I have access immediately to all my types, even stuff using fairly modern C++17 with the latest beta, while CLion takes a good 20 minutes to parse it, and most of my code is a red underlined mess.
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...
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...
Is that because your code must be precompiled with moc before it's legal C++? It seems a little unfair to say QtCreator is faster and more accurate if you're working with Qt code. Qt chose to extend the language and make many of their vocabulary types opaque pimpl'd bags of void*, which makes it very hard for any other IDE to support Qt to the same extent.
FWIW CLion also has built-in static analysis.
FWIW CLion also has built-in static analysis.
> Is that because your code must be precompiled with moc before it's legal C++?
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
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
OK, 'legal c++' was a stretch - I take that back. I absolutely stand by the point that it's not reasonable to expect non-Qt tools to work as well as QtCreator on Qt-heavy projects.
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.
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.
you seem to think that QtCreator has special cases for Qt code. AFAIK the only specificity is that some icons change on signals during autocompletion, but it works just fine for non-qt projects - it's used quite a bit for development on embedded platforms. the c++ code model is simply its of clang.
[deleted]
Clion will choke on anything that touches boost.
Anything is overstating it. I use boost pervasively, and Clion has no issue with most of how I use it. But it certainly does choke on some of it, especially the function and variant stuff. What are you seeing it choke on?
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.
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.
I still think C++ Builder and VC++ are quite up to it, specially in the debugging area, edit-and-continue, incremental building and linking.
Visual Studio Code + cquery is also very good!
https://github.com/cquery-project/cquery
https://github.com/cquery-project/cquery
I have to admit. I love QtCreator combination with Clang. Nothing even comes close. Visual Studio (despite the factor it is only available for Windows) has serious flow. It parses a big project with small change. That results of huge time waste.
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.
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.
Qt Creator is my daily driver, and the steady stream of improvements is like having Christmas several times a year. I particularly like how seamless the integration with CMake is.
Somewhat off topic, but I'm increasingly finding that Qt is the last remaining reason to use C++. Qt is amazing, but C++ isn't a very productive language to code in, even if you're good at it. OS-less microcontroller stuff is probably better done with plain C, and everything else (games, system programming, embedded programming with an OS, etc) has mature and better options available such as Rust, Go, Nim, and (particularly for gamedev) C#.
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?
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?
"everything else (games, system programming, embedded programming with an OS, etc) has mature and better options available such as Rust, Go, Nim, and (particularly for gamedev) C#."
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.
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.
Mentioning C# for gamedev and the topic being about GUIs, makes me wonder if he was talking about tools? C# with WinForms are very popular for creating tools in game studios (if you notice tool screenshots from presentations like GDC, you'll often see the telltale marks of WinForms - like the gradient menubar, the default icon, the extra padding around some elements, etc).
Nah, I was just wrong about gamedev. I genuinely believed that all modern engines were mostly programmed in C# but people in this thread corrected me. It's just the game logic scripting.
> Nah, I was just wrong about gamedev.
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.
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.
Are we collectively forgetting Unity3D?
It might only be one engine but it’s a juggernaut in the industry
It might only be one engine but it’s a juggernaut in the industry
C# is actually "Unity script" and compiles to C++. It even bundles its own C++ garbage collector.
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).
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).
Pardon my French but you’re talking out of your ass.
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.
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.
Lol I just opened unity, and can't use null coalescing. I say unity script because it all compiles down to the same IL. Where did I say you can't use async/await. It's not "real" C# in the sense that you don't get the .Net runtime.
Update your Unity3D version and learn how to set your .NET runtime.
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.
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.
Yes it's on the latest version and you can't set the runtime when targeting certain platforms.
Look, just because I abhor Unity doesn't mean you have to take it personally.
Look, just because I abhor Unity doesn't mean you have to take it personally.
I don’t care if you abhor Unity, I just particularly dislike FUD on HN. People tend to hold what people write in a slightly higher light and assume a professional is speaking... not a guy who thinks “you need the newest version” is a disqualification for a feature list.
Jeez well I've been an engine developer for 10+ years so if you want a professional that's me. Comparing the source code and functionality of Unity to, say, Unreal 4, there's just no comparison. (edit, and let's not count all the custom engines I've been exposed to or worked on)
I guess I’m glad you’ve taken 10+ years to come here and be wrong about something this simple.
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.
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.
They are in the process of adopting .NET 4.6.
IL2CPP is no different from CFront.
IL2CPP is no different from CFront.
...and is often used by translating IL code to C++, if I remember a recent cppcast episode correctly.
Yes, but that is an implementation detail.
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.
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.
> 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.
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.
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.
I'd say the term "weird filter bubble" fits your ideas of embedded -- attiny or running linux, with nothing in between -- far better than it fits the HN idea of embedded.
C++ isn't going anywhere for the foreseeable future.
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.
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.
> and everything else (games, system programming, embedded programming with an OS, etc) has mature and better options available such as Rust, Go, Nim, and (particularly for gamedev) C#.
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.
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.
When mentioning C# "for gamedev", OP was probably talking about games business logic. The Unity core engine may be C++ (and assembly and shaders), but many Unity users / developers seem to do well with C# game logic / scripting.
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?
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?
From my experience, not that frequent.
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?
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?
For normal game logic I doubt the average user will ever cross that barrier.
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
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
> 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
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!
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!
It is and it isn't; that is, from a language perspective, the big thing here is type-level integers, which we accepted an RFC for, but is going to take some time to land due to implementation work being tough. It'll get there though!
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!
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!
Nim is perfectly good for embedded. Also, GC is fine for the vast majority of systems programming. Finally, lots and lots of embedded programming doesn't need to be hard real-time. I'd wager that the majority of embedded projects are in C++ not because of any technical requirement but because the people in the field know only 1 language. (Note: I already addressed OS-less microcontroller programming in my top comment.)
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)
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)
> Also, GC is fine for the vast majority of systems programming. Finally, lots and lots of embedded programming doesn't need to be hard real-time.
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.
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.
Have you experience with the likes of PERC, JamaicaVM, WebSphere Real Time?
No, I haven't, and I am sure it is possible to do reliable real-time with those. It looks like all of those are commercial solutions (no open source).
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.
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.
Actually Nim is used for games and game engines.
The GC is optional. It's also configurable and there is a realtime garbage collector, too.
Finally there's also region based memory management.
https://nim-lang.org/docs/gc.html
https://forum.nim-lang.org/t/2489
The GC is optional. It's also configurable and there is a realtime garbage collector, too.
Finally there's also region based memory management.
https://nim-lang.org/docs/gc.html
https://forum.nim-lang.org/t/2489
>Actually Nim is used for games and game engines.
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.
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.
Yet.
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.
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.
> Yet.
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.
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.
You seem to be conflating technical merit with widespread usage. The wishful thinking was about some big success game using such a technology. The technical merits were already presented by GP. And they are real.
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.
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.
A reasonable question, but the reality is that C++ is the ONLY choice for certain fields (basically anything where you need a high-performance "engine" under the hood). Finance, gaming, databases, etc.
[deleted]
I'm a bit allergic to proclamations of C++ obsolescence but to be honest I'm finding myself using it less and less myself. Not sure I agree OS-less micros are best done with plain C, though. A lot of programmers are put off by the latest C++ developments but it's very possible to use C++ to great advantage even in tiny environments. You just have to really know what you're doing.
I see this sentiment all the time and the answer is "nooooo." It's honestly getting frustrating, and I tire of writing the same apologia.
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.
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.
Incidentally, apparently getting Rust running on consoles is fairly easy, see https://www.reddit.com/r/rust/comments/78bowa/hey_this_is_ky...
This is of course, far from the ease of official vendor support.
This is of course, far from the ease of official vendor support.
Just like C++ used to be compiled to C.
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.
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.
The usage of a GC changes the nature of the solution entirely. Say you wanted to write a bullet hell game. Spawning bullets/spells in the thousands takes pretty careful management and without memory management, understanding where you've leaked or why memory isn't being reclaimed when you expect can be nightmarish.
Same applies to malloc()/new, no one on their right mind would be allocating during the hot path of rendering loop.
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.
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.
>everything else (games, system programming, embedded programming with an OS, etc) has mature and better options available such as Rust, Go, Nim, and (particularly for gamedev) C#.
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.
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.
Paying customers for Qt are still very C++/C oriented. Qt goes where the money is, and it seems to be in contracts with large manufacturers and focus in embedded systems, especially the automotive industry, automation and digital television. The QNX and INTEGRITY support is big deal in many industries.
Isn’t it a truism though that the existing customers for a C++ tool will be very C++ oriented? Surely the real question is where is the potential growth, and future customers.
I'm sorry but I disagree. Mature Rust is not the same as mature C++. If you are a commercial entity you would, in my opinion, be fool-hearty to select a language like Rust, mature in the sense you mean or not, as the main language of use. Or at all quite frankly, for the single reason that it is more difficult to employ quality people as the talent pool to draw from is far too small. And it is also the reason I never invested myself to learn it, for its technical merits or not.
Over a hundred companies, including some big ones, disagree with your opinion here: https://www.rust-lang.org/en-US/friends.html
"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.
"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.
Just to clarify, I agree, it's not nothing. But still.
Rust and C++, esp how Qt uses it do not mix very well in my opinion. For that reason I created tool to create bindings rom a JSON model to both Qt and Rust. You write the application logic in Rust and the UI in Qt.
A talk at FOSDEM 2018 about that is here https://fosdem.org/2018/schedule/event/rust_qt_binding_gener...
A talk at FOSDEM 2018 about that is here https://fosdem.org/2018/schedule/event/rust_qt_binding_gener...
Rust isn't that mature for games, ditto with Nim, Go is ok but has a GC, C# is too slow but OK for scripting, but then again lots of languages can be used for scripting. C++ isn't going anywhere in the game development world for now. Maybe something like Rust will upend it someday, but not yet.
I agree, but it is also a matter of hardware resources.
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.
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.
It'd be interesting if Qt had something like Vala for GTK
Look into QML : http://qmlbook.github.io/en/ch04/index.html
PyQt seems to work quite well, for example fman is written in it: https://fman.io/
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.
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.
Show HN: Cross-platform desktop applications with PyQT | https://news.ycombinator.com/item?id=16318677 (yesterday)
You can get more info directly from the source:
http://blog.qt.io/blog/2018/02/07/qt-creator-4-6-beta-releas...