10 ms·

C++ is a hack

49 points by rootlocus 11y ago

dman 11y ago
C is a hack. x86 is a hack. Unix is a hack. Windows is a hack. Products with a "do what it takes" attitude appear to outrun projects driven by purism in the short to medium term. Often its too late for a better designed product to overcome the early traction lead of such projects. Richard Gabriel has captured many related issues in a series of essays with far greater eloquence than I am capable of - https://www.dreamsongs.com/WorseIsBetter.html https://www.dreamsongs.com/WorseIsBetter.html
rusabd 11y ago
There is much larger and older list: http://yosefk.com/c++fqa/ http://yosefk.com/c++fqa/
giancarlostoro 11y ago
It is indeed an attempt to extend C while maintaining backwards compatibility, which can be a bit of a mess on it's own. This is probably one of the main reasons that spawned D's creation, a language that does what C++ "should have" done and breaks backwards compatibility while still maintaining the 'power' of C++. I guess calling it a hack is acceptable, at least to me, maybe not to C++ developers though who feel it is more than just a hack. Edit: Grammar correction.
- ATsch 11y ago
  I feel like I have some kind of obligation to correct you on the common error of "should of" instead of "should have" or "should've" http://www.elearnenglishlanguage.com/blog/english-mistakes/should-have-vs-should-of/ http://www.elearnenglishlanguage.com/blog/english-mistakes/s...
  - giancarlostoro 11y ago
    Thank you, I appreciate the link even more. This is my second language, and I appreciate any opportunity to improve my writing, even though it is my second language I've learned it is still my main language I use.
lallysingh 11y ago
Some of these aren't quite true anymore. There's a C++ x64 ABI, for example. Still, it's all a big mess.
- angelbob 11y ago
  Did they finally get templates shoehorned into it? That's been the giant, glaring flaw in all the previous ABI attempts I've seen. Well, that and getting multiple compilers to use the same name-mangling standards.
