C++ Should Be C++
open-std.org
C++ Should Be C++
1–10 of 191 posts
Re: C++ Should Be C++
#2Honestly, the changes in C++ 20 and 23, plus the upcoming changes for 26 (looking at you, Concurrency TS v2) have so drastically improved the language it's almost like the ES5 -> ES6 evolution of JavaScript.
I might be in the minority here, but I genuinely enjoy writing modern C++.
My complaints are about it's dependency management story and lack of integrated, standardized tools for things like dependencies, testing, logging, etc.
Re: C++ Should Be C++
#3this feels defeatist
c++ is with us for the near future, it needs an evolutionary path that provides a sane path forward
why not break with the past? anyone needing to compile c++11 can find the tools and still use them, they can live in the past as long as they like
just getting dependency/build management and integrated testing would be huge and really a small ask given what is happening in other tools
its crazy that you still can't make sane use of things like modules, even if you fully commit to "modern" c++
Re: C++ Should Be C++
#4Honestly, the changes in C++ 20 and 23, plus the upcoming changes for 26 (looking at you, Concurrency TS v2) have so drastically improved the language it's almost like the ES5 -> ES6 evolution of JavaScript. I might be in the minority here, but I genuinely enjoy writing modern C++. My complaints are about it's dependency management story and lack of integrated, standardized tools for things like dependencies, testing…
I don't know if you're in the minority or I am, but I find modern C++ to be borderline intolerable (and I've been programming mostly in C++ from before there were C++ compilers).
I used to love C++ (and still do if we're talking about older standards), but the new stuff is just a baroque torture.
Re: C++ Should Be C++
#5Honestly, the changes in C++ 20 and 23, plus the upcoming changes for 26 (looking at you, Concurrency TS v2) have so drastically improved the language it's almost like the ES5 -> ES6 evolution of JavaScript. I might be in the minority here, but I genuinely enjoy writing modern C++. My complaints are about it's dependency management story and lack of integrated, standardized tools for things like dependencies, testing…
Anything C++11 forward is alright with me, though 17 introduces some very nice conveniences like , and most critically . Honorable mention to std::clamp too.
Re: C++ Should Be C++
#6> What is much less prevalent is a demand from average C++ users for memory safety features; they’re much more concerned about compilation speed. When most C++ developers haven’t adopted tools like Coverity and C++ core guidelines checkers, it is hard to claim that memory safety features substantially improve their lives at least from their point of view.
I don’t really agree with this. There’s also a group of developers that want more safety, but don’t feel like setting up (or in the case of Coverity purchasing) additional tooling. Some people just want a decent out of the box experience.
Re: C++ Should Be C++
#7this feels defeatist c++ is with us for the near future, it needs an evolutionary path that provides a sane path forward why not break with the past? anyone needing to compile c++11 can find the tools and still use them, they can live in the past as long as they like just getting dependency/build management and integrated testing would be huge and really a small ask given what is happening in other tools its crazy th…
Lack of modules support is the biggest thing keeping me from doing more c++ greenfield. So much friction in managing a pointless interfaceimplementation layer.
Re: C++ Should Be C++
#8Nevermind the language itself, we need a way to pull compilers and project dependencies, pinned to their specific versions, with a single, ergonomic tool. vcpkg seemed really promising but the fact that they didn't start with library versioning from the get go was a very stupid decision, and nowadays versions are pinned to specific commit hashes rather than actual dependency versions, and libraries that weren't previously versioned cannot be fetched if your project relies on an older pre-vcpkg version of a library and cannot be upgraded for one reason or another. These days I find myself struggling more and more with proper dev setup where I have an up-to-date compiler on any machine I want to build the code along with its libraries without running into a rabbit hole of compiler and library issues.
Re: C++ Should Be C++
#9this feels defeatist c++ is with us for the near future, it needs an evolutionary path that provides a sane path forward why not break with the past? anyone needing to compile c++11 can find the tools and still use them, they can live in the past as long as they like just getting dependency/build management and integrated testing would be huge and really a small ask given what is happening in other tools its crazy th…
This is the never-ending problem with programming languages.
If you make big breaking changes, the community suffers - even if the changes are very well intentioned. Look at the long tail of Python 2 vs 3 issues. If it happens once it's not so bad, but the older the community and the greater the size of its existing ecosystem - the more that pain becomes. Rust, from what I've seen, understands this issue.
Re: C++ Should Be C++
#10Honestly, the changes in C++ 20 and 23, plus the upcoming changes for 26 (looking at you, Concurrency TS v2) have so drastically improved the language it's almost like the ES5 -> ES6 evolution of JavaScript. I might be in the minority here, but I genuinely enjoy writing modern C++. My complaints are about it's dependency management story and lack of integrated, standardized tools for things like dependencies, testing…
Anything C++11 forward is alright with me, though 17 introduces some very nice conveniences like , and most critically . Honorable mention to std::clamp too.
> Honorable mention to std::clamp too.
One shudders to think how many times variations of that template have been written in house.