24 ms·

In Defense of C++

196 points by eklitzke 10y ago

Analemma_ 10y ago
I think there exists both necessary complexity and unnecessary complexity. Necessary complexity is when the underlying system is genuinely hard and trying to simplify it causes nuance to be lost -- Rust and Haskell are good examples. Unnecessary complexity just stems from poor design and then perpetually trying to add features on top of the poor design and making it worse -- the classic example is PHP. IMO, C++ has both a lot of necessary complexity (due to its lofty goals) and a lot of unnecessary complexity (mostly due to the C back-compat). I think this is the root of a lot of the "C++ sucks!"/"C++ is great!" arguments; when people only see one half or the other. My bottom line with C++ is that it tries and mostly succeeds to do a lot of hard things, but has questionable design decisions that make these things even harder than they need to be. For a while we just had to live with that because if you wanted a language that was both fast and high-level, C++ was the only game in town. I think that's no longer true, which is why I'm such a cheerleader for Rust: I see it as trying to have all the good things (necessary complexity) of C++ without the baggage.
- stcredzero 10y ago
  IMO, C++ has both a lot of necessary complexity (due to its lofty goals) and a lot of unnecessary complexity (mostly due to the C back-compat). I think this is the root of a lot of the "C++ sucks!"/"C++ is great!" arguments; when people only see one half or the other. C++ is more like an ecosystem of about a dozen languages. You can divide it into 4 languages chronologically. You can add a lot more by categorizing by use. If you pick and choose properly, you can set up a subset of C++ that makes it a great language. Half the computer programming managers out there have below average taste, however.
  - gcp 10y ago
    Any sufficiently large project that pulls in dependencies will likely involve you dealing with all 4 of them. This is one reason why I doubt adding more features to C++ (making it 5) is going to make the language any more pleasant to use (outside toy, one person programs).
    - stcredzero 10y ago
      Any sufficiently large project that pulls in dependencies will likely involve you dealing with all 4 of them. Which describes my current work situation. However, this would seem to imply that a startup or a small project would be able to set up a C++ project with a beautiful, cohesive subset of C++. Your point is something that people who are serious about language design for programming "in the large" should definitely pay attention to. This is one reason why I doubt adding more features to C++ (making it 5) is going to make the language any more pleasant to use (outside toy, one person programs). How do you distinguish between one, two, three, or four person projects? Can you really make such a blanket statement about all the different possible codebases that exist? Methinks you exaggerate. (And I say this as a former dyed-in-the-wool minimalist Smalltalker!)
      - gcp 10y ago
        I put the distinction at "more than 1" because that's the point where you need to deal with code that isn't your own. (In theory of course your buddy could use a style and feature-set really close to your own and make it all a nice abstracted API so you don't need to look inside etc, but you get my point)
        stcredzero 10y ago
        I put the distinction at "more than 1" because that's the point where you need to deal with code that isn't your own. You've never worked in a small shop where there was a good coding standard and everyone stuck to it? That sort of thing actually does pay off. I've seen this in my professional life.
        gcp 10y ago
        We tended to use libraries or external dependencies, too. (And when that was out of the question, C++11 and later usually were as well)
        stcredzero 10y ago
- soulbadguy 10y ago
  You make a good point in nuancing the different types of complexity, and trying to sort the complexity derived from doing something hard from the complexity of doing something wrong. But you skip the important details we do not have an objective way of knowing which is which. You are asserting that Rust/Haskell have more the of former and less of the later without really explaining how you go to that conclusion. Rust and Haskell are complex languages (as compared to say C). And it's not clear for a lot of people that their complexity is any better than C++. But by trying to garanty an ever increasing level of correctness and safety, they booth creating a large set of computation that are conceptually easy but very hard to express in a way that is correct to the type system/borrow checker.
stcredzero 10y ago
This creates a feedback cycle where people are using C++ to get high performance, and that drives the language evolution towards confusing "features" (and idiosyncrasies) that are done in the name of making it possible to generate more highly optimized code. You can replace C++ with <insert language here> and you can replace "language" with entire programming stacks. Large numbers of programming software toolsmiths have been laboring towards the wrong goals for the past few decades. We programmers are like old school computer hardware manufacturers hell-bent on delivering the highest spec numbers at the highest margins, while consumers were beset with poor quality, poor reliability, and experience degrading bloatware. We programmers are particularly prone to inflicting ourselves with experience degrading bloatware, while ignoring our own particular human interface design needs. We need to stop emphasizing "sexy" things like raw performance and mathematically provable semantic guarantees and start looking at how we impact our experience while reading and debugging code. We need to start calling out toolsmiths who give us "power" at the cost of long startup penalties, and unresponsive, unwieldy software tools.
bbatha 10y ago
The point about templates being easy to optimize compared to other generics systems is simply wrong. Other generics systems provide more information to the compiler, so in addition to compiling faster and providing better error messages the compiler can use knowledge of specific type classes, interfaces, modules to optimize the implementation of. For instance, Rust can optimize `type NonZeroOption<T: NonZero> = Option<T>` to just the size of `T` because it knows that the `None` sentinel value is not used by `T`. You can also have nice features like GHC's rewrite rules which allow you to effectively tell the compiler how to optimize your types. Most of the fast binary parts of templates is from stuff like specialization, which can be added to just about any generics system. Rust and Haskell both have it.
- dbaupp 10y ago
  I don't think the T: NonZero bound is doing anything there: the size optimisation is done on the monomorphised/specialised type, not the generic one. In Rust, the concept of a generic types only exist at compile time, and they have no layout. Of course, this is still an example of a generic systems that specializes for performance, in a language that isn't C++.
- gpderetta 10y ago
  > nice features like GHC's rewrite rules C++ templates, in essence, are rewrite rules. And they can be used to optimize types.
- soulbadguy 10y ago
  > Other generics systems provide more information to the compiler, so in addition to compiling faster and providing The templating system in C++ is not generic type system, it's not even strictly speaking part of the C++ type system. It's usually define as a metaprogramming facility. Because it be used to abstract on types, it's the defacto generic system in C++, but it can also be used to abstract over definitions, expressions, computation shapes (like unrolling a loop on a factor relative to the size of a type). C++ templates are slow when compared to other generic system because of a lot of bad design decisions (compilation model and how/when a template has to be intanciated), but also because it can do more, and is used to do more. > the compiler can use knowledge of specific type classes, interfaces, modules to optimize the implementation of. Depends on what you mean by more information: In c++ complex type constraints can be express through template. Even more important, in you example you have to rely on someone in the rust compiler community to implement that specific type transformation. Because, the template system is extremely expressive,whoever designed the "option type" can also ship instructions to the compiler on how to specialize for NonZero type... > You can also have nice features like GHC's rewrite rules which allow you to effectively tell the compiler how to optimize your types. It's hard to have both, most generic type system are fast because they don't do much as you start adding feature and smartness into the system, the performance degrades...scala compile time being a good example. > Rust and Haskell both have it. can you specialize on struct in rust/haskell or just implementation of traits ?
neutronicus 10y ago
I work on high-performance scientific simulation software in C++, and, I have to say, it works really well for us. Our competitors do a bunch of code generation to accomplish the same things in Fortran that we do with templates and policy classes. Sometimes, for shits and giggles, I'll prototype algorithms in Haskell or Common Lisp or what have you and, I have to say, the experience isn't really all that compelling, and this is without introducing MPI and all the associated headaches of working with MPI in something it doesn't support first-class.
- Pitarou 10y ago
  Yes, yours is one of the use cases where C++ really shines. You really do need that combination of low-level performance and high-level expression throughout your codebase.
- santaclaus 10y ago
  > and this is without introducing MPI and all the associated headaches of working with MPI in something it doesn't support first-class Have you looked into a language like Julia or a framework like Charm++? I've seen these used in research papers, but I'm curious if these are used out in industry.
- RobertDeNiro 10y ago
  Isn't Fortran faster than C++ in some cases due to it's strict pointer aliasing rules?
  - neutronicus 10y ago
    It's possible to get around this using __restrict__ to tell the compiler what it needs to know to optimize. Which is, I have to admit, kind of a pain sometimes.
- ziotom78 10y ago
  I used to write scientific code in C++ too, but since a few years I've switched to Python+Fortran using f2py to automatically create bindings. Although there are a few drawbacks (different conventions in indexing arrays is the most annoying), I have not regretted this decision, python's ecosystem is incredibly large, and Fortran plugging Fortran modules allow me to optimize both speed and memory consumption efficiently. (But I eagerly await for the day Julia will be mature enough to allow me to switch!) I only use Fortran just for low-level number crunching, and I must say I have yet to miss C++ templates here for this kind of stuff. I'm curious, what is your typical use of templates in your simulation code?
payne92 10y ago
Recent languages like Go and Rust have taken over a lot of mind share—at least on sites like Hacker News C++ isn't "good" or "bad", it's just OLD (and is backwards compatible with an even OLDER language). We are continually learning which language abstractions give a lot of implementation leverage (e.g. garbage collection), and which introduce unnecessary complexity. Any new(er) language has the benefit of incorporating those learnings into the language design.
- WildUtah 10y ago
  a lot of implementation leverage (e.g. garbage collection) Putting garbage collection in that basket is controversial and lately the evidence is piling up against it. Notice how new important growing languages like Swift and Rust don't have garbage collection and programmers don't miss it. GC is more and more restricted to low performance languages like Python, Javascript, and Ruby and a few specialized highly tuned and expensively engineered exceptions like the JVM and obscure LISP engines. And if you've ever tried to program responsive, interactive, predictable, or time-critical systems, you know that GC is ruinous and awful for those applications. Meanwhile languages like Rust, Swift, and C++ can be used for everything from systems programming to games to low power mobile apps to scripting.
  - lossolo 10y ago
    > Notice how new important growing languages like Swift and Rust don't have garbage collection Swift is using reference counting which is a form of garbage collection.
    - stouset 10y ago
      This is not what people are talking about when they say it doesn't have a garbage collector.
  - david-given 10y ago
    Swift does have garbage collection! It uses reference counting, and AFAIK it doesn't have cycle detection, which means it's up to the developer to ensure that no cycles occur. Regarding responsive interfaces: pure reference counting is particularly problematic for this, because an unbounded amount of work may happen every time an object's reference is decremented (because the object might be freed, which causes other objects' references to become zero, etc). If this happens inside a critical section Your Life Is Pain. At least you can control when this happens by taking and then dropping an additional reference. (See Obj-C's allocation pools.) C++'s shared_ptr<>, BTW, is also reference counting, and suffers from the same problem. So it's technically correct (which is the best kind of correct) to say that C++ has garbage collection too.
lettergram 10y ago
I've developed quite a bit in C, C++, Python, Go, Ruby, and Java/Coffee script and a hand full of others. The thing is, of all the languages I code in C++ is my favorite. It is the most performant (using C where necessary), and is as easy to code in as JavaScript IMO. C++14 (and higher) feels like coding in Go or Python. I feel most people don't actually have experience enough with modern C++ and are trying to use the 90's version of C++. The 90's version is awful, and even the modern has a few quirks. However, when you need performance and something less than C it's amazing.
- deleted 10y ago
  [deleted]
- WildUtah 10y ago
  C++14 (and higher) feels like coding in Go or Python. C++17 is so full of good stuff I'm considering beta compilers just to get it. Soon Python and Ruby won't have any advantages left in writing beautiful, clear, correct, bug-free, and easy to read code and C++ will still run 200x faster.
  - EamonnMR 10y ago
    Care to share any resources where you can learn about the new features that take it there?
    - WildUtah 10y ago
      Wish I could. The hours I've spent reading the formal committee proposals and specs would have been better spent on video games and junk food. But there will be books, and good ones. Next year probably. The compilers aren't even ready yet.
    - VodkaHaze 10y ago
      The best I found are CppCon youtube videos, really
  - justin66 10y ago
hedora 10y ago
I think C++ templates have hit a turning point where you can push much more static type information into your program and the compiler errors are increasingly useful. For instance using the json for modern c++ json parser, you can write this: myclass c = json_node; and it compile time statically checks that a json->myclass deserializer exists, and gives sane errors if one of the (recursive) subfields of myclass does not have a json deserializer. This makes json processing in python look like blood letting, and is close (until runtime) to the experience I'd expect from ocaml and other functional languages. https://github.com/nlohmann/json https://github.com/nlohmann/json
- WildUtah 10y ago
  C++ type inference and first class lambdas and flexible typed tuples have made it possible to create a real useful type system into C++ programs now. It's quite pleasant. But it robs a lot of much slower languages of their best value proposition. You can now do it all in C++ with correctness guarantees and still run 10x faster than most strong typed systems.
  - gpderetta 10y ago
    > C++ type inference we prefer to call it type deduction not to upset type theory purists.
    - WildUtah 10y ago
      Steve Miller and Don Henley seem like such easygoing guys on stage. Surely the purists aren't so touchy.
- VodkaHaze 10y ago
  I mean, even the Google style guide says to avoid complicated template metaprogramming, unless necessary
  - netheril96 10y ago
    And Facebook has this `folly` library that is as complicated as the Boost Library.
ndh2 10y ago
> C++ is what you get when, at every turn in the language design road, you choose to take the path that leads to higher performance. You have plenty of performance with C, and C++ is what you get when you enforce C compatibility at all costs, then tack on other stuff. The memory layout that classes and class hierarchies force upon you lead to sub-optimal caching behavior. Virtual functions don't have optimal performance, but they still made the cut. Pointer aliasing actually hurts performance as it prevents the compiler from doing optimizations. I do agree with everything that was said in "The Joy Of C++", bonus points for acknowledging the Stockholm syndrome. However, pretty much all of it could be said about C.
- lossolo 10y ago
  > The memory layout that classes ... force upon you lead to sub-optimal caching behavior. Simple classes have the same memory layout as C structs, contiguous chunk of memory which means they are cache friendly.
  - ndh2 10y ago
    No, they're not cache friendly. The problem is row-based vs column-based. Array of structs vs Structure of arrays. With arrays of structs/objects you get row-based access patterns. Especially for cases where you only want to access one or two columns, you always pull in everything else. https://www.youtube.com/watch?v=rX0ItVEVjHc https://www.youtube.com/watch?v=rX0ItVEVjHc
    - lossolo 10y ago
      SoA layout is of advantage when the components that you split into separate arrays are usually accessed separately which in most cases is not true. For most cases it is cache friendly (unless you use niche DoD).
    - corysama 10y ago
      Are there any popular languages that support SOA 1st-class? C++ is largely competing with GC languages where it is difficult to avoid separated heap allocations for every tiny bit of data.
gcp 10y ago
Gah, another one of those promotional posts about Rust. More seriously, the large enough Noto Sans font with a hint of extra weight renders so gorgeous in Firefox (it's even bearable in Chrome!). I wish all webpages were as readable. As for the content, well, going back to: https://eklitzke.org/c++-java-go-and-rust https://eklitzke.org/c++-java-go-and-rust I think the problem of the author is that he doesn't realize it's possible to do much better than C++. Claiming Rusts' ownership and borrow checking is exactly equivalent to std::unique_ptr or that Rusts' concurrency support is comparable to std::thread betrays very deep nativity, misunderstanding or just a mindset that can't see beyond what C++ offers.
- deleted 10y ago
  [deleted]
petters 10y ago
One huge advantage of C++ is Visual Studio. Once Rust gets something similar I might switch for my personal projects.
- gcp 10y ago
  There's a Rust plugin for it. I don't use it though, I use Visual Studio Code as regular Visual Studio won't work on Mac or Linux. It also depends a bit on why you like Visual Studio. Because it has one of the best Intellisense implementations? Much more common outside Visual Studio for languages that are not C++... Good visual debugger? etc...
- enturn 10y ago
  There is basic support for syntax highlighting out of the box in Visual Studio and more using a plugin. https://areweideyet.com/ https://areweideyet.com/
- Koshkin 10y ago
  > Visual Studio I am not so sure about that. C++ support in VS is rather terrible - especially when compared with support of C#. For C#, VS is excellent.
  - sandeatr 10y ago
    Nobody uses straight VS C++, they use pluggins such as Visual Assist.
    - gcp 10y ago
      In MSVC6 days yes. But in 2015 or later? The built in stuff has gotten really good.
    - pjmlp 10y ago
      Only when they have nice employers that pay for such plugins.
- flukus 10y ago
  Doesn't VS only support a really old version of c++?
vmarsy 10y ago
> So if I try to use this template with the wrong type, after a bunch of template and macro expansion the compiler will print out a cryptic error showing the templated code and the failed type substitution. This is one of the reasons why Andrew Sutton and Bjarne Stroustrup are trying to push C++ Concepts since C++11 [1]. They should provide much easier to understand compile time errors when it comes to templates. [1] https://en.wikipedia.org/wiki/Concepts_(C%2B%2B) https://en.wikipedia.org/wiki/Concepts_(C%2B%2B)
jfe 10y ago
what is with programmers and needing to defend a combination of syntax, semantics, and runtime? C++ is a programming language with advantages and disadvantages. end of story.
- pessimizer 10y ago
  > C++ is a programming language with advantages and disadvantages. end of story. Sounds like the beginning of a story, during which you explain the advantages and disadvantages, determine where C++ is best used, and compare it to other options.
justinsaccount 10y ago
Is there a "c++: The good parts" ? One of the projects I'm working on could have just as easily been written in c++ instead of go.. except that in go starting the project and building it involved mkdir my_project # hack go build I wouldn't even know where to start to write a simple c++ server that uses zmq and slings json around. How am I supposed to handle dependencies and vendoring? As much of a PITA it is trying to learn rust, getting the toolchain working and starting a new project was not one of the issues I ran into.
- sien 10y ago
  Have you read Effective C++ & More Effective C++? That's a start for what you want.
  - lj3 10y ago
    I think you mean "Effective Modern C++". The two you mention predate C++11. https://www.amazon.com/Effective-Modern-Specific-Ways-Improve/dp/1491903996/ref=pd_bxgy_14_3?_encoding=UTF8&psc=1&refRID=CJT3K27NC7A692DCXP46 https://www.amazon.com/Effective-Modern-Specific-Ways-Improv...
- jawilson2 10y ago
  20 seconds of googling turned up several answers which only require about 30 lines of C++, e.g. http://stackoverflow.com/questions/37765847/send-json-object-through-zmq-with-c-client-python-server http://stackoverflow.com/questions/37765847/send-json-object.... cmake is pretty awesome at handling dependencies; our build process grabs dependencies from git and adds them to the project. Yes, there is more overhead and a learning curve, and if you are running a simple server there are probably better choices; we use a ton of python for these things, and wrap performant code in cython.
  - justinsaccount 10y ago
    > 20 seconds of googling turned up several answers which only require about 30 lines of C++, OK... Now how do you turn those 30 lines of code into an actual project that you can build and cross compile? Write 100 lines of cmake stuff to build 30 lines of code? I think if I was starting from scratch I'd try to use something like bazel.
Pitarou 10y ago
C++ is usually a premature optimisation. I would use it for something like the Unreal game engine, because I know that: - performance is important in much of the project - the problem is complex enough to require high level language constructs But for most tasks, my time would be better spent using a high-level language and then optimising the hot spots in, say, C.
- pjmlp 10y ago
  And Unreal does have opt-in support for GC in the C++ game objects.
- joejev 10y ago
  > - performance is important in much of the project At scale this always becomes true. C++ can be written with reference counting and other high level concepts with runtime penalties. When you need to optimize or scale, you will never need to look to another language. I do a lot of numerical computing in Python and often need to drop into Cython or C; in C++ this wouldn't need to happen. One the the main goals of C++ is that "there is no language below C++". High level language constructs are always nice, and C++ has a lot of "zero-cost" abstractions, meaning you only pay for what you need. For example, an iterator in C++ can just be a raw pointer in the case of iterating over a vector, but it is more complicated for a std::map because it is backed by a tree. C++ is a high-level language, so I don't understand the argument that you would be better off splitting your stack between the "important" parts and the slow parts.
  - harry8 10y ago
    Overstated. There is a level below c++, namely assembly intrinsics. When it comes to simd code using sseN avxN you really do use them when performance is important. That's if you're staying on the CPU. Going massively parallel on a GPU? FPGA? C++ isn't as low as you go.
    - MaulingMonkey 10y ago
      I'd have more time to optimize at these lower levels if I wasn't stuck babysitting C++ codebases to protect them from and fix their undefined behavior.
amelius 10y ago
Aren't most of the points raised in the article actually solved by Rust? Doesn't Rust have a much cleaner template/metaprogramming system?
- Manishearth 10y ago
  Note that Rust's system is a generics system, and there's less metaprogramming that can be done by it. Namely, the property mentioned in the post where "So if I try to use this template with the wrong type, after a bunch of template and macro expansion the compiler will print out a cryptic error showing the templated code and the failed type substitution." does not exist in Rust, since you specify bounds in the API itself. This is both a blessing and a curse. As a blessing, it leads to very neat, clean, APIs and you never have to worry about such template expansion errors. As a curse, some of the more complex bits of C++ metaprogramming (check out what people achieve with SFINAE) are not possible. I personally think the pros outweigh the cons, but many people from the C++ world really like the power of template metaprogramming in C++. Rust is planning on offering procedural macros which address some of the use cases, but not all.
- sidlls 10y ago
  Cleaner but far less powerful in some respects. Or perhaps, as usual, the restrictions are front-loaded. For example in Rust for some operations on a generic type you must specify the appropriate Trait in the declaration ("<T: TheTrait>"). In C++ this would be deferred until you tried to perform an operation on the type for which no valid code exists after something has been instantiated. Other than metaprogramming, Rust's implementation can provide the same functionality that templates do, in a cleaner way in my view.
herewhere 10y ago
In my humble opinion, after C++ 17, C++ does not need anyone's defense. I had worked on infrastructure pieces in Google and Facebook. Given the scale of data, and number of machines, it would not have viable without C++. Consider running 10 times faster using C++ still consuming thousands of machines that would have been 10s of thousands of machines. However, if your application runs fine using any slower language still consume single machine, it might not make sense in that case.
- sqeaky 10y ago
  "Need"... I hope. We could make that sentence damning or glorifying, depending on the missing word choice and someone would argue with you about it, no matter what word.
symlinkk 10y ago
C++ is an insanely versatile language, and since you can use any C library with "extern C", it has a huge amount of high-quality libraries available for it. ffmpeg, openSSL, webkit, Qt. the problem is there is not a cross platform package manager to manage these libraries, and manually downloading and compiling libraries is a hugely painful and error-prone process. it's so bad that big C++ projects like Firefox and Chromium basically write their own scripts that download and build dependencies, and simply commit the source code of the libraries they use directly into their own tree. I believe there is some thought being put into making a C++ package standard [0], which would do wonders for the language. in my opinion half of the reason Node took off is because npm is so easy to use, and people are getting excited about Rust partially because Cargo is so well thought out. Now I might be wrong here, but I think if you took modern C++ (no raw pointer manipulation) and combined it with a good package manager, I think you would pretty much erase any advantages Rust offers. [0]: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0235r0.pdf http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p023...
- fsloth 10y ago
  "manually downloading and compiling libraries is a hugely painful and error-prone process." I think you are exaggerating. Most projects with any user base provide ready binaries which able to get going pretty fast. "it's so bad that big C++ projects like Firefox and Chromium basically write their own scripts that download and build dependencies, and simply commit the source code of the libraries they use directly into their own tree." I would not call this 'bad' but resilient. "Replicating is bad" is a non value adding rule of thumb, imo. That said, yes, it's very hard to start incorporating third party libraries to C++ when compared to any other language.
  - gcp 10y ago
    Most projects with any user base provide ready binaries which able to get going pretty fast. But what about the dependencies of those binaries/libraries? Manually playing that cat and mouse game just sucks.
  - TillE 10y ago
pka 10y ago
From a practical point of view, in many cases the performance critical sections are tiny compared to the rest of the codebase. Imposing such a cognitive overhead on the programmer when 90% of the code are executed once a second just to make those 10% really really fast, and then screaming "performance!!!" is not very convincing. Just use a high-level language and drop to C when needed. Anyway, the author later says he just enjoys writing low-level C++ code, however unpractical this may be. In which case I don't really see the point of defending his choice.
- panic 10y ago
  But once you've optimized those sections, the rest of the performance problems are left scattered through your code. I've had to rewrite a system in C++ just a few weeks away from shipping because even after optimizing all the performance-critical sections, we still needed that extra 15% or so of "ambient" performance.
  - malisper 10y ago
    > we still needed that extra 15% or so of "ambient" performance. This doesn't make sense to me. That 15% of time is spent somewhere. It certainly isn't just "ambient".
    - panic 10y ago
      Yes, it's spent carrying out the fundamental operations of the language (mostly method lookup and dispatch in this case).
  - pka 10y ago
    Sure, then you have a valid use case for C/C++ (even better, Rust!) But often people don't and still use C++.
    - deleted 10y ago
      [deleted]
bitwize 10y ago
If you're starting a new system-level project, you should be using C++ or Rust, not C and certainly not Go (which was designed for kids to write microservices with; in other words it competes with Ruby and Node, not C++). A modern language should support static typing with parametric polymorphism and statically determined object extent for most objects (with well-defined extent for the rest). Rust also gives you statically determined object access.
- microcolonel 10y ago
  How can you, knowing absolutely nothing else about the use case, suggest a solution? What if they're on an architecture where the libc++ or rust runtime is low quality? What if their application needs to be NUMA aware? There are plenty of reasons not to use C++ or Rust. They are not magic bullets which solve all engineering challenges.
lostdog 10y ago
It's hard to enjoy programming in C++ because the compile times are so long. C++ has grown up a lot, and smart pointers, a flexible template system, and lambda expressions, help you get a lot done easily, but every time you code up a useful abstraction, you risk ballooning your compile time.
- TillE 10y ago
  Yeah, this is the genuine pain point experienced by actual C++ developers. Though really only templates will kill your compile times; other modern features are pretty safe. Modules will help. Hopefully.
chhs 10y ago
I found C++ very complex and difficult to work with, though it is very powerful in terms of performance. There is also several years of libraries available in C++ that is difficult to leave behind. If you are looking for something like C++ in terms of performance and has a nicer syntax, you should try the D programming language. It's very nice to use, as fast as safe C++ code (you can write unsafe C++ that is faster), has stronger typing, templates, mixins, and can interface with C /C++ libraries. I've moved my personal projects over to D, I've started writing a game with OpenGL, SDL, ASSIMP, Devil and it's much easier than C or C++. Some links for those who are interested: Main website: http://dlang.org/ http://dlang.org/ Package manager: http://code.dlang.org/ http://code.dlang.org/ Some interesting documentation pages: Interfacing with C: http://dlang.org/spec/interfaceToC.html http://dlang.org/spec/interfaceToC.html Interfacing with C++: http://dlang.org/spec/cpp_interface.html http://dlang.org/spec/cpp_interface.html Templates: http://dlang.org/spec/template.html http://dlang.org/spec/template.html Inline Assembler: http://dlang.org/spec/iasm.html http://dlang.org/spec/iasm.html
- RobertDeNiro 10y ago
  How easily can you use D on something that's not x86? Is there decent cross compilation?
  - chhs 10y ago
    I've not used D on platforms other than x86 but I have heard cross compilation mentioned in the comments of some conference talks. I found this page which has the status of the LDC compiler on various platforms. It looks like it is still under development but I don't know recently that page was updated. Status of various platforms: https://wiki.dlang.org/LDC https://wiki.dlang.org/LDC
  - Ace17 10y ago
    At least one of the prepackaged D compilers of Debian (GDC) can target ARM, and I've tried it, it works!
hellofunk 10y ago
> a rather weak type system, one inherited with relatively few changes from C I don't understand this statement at all. C is a much weaker type system than C++. You can do things in C that will never compile in C++, it is much, much stricter.
netheril96 10y ago
> Templates are objectively extremely difficult to understand and use correctly Really? Template metaprogramming is not the only use valid use of templates. Most time a simple <class T> is enough and that is already a huge improvement over C.
- rubber_duck 10y ago
  Even most meta programming is not extremely difficult, unless we're talking boost level stuff, and more importantly it allows you to do super powerful interfaces for your API that are trivial to use (the implementation might get complex but consumption shouldn't be). Like say you have a collection of entities where each entity can have one or more components of different types. Now you want to find all entities with components A, B, C and the returned value should have typed references to components - it gets a bit hairy to implement but it's trivial to use and efficient.
jwatte 10y ago
C++ is called a "bad" language by people who think go or JavaScript are "good" languages.
tapirl 10y ago
I'm experienced in c++98. I feel c++now is a new language full of weird syntaxes. I mean, unnecessarily weird. I don't know why so many languages support lambda nowadays. It looks so weird and unnatural. I still have to use c++ in some projects, never for the new syntaxes, just for there are some libraries I must use.
- tdsamardzhiev 10y ago
  Lambdas give you a (somewhat) saner syntax for 1. Defining a function within a function. 2. Capturing a function call for later use.
  - tapirl 10y ago
    Couldn't it be some less weird, just like the anonymous functions in JavaScript and Go? Even the lambda in Java is much readable than c++. It give me the feeling that, c++ gives every corner a special syntax, or c++ adds new features by adding new syntaxes, there is no the word "reuse" in the process of improving c++. In go, anonymous functions and general functions and methods have no much differences. But in c++, lambda and general functions and class methods are too different. Using class methods as callback in c++ is awful. C++1x features make c++ code less readable, for fewer and fewer programmers know every syntax corners in c++.
makecheck 10y ago
Templates only generate maximally-efficient code in theory. Generality kills them in practice; or, it makes the template code twisted to the point of insanity. For example, there is no space-efficient way to model optional<T> for more than one value in a structure type; if you have several optional fields, it would make much more sense to be able to track optional state as single bits of one field (say) but the class structure prohibits such a space optimization and requires each template to track its own is-defined value. Pointless. It is also essentially impossible to know that your code is well-tested: even when using something large and well-known like Boost, its authors cannot know what will happen when you substitute in 4 of your own types (my bet is “result not quite working as intended; obscure bugs added”). I use templates but I am quite aware of code complexity and I essentially stop when the templating goes too far. Somewhere along the line, we seem to have gotten into a mode of wanting generic code at all costs. Why? It is just fine to expose a few common specific methods when those are very helpful and clear (such as classes exposing a “string value”, “integer value” and “float value” instead of trying to provide some single partially-specialized template mess of a method that manages to still not quite work right in every scenario).
- Animats 10y ago
  Somewhere along the line, we seem to have gotten into a mode of wanting generic code at all costs. I know. Years ago I proposed a vector library for 2, 3, and 4 element vectors [1] as a standard. The immediate complaint was that it didn't use templates. [1] http://www.animats.com/source/graphics/algebra3.h http://www.animats.com/source/graphics/algebra3.h
  - slavik81 10y ago
    The trouble is that a reasonable requirement such as single-precision floating point support would require a developer to copy/paste/modify hundreds of LOC. The choice is really fork, duplicate or template. I don't blame glm for picking the latter. Every option is painful, but templates might be a little less so.
chaotic-good 10y ago
This article doesn't have a clue. For example: > but many C++ programmers disable exceptions for performance I have never seen a project like this for 10+something years. The only piece of code with disabled exceptions that I've seen was created for Atmel controllers. And in modern C++ exceptions is zero-cost. Your paying for exceptions only when they occur so, nobody is disabling exceptions now. This is not the only line that bugs me but I don't have enough time for it right now.
- panic 10y ago
  There are reasons to disable exceptions aside from performance. Google's C++ style guide (which bans their use) discusses some of the pros and cons: https://google.github.io/styleguide/cppguide.html#Exceptions https://google.github.io/styleguide/cppguide.html#Exceptions
  - chaotic-good 10y ago
    I saw this first time many years ago. It clearly states that exceptions is a good thing but shouldn't be used in Google's projects because their code is not prepared for exceptions: > On their face, the benefits of using exceptions outweigh the costs, especially in new projects. However, for existing code, the introduction of exceptions has implications on all dependent code. If exceptions can be propagated beyond a new project, it also becomes problematic to integrate the new project into existing exception-free code. Because most existing C++ code at Google is not prepared to deal with exceptions, it is comparatively difficult to adopt new code that generates exceptions. And most importantly, I don't think that they're disabling exceptions using compiler flag. I'm sure that they just using error codes for error handling instead of exceptions.
- santaclaus 10y ago
  > nobody is disabling exceptions now Embedded people still disable exceptions.
retrogradeorbit 10y ago
AFAIK C++ still doesn't have a finally construct for its exceptions. Are there any plans to introduce it? Is so, when does it land?
- sandeatr 10y ago
  C++ does not need finally, so it would not make much sense to add it. RAII is superior and is what is used instead. Finally would likely just encourage people to write really awful C++ code.
  - retrogradeorbit 10y ago
    So are you saying that C++ has no plans to implement finally? (also I totally disagree that RAII is superior to finally. Finally, being lexically scoped, is far simpler, far shorter and far easier to understand. https://codecraft.co/2013/10/31/why-we-need-try-finally-not-just-raii/ https://codecraft.co/2013/10/31/why-we-need-try-finally-not-... )
    - sandeatr 10y ago
      That article does not convince me, scope guard + lambda appears to work just as well as finally, and is actually shorter(see tianyuzhu's comment) I do not know if anyone has proposed it for C++, but I would be surprised if it passed given that it doesn't accomplish much.
  - oselhn 10y ago
    RAII is not superior both ways have their own drawbacks. You can forget to write finally and it may produce duplicated code. On the other hand RAII requires you to create new type just for exception safety (scope guard - which you may also forget to use). I prefer RAII but there are situations where finally leads to more readable code.
mrbrowning 10y ago
This is myopic in the characteristically self-undermining way that most of these defenses are. I actually like modern C++ well enough for the niche described here; lambdas (and the control they offer over captured variables), type deduction, ranged fors and the like make it pleasant enough to write for being as performant as it can be. I've written many more lines of C++ than Rust. But it's still apparent that language-enforced invariants are quite a different species from conventions that will enable safe programs if everyone uses them correctly at all times. You can maybe guarantee that for a team, but can you guarantee it for several teams? Can you guarantee it for every external dependency? I can imagine plenty of pragmatic analyses today ending up with C++ as the ideal choice of language, but the monomaniacal focus on Performance ignores ecological concerns like these and also mostly doesn't grapple with the fact that there's plenty of low-hanging fruit to get to performance-wise in any project before something like a fundamental 1.2x performance penalty on Rust's part really matters, especially considering how domain-dependent that number is likely to be. Pure speed is a pretty poisonous obsession in our field, IMO, and I think we've reaped the whirlwind for it already. It's time for a more holistic outlook.
- pjmlp 10y ago
  As example, I never had any issue with bounds checking being enabled in all languages I used through my career. Even in C++, I always had bound checking on my own classes and always make use of the validation flags in VC++. It never mattered to the type of applications I was involved with.
  - anonymoushn 10y ago
    I spent some time working on HFT systems. These things needed to achieve end-to-end timings (from a tick being DMAed into our memory to placing an order) around xx microseconds at the 99th percentile. The bulk of the code was written in a language that forced us to have bounds checking everywhere, and that was totally fine.
    - yxhuvud 10y ago
      I'd assume most array boundary checks can be optimized away by a good compiler anyhow, assuming the array semantics allow that in the language in question.
ishitatsuyuki 10y ago
Templates: originally for generics, now misused for SFINAE and slowing down the compiler. Copy-elision: the copy constructor is unneeded, we should be move by default. Answer: Rust.
Const-me 10y ago
Very close to my view. Here’s my blog post about that: http://const.me/articles/why-cpp/ http://const.me/articles/why-cpp/
sargun 10y ago
A few things: 1) Writing concurrent code in C++ is exciting (this is a bad thing). Processors are not getting much faster in serial execution, but the number of cores are continuing to increase More here: http://joearms.github.io/2013/03/28/solving-the-wrong-problem.html http://joearms.github.io/2013/03/28/solving-the-wrong-proble... 2) Programmer time is (usually) more costly than anything else in your organization. I'd argue that for most organizations, they're not making enough money per unit of throughput to justify the excessive programming time. 3) C++ is not designed for operators. Rust has this problem too. Once you know how to inspect a Java, Erlang, or Go program, the tools become familiar.
- Const-me 10y ago
  First, OpenMP isn’t that bad. Second, the author of the article you’ve linked forgot about another kind of parallelization, SIMD. Realistically, SSE and AVX instructions are only usable from assembler, C, C++, and Fortran. Sometimes throwing hardware at problems don’t work. Either because it’s technically impossible (console games, mobile) or because you don’t own the hardware (PC games, desktop software). For such products, either you spent “excessive programming time” programming C++, or you won’t release any product at all.

196 points by eklitzke 10y ago

I think there exists both necessary complexity and unnecessary complexity. Necessary complexity is when the underlying system is genuinely hard and trying to simplify it causes nuance to be lost -- Rust and Haskell are good examples. Unnecessary complexity just stems from poor design and then perpetually trying to add features on top of the poor design and making it worse -- the classic example is PHP. IMO, C++ has both a lot of necessary complexity (due to its lofty goals) and a lot of unnecessary complexity (mostly due to the C back-compat). I think this is the root of a lot of the "C++ sucks!"/"C++ is great!" arguments; when people only see one half or the other. My bottom line with C++ is that it tries and mostly succeeds to do a lot of hard things, but has questionable design decisions that make these things even harder than they need to be. For a while we just had to live with that because if you wanted a language that was both fast and high-level, C++ was the only game in town. I think that's no longer true, which is why I'm such a cheerleader for Rust: I see it as trying to have all the good things (necessary complexity) of C++ without the baggage.

stcredzero 10y ago
IMO, C++ has both a lot of necessary complexity (due to its lofty goals) and a lot of unnecessary complexity (mostly due to the C back-compat). I think this is the root of a lot of the "C++ sucks!"/"C++ is great!" arguments; when people only see one half or the other. C++ is more like an ecosystem of about a dozen languages. You can divide it into 4 languages chronologically. You can add a lot more by categorizing by use. If you pick and choose properly, you can set up a subset of C++ that makes it a great language. Half the computer programming managers out there have below average taste, however.
- gcp 10y ago
  Any sufficiently large project that pulls in dependencies will likely involve you dealing with all 4 of them. This is one reason why I doubt adding more features to C++ (making it 5) is going to make the language any more pleasant to use (outside toy, one person programs).
  - stcredzero 10y ago
    Any sufficiently large project that pulls in dependencies will likely involve you dealing with all 4 of them. Which describes my current work situation. However, this would seem to imply that a startup or a small project would be able to set up a C++ project with a beautiful, cohesive subset of C++. Your point is something that people who are serious about language design for programming "in the large" should definitely pay attention to. This is one reason why I doubt adding more features to C++ (making it 5) is going to make the language any more pleasant to use (outside toy, one person programs). How do you distinguish between one, two, three, or four person projects? Can you really make such a blanket statement about all the different possible codebases that exist? Methinks you exaggerate. (And I say this as a former dyed-in-the-wool minimalist Smalltalker!)
    - gcp 10y ago
      I put the distinction at "more than 1" because that's the point where you need to deal with code that isn't your own. (In theory of course your buddy could use a style and feature-set really close to your own and make it all a nice abstracted API so you don't need to look inside etc, but you get my point)
      - stcredzero 10y ago
        I put the distinction at "more than 1" because that's the point where you need to deal with code that isn't your own. You've never worked in a small shop where there was a good coding standard and everyone stuck to it? That sort of thing actually does pay off. I've seen this in my professional life.
        gcp 10y ago
        We tended to use libraries or external dependencies, too. (And when that was out of the question, C++11 and later usually were as well)
        stcredzero 10y ago
soulbadguy 10y ago
You make a good point in nuancing the different types of complexity, and trying to sort the complexity derived from doing something hard from the complexity of doing something wrong. But you skip the important details we do not have an objective way of knowing which is which. You are asserting that Rust/Haskell have more the of former and less of the later without really explaining how you go to that conclusion. Rust and Haskell are complex languages (as compared to say C). And it's not clear for a lot of people that their complexity is any better than C++. But by trying to garanty an ever increasing level of correctness and safety, they booth creating a large set of computation that are conceptually easy but very hard to express in a way that is correct to the type system/borrow checker.

stcredzero 10y ago

This creates a feedback cycle where people are using C++ to get high performance, and that drives the language evolution towards confusing "features" (and idiosyncrasies) that are done in the name of making it possible to generate more highly optimized code. You can replace C++ with <insert language here> and you can replace "language" with entire programming stacks. Large numbers of programming software toolsmiths have been laboring towards the wrong goals for the past few decades. We programmers are like old school computer hardware manufacturers hell-bent on delivering the highest spec numbers at the highest margins, while consumers were beset with poor quality, poor reliability, and experience degrading bloatware. We programmers are particularly prone to inflicting ourselves with experience degrading bloatware, while ignoring our own particular human interface design needs. We need to stop emphasizing "sexy" things like raw performance and mathematically provable semantic guarantees and start looking at how we impact our experience while reading and debugging code. We need to start calling out toolsmiths who give us "power" at the cost of long startup penalties, and unresponsive, unwieldy software tools.

bbatha 10y ago

The point about templates being easy to optimize compared to other generics systems is simply wrong. Other generics systems provide more information to the compiler, so in addition to compiling faster and providing better error messages the compiler can use knowledge of specific type classes, interfaces, modules to optimize the implementation of. For instance, Rust can optimize `type NonZeroOption<T: NonZero> = Option<T>` to just the size of `T` because it knows that the `None` sentinel value is not used by `T`. You can also have nice features like GHC's rewrite rules which allow you to effectively tell the compiler how to optimize your types. Most of the fast binary parts of templates is from stuff like specialization, which can be added to just about any generics system. Rust and Haskell both have it.

dbaupp 10y ago
I don't think the T: NonZero bound is doing anything there: the size optimisation is done on the monomorphised/specialised type, not the generic one. In Rust, the concept of a generic types only exist at compile time, and they have no layout. Of course, this is still an example of a generic systems that specializes for performance, in a language that isn't C++.
gpderetta 10y ago
> nice features like GHC's rewrite rules C++ templates, in essence, are rewrite rules. And they can be used to optimize types.
soulbadguy 10y ago
> Other generics systems provide more information to the compiler, so in addition to compiling faster and providing The templating system in C++ is not generic type system, it's not even strictly speaking part of the C++ type system. It's usually define as a metaprogramming facility. Because it be used to abstract on types, it's the defacto generic system in C++, but it can also be used to abstract over definitions, expressions, computation shapes (like unrolling a loop on a factor relative to the size of a type). C++ templates are slow when compared to other generic system because of a lot of bad design decisions (compilation model and how/when a template has to be intanciated), but also because it can do more, and is used to do more. > the compiler can use knowledge of specific type classes, interfaces, modules to optimize the implementation of. Depends on what you mean by more information: In c++ complex type constraints can be express through template. Even more important, in you example you have to rely on someone in the rust compiler community to implement that specific type transformation. Because, the template system is extremely expressive,whoever designed the "option type" can also ship instructions to the compiler on how to specialize for NonZero type... > You can also have nice features like GHC's rewrite rules which allow you to effectively tell the compiler how to optimize your types. It's hard to have both, most generic type system are fast because they don't do much as you start adding feature and smartness into the system, the performance degrades...scala compile time being a good example. > Rust and Haskell both have it. can you specialize on struct in rust/haskell or just implementation of traits ?

neutronicus 10y ago

I work on high-performance scientific simulation software in C++, and, I have to say, it works really well for us. Our competitors do a bunch of code generation to accomplish the same things in Fortran that we do with templates and policy classes. Sometimes, for shits and giggles, I'll prototype algorithms in Haskell or Common Lisp or what have you and, I have to say, the experience isn't really all that compelling, and this is without introducing MPI and all the associated headaches of working with MPI in something it doesn't support first-class.

Pitarou 10y ago
Yes, yours is one of the use cases where C++ really shines. You really do need that combination of low-level performance and high-level expression throughout your codebase.
santaclaus 10y ago
> and this is without introducing MPI and all the associated headaches of working with MPI in something it doesn't support first-class Have you looked into a language like Julia or a framework like Charm++? I've seen these used in research papers, but I'm curious if these are used out in industry.
RobertDeNiro 10y ago
Isn't Fortran faster than C++ in some cases due to it's strict pointer aliasing rules?
- neutronicus 10y ago
  It's possible to get around this using __restrict__ to tell the compiler what it needs to know to optimize. Which is, I have to admit, kind of a pain sometimes.
ziotom78 10y ago
I used to write scientific code in C++ too, but since a few years I've switched to Python+Fortran using f2py to automatically create bindings. Although there are a few drawbacks (different conventions in indexing arrays is the most annoying), I have not regretted this decision, python's ecosystem is incredibly large, and Fortran plugging Fortran modules allow me to optimize both speed and memory consumption efficiently. (But I eagerly await for the day Julia will be mature enough to allow me to switch!) I only use Fortran just for low-level number crunching, and I must say I have yet to miss C++ templates here for this kind of stuff. I'm curious, what is your typical use of templates in your simulation code?

payne92 10y ago

Recent languages like Go and Rust have taken over a lot of mind share—at least on sites like Hacker News C++ isn't "good" or "bad", it's just OLD (and is backwards compatible with an even OLDER language). We are continually learning which language abstractions give a lot of implementation leverage (e.g. garbage collection), and which introduce unnecessary complexity. Any new(er) language has the benefit of incorporating those learnings into the language design.

WildUtah 10y ago
a lot of implementation leverage (e.g. garbage collection) Putting garbage collection in that basket is controversial and lately the evidence is piling up against it. Notice how new important growing languages like Swift and Rust don't have garbage collection and programmers don't miss it. GC is more and more restricted to low performance languages like Python, Javascript, and Ruby and a few specialized highly tuned and expensively engineered exceptions like the JVM and obscure LISP engines. And if you've ever tried to program responsive, interactive, predictable, or time-critical systems, you know that GC is ruinous and awful for those applications. Meanwhile languages like Rust, Swift, and C++ can be used for everything from systems programming to games to low power mobile apps to scripting.
- lossolo 10y ago
  > Notice how new important growing languages like Swift and Rust don't have garbage collection Swift is using reference counting which is a form of garbage collection.
  - stouset 10y ago
    This is not what people are talking about when they say it doesn't have a garbage collector.
- david-given 10y ago
  Swift does have garbage collection! It uses reference counting, and AFAIK it doesn't have cycle detection, which means it's up to the developer to ensure that no cycles occur. Regarding responsive interfaces: pure reference counting is particularly problematic for this, because an unbounded amount of work may happen every time an object's reference is decremented (because the object might be freed, which causes other objects' references to become zero, etc). If this happens inside a critical section Your Life Is Pain. At least you can control when this happens by taking and then dropping an additional reference. (See Obj-C's allocation pools.) C++'s shared_ptr<>, BTW, is also reference counting, and suffers from the same problem. So it's technically correct (which is the best kind of correct) to say that C++ has garbage collection too.

lettergram 10y ago

I've developed quite a bit in C, C++, Python, Go, Ruby, and Java/Coffee script and a hand full of others. The thing is, of all the languages I code in C++ is my favorite. It is the most performant (using C where necessary), and is as easy to code in as JavaScript IMO. C++14 (and higher) feels like coding in Go or Python. I feel most people don't actually have experience enough with modern C++ and are trying to use the 90's version of C++. The 90's version is awful, and even the modern has a few quirks. However, when you need performance and something less than C it's amazing.

deleted 10y ago
[deleted]
WildUtah 10y ago
C++14 (and higher) feels like coding in Go or Python. C++17 is so full of good stuff I'm considering beta compilers just to get it. Soon Python and Ruby won't have any advantages left in writing beautiful, clear, correct, bug-free, and easy to read code and C++ will still run 200x faster.
- EamonnMR 10y ago
  Care to share any resources where you can learn about the new features that take it there?
  - WildUtah 10y ago
    Wish I could. The hours I've spent reading the formal committee proposals and specs would have been better spent on video games and junk food. But there will be books, and good ones. Next year probably. The compilers aren't even ready yet.
  - VodkaHaze 10y ago
    The best I found are CppCon youtube videos, really
- justin66 10y ago

hedora 10y ago

I think C++ templates have hit a turning point where you can push much more static type information into your program and the compiler errors are increasingly useful. For instance using the json for modern c++ json parser, you can write this: myclass c = json_node; and it compile time statically checks that a json->myclass deserializer exists, and gives sane errors if one of the (recursive) subfields of myclass does not have a json deserializer. This makes json processing in python look like blood letting, and is close (until runtime) to the experience I'd expect from ocaml and other functional languages. https://github.com/nlohmann/json https://github.com/nlohmann/json

WildUtah 10y ago
C++ type inference and first class lambdas and flexible typed tuples have made it possible to create a real useful type system into C++ programs now. It's quite pleasant. But it robs a lot of much slower languages of their best value proposition. You can now do it all in C++ with correctness guarantees and still run 10x faster than most strong typed systems.
- gpderetta 10y ago
  > C++ type inference we prefer to call it type deduction not to upset type theory purists.
  - WildUtah 10y ago
    Steve Miller and Don Henley seem like such easygoing guys on stage. Surely the purists aren't so touchy.
VodkaHaze 10y ago
I mean, even the Google style guide says to avoid complicated template metaprogramming, unless necessary
- netheril96 10y ago
  And Facebook has this `folly` library that is as complicated as the Boost Library.

ndh2 10y ago

> C++ is what you get when, at every turn in the language design road, you choose to take the path that leads to higher performance. You have plenty of performance with C, and C++ is what you get when you enforce C compatibility at all costs, then tack on other stuff. The memory layout that classes and class hierarchies force upon you lead to sub-optimal caching behavior. Virtual functions don't have optimal performance, but they still made the cut. Pointer aliasing actually hurts performance as it prevents the compiler from doing optimizations. I do agree with everything that was said in "The Joy Of C++", bonus points for acknowledging the Stockholm syndrome. However, pretty much all of it could be said about C.

lossolo 10y ago
> The memory layout that classes ... force upon you lead to sub-optimal caching behavior. Simple classes have the same memory layout as C structs, contiguous chunk of memory which means they are cache friendly.
- ndh2 10y ago
  No, they're not cache friendly. The problem is row-based vs column-based. Array of structs vs Structure of arrays. With arrays of structs/objects you get row-based access patterns. Especially for cases where you only want to access one or two columns, you always pull in everything else. https://www.youtube.com/watch?v=rX0ItVEVjHc https://www.youtube.com/watch?v=rX0ItVEVjHc
  - lossolo 10y ago
    SoA layout is of advantage when the components that you split into separate arrays are usually accessed separately which in most cases is not true. For most cases it is cache friendly (unless you use niche DoD).
  - corysama 10y ago
    Are there any popular languages that support SOA 1st-class? C++ is largely competing with GC languages where it is difficult to avoid separated heap allocations for every tiny bit of data.

gcp 10y ago

Gah, another one of those promotional posts about Rust. More seriously, the large enough Noto Sans font with a hint of extra weight renders so gorgeous in Firefox (it's even bearable in Chrome!). I wish all webpages were as readable. As for the content, well, going back to: https://eklitzke.org/c++-java-go-and-rust https://eklitzke.org/c++-java-go-and-rust I think the problem of the author is that he doesn't realize it's possible to do much better than C++. Claiming Rusts' ownership and borrow checking is exactly equivalent to std::unique_ptr or that Rusts' concurrency support is comparable to std::thread betrays very deep nativity, misunderstanding or just a mindset that can't see beyond what C++ offers.

deleted 10y ago
[deleted]

petters 10y ago

One huge advantage of C++ is Visual Studio. Once Rust gets something similar I might switch for my personal projects.

gcp 10y ago
There's a Rust plugin for it. I don't use it though, I use Visual Studio Code as regular Visual Studio won't work on Mac or Linux. It also depends a bit on why you like Visual Studio. Because it has one of the best Intellisense implementations? Much more common outside Visual Studio for languages that are not C++... Good visual debugger? etc...
enturn 10y ago
There is basic support for syntax highlighting out of the box in Visual Studio and more using a plugin. https://areweideyet.com/ https://areweideyet.com/
Koshkin 10y ago
> Visual Studio I am not so sure about that. C++ support in VS is rather terrible - especially when compared with support of C#. For C#, VS is excellent.
- sandeatr 10y ago
  Nobody uses straight VS C++, they use pluggins such as Visual Assist.
  - gcp 10y ago
    In MSVC6 days yes. But in 2015 or later? The built in stuff has gotten really good.
  - pjmlp 10y ago
    Only when they have nice employers that pay for such plugins.
flukus 10y ago
Doesn't VS only support a really old version of c++?

vmarsy 10y ago

> So if I try to use this template with the wrong type, after a bunch of template and macro expansion the compiler will print out a cryptic error showing the templated code and the failed type substitution. This is one of the reasons why Andrew Sutton and Bjarne Stroustrup are trying to push C++ Concepts since C++11 [1]. They should provide much easier to understand compile time errors when it comes to templates. [1] https://en.wikipedia.org/wiki/Concepts_(C%2B%2B) https://en.wikipedia.org/wiki/Concepts_(C%2B%2B)

jfe 10y ago

what is with programmers and needing to defend a combination of syntax, semantics, and runtime? C++ is a programming language with advantages and disadvantages. end of story.

pessimizer 10y ago
> C++ is a programming language with advantages and disadvantages. end of story. Sounds like the beginning of a story, during which you explain the advantages and disadvantages, determine where C++ is best used, and compare it to other options.

justinsaccount 10y ago

Is there a "c++: The good parts" ? One of the projects I'm working on could have just as easily been written in c++ instead of go.. except that in go starting the project and building it involved mkdir my_project # hack go build I wouldn't even know where to start to write a simple c++ server that uses zmq and slings json around. How am I supposed to handle dependencies and vendoring? As much of a PITA it is trying to learn rust, getting the toolchain working and starting a new project was not one of the issues I ran into.

sien 10y ago
Have you read Effective C++ & More Effective C++? That's a start for what you want.
- lj3 10y ago
  I think you mean "Effective Modern C++". The two you mention predate C++11. https://www.amazon.com/Effective-Modern-Specific-Ways-Improve/dp/1491903996/ref=pd_bxgy_14_3?_encoding=UTF8&psc=1&refRID=CJT3K27NC7A692DCXP46 https://www.amazon.com/Effective-Modern-Specific-Ways-Improv...
jawilson2 10y ago
20 seconds of googling turned up several answers which only require about 30 lines of C++, e.g. http://stackoverflow.com/questions/37765847/send-json-object-through-zmq-with-c-client-python-server http://stackoverflow.com/questions/37765847/send-json-object.... cmake is pretty awesome at handling dependencies; our build process grabs dependencies from git and adds them to the project. Yes, there is more overhead and a learning curve, and if you are running a simple server there are probably better choices; we use a ton of python for these things, and wrap performant code in cython.
- justinsaccount 10y ago
  > 20 seconds of googling turned up several answers which only require about 30 lines of C++, OK... Now how do you turn those 30 lines of code into an actual project that you can build and cross compile? Write 100 lines of cmake stuff to build 30 lines of code? I think if I was starting from scratch I'd try to use something like bazel.

Pitarou 10y ago

C++ is usually a premature optimisation. I would use it for something like the Unreal game engine, because I know that: - performance is important in much of the project - the problem is complex enough to require high level language constructs But for most tasks, my time would be better spent using a high-level language and then optimising the hot spots in, say, C.

pjmlp 10y ago
And Unreal does have opt-in support for GC in the C++ game objects.
joejev 10y ago
> - performance is important in much of the project At scale this always becomes true. C++ can be written with reference counting and other high level concepts with runtime penalties. When you need to optimize or scale, you will never need to look to another language. I do a lot of numerical computing in Python and often need to drop into Cython or C; in C++ this wouldn't need to happen. One the the main goals of C++ is that "there is no language below C++". High level language constructs are always nice, and C++ has a lot of "zero-cost" abstractions, meaning you only pay for what you need. For example, an iterator in C++ can just be a raw pointer in the case of iterating over a vector, but it is more complicated for a std::map because it is backed by a tree. C++ is a high-level language, so I don't understand the argument that you would be better off splitting your stack between the "important" parts and the slow parts.
- harry8 10y ago
  Overstated. There is a level below c++, namely assembly intrinsics. When it comes to simd code using sseN avxN you really do use them when performance is important. That's if you're staying on the CPU. Going massively parallel on a GPU? FPGA? C++ isn't as low as you go.
  - MaulingMonkey 10y ago
    I'd have more time to optimize at these lower levels if I wasn't stuck babysitting C++ codebases to protect them from and fix their undefined behavior.

amelius 10y ago

Aren't most of the points raised in the article actually solved by Rust? Doesn't Rust have a much cleaner template/metaprogramming system?

Manishearth 10y ago
Note that Rust's system is a generics system, and there's less metaprogramming that can be done by it. Namely, the property mentioned in the post where "So if I try to use this template with the wrong type, after a bunch of template and macro expansion the compiler will print out a cryptic error showing the templated code and the failed type substitution." does not exist in Rust, since you specify bounds in the API itself. This is both a blessing and a curse. As a blessing, it leads to very neat, clean, APIs and you never have to worry about such template expansion errors. As a curse, some of the more complex bits of C++ metaprogramming (check out what people achieve with SFINAE) are not possible. I personally think the pros outweigh the cons, but many people from the C++ world really like the power of template metaprogramming in C++. Rust is planning on offering procedural macros which address some of the use cases, but not all.
sidlls 10y ago
Cleaner but far less powerful in some respects. Or perhaps, as usual, the restrictions are front-loaded. For example in Rust for some operations on a generic type you must specify the appropriate Trait in the declaration ("<T: TheTrait>"). In C++ this would be deferred until you tried to perform an operation on the type for which no valid code exists after something has been instantiated. Other than metaprogramming, Rust's implementation can provide the same functionality that templates do, in a cleaner way in my view.

herewhere 10y ago

In my humble opinion, after C++ 17, C++ does not need anyone's defense. I had worked on infrastructure pieces in Google and Facebook. Given the scale of data, and number of machines, it would not have viable without C++. Consider running 10 times faster using C++ still consuming thousands of machines that would have been 10s of thousands of machines. However, if your application runs fine using any slower language still consume single machine, it might not make sense in that case.

sqeaky 10y ago
"Need"... I hope. We could make that sentence damning or glorifying, depending on the missing word choice and someone would argue with you about it, no matter what word.

symlinkk 10y ago

C++ is an insanely versatile language, and since you can use any C library with "extern C", it has a huge amount of high-quality libraries available for it. ffmpeg, openSSL, webkit, Qt. the problem is there is not a cross platform package manager to manage these libraries, and manually downloading and compiling libraries is a hugely painful and error-prone process. it's so bad that big C++ projects like Firefox and Chromium basically write their own scripts that download and build dependencies, and simply commit the source code of the libraries they use directly into their own tree. I believe there is some thought being put into making a C++ package standard [0], which would do wonders for the language. in my opinion half of the reason Node took off is because npm is so easy to use, and people are getting excited about Rust partially because Cargo is so well thought out. Now I might be wrong here, but I think if you took modern C++ (no raw pointer manipulation) and combined it with a good package manager, I think you would pretty much erase any advantages Rust offers. [0]: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0235r0.pdf http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p023...

fsloth 10y ago
"manually downloading and compiling libraries is a hugely painful and error-prone process." I think you are exaggerating. Most projects with any user base provide ready binaries which able to get going pretty fast. "it's so bad that big C++ projects like Firefox and Chromium basically write their own scripts that download and build dependencies, and simply commit the source code of the libraries they use directly into their own tree." I would not call this 'bad' but resilient. "Replicating is bad" is a non value adding rule of thumb, imo. That said, yes, it's very hard to start incorporating third party libraries to C++ when compared to any other language.
- gcp 10y ago
  Most projects with any user base provide ready binaries which able to get going pretty fast. But what about the dependencies of those binaries/libraries? Manually playing that cat and mouse game just sucks.
- TillE 10y ago

pka 10y ago

From a practical point of view, in many cases the performance critical sections are tiny compared to the rest of the codebase. Imposing such a cognitive overhead on the programmer when 90% of the code are executed once a second just to make those 10% really really fast, and then screaming "performance!!!" is not very convincing. Just use a high-level language and drop to C when needed. Anyway, the author later says he just enjoys writing low-level C++ code, however unpractical this may be. In which case I don't really see the point of defending his choice.

panic 10y ago
But once you've optimized those sections, the rest of the performance problems are left scattered through your code. I've had to rewrite a system in C++ just a few weeks away from shipping because even after optimizing all the performance-critical sections, we still needed that extra 15% or so of "ambient" performance.
- malisper 10y ago
  > we still needed that extra 15% or so of "ambient" performance. This doesn't make sense to me. That 15% of time is spent somewhere. It certainly isn't just "ambient".
  - panic 10y ago
    Yes, it's spent carrying out the fundamental operations of the language (mostly method lookup and dispatch in this case).
- pka 10y ago
  Sure, then you have a valid use case for C/C++ (even better, Rust!) But often people don't and still use C++.
  - deleted 10y ago
    [deleted]

bitwize 10y ago

If you're starting a new system-level project, you should be using C++ or Rust, not C and certainly not Go (which was designed for kids to write microservices with; in other words it competes with Ruby and Node, not C++). A modern language should support static typing with parametric polymorphism and statically determined object extent for most objects (with well-defined extent for the rest). Rust also gives you statically determined object access.

microcolonel 10y ago
How can you, knowing absolutely nothing else about the use case, suggest a solution? What if they're on an architecture where the libc++ or rust runtime is low quality? What if their application needs to be NUMA aware? There are plenty of reasons not to use C++ or Rust. They are not magic bullets which solve all engineering challenges.

lostdog 10y ago

It's hard to enjoy programming in C++ because the compile times are so long. C++ has grown up a lot, and smart pointers, a flexible template system, and lambda expressions, help you get a lot done easily, but every time you code up a useful abstraction, you risk ballooning your compile time.

TillE 10y ago
Yeah, this is the genuine pain point experienced by actual C++ developers. Though really only templates will kill your compile times; other modern features are pretty safe. Modules will help. Hopefully.

chhs 10y ago

I found C++ very complex and difficult to work with, though it is very powerful in terms of performance. There is also several years of libraries available in C++ that is difficult to leave behind. If you are looking for something like C++ in terms of performance and has a nicer syntax, you should try the D programming language. It's very nice to use, as fast as safe C++ code (you can write unsafe C++ that is faster), has stronger typing, templates, mixins, and can interface with C /C++ libraries. I've moved my personal projects over to D, I've started writing a game with OpenGL, SDL, ASSIMP, Devil and it's much easier than C or C++. Some links for those who are interested: Main website: http://dlang.org/ http://dlang.org/ Package manager: http://code.dlang.org/ http://code.dlang.org/ Some interesting documentation pages: Interfacing with C: http://dlang.org/spec/interfaceToC.html http://dlang.org/spec/interfaceToC.html Interfacing with C++: http://dlang.org/spec/cpp_interface.html http://dlang.org/spec/cpp_interface.html Templates: http://dlang.org/spec/template.html http://dlang.org/spec/template.html Inline Assembler: http://dlang.org/spec/iasm.html http://dlang.org/spec/iasm.html

RobertDeNiro 10y ago
How easily can you use D on something that's not x86? Is there decent cross compilation?
- chhs 10y ago
  I've not used D on platforms other than x86 but I have heard cross compilation mentioned in the comments of some conference talks. I found this page which has the status of the LDC compiler on various platforms. It looks like it is still under development but I don't know recently that page was updated. Status of various platforms: https://wiki.dlang.org/LDC https://wiki.dlang.org/LDC
- Ace17 10y ago
  At least one of the prepackaged D compilers of Debian (GDC) can target ARM, and I've tried it, it works!

hellofunk 10y ago

> a rather weak type system, one inherited with relatively few changes from C I don't understand this statement at all. C is a much weaker type system than C++. You can do things in C that will never compile in C++, it is much, much stricter.

netheril96 10y ago

> Templates are objectively extremely difficult to understand and use correctly Really? Template metaprogramming is not the only use valid use of templates. Most time a simple <class T> is enough and that is already a huge improvement over C.

rubber_duck 10y ago
Even most meta programming is not extremely difficult, unless we're talking boost level stuff, and more importantly it allows you to do super powerful interfaces for your API that are trivial to use (the implementation might get complex but consumption shouldn't be). Like say you have a collection of entities where each entity can have one or more components of different types. Now you want to find all entities with components A, B, C and the returned value should have typed references to components - it gets a bit hairy to implement but it's trivial to use and efficient.

jwatte 10y ago

C++ is called a "bad" language by people who think go or JavaScript are "good" languages.

tapirl 10y ago

I'm experienced in c++98. I feel c++now is a new language full of weird syntaxes. I mean, unnecessarily weird. I don't know why so many languages support lambda nowadays. It looks so weird and unnatural. I still have to use c++ in some projects, never for the new syntaxes, just for there are some libraries I must use.

tdsamardzhiev 10y ago
Lambdas give you a (somewhat) saner syntax for 1. Defining a function within a function. 2. Capturing a function call for later use.
- tapirl 10y ago
  Couldn't it be some less weird, just like the anonymous functions in JavaScript and Go? Even the lambda in Java is much readable than c++. It give me the feeling that, c++ gives every corner a special syntax, or c++ adds new features by adding new syntaxes, there is no the word "reuse" in the process of improving c++. In go, anonymous functions and general functions and methods have no much differences. But in c++, lambda and general functions and class methods are too different. Using class methods as callback in c++ is awful. C++1x features make c++ code less readable, for fewer and fewer programmers know every syntax corners in c++.

makecheck 10y ago

Templates only generate maximally-efficient code in theory. Generality kills them in practice; or, it makes the template code twisted to the point of insanity. For example, there is no space-efficient way to model optional<T> for more than one value in a structure type; if you have several optional fields, it would make much more sense to be able to track optional state as single bits of one field (say) but the class structure prohibits such a space optimization and requires each template to track its own is-defined value. Pointless. It is also essentially impossible to know that your code is well-tested: even when using something large and well-known like Boost, its authors cannot know what will happen when you substitute in 4 of your own types (my bet is “result not quite working as intended; obscure bugs added”). I use templates but I am quite aware of code complexity and I essentially stop when the templating goes too far. Somewhere along the line, we seem to have gotten into a mode of wanting generic code at all costs. Why? It is just fine to expose a few common specific methods when those are very helpful and clear (such as classes exposing a “string value”, “integer value” and “float value” instead of trying to provide some single partially-specialized template mess of a method that manages to still not quite work right in every scenario).

Animats 10y ago
Somewhere along the line, we seem to have gotten into a mode of wanting generic code at all costs. I know. Years ago I proposed a vector library for 2, 3, and 4 element vectors [1] as a standard. The immediate complaint was that it didn't use templates. [1] http://www.animats.com/source/graphics/algebra3.h http://www.animats.com/source/graphics/algebra3.h
- slavik81 10y ago
  The trouble is that a reasonable requirement such as single-precision floating point support would require a developer to copy/paste/modify hundreds of LOC. The choice is really fork, duplicate or template. I don't blame glm for picking the latter. Every option is painful, but templates might be a little less so.

chaotic-good 10y ago

This article doesn't have a clue. For example: > but many C++ programmers disable exceptions for performance I have never seen a project like this for 10+something years. The only piece of code with disabled exceptions that I've seen was created for Atmel controllers. And in modern C++ exceptions is zero-cost. Your paying for exceptions only when they occur so, nobody is disabling exceptions now. This is not the only line that bugs me but I don't have enough time for it right now.

panic 10y ago
There are reasons to disable exceptions aside from performance. Google's C++ style guide (which bans their use) discusses some of the pros and cons: https://google.github.io/styleguide/cppguide.html#Exceptions https://google.github.io/styleguide/cppguide.html#Exceptions
- chaotic-good 10y ago
  I saw this first time many years ago. It clearly states that exceptions is a good thing but shouldn't be used in Google's projects because their code is not prepared for exceptions: > On their face, the benefits of using exceptions outweigh the costs, especially in new projects. However, for existing code, the introduction of exceptions has implications on all dependent code. If exceptions can be propagated beyond a new project, it also becomes problematic to integrate the new project into existing exception-free code. Because most existing C++ code at Google is not prepared to deal with exceptions, it is comparatively difficult to adopt new code that generates exceptions. And most importantly, I don't think that they're disabling exceptions using compiler flag. I'm sure that they just using error codes for error handling instead of exceptions.
santaclaus 10y ago
> nobody is disabling exceptions now Embedded people still disable exceptions.

retrogradeorbit 10y ago

AFAIK C++ still doesn't have a finally construct for its exceptions. Are there any plans to introduce it? Is so, when does it land?

sandeatr 10y ago
C++ does not need finally, so it would not make much sense to add it. RAII is superior and is what is used instead. Finally would likely just encourage people to write really awful C++ code.
- retrogradeorbit 10y ago
  So are you saying that C++ has no plans to implement finally? (also I totally disagree that RAII is superior to finally. Finally, being lexically scoped, is far simpler, far shorter and far easier to understand. https://codecraft.co/2013/10/31/why-we-need-try-finally-not-just-raii/ https://codecraft.co/2013/10/31/why-we-need-try-finally-not-... )
  - sandeatr 10y ago
    That article does not convince me, scope guard + lambda appears to work just as well as finally, and is actually shorter(see tianyuzhu's comment) I do not know if anyone has proposed it for C++, but I would be surprised if it passed given that it doesn't accomplish much.
- oselhn 10y ago
  RAII is not superior both ways have their own drawbacks. You can forget to write finally and it may produce duplicated code. On the other hand RAII requires you to create new type just for exception safety (scope guard - which you may also forget to use). I prefer RAII but there are situations where finally leads to more readable code.

mrbrowning 10y ago

This is myopic in the characteristically self-undermining way that most of these defenses are. I actually like modern C++ well enough for the niche described here; lambdas (and the control they offer over captured variables), type deduction, ranged fors and the like make it pleasant enough to write for being as performant as it can be. I've written many more lines of C++ than Rust. But it's still apparent that language-enforced invariants are quite a different species from conventions that will enable safe programs if everyone uses them correctly at all times. You can maybe guarantee that for a team, but can you guarantee it for several teams? Can you guarantee it for every external dependency? I can imagine plenty of pragmatic analyses today ending up with C++ as the ideal choice of language, but the monomaniacal focus on Performance ignores ecological concerns like these and also mostly doesn't grapple with the fact that there's plenty of low-hanging fruit to get to performance-wise in any project before something like a fundamental 1.2x performance penalty on Rust's part really matters, especially considering how domain-dependent that number is likely to be. Pure speed is a pretty poisonous obsession in our field, IMO, and I think we've reaped the whirlwind for it already. It's time for a more holistic outlook.

pjmlp 10y ago
As example, I never had any issue with bounds checking being enabled in all languages I used through my career. Even in C++, I always had bound checking on my own classes and always make use of the validation flags in VC++. It never mattered to the type of applications I was involved with.
- anonymoushn 10y ago
  I spent some time working on HFT systems. These things needed to achieve end-to-end timings (from a tick being DMAed into our memory to placing an order) around xx microseconds at the 99th percentile. The bulk of the code was written in a language that forced us to have bounds checking everywhere, and that was totally fine.
  - yxhuvud 10y ago
    I'd assume most array boundary checks can be optimized away by a good compiler anyhow, assuming the array semantics allow that in the language in question.

ishitatsuyuki 10y ago

Templates: originally for generics, now misused for SFINAE and slowing down the compiler. Copy-elision: the copy constructor is unneeded, we should be move by default. Answer: Rust.

Const-me 10y ago

Very close to my view. Here’s my blog post about that: http://const.me/articles/why-cpp/ http://const.me/articles/why-cpp/

sargun 10y ago

A few things: 1) Writing concurrent code in C++ is exciting (this is a bad thing). Processors are not getting much faster in serial execution, but the number of cores are continuing to increase More here: http://joearms.github.io/2013/03/28/solving-the-wrong-problem.html http://joearms.github.io/2013/03/28/solving-the-wrong-proble... 2) Programmer time is (usually) more costly than anything else in your organization. I'd argue that for most organizations, they're not making enough money per unit of throughput to justify the excessive programming time. 3) C++ is not designed for operators. Rust has this problem too. Once you know how to inspect a Java, Erlang, or Go program, the tools become familiar.

Const-me 10y ago
First, OpenMP isn’t that bad. Second, the author of the article you’ve linked forgot about another kind of parallelization, SIMD. Realistically, SSE and AVX instructions are only usable from assembler, C, C++, and Fortran. Sometimes throwing hardware at problems don’t work. Either because it’s technically impossible (console games, mobile) or because you don’t own the hardware (PC games, desktop software). For such products, either you spent “excessive programming time” programming C++, or you won’t release any product at all.