kazinator 11y ago
Misguided right off the bat: > Not only does C++ have no notion of interfaces, it actually allows subclasses to hide public methods from the superclass. C++ doesn't have "methods"; it has member functions (static or nonstatic). Nonstatic ones can be virtual. Virtual member functions are what corresponds to OOP methods. To use virtual functions as methods, you call them through a base class pointer or reference to an object. That's when you're doing OOP dispatch. Now a derived class in C++ can define member functions of the same names as a base. These functions lexically shadow the ones in the base. If you use derived objects as their actual derived type (not through a base reference), then you're using those functions. This is "statically clear" in a static language, and it makes sense. If I open up "program.cpp" in my text editor and edit some function so that a "Foo f" object is replaced by a "DerivedFoo f", then I want all occurrences of f.func() to now be calling DerivedFoo::f rather than Foo::f, if DerivedFoo::f exists. I don't want the compiler to complain that the situation is ambiguous, and I don't want it to keep calling Foo::f, which is nonsensical. Lastly, access is orthogonal to visibility in C++; it is not accurate to say things like "allows subclasses to hide public methods". Identifiers declared in the derived class scope simply shadow like-named definitions in base classes, period. That is regardless of access. Access specifiers do not alter visibility (or any program semantics). If you manipulate the access specifiers in a C++ program, at best you can make some diagnostic go away, or introduce the need for one. All permutations of access specifiers which don't require a diagnostic will behave the same way (and should produce identical code, really). > One of the increment operators takes a dummy int parameter in order to allow overloading. Can you tell which without googling? Yes, I can tell without googling as can any reasonably competent C++ programmer. Why would you need to answer the question in this form? The feature is there for when the situation arises that you're writing an overloaded ++ operator and would like it to be postfix. If you don't care about overloading ++ or making it postfix, you don't have to be aware that there is an int hack for this. > Without adding another layer of indirection via the PIMPL idiom, changes to the internal structure of the class propagate to all it's users, making compilation painfully / unecessary slow. The class declaration being fully visible to all places which use it allows C++ to be efficient in its handling of data types. For instance, when you have a local variable "FooClass x", the compiler knows exactly how large x is down to the byte and can give it a fixed-size place in a fixed-size stack frame. It also allows for inline functions which compile to code that accesses the object directly. This low-level nature is a conscious design trade off in C++, which makes it what it is. If you want to eliminate the dependencies, you use that PIMPL idiom explicitly. In some higher level languages, the equivalent of PIMPL is implicit everywhere. (For instance, everything is a "heap object"). C++ is one language you can reach for in situations when you don't want everything to be a heap object, yet still have some halfway useful abstractions. > C++ did not have any standard multithreading implementation until C++ 11. That was five years ago. C++ users did threading in C++ code for at least twenty years before that, in platform-specific ways, or using cross platform frameworks like ACE. Because C++ doesn't hide a lot of behaviors under the hood, you can let platform threads loose directly into C++ code and the effects are predictable and manageable, for the most part, modulo issues like "does unwinding happen if the thread dies" and such. > The C++ compilator was originally a preprocessor for C (CFront), and still maintains binary compatibility with C. This point is also inaccurate. C++ has to live in a world with linkers and object file formats which do not support type information on a symbol. That is why name mangling is required. If you want three flavors of a function called foo, with separate external linkage (rather than, say, some internal runt-time dispatch behind a single function) then you need three separate entries in the symbol table. In most object file formats, that means you need three different symbol names. It has nothing to do with C++ originally having been preprocessed, or compatibility with C. C itself is simply compatible with assembly language linkage models. (And so C has failed to promote any improvements in object file formats and linkers, by imposing no special requirements.) Some other languages have to do name mangling in their implementations, to some extent. I used a Modula-2 compiler in the late 1980's which used a "module$ident" scheme in the object file format. That is to say, function foo in module bar was turned into the symbol "bar$foo" with a dollar sign.
vvanders 11y ago
Maybe, but a very useful hack.
evmar 11y ago
"There are only two kinds of languages: the ones people complain about and the ones nobody uses." - Bjarne Stroustrup
- jokoon 11y ago
  I wish D will be popular in the future. Breaking compatibility with C isn't such a bad thing. Also I think C, C++ and D are easily made compatible with each other (I would not bet on that too much though).
  - douche 11y ago
    I've been hearing about D for at least ten years. I don't think it's going to really break out at this point - it's been sort of lapped in the trendy, new language corner by Go and Rust and whatnot.
    - kedean 11y ago
      Worse, it's been lapped into the 'who cares' corner. D had a burst of buzz for a while, about 10 years ago, but at the time nobody really wanted alternative systems languages. IT got a little support, but mostly people ignored it. Now, you have Go/Rust/Nim jumping into the space and getting lots of Buzz, but if D is mentioned then one of two things will happen: A) "Oh yeah, that language from the mid 2000s. I didn't want to use it then, why would I use it now?" B) "D? Oh it's from the mid 2000's? I wonder why nobody used it? It probably sucks." Even if those statements are false, it's hit the same problem that a 50-year old programmer in the job market is going to hit, age discrimination.
- stinos 11y ago
  Basically, this! Most of the OP's points are valid, no denying that. But, looking at the myriads of properly working, fast, not 'exploding in your face at runtime', often even beautiful code produced in C++ despite these shortcomings: doesn't really seem like a poblem if one knows how to deal with it.
  - 11y ago
amelius 11y ago
CSS is a hack too. [1] [1] https://wiki.csswg.org/ideas/mistakes https://wiki.csswg.org/ideas/mistakes
- brink 11y ago
  Yea, but anyone good enough at CSS already knows that.
- nommm-nommm 11y ago
  Yeah, but nobody likes CSS or thinks its well designed.
  - pcwalton 11y ago
    I think CSS is overall well designed, though with plenty of flaws. It's remarkable, though, that everyone agrees that it's bad, but every proposed replacement I've seen has been significantly worse. Those mistakes are legitimate complaints. But it's interesting that most of the complaints about CSS do not fall under that list.
  - jryan49 11y ago
    Neither do people who use C++ :)
- amelius 11y ago
  And, unfortunately, Javascript is a hack too: > var m = {}; > m["__alpha__"] = 10; > m["__bravo__"] = 20; > m["__proto__"] = 30; > for(var key in m) { console.log(key); } __alpha__ __bravo__
