3 ms·

> Many projects don't need to worry about some low levels aspect of the design (if at all): memory management, for instance, can mostly be left to compilers and

> Many projects don't need to worry about some low levels aspect of the design (if at all): memory management, for instance, can mostly be left to compilers and linkers. And in properly written C++, it is.

loup-vaillant 17y ago
No it is not. More precisely, I don't see how you could avoid manual memory management in any significant C++ project. Here's why: The only memory that is automatically managed in C++ is the stack. (If you disagree, please know that I will be very difficult to convince.) So, "properly written C++" literally means "C++ code which doesn't uses the heap at all". That's probably not what you meant. Relaxing this rule a bit, you could code in a RAII fashion. That way, the users of properly written objects won't manage the memory themselves. The implementation of those, however, still have to. A prime example is the STL. Plus, I'm not sure RAII all the way down is "properly written". See, such logic is quite copy-prone, affecting the code's efficiency. You use C++ for it's performance, right? So you have to manage the memory manually at some point. Or you could use smart pointers. They mitigate the need for manual memory management, and allow sharing. But even then, you might want to (manually) pay attention to loops in the pointing chains.
- jemfinch 17y ago
  Relaxing this rule a bit, you could code in a RAII fashion. That way, the users of properly written objects won't manage the memory themselves. Which is exactly my point: between the standard library and smart pointers, many projects will never have to touch any details of memory management. The implementation of those, however, still have to. A prime example is the STL. Of course. But you only need one standard library, and many projects can use it. Don't forget your original claim, which I quoted in my previous post: "Many projects don't need to worry about some low levels aspect of the design (if at all)." It's absolutely true that many sizable projects written in modern C++ never have to consider the low-level details of things like memory management, since those details have been pushed into the libraries they use. Plus, I'm not sure RAII all the way down is "properly written". See, such logic is quite copy-prone, affecting the code's efficiency. There are ways to mitigate that impact, if it becomes a performance issue, but it rarely does. Or you could use smart pointers. They mitigate the need for manual memory management, and allow sharing. But even then, you might want to (manually) pay attention to loops in the pointing chains. That's only a problem for self-referential data structures, of which there are few not already implemented for you in the standard library.
  - loup-vaillant 17y ago
    There are ways to mitigate that impact, if it becomes a performance issue, but it rarely does. Ah. So you don't really care about performance. In that case, the only justification left to C++ is legacy code. (Knowing Ocaml and Haskell makes me quite certain of it.) That was my original point: C++, even when you try to use a wisely chosen subset of it, remains very complicated and error prone. I blame it's design choices. I agree that those choices were precisely what made C++ popular, but popularity is hardly a criterion for me. And on all other fronts, C++ really sucks.
    - jemfinch 17y ago
      So you don't really care about performance. Did I say that? That was my original point: C++, even when you try to use a wisely chosen subset of it, remains very complicated and error prone. Your original point, which I've now quoted twice, was that C++ is inappropriate because many programs don't need to deal with low-level details like memory management. My counterclaim, which you have yet to refute, is that C++ is no obstacle to that end. I blame it's design choices. The vast majority of people who blame C++'s design choices don't understand them. Have you read Stroustrup's D&E? And on all other fronts, C++ really sucks. Stating a claim is no defense of it.
      - loup-vaillant 17y ago
        > > So you don't really care about performance. > Did I say that? Yes, by saying that copy prone RAII is rarely an issue. Meaning, performance is rarely an issue. So, you rarely care about performance. That's fine: performance rarely matters, anyway. When it does, we can still locally optimize. > > And on all other fronts, C++ really sucks. > Stating a claim is no defense of it. You're right. This is: http://yosefk.com/c++fqa/ http://yosefk.com/c++fqa/ The writing is quite fun, and the whole thing is actually informative. To sum up, the guy says that for a new project with few dependencies, C++ is almost never the best choice. Meaning, (almost) no niche is best filled by C++. Each one is better served with another language. > Your original point, which I've now quoted twice, was that C++ is inappropriate because many programs don't need to deal with low-level details like memory management. My counterclaim, which you have yet to refute, is that C++ is no obstacle to that end. You're right (again). I can't refute that point. Now my point is, that doesn't make C++ appropriate. See, when you don't need to do low-level stuff, many programming languages are vastly simpler, safer, more terse, and more flexible than C++. All at the same time. And you can learn them in no time (you were able to learn C++, after all). So, in that case, C++ isn't the best option. Why bother with it? But still, I wonder how a significant project could avoid to implement some sort of data structure itself (which would mean worry about memory). Do you have any example? > The vast majority of people who blame C++'s design choices don't understand them. Have you read Stroustrup's D&E? I didn't. As I understand it, Stroustrup had some goals, and C++ achieved them. One such goal was to bring Object Orientation to C programmers (the "masses"). So I won't say that C++ didn't achieve it's purposes. It did. I just say those purposes weren't worth the behemoth that C++ is. Object Orientation for instance, is a mistake. As seen by C++ (and Java), OO encourages high coupling and side effects more than is healthy. And that's before you need to apply one of the baroque design patterns from the GoF book.

