5 ms·

True, but I think a lot of the encouragement is to move away from writing C++ like it is C because we really don't want to encourage people to write with danger

True, but I think a lot of the encouragement is to move away from writing C++ like it is C because we really don't want to encourage people to write with dangerous approaches anymore (like you can if you write C++ like it is C). I work with a few who write their C++ like it is C (pointers thrown around, no const-correctness, memcpy instead of copy constructors etc. etc.) and it is horrible to read. There is no indication of lifetimes of objects, nor any indication of ownership. No RAII, no exceptions, nothing. It is dangerous. You are rewarded for writing C++ safely because you won't have to fix any bugs and you can offload all the work onto the compiler for checking types and safety for you. Like you, though, I don't understand people who get red in the face about C++ and go into a profane rage. It is just a language after all.

ratboy666 11y ago
Guilty. Of writing C++ as if it were C. Sometimes even with classes. Yes, I use memcpy instead of copy constructors. I find "modern C++" horrible to read. Indication of object lifetime? Ownership? Um... why? If the development support does not include a garbage collector, I have to be very careful about these things. And, I am. Very careful indeed. I just use the approach I do in C, and assume NOTHING from C++. Honestly, I do NOT assume that the language system, compiler or run-time can do it properly. I have been bitten too many times. I do presume a garbage collector at the very next level up. Yes, you may find my code "horrible to read". And, yes, I have gone into profane rages over C++ code. It happens when the code bullies me -- with hopeless error messages for simple typos. When simple changes cause the application to no longer link. When simple changes cause massive explosions in object size. In fact C++ is so complex, it encourages cargo cult programming. Not just use of libraries, but enforced cargo-cult when USING the libraries. Because, raisons. Not just a language -- hell-spawn. Sorry, "modern hell-spawn".
- 72deluxe 11y ago
  The problem is that if you were hit by a bus, the next guy maintaining the code has to know about where everything is cleaned up and has to know all of the secrets that you know and that you decided you knew better than the compiler in areas. This makes for unmaintainable code. Ownership is very important because if you don't know who owns it, who will clean it up?? If you don't know how long an object will be around because you've got a pointer, it is now a dangling pointer and attempts to use it will cause chaos. So object lifetime is important too. The error messages are usually quite helpful. clang's messages are more helpful for gcc, I have found. C++ is complex, but you can still write safe code without using any of the complexities.
- vvanders 11y ago
  If you hate the idea of ownership and lifetimes I want to stay the hell away from any codebase you work on.
  - ratboy666 11y ago
    No, what I "hate" is the idea that C++ promotes "automatic" management of "ownership and lifetime" without a garbage collector. Which works, except when it doesn't. Which results in stuff like reference counting in the codebase. Which, of course, changes on a whim. Example: the CEF3 library (chromium embedded framework). Reference counted objects. Which requires source code changes depending on the version of CEF 3 being used. Requires VERY deep analysis to determine what to change in the using code. Really -- because the objects participate in a multi-threaded library. So, most code ends up as "cargo cult". Since my code doesn't fit into the CEF3 object model, I do the contortions needed -- building another layer.
    - vvanders 11y ago
      Ownership and Lifetimes != Reference counting. Reference counting is code smell that you don't have a clear ownership model. Take a look a Rust for something more along the lines of what I'm talking about. There's been quite a few people who've re-written their C/C++ code to Rust only to find out that they didn't have a clear ownership model and found architectural improvements because of it.
    - 72deluxe 11y ago
      RAII solves this. Allocate all you need in the constructor, tidy up in the destructor. So when the parent item gets cleaned up, the child items get cleaned up too (so lifetime is sorted for you, and ownership is done too as the parent that owns it is getting cleaned up). You will eventually only have one parent item but if you tidy everything up for that in its destructor, the lifetimes of everything is sorted. If your acquisition of a resource fails or initialisation fails, throw an exception in the constructor. C++11's threading support library in the STL should help your threaded problems. If you need containers of items, put them into an STL container. Don't allocate them with new - write a move constructor for your item and it'll be moved. Or a copy constructor; follow the "rule of 5" if you have pointer-held items in your object (probably best not to), or "rule of 0" and let the compiler do it for you. std::move your items into the container. Use const references if you want to let something else use it, ordinary references if you want them to modify it. Or if you must use naked pointers, put them in a unique_ptr so it gets cleaned up eventually (http://en.cppreference.com/w/cpp/memory/unique_ptr http://en.cppreference.com/w/cpp/memory/unique_ptr). Or shared_ptr in other areas (see Stroutrup 5.2.1 in C++ 4th edition). If you need naked pointers, allocate them on the heap but wrap them in std::unique_ptr or have a vector of unique_ptr. If your objects are child items in a class hierarchy (e.g.. ChildClass : public BassClass) or the base class is an abstract class and you want to have a generic STL container (like std::vector<BaseClass* >) to store all base and child items in one neat place, you will have to use pointers (as you can't have std::vector<MyAbstractBaseClass> but you can have std::vector<MyAbstractBaseClass* >), you will need to take care in the containing object's destructor to clean up this container, eg. while(!vector.empty()) { delete vector.back(); vector.pop_back(); } You shouldn't need reference counting. A read of Stroustrup's C++ Fourth Edition book and the "tour of C++" section toward the beginning will help you immensely.