aback 11y ago
All third-generation programming languages (and higher) are leaky abstractions. Why is C++ worse than others?
deleted 11y ago
[deleted]
thinkpad20 11y ago
Isn't name mangling a standard thing done by just about every language except for C that compiles to object code? The lack of standardization between compilers sounds potentially problematic, but name mangling itself doesn't seem like a bad thing. The alternative is to force the programmer to do their own "name mangling" a la C.
- JoeAltmaier 11y ago
  Name mangling is a sad old way of using antiquated object formats while moving forward with a language. Better solutions are obvious - a new object format that stores constraints/annotations/scope info would be a good one.
usefulcat 11y ago
"[C++] actually allows subclasses to hide public methods from the superclass." That one doesn't even make sense. A base class (superclass) in C++ never knows anything about any of its descendants. So it can only ever know about methods declared in the base class, and what their visibility is in the base class. Secondly, it's true that a derived class could (for example) override a public base class method and make it private in the derived class, but that won't change the ability of the base class to call that method.
- nikbackm 11y ago
  It's a bit like an explicit interface implementation in C#.
- rootlocus 11y ago
  The base class is not the only client of that method.
  - usefulcat 11y ago
    True, but it specifically says "hide public methods from the superclass".
    - softawre 11y ago
      Oh, I get it. I think s/from/of is what was meant.
- slavik81 11y ago
  You misunderstood. When the author wrote "from the superclass" they were trying to say "declared on the superclass". It has since been updated to be clearer.
- lfowles 11y ago
  I actually tested this one since I had never encountered it in the wild. You can indeed call and get the expected results from the derived classes (now private) member function.
exelius 11y ago
Ok -- but I don't think anyone legitimately holds on to C++ as an example of a great, well-designed language. C++ has existed for a long time, and the corporate world has increasingly moved away from C++ because it doesn't offer enough object-oriented goodness while tying you down to a certain memory management style with a difficult to use typing/inheritance system. Pick any modern OO language: Java, Ruby, Swift, hell, even Python. They are all far easier languages to write in than C++, have much better library support, and don't make you dive into memory management hell. IMO C++ is syntactically very difficult, and the language too far out of touch with the architecture patterns and styles used by programmers today.
- LanguageGamer 11y ago
  C++ is a mess, but Java, Ruby, Swift and Python aren't viable options if your software is performance sensitive.
  - austinsharp 11y ago
    Java is pretty viable if you are performance sensitive but not HFT or video game performance sensitive. It's certainly far ahead of Ruby and Python, at least. It's not as fast as C++, but C++ isn't as fast as assembly, either. They're at different points on the tradeoff curve - HOW performance sensitive are you? It's not a binary choice.
    - pkolaczk 11y ago
      There are companies using Java for HFT now as well.
      - rootlocus 11y ago
        I'm actually working for such a company. Peter Lawrey is a renowned advocate for efficient use of java in HFT.
    - exelius 11y ago
      Java is totally viable for nearly anything; it just doesn't work well for games because they require low-level access to graphics hardware (which is definitely not something Java supports). Also, the state of the JVM on the desktop is kind of sad - also from the graphics perspective. But Java is probably the most performant server-side language out there at this point (if you exempt the masochists who write network code in C/C++).
athenot 11y ago
C++ is a multi-paradigm language. Of course that is going to be messy. There are domains of applicability where you want everyone to use the same model, the same patterns, the same paradigms. That yields true benefits for some teams. But there are other areas where you really want to have a Big Bag Of Tricks to get things done, because they are areas where efficiency or fine-grained control are required or it just plain makes sense. I should note that most successful C++ projects I've come across seem to only use a subset of what that Big Bag O' Tricks provides. Yet in some corners, if need be, some specialized trick can be used because it makes sense there. And it ends up being much less of a hack than if it had to be done in the mono-paradigm language.
- lfowles 11y ago
  I appreciate it being multi-paradigm as well. There are 3-4 languages in there with _great_ interoperability. As well as the ability to pull in a C library to a project with little fuss.
meirelles 11y ago
It's a great language showing aging signs. Most languages become obsolete before becoming old.
- angelbob 11y ago
  I learned C++ around 1990. It was a hack then, too. It began life as a weird preprocessor for C, and some of the seams from that beginning have shown the entire time.
