4 ms·
I'm a former C++ programmer (I haven't had an assignment that used C++ for years, though I pressed for a limited subset on a recent embedded system) I likely ne
by HankB99 9y ago
I'm a former C++ programmer (I haven't had an assignment that used C++ for years, though I pressed for a limited subset on a recent embedded system) I likely never reached the sophistication of most of the respondents here and my concerns may have been addressed.
The things that concerned me about C++ were the pitfalls that could happen due to ignorance or omission vs. errors introduced by commission. For example forgetting to implement a copy constructor for a class that allocates member data. (That results in two objects that hold pointers to the allocated data following a copy operation and if one is deleted, the other points to now deleted data.) Perhaps there are better compiler warnings or static analysis tools that will reveal problems like that today.
My other concern is how big the language has grown. I recall my excitement when I first worked with C++ since it provided direct support for a lot of things I was doing with C (Object orientation, function pointers in structs and similar) with the addition of better type safety. Nowadays many of the language features are incomprehensible and beyond my skill level. I suppose largely because I don't work with C++ on a day to day basis.
- fiddlerwoaroof 9y agoDoesn't std::shared_pointer help with the copy constructor issue?
- int_19h 9y agoIf you mean using shared_ptr everywhere, then 1) this would be extremely non-idiomatic C++, 2) you can still forget to do so, and 3) the moment you do, the language makes it ridiculously easy to implicitly copy something.
- gpderetta 9y agoIf you use a proper smart pointer time to store an owned object as recommended, you'll get sensible behavior: either the copy will be shallow (with shared_ptr) or the implicit copy constructor instantiation will fail to compile (with unique_ptr).