- scott_s 11y ago
  If you don't want to use basic C++ features such as copy constructors, then why use C++ and not C?
pjmlp 11y ago
This is why although I like C++ a lot, nowadays my day job is spent between JVM and .NET languages, with C++ only when I need to step out of them. From what I know, having the chance to ever find a job on my area where one can use proper C++ is very thin.
pcwalton 11y ago
> You are rewarded for writing C++ safely because you won't have to fix any bugs and you can offload all the work onto the compiler for checking types and safety for you. But that's not the case. No shipping version of C++ is memory safe. In fact, this is exactly what the article is about.
alfalfasprout 11y ago
Here's the thing, there is a nice way (well, more than one) to blend highly tuned low-level C code with clean, modern C++. I have to do it: I work on high performance algorithmic trading systems. You want to keep raw pointers, etc. confined to private class members, initialize memory only within the constructor (if possible), and free memory at the destructor. The user/public API should not expose unsafe stuff. With all this, RAII will give you a nice expectation of lifetime, etc. Plus you're able to use something like tcmalloc. I often find a difficult issue arises when you have a large data structure that you want to free before it goes out of scope (to reclaim some memory). In this case, adding a "clear" method that frees the internals is handy. The destructor will call clear() but you can call it at any time. No harm done if it's called twice. The next thing is const-correctness: if you follow it then any C-like code underneath should be relatively safe. Not using copy constructors is just awful. Memcpy has a time and a place: at the low level (eg; I use it for serializing to a buffer). If you're using memcpy for classes you're probably doing something wrong. Exceptions are a place where you see a wide gamut of safety. Some people don't use them at all: which isn't great. Others add hundreds of lines of code by wrapping everything in a try/catch. Not sure where I stand here, honestly. There's a point where you're catching exceptions that just aren't going to happen...

ratboy666 11y ago

Guilty. Of writing C++ as if it were C. Sometimes even with classes. Yes, I use memcpy instead of copy constructors. I find "modern C++" horrible to read. Indication of object lifetime? Ownership? Um... why? If the development support does not include a garbage collector, I have to be very careful about these things. And, I am. Very careful indeed. I just use the approach I do in C, and assume NOTHING from C++. Honestly, I do NOT assume that the language system, compiler or run-time can do it properly. I have been bitten too many times. I do presume a garbage collector at the very next level up. Yes, you may find my code "horrible to read". And, yes, I have gone into profane rages over C++ code. It happens when the code bullies me -- with hopeless error messages for simple typos. When simple changes cause the application to no longer link. When simple changes cause massive explosions in object size. In fact C++ is so complex, it encourages cargo cult programming. Not just use of libraries, but enforced cargo-cult when USING the libraries. Because, raisons. Not just a language -- hell-spawn. Sorry, "modern hell-spawn".