loup-vaillant 17y ago

No it is not. More precisely, I don't see how you could avoid manual memory management in any significant C++ project. Here's why: The only memory that is automatically managed in C++ is the stack. (If you disagree, please know that I will be very difficult to convince.) So, "properly written C++" literally means "C++ code which doesn't uses the heap at all". That's probably not what you meant. Relaxing this rule a bit, you could code in a RAII fashion. That way, the users of properly written objects won't manage the memory themselves. The implementation of those, however, still have to. A prime example is the STL. Plus, I'm not sure RAII all the way down is "properly written". See, such logic is quite copy-prone, affecting the code's efficiency. You use C++ for it's performance, right? So you have to manage the memory manually at some point. Or you could use smart pointers. They mitigate the need for manual memory management, and allow sharing. But even then, you might want to (manually) pay attention to loops in the pointing chains.

jemfinch 17y ago
Relaxing this rule a bit, you could code in a RAII fashion. That way, the users of properly written objects won't manage the memory themselves. Which is exactly my point: between the standard library and smart pointers, many projects will never have to touch any details of memory management. The implementation of those, however, still have to. A prime example is the STL. Of course. But you only need one standard library, and many projects can use it. Don't forget your original claim, which I quoted in my previous post: "Many projects don't need to worry about some low levels aspect of the design (if at all)." It's absolutely true that many sizable projects written in modern C++ never have to consider the low-level details of things like memory management, since those details have been pushed into the libraries they use. Plus, I'm not sure RAII all the way down is "properly written". See, such logic is quite copy-prone, affecting the code's efficiency. There are ways to mitigate that impact, if it becomes a performance issue, but it rarely does. Or you could use smart pointers. They mitigate the need for manual memory management, and allow sharing. But even then, you might want to (manually) pay attention to loops in the pointing chains. That's only a problem for self-referential data structures, of which there are few not already implemented for you in the standard library.
- loup-vaillant 17y ago
  There are ways to mitigate that impact, if it becomes a performance issue, but it rarely does. Ah. So you don't really care about performance. In that case, the only justification left to C++ is legacy code. (Knowing Ocaml and Haskell makes me quite certain of it.) That was my original point: C++, even when you try to use a wisely chosen subset of it, remains very complicated and error prone. I blame it's design choices. I agree that those choices were precisely what made C++ popular, but popularity is hardly a criterion for me. And on all other fronts, C++ really sucks.
  - jemfinch 17y ago
    So you don't really care about performance. Did I say that? That was my original point: C++, even when you try to use a wisely chosen subset of it, remains very complicated and error prone. Your original point, which I've now quoted twice, was that C++ is inappropriate because many programs don't need to deal with low-level details like memory management. My counterclaim, which you have yet to refute, is that C++ is no obstacle to that end. I blame it's design choices. The vast majority of people who blame C++'s design choices don't understand them. Have you read Stroustrup's D&E? And on all other fronts, C++ really sucks. Stating a claim is no defense of it.
    - loup-vaillant 17y ago
      > > So you don't really care about performance. > Did I say that? Yes, by saying that copy prone RAII is rarely an issue. Meaning, performance is rarely an issue. So, you rarely care about performance. That's fine: performance rarely matters, anyway. When it does, we can still locally optimize. > > And on all other fronts, C++ really sucks. > Stating a claim is no defense of it. You're right. This is: http://yosefk.com/c++fqa/ http://yosefk.com/c++fqa/ The writing is quite fun, and the whole thing is actually informative. To sum up, the guy says that for a new project with few dependencies, C++ is almost never the best choice. Meaning, (almost) no niche is best filled by C++. Each one is better served with another language. > Your original point, which I've now quoted twice, was that C++ is inappropriate because many programs don't need to deal with low-level details like memory management. My counterclaim, which you have yet to refute, is that C++ is no obstacle to that end. You're right (again). I can't refute that point. Now my point is, that doesn't make C++ appropriate. See, when you don't need to do low-level stuff, many programming languages are vastly simpler, safer, more terse, and more flexible than C++. All at the same time. And you can learn them in no time (you were able to learn C++, after all). So, in that case, C++ isn't the best option. Why bother with it? But still, I wonder how a significant project could avoid to implement some sort of data structure itself (which would mean worry about memory). Do you have any example? > The vast majority of people who blame C++'s design choices don't understand them. Have you read Stroustrup's D&E? I didn't. As I understand it, Stroustrup had some goals, and C++ achieved them. One such goal was to bring Object Orientation to C programmers (the "masses"). So I won't say that C++ didn't achieve it's purposes. It did. I just say those purposes weren't worth the behemoth that C++ is. Object Orientation for instance, is a mistake. As seen by C++ (and Java), OO encourages high coupling and side effects more than is healthy. And that's before you need to apply one of the baroque design patterns from the GoF book.