4 ms·

I think this sentence embodies the biggest problem with C++: "...abstraction mechanisms that allows programmers to express ideas beyond what I can imagine with

I think this sentence embodies the biggest problem with C++: "...abstraction mechanisms that allows programmers to express ideas beyond what I can imagine with no overhead compared to hand-crafted code." This is superficially similar to the Lisp community's "sufficiently advanced compiler," but in C++ it really means that high-level features are thoroughly undermined by low-level concerns (as opposed to just being slow until better compilers come along). Other languages seem to get high-level abstractions right, in the sense of exchanging a constant-factor loss in performance for a large gain in programmer productivity.

SamReidHughes 13y ago
That's a weird thing to say, because C++ has better high-level abstraction facilities than any other mainstream language today.
- betterunix 13y ago
  Better than C#? Better than Python? I think your definition of "mainstream" might be a little narrow, or else you have a very odd understanding of what makes a good high-level abstraction. Also, why limit ourselves to "mainstream" languages? Once upon a time C++ was not mainstream. Why should we shy away from Lisp, OCaml, or Haskell just because they are not popular? In every discussion about C++ and its technical ups and downs, someone points to its popularity, as if that were some kind of justification. The history of computers is overrun with examples of popular-but-inferior technology.
  - SamReidHughes 13y ago
    Yes, better than C#, and waaay better than Python. Similar to but slightly better than Haskell, too. I don't know about OCaml. (edit: C++'s main deficiency against C# and Python is its lack of a reflection system. Against Haskell, C++ is well known for being similar, but templates in C++ are more flexible and less constraining than Haskell's type system features -- for example if you want to overload + you don't have to buy into the entire Num typeclass.)
    - betterunix 13y ago
      I would say that the lack of a standard garbage collector ("smart" pointers do not count since programmers must manually break cycles and decide among smart pointer types) is a pretty serious deficiency. I would also point to the abysmal error-handling support in C++; you do not even get a reliable way to report errors that occur in destructors. Really though, my big issue with C++ is that the high-level features are bogged down by low-level details -- if I wanted to deal with low-level details I would not be using high-level features in the first place. Why should I have to manually determine how to capture variables in a lexical closure? Why should I have to manually declare "virtual" inheritance to deal with the multiple inheritance diamond? Why are destructors not virtual by default? Why are string literals still pointers to character arrays, why are arrays still not bounds-checked, why are integers still fixed-width (and why are integer overflows not reported as errors?)? Yes, these things all make sense sometimes but in most cases they are the opposite of what you want -- you should have to write more code to get this behavior than to avoid it.
      - SamReidHughes 13y ago
        Well, I agree with your complaints about the annoyance of lacking garbage collection, but not everything you complain about. The only nit I really disagree with you on in this post is that it's certainly reasonable that you should have to manually determine how to capture variables in a closure, in C++, because of the nature of the language. Also, many other languages avoid the multiple inheritance diamond simply by not allowing multiple inheritance (and others do it a bit better). The other questions, you know the answer to, and the answer is very obviously performance or compatibility with C (or just bugs in the language). But I'm not claiming that C++ is less annoying to use. I'm saying it has better facilities for making high-level abstractions. That's because of its type system, and you have to go to something like Scala, Haskell, or other statically typed languages, or maybe something homoiconic like Lisp, or something odd like Oz, to really beat. You can make better, more accurate abstractions in C++ than in other mainstream languages, and they're safe and solid, while in languages like C# you often end up having to resort to unsafe conversions.
        13y ago
