4 ms·
Looking at LLVM build times I seriously believe that C would have been the better choice :/ (it wouldn't be a problem if LLVM wouldn't be the base for so many o
by flohofwoe 8mo ago
Looking at LLVM build times I seriously believe that C would have been the better choice :/ (it wouldn't be a problem if LLVM wouldn't be the base for so many other projects)
Same for the Metal shading language. C++ adds exactly nothing useful to a shading language over a C dialect that's extended with vector and matrix math types (at least they didn't pick ObjC or Swift though).
- pjmlp 8mo agoCUDA, SYSCL, HLSL evolution roadmap, and Khronos future for Vulkan beg to differ with your opinion.
- flohofwoe 8mo ago> HLSL evolution roadmap ...that's just because of the traditional-game-dev Stockholm syndrome towards C++ (but not too much C++ please!). > Khronos future for Vulkan As far as I'm aware Khronos is not planning to move the Vulkan API to C++ - and the 'modern C++' sample code which adds a C++ RAII wrapper on top of the Vulkan C API does more harm than good (especially since lifetime management for Vulkan object is a bit more involved than just adding a class wrapper with a destructor).
- pjmlp 8mo agoSee the talks around Vulkan ecosystem, and GPU shading languages from February. There is more than one sample using C++, now they make use of C++20, including modules if desired.
- flohofwoe 8mo ago> now they make use of C++20, including modules if desired. It's in line with many other shitty design decisions coming out of Khronos, so I'm not even surprised ;) IMHO it's a pretty big problem when the spec is on an entirely different abstraction level than the sample code (those new samples also move significant code into 'helper classes', which means all the interesting stuff is hidden away).