C and C++ are very cross-platform, if you only use cross-platform dependencies and if you are careful to write portable code. Most C and C++ applications don't do that.
* Don't include windows.h
* Use a gui toolkit like gtk and qt (which you probably want to do anyway)
Generally, making a software windows-only is a deliberate choice, not something that happens 'by accident'.
But if you use something like Qt you've got all of this cross-platform out of the box - I have a multiple hundred lines of code C++ software which does all this and much more ; it has almost zero platform-specific stuff except one function at some point to set real-time priorty to threads.
I feel like this whole line of argument is disingenuous. In Rust, you don't need to bundle a GUI toolkit to get cross platform stuff that works. The standard library was built with Windows in mind, and it shows. You don't need any additional POSIX layer. You just use the standard library.
If you go and look at competitors to things like xsv and ripgrep that are written in C or C++, they either require some kind of POSIX thing on Windows to run correctly (like cygwin), or they jump through lots of hoops to behave as a native Windows application.
It really should not be a controversial statement to say that Rust has a better cross platform story (Windows/mac/Linux). It was a design goal.
Qt is not a GUI toolkit, it's a general framework. If you only link to -lQtCore you won't have anything remotely related to GUI in your binary. For instance doxygen is built like this.
common enough for me
For those like me who’ve never used QT: As long as you don’t statically link the QT libraries you don’t have to open source your entire commercial application. I’m not a lawyer.
General notes about licensing https://www1.qt.io/licensing/
Comparison of licenses https://www1.qt.io/licensing-comparison/
I provided a link from the FSF that shows that this is not the case just below - you can statically link proprietary apps with LGPL qt.
So for LGPL. As a commercial application developer I’m not sure I’d want to do that. I’d then have to field support requests for that object file.
Still, good to know.
no, that's tiresomely false. You can link proprietary code statically with LGPL code. LGPL does not give a shit about static or dynamic libraries because LGPL is not a language-specific license.
Right from the source: https://www.gnu.org/licenses/gpl-faq.html#LGPLStaticVsDynami...
* Python can be reasonably fast with pypy.
* Go and rust maybe don't have segfaults, but they can still crash and burn, or have other kinds of bugs.