3 ms·

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 exactl

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.
    - jemfinch 17y ago
      Yes, by saying that copy prone RAII is rarely an issue. Meaning, performance is rarely an issue. So, you rarely care about performance. You need to do some work on correcting your faulty interpreter. Saying that copying rarely causes performance problems is not at all saying that I don't care about performance. 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. Not really. Yosefk, like many C++ detractors, very clearly does not understand the rationale for a number of C++ features. But this isn't the place for me to spend hours refuting a link that too you mere seconds to dig up. 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++. That's not actually the case, though. For a lot of simple (e.g., scripting) tasks, writing them in C++ results in a program a few small lines longer and orders of magnitude faster. In one case I had billions of integers on which I needed to calculate some simple satistics; while the Python program was running, I was able to write, compile, and run to completion a C++ version that was a mere four lines longer (mostly empty-brace lines). Some more complex tasks are actually easier in C++ than in other languages. I had to write a parser and virtual machine for an assembly language in college. Doing the bit-level operations in Python would have been a pain, in large part due to the automatic promotion of integers to longs; doing them in C++ was simple and preserved the semantics that I required. I didn't need to manage any low-level allocation in that program; all my "new" calls went straight into smart pointers (auto_ptr actually worked fine in my situation and didn't require a non-standard library) and they handled all deallocation. Valgrind confirmed that there were no memory leaks, with no effort at all on my part. The vast majority of people who consider C++ difficult to write are unaware (commonly through willful ignorance) of how to write C++ for this the frequently cited issues never arise in the first place. And you can learn them in no time (you were able to learn C++, after all). It's not a matter of learning other languages; I'm competent in Python, OCaml, Perl, and a number of other languages I've worked with over the years. C++ is actually a rather late addition to my bevy of languages. So, in that case, C++ isn't the best option. Why bother with it? Just because I can learn other languages doesn't mean C++ isn't the best option. Sure, I could similar speed in OCaml, but then I'd be the only one who could work on it, and my employer would be in a tight spot if I were hit by a bus. I could write it in Python or Perl a little bit faster, but it would be an order of magnitude slower, and I'd have to throw tons more hardware at the problem to process the same amount of data. Object Orientation for instance, is a mistake. Ah. I see now that I'm arguing with an ideologue. Good day.

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.
  - jemfinch 17y ago
    Yes, by saying that copy prone RAII is rarely an issue. Meaning, performance is rarely an issue. So, you rarely care about performance. You need to do some work on correcting your faulty interpreter. Saying that copying rarely causes performance problems is not at all saying that I don't care about performance. 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. Not really. Yosefk, like many C++ detractors, very clearly does not understand the rationale for a number of C++ features. But this isn't the place for me to spend hours refuting a link that too you mere seconds to dig up. 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++. That's not actually the case, though. For a lot of simple (e.g., scripting) tasks, writing them in C++ results in a program a few small lines longer and orders of magnitude faster. In one case I had billions of integers on which I needed to calculate some simple satistics; while the Python program was running, I was able to write, compile, and run to completion a C++ version that was a mere four lines longer (mostly empty-brace lines). Some more complex tasks are actually easier in C++ than in other languages. I had to write a parser and virtual machine for an assembly language in college. Doing the bit-level operations in Python would have been a pain, in large part due to the automatic promotion of integers to longs; doing them in C++ was simple and preserved the semantics that I required. I didn't need to manage any low-level allocation in that program; all my "new" calls went straight into smart pointers (auto_ptr actually worked fine in my situation and didn't require a non-standard library) and they handled all deallocation. Valgrind confirmed that there were no memory leaks, with no effort at all on my part. The vast majority of people who consider C++ difficult to write are unaware (commonly through willful ignorance) of how to write C++ for this the frequently cited issues never arise in the first place. And you can learn them in no time (you were able to learn C++, after all). It's not a matter of learning other languages; I'm competent in Python, OCaml, Perl, and a number of other languages I've worked with over the years. C++ is actually a rather late addition to my bevy of languages. So, in that case, C++ isn't the best option. Why bother with it? Just because I can learn other languages doesn't mean C++ isn't the best option. Sure, I could similar speed in OCaml, but then I'd be the only one who could work on it, and my employer would be in a tight spot if I were hit by a bus. I could write it in Python or Perl a little bit faster, but it would be an order of magnitude slower, and I'd have to throw tons more hardware at the problem to process the same amount of data. Object Orientation for instance, is a mistake. Ah. I see now that I'm arguing with an ideologue. Good day.