6 ms·

I've been writing C++ since 1990. I make a good living from a little C++ app (500KLOC) that sells in fifty countries. I love the ultra-static typing. It's saved

I've been writing C++ since 1990. I make a good living from a little C++ app (500KLOC) that sells in fifty countries. I love the ultra-static typing. It's saved my bacon many a times. Long ago "modern" C++ crossed into a territory that I will never understand or use. STL is the fanciest stuff I write. Code needs to be maintainable. If I have to hire geniuses to collaborate on my code, that's not going to be cost-effective. So I use a conservative subset, and thank my lucky stars I don't need to pay attention to the latest exotica.

MrBuddyCasino 6y ago
Since this is your business, your incentives are aligned: develop a product by means of a tool that needs to be productive and cost effective. In other words, you have skin in the game, unlike the average employed coder. This changes perspective.
bsenftner 6y ago
Likewise. I've been writing C professionally since '83, and thru the decades of my career spanning computer graphics, embedded systems, video games, film VFX, high compute web apps, and now facial recognition - the rule has been using a conservative subset of C++. STL being about as fancy as one gets, with an eye towards maintainability has been satisfying. By working with and employing people with backgrounds like former video game developers, they know the value of only optimizing bottlenecks. Clean easy to read C++ that any C programmer could read works, very well.
dkersten 6y ago
> Long ago "modern" C++ crossed into a territory that I will never understand or use. Do you know where the line is? C++11? Later versions? I ask because I quite like a lot of the changes that C++11 brought to the language, I feel they make my code much simpler to understand and maintain, but I got very confused by post-11 C++ for a long time to the point where I said I'd never bother with C++17 or later (14 turned out not to be too scary once I actually sat down with it) because 17 and 20 added so much stuff that just looked beyond me. But I've since changed my mind and have started to experiment with C++20, after I sat down and read a few articles and watched a few cppcon videos on the changes. I don't know all that these versions have to offer, but I do understand the main changes enough to get by and most of them do make the language better, in my opinion. Overall, the language is a mess, simply because they keep adding to it and very little stuff gets deprecated, removed, changed or cleaned. That leaves a large and messy language, especially compared to more recent deliberately-designed languages, but it turned out I could understand "most" of the things, once I had someone explain them to me. A few times ;) Having said that, it probably isn't worth your time to "modernise" the C++ in your money-making codebase at this stage, if you're comfortable with it how it is. You likely wouldn't see a return in the effort it would take.
- lasagnaphil 6y ago
  For C++17, the only best thing for me was that you can destructure tuples and pairs with a simple syntax (when otherwise you needed to use std::tie) auto [a, b] = functionThatReturnsATuple(); For C++20, the one single thing I'm excited about is designated initializers (which was already in C99! It's kinda mad why this came so late). Basically you can initialize structs with parameter names with just a single line of code: struct Person { std::string name; int age; }; Person person = {.name = "Bob", .age = 29}; Anything else from C++17 and onwards I really don't find a usage for right now. Compile-time programming using constexpr and consteval is great, until you realize that compile-time programming works under the hood by evaluating the AST directly (which is the slowest possible way for an interpreter), and would make your build times skyrocket to the moon. Concepts are kinda nice because of better error messages, but doesn't really matter for me if heavily templated libraries like STL and Eigen aren't fully ported for this feature. Ranges are just unnecessary for me, I learned the hard way that for loops are much better in terms of clarity and performance. And for modules: again, it only matters if the STL, tooling, and major libraries are ready for it, and I'm skeptical it will be achieved at any time.
  - dkersten 6y ago
    For C++20, I agree with you on Concepts. They're nice to have, but its probably going to be quite rare that I will use them. I am, however, interested in coroutines and modules too (the other two of the three main things 20 adds). I also agree on the initializers, that's something I wish C++ had added long ago, since C has had it for so long. Funny thing is, I didn't even think of ranges while writing my comment above. I like the idea of them and they do allow some nice code, but its not something I've been wishing I had. For C++17, there's a bunch of small things that I like: standard attributes like [[nodiscard]], nested namespace definitions are a nice convenience, constexpr if statements and some of the library additions are nice (string_view, optional, etc). Destructuring auto, as you said. Nothing as exciting as what C++11 or 20 adds, but still nice to haves.
  - ncmncm 6y ago
    If that is your favorite thing from C++20, I have very good news for you: You hain't seen nothin' yet. Saying concepts are just for better error messages is like saying types are just for error checking. You can rely on them only for that. Or you can put them to work. Most of what makes C++ powerful is from putting types to work. Concepts are just as powerful. You haven't seen yet what they can do.
ensiferum 6y ago
Some of the modern c++ is a what I'd consider essential really. And there's plenty more that is very nice to have. Move semantics and unique_ptr are really IMHO essential. Then lots of nice to have stuff such as, shared_ptr, threads, lambdas (make STL a lot more usable). Personally I'd not want to be maintaining a C++98 style of code base at this point. That being said you have probably already written all of the "nice to have" stuff so there's no real value benefit to go and replace it as such. So I understand your POV as well. That being said I'd probably modernize the code as I go whenever I touch any part of the codebase.
attilakun 6y ago
What is the app if you don't mind sharing?
- GnarfGnarf 6y ago
  Genealogy graphics: a niche within a niche. https://progenygenealogy.com/products/family-tree-charts/ https://progenygenealogy.com/products/family-tree-charts/

