LsCs is a cross platform C++ GUI library focused on Medical Devices
lscs-software.com
lscs-software.com
I'm curious for your expertise on that: my guess is some people can get away with that, but if you're operating ex. a medical laser, you gotta take it more seriously and actually guarantee ex. "This code will be delayed at most 8 ms, it's thread is guaranteed to get CPU time by then"
I certainly would never describe a product as real time if there was not a true realtime component to it, but I think people think it sounds cool and slap it on anything that's high performance. Happy to answer any specific questions on my email, see the profile.
The deprecation would get you a warning for this nonsense in new C++ versions. It would still compile as before, but you'd get a warning so that maybe you can write something which isn't nonsense instead - an opportunity to express what you actually meant. But this was unacceptable of course.
You can see some of the same wailing for uninitialized access. Currently draft C++ 26 will just silently initialize your variable to some agreed bit pattern so that you don't incur Undefined Behaviour for uninitialized access by default. This seems to make many of the same people very angry.
Modern C++ standards are the bare minimum you should enforce in terms of software safety and correctness.
Every three years there will be another iteration of "Modern C++" (it seems like some want to now call C++ 20 and C++ 23 "Contemporary C++" instead of "Modern C++" but it's the same again) and you're back to do more rewrites.
You can do it incrementally with C++, not to mention not needing to hire a team of rust developers. I don’t think you want to let a team of C++ devs that are just learning Rust do a full rewrite as their first big project experience.
Also, when switching from, say, C++20 to C++23, thinking it’s the same amount of work as a full rewrite in Rust is laughable.
Certainly not! The update can be done incrementally as pre-modern C++ is (almost) fully compatible with modern C++.
Not only will a Rust rewrite take 5-20x longer, you'll also be supporting 2 versions (C++ and Rust) for a long time, while doing the rewrite and migration, and that will eat up a lot of dev hours.
I've done incremental C++ migrations and they are not nearly as complex or stressful, especially when you leverage libtooling or Python bindings to write AST-rewriting scripts for those large refactorings.
If "Modern C++" really was a static target you could imagine performing the transition to "Modern C++" and you're done. If that existed it would compare to the Rust rewrite, maybe it would be 5-20x faster. But "Modern C++" isn't a static target, if we understand "Modern C++" this way (say, as C++ 17) obviously it's unsuitable for such safety of life software.
Instead the "Modern C++" transition is like a worse version of one of Zero's paradoxes. We never arrive at our intended destination and are always instead asked to perform another transition, the work never ends.
> Long ago there was an OpenSource library called Qt. When it was C++ and Widgets, it was great. Then the library lost its way and became focused on phones. It also became dramatically less "open" and much more "you have to buy a license." The C++ Widgets side of the library withered as resources were poured into a non-typesafe worthless thing called QML. This was well after making a play for the medical device market. You can't use non-typesafe junk when lives are on the line.
Their writing style is a serious turn-off.
The latest crazy Windows IP stack RCE pushed me wholly over into the "nothing new should be written in C/C++" camp. It's clear that secure reliable software can't be done in these languages, at least at scale.
The macho counter-argument of "but I can do it!" doesn't work. Maybe you can. It doesn't matter. Code will be worked on by more people than just you if it lives for a long time. Code "rots" and acquires bugs, and having the compiler catch the worst ones (memory errors, type errors) is a huge win.
There are formal languages that do more than Rust, but they're a lot less practical. Working on making a more practical one would be a useful exercise.
You can forbid unsafe at the Cargo.toml level in Rust. You can also just search a project for the keyword "unsafe" to subject all unsafe code to extra levels of scrutiny. Some orgs set commit rules where commits containing "unsafe" must be approved by more people or must pass through a security audit team.
No language that I'm aware of protects against bit flips or claims to have memory safety in its memory unsafe escape hatches (kind of the point).
[0] https://www.theregister.com/2015/05/26/unisys_finally_weans_...
The next parapgraph sounded like they're concerned about bugs from not having the same integer representation as those systems:
> Passing 2's complement data to backend systems or front end sensors expecting 1's complement causes catastrophes.
I don't really understand their concern though--surely all actual C++ implementations that build QT apps and the platforms that run them are using twos complement anyway? Like, the C++ standard change is not making anyone change their integer representation, it's just telling the not-twos-complement people that they're on their own, right?
Of course I'm not surprised not to be following the logic since I have to count myself among "those who never went to college for Computer Science".
There is of course a much larger back story but I think this speaks volumes about the situation.
Barbara Geller CopperSpice Co-Founder
Our understanding is that Qt wants to remain a framework. No clue what Roland might be considering, but he did give us an "ear full" of bike shedding.
Barbara Geller CopperSpice Co-Founder
I developed a successful medical device on Qt 4.8 and can attest that it was a joy to work with.
Not sure about how the FDA would feel about an old framework. I don't think they would care too much or it would become anymore easy to provide software verification.
A decision was made to move to C++20 and we are keeping an eye on when to make the next jump. We welcome contributors and friendly conversations.
Barbara Geller CopperSpice Co-Founder