6 ms·

If x - (fast_dev_time + ease_of_learning + common_runtime + managed_GC + easy_of_understanding) = kicks_ass, then what's x? In other words, what redeems C++? W

If x - (fast_dev_time + ease_of_learning + common_runtime + managed_GC + easy_of_understanding) = kicks_ass, then what's x? In other words, what redeems C++? What's the point of the language?

kingkongrevenge 17y ago
> What's the point of the language? It's a drop-in replacement for C that is much more powerful and succinct.
- halostatue 17y ago
  That's the theory. The reality is that it's not more succinct and it's not significantly more powerful in most cases. Yes, there are some neat things you can do with templates (and I do), and some of the syntactic sugar things you get with objects and overloading and namespaces are nice, but there's nothing that you can do in C++ that you can't do equally well in C. That said, C++ is in no way a "drop-in replacement" for C. What makes C++ "interesting" is that most of the time, you can drop C code into a C++ program and it will just work. Of course, you can do the same thing with Objective C, and the object model behind Objective C is much more sane.
  - kingkongrevenge 17y ago
    > but there's nothing that you can do in C++ that you can't do equally well in C. I'm shocked you're saying this in seriousness. C is a simple language lacking a large number of constructs and compiler safety features of C++. You might as well argue that BASIC is just as powerful as Python. Inherently OOP problems like large simulations with huge class hierarchies could not realistically be done in C. The C++ frameworks for writing servers have no parallel in C because the language lacks required abstractions. I have never seen C code that could not be rewritten more clearly in C++.
    - deleted 17y ago
      [deleted]
    - halostatue 17y ago
      IMO, C++ offers no useful compiler safety features. One of the most celebrated "safety features" is const correctness. That's caused more pain in my experience than any possible value that it supports (and it has also resulted in a lot of unnecessary duplicated boilerplate code). Templates, while useful and (sometimes) fun (as long as you're not having to debug them), aren't as interesting as having a real dynamic language like Python or Ruby. I'd argue that your statement about "Inherently OOP problems" is incorrect from the first word. IMO, there's no such thing as a problem that's "inherently OOP"; there are problems which may be modeled easier in OO, but there's no problem that OOP solves that can't be solved a different way. (Why does a large simulation require a huge class hierarchy in any case? Maybe you're just Doing It Wrong.) There's also an assumption that C can't do OO, which is patently false; it's just not sugared for you like in C++. I'd love to see what "required abstractions" you think that C++ provides, because I just simply don't see them. Except maybe namespaces. Overloading is nice, but not a necessary condition. References are just a mess. Templates are overkill for a lot of things. RTTI in C++ is a joke, especially if you're working cross-platform (and dynamic_cast on older versions of g++ just don't work, and sometimes you just can't escape those older versions). All that said, I write C++ in my day job. A lot of it. But I don't pretend that anything I'm doing in C++ couldn't be done in C, possibly better and cleaner. We're designing a new set of APIs for plug-ins in our product, and we're moving toward a clean set of C-based APIs because they're (a) more portable across platforms and (b) more portable across languages so that we don't force people who want to write plug-ins for our product to use C++.
mojuba 17y ago
C and C++ (and a couple of other languages like Delphi) provide naked, unprotected pointers, which implies almost full control over memory and the CPU that no higher-level language can give. With pointers you are closer to hardware, in other words. On top of that, C++ has damn powerful meta-language facilities no other language of any level has, which are, however, beneficial only when in good hands. It's too easy to misuse C++ unfortunately.
- Hexstream 17y ago
  I agree with your first point. However, I'll have to very strongly disagree with "C++ has damn powerful meta-language facilities no other language of any level has". C++ actually has terrible support for meta-language facilities. It is inconceivable in my mind that C++'s support for that is anywhere near something like Common Lisp, so forget about it being the best in that respect. I'd love to know what parts of C++ are great meta-language facilities. If you say C++ macros I'll have to laugh. Hard. </smuglispweenie>
  - william-newman 17y ago
    Stepanov (i.e., Mr. C++ Standard Template Library) has said some comparably strong things about the expressiveness of C++ templates for the kinds of things expressed in STL, and he doesn't seem to be guilty of not investigating Lispy alternatives. e.g., http://www.antiquark.com/escape/public_html/stepanovusa.html http://www.antiquark.com/escape/public_html/stepanovusa.html There are various gnarly problems with C++'s model, some of which show up as gnarly problems in STL, even in fundamental stuff like implementing collections of refcounting pointers last time I looked. But as far as I can tell, every language which tries to get this correct within the language has some serious limitations or issues, arguably at least as bad, especially if like Stepanov one of your top priorities is eliminating every last bit of runtime overhead in the generated code. (E.g., implementing arrays of objects only as arrays of fixed-size pointers into variable-sized objects on the heap, as in typical CL and Java, is a no-go given STL priorities, and thus STL constantly wrestles with a bunch of problems that lots of other implementors have dodged by giving up on them.) As far as I know, no one has a comprehensively satisfactory solution for metalanguage facilities within the language. Getting metalanguage correct by stepping outside the language and upstream from the compiler, writing a separate program to generate the target program, has been a solved problem as long as we've known how to write compilers in Turing-complete languages. That approach is sometimes used for app code in conventional languages, as in FFTW, and to some extent it's what Lispy macros do. But for some applications, including STL as I understand it, stepping upstream is unsatisfactory. Sometimes what you'd really like to do is have your code generator query the compiler about what the compiler knows. STL in particular, IIRC, wants to have its code generation depend on what the compiler knows about types and typedefs and so forth. In an ideal world it would be routine for code generators to be able to ask the compiler about other things, too, like dead code, namespaces, and safety and other pragmas.
DanielBMarkham 17y ago
I love advanced math. But 99% of my life can be managed just fine with addition, subtraction, multiplication, and division. It's that other 1%, though, where more advanced math kicks ass. If you've never seen it or watch it happen it's hard to describe how cool it is. With C++ you're controlling the CPU at a level just above machine language. I love advanced math, but I rarely ever use it. Advanced math kicks ass.
frig 17y ago
The redeeming quality of C++ is that there's nothing better in its specific niches. The question to ask is: - do you just care about results: I need a program that produces these outputs when given these inputs - or do you care about what actually happens: I want the computer to do this, then this, then this, in exactly this way please. ...? It's usually a good idea only to care about the former -- the essence of functional programming, higher-order functions, etc., is to be able to focus on the former as much as possible -- and so long as you only care about the former C++ doesn't have much to recommend it except in special circumstances. On the other hand, there are times when what happens, exactly is important (eg: device drivers, other low-level code, directly interacting with hardware, etc.). In that scenario what C++ offers is a language that standardizes a lot of the functionality that most sufficiently-large raw-C programs have implemented in an ad-hoc basis. There are other ways of doing low-level code, but at the present time C++ is the best of bunch (or at least the safest choice if you have an eye to the long term), not so much b/c it's particularly awesome but b/c the others have either faded away for business or political reasons, or b/c the others made limiting choices (C++ makes very few decisions for you, which means it's equally suited -- or unsuited -- to every task in its particularly niche).
- rmaccloy 17y ago
  I don't have a dog in this fight, but a major thesis of the article is that this is effectively not true for C++ (vs C) because the language is so complicated (thus the implementations so inconsistent/subtly incorrect) that it's incredibly difficult to determine exactly what the compiler is going to do with your input (or conversely, determine what in your input caused a given error in your object code.)
william-newman 17y ago
It is seldom a good idea, or even sane, to choose to machine something out of titanium (or beryllium). But sometimes there are reasons. I think C++ does a decent job of being as logically expressive as practical while still supporting C-level memory micromanagement. Typically exposing C-level memory micromanagement issues is a bug, but occasionally it's a feature. So to me, the point of C++ is to express abstractions like polymorphism and exceptions in the same few pages of code as low level memory operations. How often do I want to do that? Not very often, but it can happen. Also, while C++ is very hairy and I wouldn't want to have to implement it, C++ seems to be implementable enough and standard enough that it may be usefully supported on a platform well before other more expressive languages. Perhaps it's because a lot of the C++ hair is frontend target-independent stuff like parsing and templates, so that once you've ported the C backend you're almost done porting C++ too? Dunno for sure why, but it seems to happen: e.g., it was my impression on my Atari ST many many years ago, and is my casual impression that something similar happened for the Arduino more recently. C++ is admittedly a weird mess in various ways, but given the choice of source almost-compatibility with C (which I don't particularly value, but which I can at least understand) and C-level linkers (which I have mixed feelings about) a mess seems inevitable. Thus, I still consider it an impressive design. Occsionally I've seen IMO-excessively broad claims that higher level languages are the best. It sometimes makes me think I might be able to cook up an example where C++ would be hard to beat: a small backtracking search problem where trailing operations (in the sense of "trailing" that you'll see if you Google "trailing backtracking") are in the inner loop. Take this thought of mine with a generous amount of salt, because I've never boiled it down to a really clean challenge. OTOH, I have at least implemented such search in several languages, and I even did a few casual benchmarks --- but 10+ years ago, when performance tradeoffs were rather different. That's a particular case of a general theme where C-level programming could win: performance dominated by a very simple memory allocation regularity (LIFO, in this case) that the GC doesn't know about. (This theme also involves the precondition that you should care more about a factor of 2 in performance than a factor of 2 in programmer time, which often doesn't hold.) In many instances of this theme, the accreted featuritis bloat of C++ would be overkill, so you'd prefer C. In this instance, though, placement new() of polymorphic objects into LIFO-allocated raw memory is more expressive than anything I can see how to do in C. Now, we should not forget that many programmers can go all year without running into a single problem where a factor of 2 in performance is worth a factor of 2 in programmer time. And we should not forget that even the ones who need to care deeply about performance often find it's not determined by a few low-level hotspots where low-level tweaking helps. But in some subfields, it's not too unusual to rationally choose to micromanage stuff at the level of C/C++. (I nominate the subfields of embedded programming and compute-heavy search from personal experience, and Quake/Unreal-like engine programming by reputation; I also explicitly do not nominate implementing web browsers, ow ow ow.) It's harder to think of reasons I'd choose to write sizable programs in C++ (other than the compelling but unsatisfying accidental-seeming reason of early availability on a platform). One reason, though, is that there are many subproblems for which the choice of language doesn't matter all that much. E.g., Fortran is adequately expressive for a lot of the stuff in a book like _Numerical Recipes_, and you can famously write Fortran in (almost) any language. Because of this, I sometimes encounter a program where some key subproblem really cries for a particular style of language, possibly C++, and then I can be language-agnostic about solving the other subproblems, not minding writing it in whatever language I chose for the key part.