MrBuddyCasino 6y ago

Since this is your business, your incentives are aligned: develop a product by means of a tool that needs to be productive and cost effective. In other words, you have skin in the game, unlike the average employed coder. This changes perspective.

bsenftner 6y ago

Likewise. I've been writing C professionally since '83, and thru the decades of my career spanning computer graphics, embedded systems, video games, film VFX, high compute web apps, and now facial recognition - the rule has been using a conservative subset of C++. STL being about as fancy as one gets, with an eye towards maintainability has been satisfying. By working with and employing people with backgrounds like former video game developers, they know the value of only optimizing bottlenecks. Clean easy to read C++ that any C programmer could read works, very well.

dkersten 6y ago

> Long ago "modern" C++ crossed into a territory that I will never understand or use. Do you know where the line is? C++11? Later versions? I ask because I quite like a lot of the changes that C++11 brought to the language, I feel they make my code much simpler to understand and maintain, but I got very confused by post-11 C++ for a long time to the point where I said I'd never bother with C++17 or later (14 turned out not to be too scary once I actually sat down with it) because 17 and 20 added so much stuff that just looked beyond me. But I've since changed my mind and have started to experiment with C++20, after I sat down and read a few articles and watched a few cppcon videos on the changes. I don't know all that these versions have to offer, but I do understand the main changes enough to get by and most of them do make the language better, in my opinion. Overall, the language is a mess, simply because they keep adding to it and very little stuff gets deprecated, removed, changed or cleaned. That leaves a large and messy language, especially compared to more recent deliberately-designed languages, but it turned out I could understand "most" of the things, once I had someone explain them to me. A few times ;) Having said that, it probably isn't worth your time to "modernise" the C++ in your money-making codebase at this stage, if you're comfortable with it how it is. You likely wouldn't see a return in the effort it would take.

lasagnaphil 6y ago
For C++17, the only best thing for me was that you can destructure tuples and pairs with a simple syntax (when otherwise you needed to use std::tie) auto [a, b] = functionThatReturnsATuple(); For C++20, the one single thing I'm excited about is designated initializers (which was already in C99! It's kinda mad why this came so late). Basically you can initialize structs with parameter names with just a single line of code: struct Person { std::string name; int age; }; Person person = {.name = "Bob", .age = 29}; Anything else from C++17 and onwards I really don't find a usage for right now. Compile-time programming using constexpr and consteval is great, until you realize that compile-time programming works under the hood by evaluating the AST directly (which is the slowest possible way for an interpreter), and would make your build times skyrocket to the moon. Concepts are kinda nice because of better error messages, but doesn't really matter for me if heavily templated libraries like STL and Eigen aren't fully ported for this feature. Ranges are just unnecessary for me, I learned the hard way that for loops are much better in terms of clarity and performance. And for modules: again, it only matters if the STL, tooling, and major libraries are ready for it, and I'm skeptical it will be achieved at any time.
- dkersten 6y ago
  For C++20, I agree with you on Concepts. They're nice to have, but its probably going to be quite rare that I will use them. I am, however, interested in coroutines and modules too (the other two of the three main things 20 adds). I also agree on the initializers, that's something I wish C++ had added long ago, since C has had it for so long. Funny thing is, I didn't even think of ranges while writing my comment above. I like the idea of them and they do allow some nice code, but its not something I've been wishing I had. For C++17, there's a bunch of small things that I like: standard attributes like [[nodiscard]], nested namespace definitions are a nice convenience, constexpr if statements and some of the library additions are nice (string_view, optional, etc). Destructuring auto, as you said. Nothing as exciting as what C++11 or 20 adds, but still nice to haves.
- ncmncm 6y ago
  If that is your favorite thing from C++20, I have very good news for you: You hain't seen nothin' yet. Saying concepts are just for better error messages is like saying types are just for error checking. You can rely on them only for that. Or you can put them to work. Most of what makes C++ powerful is from putting types to work. Concepts are just as powerful. You haven't seen yet what they can do.

ensiferum 6y ago

Some of the modern c++ is a what I'd consider essential really. And there's plenty more that is very nice to have. Move semantics and unique_ptr are really IMHO essential. Then lots of nice to have stuff such as, shared_ptr, threads, lambdas (make STL a lot more usable). Personally I'd not want to be maintaining a C++98 style of code base at this point. That being said you have probably already written all of the "nice to have" stuff so there's no real value benefit to go and replace it as such. So I understand your POV as well. That being said I'd probably modernize the code as I go whenever I touch any part of the codebase.

attilakun 6y ago

What is the app if you don't mind sharing?

GnarfGnarf 6y ago
Genealogy graphics: a niche within a niche. https://progenygenealogy.com/products/family-tree-charts/ https://progenygenealogy.com/products/family-tree-charts/