6 ms·
I'll reply at all the above here. When you have load/concurrency that needs you to move to C++ there's no doubt C++ is right. When you reach that level though
by pothibo 13y ago
I'll reply at all the above here.
When you have load/concurrency that needs you to move to C++ there's no doubt C++ is right.
When you reach that level though, you will usually have the resource to build infrastructure specifically designed to your need, dismissing any "general" purpose C++ framework.
All the example mentioned here are using in-house products for the most part.
- betterunix 13y agoI am not sure it is ever true that there are no doubts about C++ being "right." It might be "good enough," but it is a generally bad language that would not be my first choice for anything (I would sooner use C, but even that's not my top choice).
- pothibo 13y agoWell, I might have over-emphasize on what is "right". Blame this on the language barrier :)
- alexchamberlain 13y agoAnd I would sooner use modern C++, it is personal preference and experience.
- betterunix 13y agoIt's not about experience, it is about the language. Modern C++ is basically a motorized stone hand-ax. Even experienced C++ programmers are surprised by undefined behavior and unexpected semantics.
- pbsd 13y agoA significant amount of undefined (and unexpected) behavior in C++ is inherited from C, for compatibility. You'd sooner use C, and fall into undefined behavior quickly as well. C++ is large and hard to master, but I don't think UB is the best reason to choose C over it.
- CCs 13y agoC++11 is years ahead of Java. http://herbsutter.com/elements-of-modern-c-style/ http://herbsutter.com/elements-of-modern-c-style/ I especially like the fact that you can specify which variables are captured by the closure: http://www.cprogramming.com/c++11/c++11-lambda-closures.html http://www.cprogramming.com/c++11/c++11-lambda-closures.html I use both C++ and Scala on daily basis and there are just a few things I wish C++ had from Scala. On the other hand it is a huge time saver not having to worry about the JVM GC freeze.
- happy_dino 13y ago> not having to worry about the JVM GC freeze Bad engineers blame their tools.
- CCs 13y agoGood engineers start with good tools and avoid wasting time. See section 9 http://www.joelonsoftware.com/articles/fog0000000043.html http://www.joelonsoftware.com/articles/fog0000000043.html
- happy_dino 13y agoYeah, let's use a memory unsafe language, handle memory management by hand and just completely ignore the fact that no human being has ever managed to consistently write bullet-proof code in it. Using software which automates memory management, engineered by the brightest minds on this topic, is for hipsters, right? I guess you also roll your own crypto and implement stuff in assembler “for performance”?
- CCs 13y agoIt depends on the use case. Sometimes you need performance or there are other constraints, in which case your choice of language is very limited. Automated memory management works, but not all the time. And how about other resources? How you make sure your mutex gets released? Add a comment "please don't forget to release this one"? How about file handle, temporary file, serial port, DMA, GPU, network port and other limited resources? BTW, I think most of the brightest minds you mention use C or C++ on daily basis. :)