4 ms·

C programming is still alive and well is many parts of our profession. The biggest reason why is that even though c++ _can_ do memory management like C most of

by dkhenry 14y ago

C programming is still alive and well is many parts of our profession. The biggest reason why is that even though c++ _can_ do memory management like C most of the time programs implemented in it don't and you can really start to loose a grasp as to what your asking the computer to do when you abstract away where your putting all the stuff your unknowingly asking it to make.

mpyne 14y ago
In the other hand, I find that C++'s ability to add semantics to memory management is extremely valuable in doing the right thing at all times. unique_ptr<>, scoped_ptr<>, and shared_ptr<> all say different things about heap memory lifetime, and those make it easier to maintain your grasp on what you're asking the computer to do. Like many things in C++, you can do that in C too (e.g. by using a variant of Hungarian notation). But the important thing is to do it.
- drbawb 14y ago
  I've been playing w/ Rust this past week, and I've had something of an enlightening experience related to the pointer semantics you describe. Rust's memory management works similarly to what you describe in C++[0], but things like unique_ptr, et al. are baked into the syntax and compiler. -- It's basically syntactic sugar for memory semantics. Coming from a background of GC'd languages (Java, Go, and Ruby) these different allocation semantics were Very Hard(TM) for me to understand at first. I kept battling w/ the type checker, throwing different pointer types at it until the example compiled. (Rust's compiler is _very_ intelligent, w/o using "unsafe" code, you basically cannot have a "use after free" condition in Rust. -- It will not compile.) As the parent points out: I've never really spent any length of time _understanding_ the allocations I'm asking a computer to make. I just generate things, they become garbage, and the runtime cleans it up eventually. Once Rust "clicked" for me, I realized something: I know the lifetime of _every single variable_ in this piece of code. I know when it's allocated, where it's allocated, and when it gets freed. The reason it was so hard for me to initially grok Rust was because I'm _not used to reasoning_ about memory allocation. Once I understood the semantics though, it was as though I had an _entirely new_ level of abstraction at my fingertips. These semantics are definitely some powerful stuff, and I'm very glad I'm taking the time to try and understand them. [0]: http://pcwalton.github.com/blog/2013/03/18/an-overview-of-memory-management-in-rust/ http://pcwalton.github.com/blog/2013/03/18/an-overview-of-me...
  - pjmlp 14y ago
    The biggest problem with manual memory management is when doing software in large teams. Suddenly you have distributed knowledge across team members with various skill levels and producing memory leaks is very easy. Nowadays automatic memory management in the form of GC or reference counting is the way to go.
    - dkhenry 14y ago
      Or you can do what c++ and rust did which is neither reference counting or GC ( yes I know rust has a GC just stay with me for a little). Its a strong and distinct message about what you plan on doing with the memory your getting. When I run across a int* i don't know what your doing with it just by seeing its type, but if I run across a shared_ptr<int> I know its reference counted and will stick around until I am done with it and if I am the last one it will be free'd. In the same manner If i see a unique_ptr<int> I know that if i need it I must take it from someplace and the compiler will be kind enough to tell me if I messed it up somehow.
      - pjmlp 14y ago
        I fail to see how that is not reference counting, even if implemented at library level.
        mpyne 14y ago
        shared_ptr probably does use reference counting, but unique_ptr doesn't. There's literally only ever one "owner" of a unique_ptr, which is why the parent comment talked about taking it from somewhere. C++ exchanges ownership of unique_ptr's in the move constructor or assignment operator (i.e. there's no "copy" operation available, unlike with std::auto_ptr). If a unique_ptr still happens to own a pointer when the unique_ptr is destructed, it knows to destroy the pointed-to object as well and free the memory, but the object itself is not reference-counted per se, there's only the Boolean sense "alive/dead".
        14y ago
pjmlp 14y ago
Linux and BSD distributions, embedded systems, on other domains developers have moved on.

by dkhenry 14y ago

mpyne 14y ago

In the other hand, I find that C++'s ability to add semantics to memory management is extremely valuable in doing the right thing at all times. unique_ptr<>, scoped_ptr<>, and shared_ptr<> all say different things about heap memory lifetime, and those make it easier to maintain your grasp on what you're asking the computer to do. Like many things in C++, you can do that in C too (e.g. by using a variant of Hungarian notation). But the important thing is to do it.

drbawb 14y ago
I've been playing w/ Rust this past week, and I've had something of an enlightening experience related to the pointer semantics you describe. Rust's memory management works similarly to what you describe in C++[0], but things like unique_ptr, et al. are baked into the syntax and compiler. -- It's basically syntactic sugar for memory semantics. Coming from a background of GC'd languages (Java, Go, and Ruby) these different allocation semantics were Very Hard(TM) for me to understand at first. I kept battling w/ the type checker, throwing different pointer types at it until the example compiled. (Rust's compiler is _very_ intelligent, w/o using "unsafe" code, you basically cannot have a "use after free" condition in Rust. -- It will not compile.) As the parent points out: I've never really spent any length of time _understanding_ the allocations I'm asking a computer to make. I just generate things, they become garbage, and the runtime cleans it up eventually. Once Rust "clicked" for me, I realized something: I know the lifetime of _every single variable_ in this piece of code. I know when it's allocated, where it's allocated, and when it gets freed. The reason it was so hard for me to initially grok Rust was because I'm _not used to reasoning_ about memory allocation. Once I understood the semantics though, it was as though I had an _entirely new_ level of abstraction at my fingertips. These semantics are definitely some powerful stuff, and I'm very glad I'm taking the time to try and understand them. [0]: http://pcwalton.github.com/blog/2013/03/18/an-overview-of-memory-management-in-rust/ http://pcwalton.github.com/blog/2013/03/18/an-overview-of-me...
- pjmlp 14y ago
  The biggest problem with manual memory management is when doing software in large teams. Suddenly you have distributed knowledge across team members with various skill levels and producing memory leaks is very easy. Nowadays automatic memory management in the form of GC or reference counting is the way to go.
  - dkhenry 14y ago
    Or you can do what c++ and rust did which is neither reference counting or GC ( yes I know rust has a GC just stay with me for a little). Its a strong and distinct message about what you plan on doing with the memory your getting. When I run across a int* i don't know what your doing with it just by seeing its type, but if I run across a shared_ptr<int> I know its reference counted and will stick around until I am done with it and if I am the last one it will be free'd. In the same manner If i see a unique_ptr<int> I know that if i need it I must take it from someplace and the compiler will be kind enough to tell me if I messed it up somehow.
    - pjmlp 14y ago
      I fail to see how that is not reference counting, even if implemented at library level.
      - mpyne 14y ago
        shared_ptr probably does use reference counting, but unique_ptr doesn't. There's literally only ever one "owner" of a unique_ptr, which is why the parent comment talked about taking it from somewhere. C++ exchanges ownership of unique_ptr's in the move constructor or assignment operator (i.e. there's no "copy" operation available, unlike with std::auto_ptr). If a unique_ptr still happens to own a pointer when the unique_ptr is destructed, it knows to destroy the pointed-to object as well and free the memory, but the object itself is not reference-counted per se, there's only the Boolean sense "alive/dead".
        14y ago

pjmlp 14y ago

Linux and BSD distributions, embedded systems, on other domains developers have moved on.