ansible 11y ago
My team is about to embark upon a C++ project. The compiler will be gcc 4.8.x, and supports C++11. So I've bought Stroustrup's "C++ Programming language 4th Edition", and Scott Meyer's "Effective Modern C++". I've got some reading to do. What's the state of tools related to encouraging / enforcing modern C++ style? Edit: grammar.
- jjuhl 11y ago
  You should check out clang-tidy: http://clang.llvm.org/extra/clang-tidy/ http://clang.llvm.org/extra/clang-tidy/ clang-format: http://clang.llvm.org/docs/ClangFormat.html http://clang.llvm.org/docs/ClangFormat.html C++ Core Guidelines: https://github.com/isocpp/CppCoreGuidelines https://github.com/isocpp/CppCoreGuidelines C++ Core Guidelines Checkers for VS 2015 Update 1: https://blogs.msdn.microsoft.com/vcblog/2015/12/03/c-core-guidelines-checkers-available-for-vs-2015-update-1/ https://blogs.msdn.microsoft.com/vcblog/2015/12/03/c-core-gu...
  - ansible 11y ago
    Awesome, thanks.
diegoperini 11y ago
"Why I think C++ is a hack" is a more appropriate title. The stated arguments have legit points though.
- rootlocus 11y ago
  I'm getting annoyed of being 'politically correct' on the internet all the time. The title is obviously a metaphor, and it doesn't need to be defensive. http://www.metafilter.com/156134/The-internet-has-made-defensive-writers-of-us-all http://www.metafilter.com/156134/The-internet-has-made-defen...
- sevensor 11y ago
  "It's a hack" is also an insufficient reason to avoid using C++, although I think it's both true and a useful thing to know before getting involved with C++.
  - rootlocus 11y ago
    What is or isn't sufficient is relative and context-sensitive. For me it might be. For triple A game studios definitely isn't.
  - austinsharp 11y ago
    The very nature of a hack is that someone needed it at some point. Even if C++ is a hack, that doesn't prohibit it from being the right answer in some situations.
autoreleasepool 11y ago
> 6. Multithreading: C++ did not have any standard multithreading implementation until C++ 11. How is expanding the standard library a hack?
pcwalton 11y ago
Many of these are legitimate, but a couple aren't: - "Dependency hell"—Yeah, it's annoying for sure. But what's the solution? You can't reasonably have value types and ABI stability in the presence of adding and removing fields from those value types: it's impossible. - "Name mangling"—The legitimate complaint here is that the name mangling schema is not standardized (though Itanium is a de facto standard in the open source world). But the fact that name mangling exists isn't something you can blame C++ for: it's really Unix that deserves the blame for not supporting namespaces in their object files.
- rootlocus 11y ago
  Object files are not standardized either (as far as C++ is concerned). Microsoft has it's own format. I can blame C++ for using a hack in order to keep using the same obj files as C.
georgehaake 11y ago
Well if hack is the polar opposite of elegant, then C++ is a hack indeed.
cubano 11y ago
I've been involved in this debate, professionally, for some 28 years now, and while I don't claim to have any deep or unique insights into it, I would like to state that I find almost amazing that it still rages at pretty much the same level as it did back in 1988. As I've mentioned before, my first professional gig was writing real-time games and business apps for the MajorBBS, a fabulous pre-WWW multi-line BBS, in C. Since the MajorBBS DevKit was shipped as C source and compiled as protected-mode DLLs (to of course overcome the 640k memory limit of DOS...yeah that was a thing at one time), there were several devs that wanted to use C++ "goodies" to help speed development or whatever. The debate started when Galacticomm, the makers of the MajorBBS flat-out refused to consider it and used many of the same rational as the OP listed as reasons why it was not going to ported. Reading over this list jogged many old memories, which is why I felt compelled to write this rather long-winded post. My local opinion? Use whatever gets the job done and can be maintained and supported at a reasonable cost long after you are gone.
pklausler 11y ago
I've used C++ for many major projects, and as a compiler writer, I understand the language at a high level. C++ requires an unprecedented degree of organizational discipline to use successfully. For most projects, in most organizations, it's a terrible technological choice -- bloated, inconsistent, dangerous, poorly understood, and still rapidly changing. The programming world needs a language with some of the features of C++ (strong typing, easy interoperation with C, polymorphism, destructors, and control of memory ownership). But it also needs a language that doesn't perpetuate every single language design flaw that has accumulated since the Nixon administration while dramatically changing in ways that alter "best practices" across revisions of the language standard and too frequently take steps backward in readability. And I disagree that C++ is "evolving". A process isn't really evolution unless old things are dying.

