4 ms·
A question people who use C++ regularly, is C++ becoming easier to read and code?
by oolongCat 10y ago
A question people who use C++ regularly, is C++ becoming easier to read and code?
- gregstula 10y agoIt does get easier to read and code over time. As an aside, the C++ in this post is pretty much as elegant as it gets.
- hendzen 10y agoYes, I work in a template heavy C++ codebase and the (already quite good) situation is getting better with each language standard. C++11 was really a turning point for the language - features like 'auto', lambdas, and variadic templates have enabled succinct generic code that is both readable and highly performant. Increased competition between the gcc and clang teams has also been a major improvement - both have implemented many C++17 features very quickly, and error messages have greatly improved in both compilers. This is especially welcome when developing templates. Clang's licensing has made it possible to integrate libclang in to vim/emacs (ycmd, irony-mode, rtags, etc) for very accurate completion/syntax checking, etc. Clang-format has also seen quite a bit of adoption, bringing the benefits of standardized formatting to large projects. The sanitizers have also been a huge boon - getting automatic memory leak, buffer/heap overflow, use after free, uninitialized memory, integer overflow, etc is now as easy as compiling with '-fsanitize=[address|undefined|memory|etc]'. Overall, C++(11+) is a very productive language if you have stringent performance and latency requirements and you need powerful abstraction facilities.
- int_19h 10y agoDo you mean, becoming easier with new language features that get added?
- vanderZwan 10y agoContrary to popular belief, new features can make a language more elegant and simple, if they make clunky old features obsolete with a simpler alternative.
- MereInterest 10y agoAbsolutely, and without a doubt. * `unique_ptr` as a local variable. Before C++11, I needed to either (a) define a holder class for anything that should be deleted at the end of a scope or (b) delete it manually and pray that there isn't an exception thrown. Now, I can just declare it, and trust the destructor to clean up after me. * `unique_ptr` as a return value. Previously, if a function returns a pointer, there was no way on knowing who was responsible for calling `delete`. Now, I can clearly indicate intent. `unique_ptr` means that the caller now owns the object, while C-style pointer or reference means that the callee still owns the object. * With lambda statements, I can call `std::sort` in-place, with the sorting criteria immediately visible. Previously, I would need to define a function elsewhere in the code, obscuring what may be a simple `a.param < b.param`. * With range-based for loops, I can loop over any container without needing the very long `std::vector<MyClassName>::iterator` declaration. * `= delete` to remove an automatically generated method, such as copy constructors. Previously, you would declare that method to be private, then never make an implementation of it. `= delete` shows your intent much more clearly. * `static_assert`, so that you can bail out of templates earlier, and with reasonable error messages. * Variadic templates. These aren't needed in 99% of cases, but they are incredibly useful when designing libraries. * `std::thread` No more messing around with different thread libraries depending on which platform you are on.
- jwilk 10y agoRe unique_ptr as a local variable: in C++98 you can use auto_ptr.
- MereInterest 10y agoTrue, I didn't mention it, because it has its own issues. The move-on-copy semantics of auto_ptr makes it incompatible with std containers, and makes for some rather unexpected behavior.