If x - (fast_dev_time + ease_of_learning + common_runtime + managed_GC + easy_of_understanding) = kicks_ass, then what's x? In other words, what redeems C++? What's the point of the language?

kingkongrevenge 17y ago

> What's the point of the language? It's a drop-in replacement for C that is much more powerful and succinct.

halostatue 17y ago
That's the theory. The reality is that it's not more succinct and it's not significantly more powerful in most cases. Yes, there are some neat things you can do with templates (and I do), and some of the syntactic sugar things you get with objects and overloading and namespaces are nice, but there's nothing that you can do in C++ that you can't do equally well in C. That said, C++ is in no way a "drop-in replacement" for C. What makes C++ "interesting" is that most of the time, you can drop C code into a C++ program and it will just work. Of course, you can do the same thing with Objective C, and the object model behind Objective C is much more sane.
- kingkongrevenge 17y ago
  > but there's nothing that you can do in C++ that you can't do equally well in C. I'm shocked you're saying this in seriousness. C is a simple language lacking a large number of constructs and compiler safety features of C++. You might as well argue that BASIC is just as powerful as Python. Inherently OOP problems like large simulations with huge class hierarchies could not realistically be done in C. The C++ frameworks for writing servers have no parallel in C because the language lacks required abstractions. I have never seen C code that could not be rewritten more clearly in C++.
  - deleted 17y ago
    [deleted]
  - halostatue 17y ago
    IMO, C++ offers no useful compiler safety features. One of the most celebrated "safety features" is const correctness. That's caused more pain in my experience than any possible value that it supports (and it has also resulted in a lot of unnecessary duplicated boilerplate code). Templates, while useful and (sometimes) fun (as long as you're not having to debug them), aren't as interesting as having a real dynamic language like Python or Ruby. I'd argue that your statement about "Inherently OOP problems" is incorrect from the first word. IMO, there's no such thing as a problem that's "inherently OOP"; there are problems which may be modeled easier in OO, but there's no problem that OOP solves that can't be solved a different way. (Why does a large simulation require a huge class hierarchy in any case? Maybe you're just Doing It Wrong.) There's also an assumption that C can't do OO, which is patently false; it's just not sugared for you like in C++. I'd love to see what "required abstractions" you think that C++ provides, because I just simply don't see them. Except maybe namespaces. Overloading is nice, but not a necessary condition. References are just a mess. Templates are overkill for a lot of things. RTTI in C++ is a joke, especially if you're working cross-platform (and dynamic_cast on older versions of g++ just don't work, and sometimes you just can't escape those older versions). All that said, I write C++ in my day job. A lot of it. But I don't pretend that anything I'm doing in C++ couldn't be done in C, possibly better and cleaner. We're designing a new set of APIs for plug-ins in our product, and we're moving toward a clean set of C-based APIs because they're (a) more portable across platforms and (b) more portable across languages so that we don't force people who want to write plug-ins for our product to use C++.

mojuba 17y ago

C and C++ (and a couple of other languages like Delphi) provide naked, unprotected pointers, which implies almost full control over memory and the CPU that no higher-level language can give. With pointers you are closer to hardware, in other words. On top of that, C++ has damn powerful meta-language facilities no other language of any level has, which are, however, beneficial only when in good hands. It's too easy to misuse C++ unfortunately.

Hexstream 17y ago
I agree with your first point. However, I'll have to very strongly disagree with "C++ has damn powerful meta-language facilities no other language of any level has". C++ actually has terrible support for meta-language facilities. It is inconceivable in my mind that C++'s support for that is anywhere near something like Common Lisp, so forget about it being the best in that respect. I'd love to know what parts of C++ are great meta-language facilities. If you say C++ macros I'll have to laugh. Hard. </smuglispweenie>
- william-newman 17y ago
  Stepanov (i.e., Mr. C++ Standard Template Library) has said some comparably strong things about the expressiveness of C++ templates for the kinds of things expressed in STL, and he doesn't seem to be guilty of not investigating Lispy alternatives. e.g., http://www.antiquark.com/escape/public_html/stepanovusa.html http://www.antiquark.com/escape/public_html/stepanovusa.html There are various gnarly problems with C++'s model, some of which show up as gnarly problems in STL, even in fundamental stuff like implementing collections of refcounting pointers last time I looked. But as far as I can tell, every language which tries to get this correct within the language has some serious limitations or issues, arguably at least as bad, especially if like Stepanov one of your top priorities is eliminating every last bit of runtime overhead in the generated code. (E.g., implementing arrays of objects only as arrays of fixed-size pointers into variable-sized objects on the heap, as in typical CL and Java, is a no-go given STL priorities, and thus STL constantly wrestles with a bunch of problems that lots of other implementors have dodged by giving up on them.) As far as I know, no one has a comprehensively satisfactory solution for metalanguage facilities within the language. Getting metalanguage correct by stepping outside the language and upstream from the compiler, writing a separate program to generate the target program, has been a solved problem as long as we've known how to write compilers in Turing-complete languages. That approach is sometimes used for app code in conventional languages, as in FFTW, and to some extent it's what Lispy macros do. But for some applications, including STL as I understand it, stepping upstream is unsatisfactory. Sometimes what you'd really like to do is have your code generator query the compiler about what the compiler knows. STL in particular, IIRC, wants to have its code generation depend on what the compiler knows about types and typedefs and so forth. In an ideal world it would be routine for code generators to be able to ask the compiler about other things, too, like dead code, namespaces, and safety and other pragmas.

DanielBMarkham 17y ago

I love advanced math. But 99% of my life can be managed just fine with addition, subtraction, multiplication, and division. It's that other 1%, though, where more advanced math kicks ass. If you've never seen it or watch it happen it's hard to describe how cool it is. With C++ you're controlling the CPU at a level just above machine language. I love advanced math, but I rarely ever use it. Advanced math kicks ass.

frig 17y ago

The redeeming quality of C++ is that there's nothing better in its specific niches. The question to ask is: - do you just care about results: I need a program that produces these outputs when given these inputs - or do you care about what actually happens: I want the computer to do this, then this, then this, in exactly this way please. ...? It's usually a good idea only to care about the former -- the essence of functional programming, higher-order functions, etc., is to be able to focus on the former as much as possible -- and so long as you only care about the former C++ doesn't have much to recommend it except in special circumstances. On the other hand, there are times when what happens, exactly is important (eg: device drivers, other low-level code, directly interacting with hardware, etc.). In that scenario what C++ offers is a language that standardizes a lot of the functionality that most sufficiently-large raw-C programs have implemented in an ad-hoc basis. There are other ways of doing low-level code, but at the present time C++ is the best of bunch (or at least the safest choice if you have an eye to the long term), not so much b/c it's particularly awesome but b/c the others have either faded away for business or political reasons, or b/c the others made limiting choices (C++ makes very few decisions for you, which means it's equally suited -- or unsuited -- to every task in its particularly niche).

rmaccloy 17y ago
I don't have a dog in this fight, but a major thesis of the article is that this is effectively not true for C++ (vs C) because the language is so complicated (thus the implementations so inconsistent/subtly incorrect) that it's incredibly difficult to determine exactly what the compiler is going to do with your input (or conversely, determine what in your input caused a given error in your object code.)

william-newman 17y ago

It is seldom a good idea, or even sane, to choose to machine something out of titanium (or beryllium). But sometimes there are reasons. I think C++ does a decent job of being as logically expressive as practical while still supporting C-level memory micromanagement. Typically exposing C-level memory micromanagement issues is a bug, but occasionally it's a feature. So to me, the point of C++ is to express abstractions like polymorphism and exceptions in the same few pages of code as low level memory operations. How often do I want to do that? Not very often, but it can happen. Also, while C++ is very hairy and I wouldn't want to have to implement it, C++ seems to be implementable enough and standard enough that it may be usefully supported on a platform well before other more expressive languages. Perhaps it's because a lot of the C++ hair is frontend target-independent stuff like parsing and templates, so that once you've ported the C backend you're almost done porting C++ too? Dunno for sure why, but it seems to happen: e.g., it was my impression on my Atari ST many many years ago, and is my casual impression that something similar happened for the Arduino more recently. C++ is admittedly a weird mess in various ways, but given the choice of source almost-compatibility with C (which I don't particularly value, but which I can at least understand) and C-level linkers (which I have mixed feelings about) a mess seems inevitable. Thus, I still consider it an impressive design. Occsionally I've seen IMO-excessively broad claims that higher level languages are the best. It sometimes makes me think I might be able to cook up an example where C++ would be hard to beat: a small backtracking search problem where trailing operations (in the sense of "trailing" that you'll see if you Google "trailing backtracking") are in the inner loop. Take this thought of mine with a generous amount of salt, because I've never boiled it down to a really clean challenge. OTOH, I have at least implemented such search in several languages, and I even did a few casual benchmarks --- but 10+ years ago, when performance tradeoffs were rather different. That's a particular case of a general theme where C-level programming could win: performance dominated by a very simple memory allocation regularity (LIFO, in this case) that the GC doesn't know about. (This theme also involves the precondition that you should care more about a factor of 2 in performance than a factor of 2 in programmer time, which often doesn't hold.) In many instances of this theme, the accreted featuritis bloat of C++ would be overkill, so you'd prefer C. In this instance, though, placement new() of polymorphic objects into LIFO-allocated raw memory is more expressive than anything I can see how to do in C. Now, we should not forget that many programmers can go all year without running into a single problem where a factor of 2 in performance is worth a factor of 2 in programmer time. And we should not forget that even the ones who need to care deeply about performance often find it's not determined by a few low-level hotspots where low-level tweaking helps. But in some subfields, it's not too unusual to rationally choose to micromanage stuff at the level of C/C++. (I nominate the subfields of embedded programming and compute-heavy search from personal experience, and Quake/Unreal-like engine programming by reputation; I also explicitly do not nominate implementing web browsers, ow ow ow.) It's harder to think of reasons I'd choose to write sizable programs in C++ (other than the compelling but unsatisfying accidental-seeming reason of early availability on a platform). One reason, though, is that there are many subproblems for which the choice of language doesn't matter all that much. E.g., Fortran is adequately expressive for a lot of the stuff in a book like _Numerical Recipes_, and you can famously write Fortran in (almost) any language. Because of this, I sometimes encounter a program where some key subproblem really cries for a particular style of language, possibly C++, and then I can be language-agnostic about solving the other subproblems, not minding writing it in whatever language I chose for the key part.