49 points by rootlocus 11y ago

dman 11y ago

C is a hack. x86 is a hack. Unix is a hack. Windows is a hack. Products with a "do what it takes" attitude appear to outrun projects driven by purism in the short to medium term. Often its too late for a better designed product to overcome the early traction lead of such projects. Richard Gabriel has captured many related issues in a series of essays with far greater eloquence than I am capable of - https://www.dreamsongs.com/WorseIsBetter.html https://www.dreamsongs.com/WorseIsBetter.html

rusabd 11y ago

There is much larger and older list: http://yosefk.com/c++fqa/ http://yosefk.com/c++fqa/

giancarlostoro 11y ago

It is indeed an attempt to extend C while maintaining backwards compatibility, which can be a bit of a mess on it's own. This is probably one of the main reasons that spawned D's creation, a language that does what C++ "should have" done and breaks backwards compatibility while still maintaining the 'power' of C++. I guess calling it a hack is acceptable, at least to me, maybe not to C++ developers though who feel it is more than just a hack. Edit: Grammar correction.

ATsch 11y ago
I feel like I have some kind of obligation to correct you on the common error of "should of" instead of "should have" or "should've" http://www.elearnenglishlanguage.com/blog/english-mistakes/should-have-vs-should-of/ http://www.elearnenglishlanguage.com/blog/english-mistakes/s...
- giancarlostoro 11y ago
  Thank you, I appreciate the link even more. This is my second language, and I appreciate any opportunity to improve my writing, even though it is my second language I've learned it is still my main language I use.

lallysingh 11y ago

Some of these aren't quite true anymore. There's a C++ x64 ABI, for example. Still, it's all a big mess.

angelbob 11y ago
Did they finally get templates shoehorned into it? That's been the giant, glaring flaw in all the previous ABI attempts I've seen. Well, that and getting multiple compilers to use the same name-mangling standards.

kazinator 11y ago

Misguided right off the bat: > Not only does C++ have no notion of interfaces, it actually allows subclasses to hide public methods from the superclass. C++ doesn't have "methods"; it has member functions (static or nonstatic). Nonstatic ones can be virtual. Virtual member functions are what corresponds to OOP methods. To use virtual functions as methods, you call them through a base class pointer or reference to an object. That's when you're doing OOP dispatch. Now a derived class in C++ can define member functions of the same names as a base. These functions lexically shadow the ones in the base. If you use derived objects as their actual derived type (not through a base reference), then you're using those functions. This is "statically clear" in a static language, and it makes sense. If I open up "program.cpp" in my text editor and edit some function so that a "Foo f" object is replaced by a "DerivedFoo f", then I want all occurrences of f.func() to now be calling DerivedFoo::f rather than Foo::f, if DerivedFoo::f exists. I don't want the compiler to complain that the situation is ambiguous, and I don't want it to keep calling Foo::f, which is nonsensical. Lastly, access is orthogonal to visibility in C++; it is not accurate to say things like "allows subclasses to hide public methods". Identifiers declared in the derived class scope simply shadow like-named definitions in base classes, period. That is regardless of access. Access specifiers do not alter visibility (or any program semantics). If you manipulate the access specifiers in a C++ program, at best you can make some diagnostic go away, or introduce the need for one. All permutations of access specifiers which don't require a diagnostic will behave the same way (and should produce identical code, really). > One of the increment operators takes a dummy int parameter in order to allow overloading. Can you tell which without googling? Yes, I can tell without googling as can any reasonably competent C++ programmer. Why would you need to answer the question in this form? The feature is there for when the situation arises that you're writing an overloaded ++ operator and would like it to be postfix. If you don't care about overloading ++ or making it postfix, you don't have to be aware that there is an int hack for this. > Without adding another layer of indirection via the PIMPL idiom, changes to the internal structure of the class propagate to all it's users, making compilation painfully / unecessary slow. The class declaration being fully visible to all places which use it allows C++ to be efficient in its handling of data types. For instance, when you have a local variable "FooClass x", the compiler knows exactly how large x is down to the byte and can give it a fixed-size place in a fixed-size stack frame. It also allows for inline functions which compile to code that accesses the object directly. This low-level nature is a conscious design trade off in C++, which makes it what it is. If you want to eliminate the dependencies, you use that PIMPL idiom explicitly. In some higher level languages, the equivalent of PIMPL is implicit everywhere. (For instance, everything is a "heap object"). C++ is one language you can reach for in situations when you don't want everything to be a heap object, yet still have some halfway useful abstractions. > C++ did not have any standard multithreading implementation until C++ 11. That was five years ago. C++ users did threading in C++ code for at least twenty years before that, in platform-specific ways, or using cross platform frameworks like ACE. Because C++ doesn't hide a lot of behaviors under the hood, you can let platform threads loose directly into C++ code and the effects are predictable and manageable, for the most part, modulo issues like "does unwinding happen if the thread dies" and such. > The C++ compilator was originally a preprocessor for C (CFront), and still maintains binary compatibility with C. This point is also inaccurate. C++ has to live in a world with linkers and object file formats which do not support type information on a symbol. That is why name mangling is required. If you want three flavors of a function called foo, with separate external linkage (rather than, say, some internal runt-time dispatch behind a single function) then you need three separate entries in the symbol table. In most object file formats, that means you need three different symbol names. It has nothing to do with C++ originally having been preprocessed, or compatibility with C. C itself is simply compatible with assembly language linkage models. (And so C has failed to promote any improvements in object file formats and linkers, by imposing no special requirements.) Some other languages have to do name mangling in their implementations, to some extent. I used a Modula-2 compiler in the late 1980's which used a "module$ident" scheme in the object file format. That is to say, function foo in module bar was turned into the symbol "bar$foo" with a dollar sign.