72deluxe 11y ago
The problem is that if you were hit by a bus, the next guy maintaining the code has to know about where everything is cleaned up and has to know all of the secrets that you know and that you decided you knew better than the compiler in areas. This makes for unmaintainable code. Ownership is very important because if you don't know who owns it, who will clean it up?? If you don't know how long an object will be around because you've got a pointer, it is now a dangling pointer and attempts to use it will cause chaos. So object lifetime is important too. The error messages are usually quite helpful. clang's messages are more helpful for gcc, I have found. C++ is complex, but you can still write safe code without using any of the complexities.
vvanders 11y ago
If you hate the idea of ownership and lifetimes I want to stay the hell away from any codebase you work on.
- ratboy666 11y ago
  No, what I "hate" is the idea that C++ promotes "automatic" management of "ownership and lifetime" without a garbage collector. Which works, except when it doesn't. Which results in stuff like reference counting in the codebase. Which, of course, changes on a whim. Example: the CEF3 library (chromium embedded framework). Reference counted objects. Which requires source code changes depending on the version of CEF 3 being used. Requires VERY deep analysis to determine what to change in the using code. Really -- because the objects participate in a multi-threaded library. So, most code ends up as "cargo cult". Since my code doesn't fit into the CEF3 object model, I do the contortions needed -- building another layer.
  - vvanders 11y ago
    Ownership and Lifetimes != Reference counting. Reference counting is code smell that you don't have a clear ownership model. Take a look a Rust for something more along the lines of what I'm talking about. There's been quite a few people who've re-written their C/C++ code to Rust only to find out that they didn't have a clear ownership model and found architectural improvements because of it.
  - 72deluxe 11y ago
    RAII solves this. Allocate all you need in the constructor, tidy up in the destructor. So when the parent item gets cleaned up, the child items get cleaned up too (so lifetime is sorted for you, and ownership is done too as the parent that owns it is getting cleaned up). You will eventually only have one parent item but if you tidy everything up for that in its destructor, the lifetimes of everything is sorted. If your acquisition of a resource fails or initialisation fails, throw an exception in the constructor. C++11's threading support library in the STL should help your threaded problems. If you need containers of items, put them into an STL container. Don't allocate them with new - write a move constructor for your item and it'll be moved. Or a copy constructor; follow the "rule of 5" if you have pointer-held items in your object (probably best not to), or "rule of 0" and let the compiler do it for you. std::move your items into the container. Use const references if you want to let something else use it, ordinary references if you want them to modify it. Or if you must use naked pointers, put them in a unique_ptr so it gets cleaned up eventually (http://en.cppreference.com/w/cpp/memory/unique_ptr http://en.cppreference.com/w/cpp/memory/unique_ptr). Or shared_ptr in other areas (see Stroutrup 5.2.1 in C++ 4th edition). If you need naked pointers, allocate them on the heap but wrap them in std::unique_ptr or have a vector of unique_ptr. If your objects are child items in a class hierarchy (e.g.. ChildClass : public BassClass) or the base class is an abstract class and you want to have a generic STL container (like std::vector<BaseClass* >) to store all base and child items in one neat place, you will have to use pointers (as you can't have std::vector<MyAbstractBaseClass> but you can have std::vector<MyAbstractBaseClass* >), you will need to take care in the containing object's destructor to clean up this container, eg. while(!vector.empty()) { delete vector.back(); vector.pop_back(); } You shouldn't need reference counting. A read of Stroustrup's C++ Fourth Edition book and the "tour of C++" section toward the beginning will help you immensely.
scott_s 11y ago
If you don't want to use basic C++ features such as copy constructors, then why use C++ and not C?

pjmlp 11y ago

This is why although I like C++ a lot, nowadays my day job is spent between JVM and .NET languages, with C++ only when I need to step out of them. From what I know, having the chance to ever find a job on my area where one can use proper C++ is very thin.

pcwalton 11y ago

> You are rewarded for writing C++ safely because you won't have to fix any bugs and you can offload all the work onto the compiler for checking types and safety for you. But that's not the case. No shipping version of C++ is memory safe. In fact, this is exactly what the article is about.

alfalfasprout 11y ago

Here's the thing, there is a nice way (well, more than one) to blend highly tuned low-level C code with clean, modern C++. I have to do it: I work on high performance algorithmic trading systems. You want to keep raw pointers, etc. confined to private class members, initialize memory only within the constructor (if possible), and free memory at the destructor. The user/public API should not expose unsafe stuff. With all this, RAII will give you a nice expectation of lifetime, etc. Plus you're able to use something like tcmalloc. I often find a difficult issue arises when you have a large data structure that you want to free before it goes out of scope (to reclaim some memory). In this case, adding a "clear" method that frees the internals is handy. The destructor will call clear() but you can call it at any time. No harm done if it's called twice. The next thing is const-correctness: if you follow it then any C-like code underneath should be relatively safe. Not using copy constructors is just awful. Memcpy has a time and a place: at the low level (eg; I use it for serializing to a buffer). If you're using memcpy for classes you're probably doing something wrong. Exceptions are a place where you see a wide gamut of safety. Some people don't use them at all: which isn't great. Others add hundreds of lines of code by wrapping everything in a try/catch. Not sure where I stand here, honestly. There's a point where you're catching exceptions that just aren't going to happen...