- gcr 13y ago
  I don't understand your point. C++ does not have the ability to manipulate syntax trees as data the way Lisp does, for example, making it strictly less "powerful" in terms of abstraction. (Templates, though turing complete, aren't what I mean here)
  - SamReidHughes 13y ago
    Lisp isn't a mainstream language. Edit: Also, I don't know much about Lisp, despite being a bit of a Scheme weenie in the past. When I try to think about whether I'd like to implement some hypothetical project in Lisp or C++, the most important difference between them seems to be garbage collection. It's more realistic to ask whether I'd rather use Lisp vs. Java, or Lisp vs. Scala, or Lisp vs. C# or Python or Ruby, than C++, because garbage collection is a big issue that makes it difficult to compare them by some notion of how it would feel to use the languages. I have a hard time evaluating whether macros are really that useful. Whenever I see people give examples of using macros, usually it's just superfluous, something that could be done a bit more verbosely without macros in a language like Python or Ruby, or done a bit superiorly in something like Haskell. And if it were a situation where macros were very useful, all I can think then is (now let's pull some anti-macro tropes out of the hat!) how debuggable is this? And would it really be that hard to solve the same problem in one of the other languages?
  - mihai_ionic 13y ago
    Have you looked at Boost.Proto? You can in principle manipulate syntax trees in any way you like, but you'll have to spice things up a little to fit with operator overloading.

SamReidHughes 13y ago

That's a weird thing to say, because C++ has better high-level abstraction facilities than any other mainstream language today.

betterunix 13y ago
Better than C#? Better than Python? I think your definition of "mainstream" might be a little narrow, or else you have a very odd understanding of what makes a good high-level abstraction. Also, why limit ourselves to "mainstream" languages? Once upon a time C++ was not mainstream. Why should we shy away from Lisp, OCaml, or Haskell just because they are not popular? In every discussion about C++ and its technical ups and downs, someone points to its popularity, as if that were some kind of justification. The history of computers is overrun with examples of popular-but-inferior technology.
- SamReidHughes 13y ago
  Yes, better than C#, and waaay better than Python. Similar to but slightly better than Haskell, too. I don't know about OCaml. (edit: C++'s main deficiency against C# and Python is its lack of a reflection system. Against Haskell, C++ is well known for being similar, but templates in C++ are more flexible and less constraining than Haskell's type system features -- for example if you want to overload + you don't have to buy into the entire Num typeclass.)
  - betterunix 13y ago
    I would say that the lack of a standard garbage collector ("smart" pointers do not count since programmers must manually break cycles and decide among smart pointer types) is a pretty serious deficiency. I would also point to the abysmal error-handling support in C++; you do not even get a reliable way to report errors that occur in destructors. Really though, my big issue with C++ is that the high-level features are bogged down by low-level details -- if I wanted to deal with low-level details I would not be using high-level features in the first place. Why should I have to manually determine how to capture variables in a lexical closure? Why should I have to manually declare "virtual" inheritance to deal with the multiple inheritance diamond? Why are destructors not virtual by default? Why are string literals still pointers to character arrays, why are arrays still not bounds-checked, why are integers still fixed-width (and why are integer overflows not reported as errors?)? Yes, these things all make sense sometimes but in most cases they are the opposite of what you want -- you should have to write more code to get this behavior than to avoid it.
    - SamReidHughes 13y ago
      Well, I agree with your complaints about the annoyance of lacking garbage collection, but not everything you complain about. The only nit I really disagree with you on in this post is that it's certainly reasonable that you should have to manually determine how to capture variables in a closure, in C++, because of the nature of the language. Also, many other languages avoid the multiple inheritance diamond simply by not allowing multiple inheritance (and others do it a bit better). The other questions, you know the answer to, and the answer is very obviously performance or compatibility with C (or just bugs in the language). But I'm not claiming that C++ is less annoying to use. I'm saying it has better facilities for making high-level abstractions. That's because of its type system, and you have to go to something like Scala, Haskell, or other statically typed languages, or maybe something homoiconic like Lisp, or something odd like Oz, to really beat. You can make better, more accurate abstractions in C++ than in other mainstream languages, and they're safe and solid, while in languages like C# you often end up having to resort to unsafe conversions.
      - 13y ago
gcr 13y ago
I don't understand your point. C++ does not have the ability to manipulate syntax trees as data the way Lisp does, for example, making it strictly less "powerful" in terms of abstraction. (Templates, though turing complete, aren't what I mean here)
- SamReidHughes 13y ago
  Lisp isn't a mainstream language. Edit: Also, I don't know much about Lisp, despite being a bit of a Scheme weenie in the past. When I try to think about whether I'd like to implement some hypothetical project in Lisp or C++, the most important difference between them seems to be garbage collection. It's more realistic to ask whether I'd rather use Lisp vs. Java, or Lisp vs. Scala, or Lisp vs. C# or Python or Ruby, than C++, because garbage collection is a big issue that makes it difficult to compare them by some notion of how it would feel to use the languages. I have a hard time evaluating whether macros are really that useful. Whenever I see people give examples of using macros, usually it's just superfluous, something that could be done a bit more verbosely without macros in a language like Python or Ruby, or done a bit superiorly in something like Haskell. And if it were a situation where macros were very useful, all I can think then is (now let's pull some anti-macro tropes out of the hat!) how debuggable is this? And would it really be that hard to solve the same problem in one of the other languages?
- mihai_ionic 13y ago
  Have you looked at Boost.Proto? You can in principle manipulate syntax trees in any way you like, but you'll have to spice things up a little to fit with operator overloading.