vvanders 11y ago

Maybe, but a very useful hack.

evmar 11y ago

"There are only two kinds of languages: the ones people complain about and the ones nobody uses." - Bjarne Stroustrup

jokoon 11y ago
I wish D will be popular in the future. Breaking compatibility with C isn't such a bad thing. Also I think C, C++ and D are easily made compatible with each other (I would not bet on that too much though).
- douche 11y ago
  I've been hearing about D for at least ten years. I don't think it's going to really break out at this point - it's been sort of lapped in the trendy, new language corner by Go and Rust and whatnot.
  - kedean 11y ago
    Worse, it's been lapped into the 'who cares' corner. D had a burst of buzz for a while, about 10 years ago, but at the time nobody really wanted alternative systems languages. IT got a little support, but mostly people ignored it. Now, you have Go/Rust/Nim jumping into the space and getting lots of Buzz, but if D is mentioned then one of two things will happen: A) "Oh yeah, that language from the mid 2000s. I didn't want to use it then, why would I use it now?" B) "D? Oh it's from the mid 2000's? I wonder why nobody used it? It probably sucks." Even if those statements are false, it's hit the same problem that a 50-year old programmer in the job market is going to hit, age discrimination.
stinos 11y ago
Basically, this! Most of the OP's points are valid, no denying that. But, looking at the myriads of properly working, fast, not 'exploding in your face at runtime', often even beautiful code produced in C++ despite these shortcomings: doesn't really seem like a poblem if one knows how to deal with it.
- 11y ago

amelius 11y ago

CSS is a hack too. [1] [1] https://wiki.csswg.org/ideas/mistakes https://wiki.csswg.org/ideas/mistakes

brink 11y ago
Yea, but anyone good enough at CSS already knows that.
nommm-nommm 11y ago
Yeah, but nobody likes CSS or thinks its well designed.
- pcwalton 11y ago
  I think CSS is overall well designed, though with plenty of flaws. It's remarkable, though, that everyone agrees that it's bad, but every proposed replacement I've seen has been significantly worse. Those mistakes are legitimate complaints. But it's interesting that most of the complaints about CSS do not fall under that list.
- jryan49 11y ago
  Neither do people who use C++ :)
amelius 11y ago
And, unfortunately, Javascript is a hack too: > var m = {}; > m["__alpha__"] = 10; > m["__bravo__"] = 20; > m["__proto__"] = 30; > for(var key in m) { console.log(key); } __alpha__ __bravo__

aback 11y ago

All third-generation programming languages (and higher) are leaky abstractions. Why is C++ worse than others?

deleted 11y ago

[deleted]

thinkpad20 11y ago

