I never understand these drive-by comments. It's not like developing on/for the competition is any easier or less convoluted. The author is debugging a cross-language (both managed and native), cross-architecture video game with a variety of third-party libraries.
Turns out that the Windows graphics stack is complicated (mainly because it needs to support a variety of closed-source programs that never saw maintenance after initial release), so compatibility layers meant to optimise for certain programs (an easy optimisation, frankly) accidentally caught the author's program in the master list, too.
There are people who actually try to implement better APIs. (We can quibble over effectiveness all day long. Sadly, it looks like a losing battle.) This is the only way to find them.
> Why is something which shall makes things easy and secure so complicated?
> I'm used to:
>
> g++ -o hello hello.cpp
That is simple, because C++ inherited C's simplistic, primitive, and unsafe compilation and abstraction model of brute-force textual inclusion. When you scale this to a large project with hundreds of thousands of translation units, every command-line invocation becomes a huge list of flag soup that plain Makefiles become intractable.
Almost all other reasonably-recent programming languages have all of the following:
- a strong coupling of dependency management, building, installation, and publishing tools
- some description of a directed acyclic graph of dependencies, whether it be requirements.txt, cargo.toml, Maven, dotnet and Nuget .csproj files, Go modules, OPAM, PowerShell gallery, and more
- some way to describe the dependencies within the source code itself
C++20 modules are a very good thing, and enforce a stronger coupling between compiler and build tool; it's no longer just some weekend project chucking flags at g++/clang++/cl.exe but analysing source code, realising it needs a, b, c, x, y, z modules, ensuring those modules are built and export the necessary symbols, and then compiling the source at hand correctly. That is what `clang-scan-deps` does: https://clang.llvm.org/docs/StandardCPlusPlusModules.html#di...
I concede there are two problems with C++20 modules: we didn't have a working and correct compiler implementation before the paper was accepted into C++20, and secondly, the built/binary module interface specification is not fixed, so BMIs aren't (yet) portable across compilers.
The Meson developer is notorious for stirring the pot with respect to both the build system competition, and C++20 modules. The Reddit thread on his latest blog post provides a searing criticism for why he is badly mistaken: https://www.reddit.com/r/cpp/comments/1n53mpl/we_need_to_ser...
Universal source package management would have been better time spent.
This doesn’t solve any problem that wasn’t self-inflicted.
I agree on your points about having a working implementation before the paper was accepted, this is why C++ is a mess and will never be cleaned up. I love C++ but man, things like this are plenty.
One thing I'd say is to apply some anti-aliasing (MSAA, SMAA?)—even on a 4K display with a pixel density of 64.3 px/cm, the jaggies are visible, especially because of the extreme contrast of the caustics behind the dark background.
I'm not especially familiar with this, but I believe making the SVG element larger can increase its filter effects' resolution, and then using CSS transforms to scale the element's parent will return it to its original size, but with a higher resolution result. From there, additional changes to the filter effect (to incorporate a subtle blur for instance) may help it over the finish line.
Regardless, this is a great writeup for changes I wish to never see in ordinary UI.
This clause is abstracting away a ton of work. If you want to compile the latest LLVM and get 'portable C++26', you need to bootstrap everything, including CMake from that old-hat libc on some ancient distro like CentOS 6 or Ubuntu 12.04.
I've said it before, I'll say it again: the Linux kernel may maintain ABI compatibility, but the fact that GNU libc breaks it anyway makes it a moot point. It is a pain to target older Linux with a newer distro, which is by far the most common development use case.
Definitely, and I know this sounds like ignoring the problem, but in my experience the best solution is to just not use the bleeding edge.
Write your code such that you can load it onto (for example) the oldest supported Ubuntu and compile cleanly and you’ll have virtually zero problems. Again, I know that if your goal is to truly ship something written in e.g. C++26 portably then it’s a huge pain. But as someone who writes plain C and very much enjoys it, I think it’s better to skip this class of problem.
> I think it’s better to skip this class of problem.
I'll keep my templates, smart pointers, concepts, RAII, and now reflection, thanks. C and its macros are good for compile times but nothing much else. Programming in C feels like banging rocks together.
Agree to disagree, then! Templates, smart pointers, and RAII have cost me far, far more than they’ve paid me back. You should write whatever feels good to you.
C feels a little like survival mode in Minecraft; you have a set of very simple abstractions, a relatively simple language, with which one can build the world (and in many cases, we have).
C++ feels like a complex city builder, with lots of tools, designs, and paradigms available, but also allows one to screw up in bigger ways.
Turns out that the Windows graphics stack is complicated (mainly because it needs to support a variety of closed-source programs that never saw maintenance after initial release), so compatibility layers meant to optimise for certain programs (an easy optimisation, frankly) accidentally caught the author's program in the master list, too.
reply