Isn't name mangling a standard thing done by just about every language except for C that compiles to object code? The lack of standardization between compilers sounds potentially problematic, but name mangling itself doesn't seem like a bad thing. The alternative is to force the programmer to do their own "name mangling" a la C.

JoeAltmaier 11y ago
Name mangling is a sad old way of using antiquated object formats while moving forward with a language. Better solutions are obvious - a new object format that stores constraints/annotations/scope info would be a good one.

usefulcat 11y ago

"[C++] actually allows subclasses to hide public methods from the superclass." That one doesn't even make sense. A base class (superclass) in C++ never knows anything about any of its descendants. So it can only ever know about methods declared in the base class, and what their visibility is in the base class. Secondly, it's true that a derived class could (for example) override a public base class method and make it private in the derived class, but that won't change the ability of the base class to call that method.

nikbackm 11y ago
It's a bit like an explicit interface implementation in C#.
rootlocus 11y ago
The base class is not the only client of that method.
- usefulcat 11y ago
  True, but it specifically says "hide public methods from the superclass".
  - softawre 11y ago
    Oh, I get it. I think s/from/of is what was meant.
slavik81 11y ago
You misunderstood. When the author wrote "from the superclass" they were trying to say "declared on the superclass". It has since been updated to be clearer.
lfowles 11y ago
I actually tested this one since I had never encountered it in the wild. You can indeed call and get the expected results from the derived classes (now private) member function.

exelius 11y ago

Ok -- but I don't think anyone legitimately holds on to C++ as an example of a great, well-designed language. C++ has existed for a long time, and the corporate world has increasingly moved away from C++ because it doesn't offer enough object-oriented goodness while tying you down to a certain memory management style with a difficult to use typing/inheritance system. Pick any modern OO language: Java, Ruby, Swift, hell, even Python. They are all far easier languages to write in than C++, have much better library support, and don't make you dive into memory management hell. IMO C++ is syntactically very difficult, and the language too far out of touch with the architecture patterns and styles used by programmers today.

LanguageGamer 11y ago
C++ is a mess, but Java, Ruby, Swift and Python aren't viable options if your software is performance sensitive.
- austinsharp 11y ago
  Java is pretty viable if you are performance sensitive but not HFT or video game performance sensitive. It's certainly far ahead of Ruby and Python, at least. It's not as fast as C++, but C++ isn't as fast as assembly, either. They're at different points on the tradeoff curve - HOW performance sensitive are you? It's not a binary choice.
  - pkolaczk 11y ago
    There are companies using Java for HFT now as well.
    - rootlocus 11y ago
      I'm actually working for such a company. Peter Lawrey is a renowned advocate for efficient use of java in HFT.
  - exelius 11y ago
    Java is totally viable for nearly anything; it just doesn't work well for games because they require low-level access to graphics hardware (which is definitely not something Java supports). Also, the state of the JVM on the desktop is kind of sad - also from the graphics perspective. But Java is probably the most performant server-side language out there at this point (if you exempt the masochists who write network code in C/C++).

athenot 11y ago

C++ is a multi-paradigm language. Of course that is going to be messy. There are domains of applicability where you want everyone to use the same model, the same patterns, the same paradigms. That yields true benefits for some teams. But there are other areas where you really want to have a Big Bag Of Tricks to get things done, because they are areas where efficiency or fine-grained control are required or it just plain makes sense. I should note that most successful C++ projects I've come across seem to only use a subset of what that Big Bag O' Tricks provides. Yet in some corners, if need be, some specialized trick can be used because it makes sense there. And it ends up being much less of a hack than if it had to be done in the mono-paradigm language.

lfowles 11y ago
I appreciate it being multi-paradigm as well. There are 3-4 languages in there with _great_ interoperability. As well as the ability to pull in a C library to a project with little fuss.

meirelles 11y ago

It's a great language showing aging signs. Most languages become obsolete before becoming old.

angelbob 11y ago
I learned C++ around 1990. It was a hack then, too. It began life as a weird preprocessor for C, and some of the seams from that beginning have shown the entire time.

ansible 11y ago

My team is about to embark upon a C++ project. The compiler will be gcc 4.8.x, and supports C++11. So I've bought Stroustrup's "C++ Programming language 4th Edition", and Scott Meyer's "Effective Modern C++". I've got some reading to do. What's the state of tools related to encouraging / enforcing modern C++ style? Edit: grammar.

jjuhl 11y ago
You should check out clang-tidy: http://clang.llvm.org/extra/clang-tidy/ http://clang.llvm.org/extra/clang-tidy/ clang-format: http://clang.llvm.org/docs/ClangFormat.html http://clang.llvm.org/docs/ClangFormat.html C++ Core Guidelines: https://github.com/isocpp/CppCoreGuidelines https://github.com/isocpp/CppCoreGuidelines C++ Core Guidelines Checkers for VS 2015 Update 1: https://blogs.msdn.microsoft.com/vcblog/2015/12/03/c-core-guidelines-checkers-available-for-vs-2015-update-1/ https://blogs.msdn.microsoft.com/vcblog/2015/12/03/c-core-gu...
- ansible 11y ago
  Awesome, thanks.

diegoperini 11y ago

"Why I think C++ is a hack" is a more appropriate title. The stated arguments have legit points though.

rootlocus 11y ago
I'm getting annoyed of being 'politically correct' on the internet all the time. The title is obviously a metaphor, and it doesn't need to be defensive. http://www.metafilter.com/156134/The-internet-has-made-defensive-writers-of-us-all http://www.metafilter.com/156134/The-internet-has-made-defen...
sevensor 11y ago
"It's a hack" is also an insufficient reason to avoid using C++, although I think it's both true and a useful thing to know before getting involved with C++.
- rootlocus 11y ago
  What is or isn't sufficient is relative and context-sensitive. For me it might be. For triple A game studios definitely isn't.
- austinsharp 11y ago
  The very nature of a hack is that someone needed it at some point. Even if C++ is a hack, that doesn't prohibit it from being the right answer in some situations.

autoreleasepool 11y ago

> 6. Multithreading: C++ did not have any standard multithreading implementation until C++ 11. How is expanding the standard library a hack?

pcwalton 11y ago

Many of these are legitimate, but a couple aren't: - "Dependency hell"—Yeah, it's annoying for sure. But what's the solution? You can't reasonably have value types and ABI stability in the presence of adding and removing fields from those value types: it's impossible. - "Name mangling"—The legitimate complaint here is that the name mangling schema is not standardized (though Itanium is a de facto standard in the open source world). But the fact that name mangling exists isn't something you can blame C++ for: it's really Unix that deserves the blame for not supporting namespaces in their object files.

rootlocus 11y ago
Object files are not standardized either (as far as C++ is concerned). Microsoft has it's own format. I can blame C++ for using a hack in order to keep using the same obj files as C.

georgehaake 11y ago

Well if hack is the polar opposite of elegant, then C++ is a hack indeed.

cubano 11y ago

I've been involved in this debate, professionally, for some 28 years now, and while I don't claim to have any deep or unique insights into it, I would like to state that I find almost amazing that it still rages at pretty much the same level as it did back in 1988. As I've mentioned before, my first professional gig was writing real-time games and business apps for the MajorBBS, a fabulous pre-WWW multi-line BBS, in C. Since the MajorBBS DevKit was shipped as C source and compiled as protected-mode DLLs (to of course overcome the 640k memory limit of DOS...yeah that was a thing at one time), there were several devs that wanted to use C++ "goodies" to help speed development or whatever. The debate started when Galacticomm, the makers of the MajorBBS flat-out refused to consider it and used many of the same rational as the OP listed as reasons why it was not going to ported. Reading over this list jogged many old memories, which is why I felt compelled to write this rather long-winded post. My local opinion? Use whatever gets the job done and can be maintained and supported at a reasonable cost long after you are gone.

pklausler 11y ago

I've used C++ for many major projects, and as a compiler writer, I understand the language at a high level. C++ requires an unprecedented degree of organizational discipline to use successfully. For most projects, in most organizations, it's a terrible technological choice -- bloated, inconsistent, dangerous, poorly understood, and still rapidly changing. The programming world needs a language with some of the features of C++ (strong typing, easy interoperation with C, polymorphism, destructors, and control of memory ownership). But it also needs a language that doesn't perpetuate every single language design flaw that has accumulated since the Nixon administration while dramatically changing in ways that alter "best practices" across revisions of the language standard and too frequently take steps backward in readability. And I disagree that C++ is "evolving". A process isn't really evolution unless old things are dying.