11 ms·

Modern C++ Won't Save Us

326 points by neptvn 7y ago

deleted 7y ago
[deleted]
781 7y ago
There was an article recently about a behavior which in a recent version of C++ was made from defined behavior into undefined behavior, because making it undefined allowed for better compiler optimizations. I always thought that undefined behaviors were historical accidents. But apparently sometime people just say "hey, lets add a few more undefined behaviors" This is the insanity of C++
- dman 7y ago
  Can you please find a reference? That sounds interesting.
  - tmyklebu 7y ago
    Not exactly what you asked for, but C11 added this bit that was not there in C99: An iteration statement whose controlling expression is not a constant expression, that performs no input/output operations, does not access volatile objects, and performs no synchronization or atomic operations in its body, controlling expression, or (in the case of a for statement) its expression, may be assumed by the implementation to terminate. And C++11 added this bit that wasn't there in C++03: A loop that, outside of the for-init-statement in the case of a for statement, - makes no calls to library I/O functions, and - does not access or modify volatile objects, and - performs no synchronization operations (1.10) or atomic operations (Clause 29) may be assumed by the implementation to terminate. [Note: This is intended to allow compiler transformations, such as removal of empty loops, even when termination cannot be proven. -- end note]
- taspeotis 7y ago
  I am happy to be proven wrong but I feel that they’d never change defined behavior to undefined. Unspecified to undefined sounds more likely. There’s this article [1] about compilers exploiting undefined behavior but ... it’s already undefined behavior. [1] https://devblogs.microsoft.com/oldnewthing/20140627-00/?p=633 https://devblogs.microsoft.com/oldnewthing/20140627-00/?p=63...
- sbov 7y ago
  This sounds wrong. You're probably thinking of undefined behavior that happened to behave the same across all available C++ compilers, so people began to rely on it. But since it was technically undefined behavior, optimizers were free to take advantage of it, and when they started to it smashed any code that relied on that undefined behavior behaving in a consistent way.
  - zaphar 7y ago
    While technically correct, (which is the best kind of correct), the sad reality is that de-facto standards matter. Languages that understand this tend to be safer than languages that do not.
- systemBuilder 7y ago
  In the article the compiler noticed that because of the loop iterator reading the array a[i+1] ... under the assumption the program never indexed beyond the end of the array ... The compiler assumed the loop variable was always less than the limit and therefore changed the loop into an infinite loop. This is the insanity of some of the newer compilers which assume your program never performs an undefined behavior. They compile your mildly buggy slightly undefined code into shit*.
0xDEEPFAC 7y ago
What do you need saving from - Ada has existed for nearly 30 years now ; )
- ajxs 7y ago
  I came here to the comments to post this exact thing, haha. I'm very late to the Ada party, and I'm amazed at how ahead of its time this language was. It's still very usable and modern by today's standards.
  - DoingIsLearning 7y ago
    > by today's standards You make it sound like Ada stopped in the 80's. They don't release standards in rapid succession but 'Ada 2012' has pretty much all of the features that people were asking for in C++ since 2011. The only issue (on top of the obvious lack of coolness and hype around it) is that professional grade Ada compilers/toolchain are still quite a high cost for single developers or small companies. AdaCore's business model is still pretty much focused on support contracts to big Aerospace/ATC/Defense clients.
    - ajxs 7y ago
      My comment was more addressing the general public misconceptions of the language. I showed some of my teammates the work I've been doing in it and they were shocked, expecting the language to look like COBOL. When I reference "today's standards", I was referring to the kinds of modern features people expect from a newer language. I haven't had too many problems using the community version of Gnat made by AdaCore, but I share many people's concerns with the main toolchain being developed by a private enterprise who commercialise it. The version of GCC bundled with Fedora Linux IIRC had an Ada toolchain out of the box too. The lack of runtime support for a wide range of architectures/boards was a bit of a bummer, but that's just a function of it's popularity I guess.
    - 0xDEEPFAC 7y ago
      Many of AdaCore's "community" versions are the full compiler and if they dont have builds available for your bareboard arch you can build it yourself or get one from gcc. The only difference is that use of the special "GNAT.X" packages outside the standard runtime are under a GPL restriction and you would be required to export those dependencies as a separate lib and do open dev on it. Otherwise you are free to sell or keep any trade secrets you want without giving AdaCore anything.
namirez 7y ago
This has been discussed extensively in the C++ community. I think if you need a very safe code, you shouldn't use the string_view or span without thinking about the potential consequences. These are added to the language to prevent memory allocation and data copy for performance critical software. Herb Sutter has concrete proposals to address this issue and Clang already supports them: https://www.infoworld.com/article/3307522/revised-proposal-could-solve-longstanding-c-bugs.html https://www.infoworld.com/article/3307522/revised-proposal-c...
- wwright 7y ago
  The thing is, Rust has tools that are easier to use _and_ have great performance _and_ prevent security and stability mistakes.
  - the_trapper 7y ago
    However Rust is single vendor and single implementation, has a much smaller community and ecosystem than C++, is not standardized, and does not support all of the platforms and use cases that C++ does.
    - wwright 7y ago
      That’s very true. But all of those communities, ecosystems, standards, and use cases have an extreme learning curve and a very deep problem with security. :-)
      - the_trapper 7y ago
        Rust's learning curve isn't exactly a shallow one either. For the record I think Rust has a lot going for it, but it is not the C++ killer that many are touting it to be.
        swiftcoder 7y ago
        It's a bona fide C++ killer for applications that are both security and performance critical. It's already gaining traction for those applications even within relatively conservative engineering organisations. That said, there are many performance-critical applications who are not security-critical, and in those I'd expect C/C++ to persist pretty much indefinitely. And many security-critical applications which are not performance-critical, and can perfectly well be served by garbage collected languages like Java/C#/Go.
sys_64738 7y ago
Today's C++ will be considered a cobbled together relic in a few C++ standards time periods!
- ncmncm 7y ago
  By then Rust will also seem a cobbled-together relic, and you will be chasing the new hotness. In the meantime, we are writing the code that makes the world work. In C++. By then, many will also be writing it in Rust, and you will be sneering at them, too. It has always bern easy to sneer at people busy making things work.
raphlinus 7y ago
From the article: > Dereferencing a nullptr gives a segfault (which is not a security issue, except in older kernels). I know a lot of people make that assumption, and compilers used to work that way pretty reliably, but I'm pretty confident it's not true. With undefined behavior, anything is possible.
- _wmd 7y ago
  Linux hit a related situation: a harmless null pointer dereference was treated by GCC as a signal that a subsequent isnull test could not be true, causing the test to be optimized away. https://lwn.net/Articles/575563/ https://lwn.net/Articles/575563/
  - mjevans 7y ago
    My opinion on that, is that such code MUST NOT be optimized away. Instead it should be a compile error.
    - raphlinus 7y ago
      You might wish for that, but the ship has sailed. Undefined behavior means that the implementation can do whatever it can. That said, I do expect tools, both sanitizers and static analyzers to improve to detect more of these kinds of cases.
      - umanwizard 7y ago
        Well, not exactly. There are things that are UB according to the standard but that particular compilers give an option to make defined: see `-fwrapv`, for example.
      - AnimalMuppet 7y ago
        There have been static analyzers that will detect this for years. They report "check for null after use" or some such.
      - lmm 7y ago
leshow 7y ago
Rust and Swift have different definitions of memory safety, don't they?
- 0815test 7y ago
  Yes, AIUI Swift does not ensure memory safety for concurrent code like Rust does. You have to expressly opt-in to concurrency-safety, and it's not checked by the compiler. Go definitely has this issue, which is admittedly bizarre for a language that's so often used to code network-oriented services making heavy use of concurrency.
  - favorited 7y ago
    That's because Swift doesn't have a first-class concurrency story yet. I imagine that concurrency safety will be sorted out when Swift gets concurrency, but in the meantime all Swift concurrency is using C primitives like pthreads and libdispatch.
    - leshow 7y ago
      That sounds like it's going to be a mess. If they introduce compile time checks that have the same strictness as Rust it will break existing code. It seems like Swift has already done that a few times over.
      - favorited 7y ago
        Using a new language concurrency feature would require you to change your code anyway, the same way using any new feature would. And when the Elm/Rust-style ownership annotations are made public, they will be opt-in.
  - mlindner 7y ago
    I find anyone using Go for networking code bizarre. It's bizarre to me the language ever caught on especially because all their design goals are explicitly the wrong goals. Their goal was to make a "simple like C" language which simply disguises the complexity in writing software. Go simply punts complexity to technical debt of any project and assumes you will throw out your code after a year of using it.
jclay 7y ago
I really don't get all the hate that C++ gets. The suggested alternatives in the article are Rust and Swift. What if you need to develop a cross platform GUI, that has a backend running a CUDA or OpenCL algorithm? For the former, you can use Qt, which isn't without it's warts, but is pretty tried and true in my experience (see KDE, VTK, etc). For the latter, you'll end up writing your CUDA code in C++ anyways. I guess you could go the route of writing bindings, but that is not without additional effort. Not that it won't happen for Rust, but C++ also has tooling suited for enterprise use that are largely unmatched in other languages (Visual Studio, Qt, etc). Sandboxing, static analysis, and fuzzing tools are also mostly built for C/C++ codebases. It's also an ISO standard language which makes it both a language full of warts due to decision by committee, but also a candidate for a stable, long-lasting language that will outlive many of us. (Try finding an ISO Standard Language you don't hate). Either way, C++ is certainly not for every project, but the articles scattered around the web claiming it should be superseded by Rust are plentiful. These opinion pieces make no attempt to credit C++ for when it does make sense to use. Despite it's quirks, it is still the most optimal way to program HPC applications or cross platform GUIs that are not Electron based. The security tools around it and the fact that it's an ISO standard language make it a solid choice for many enterprises.
- mannykannot 7y ago
  I do not think it helps to think in emotional terms such as 'hate'. There is nothing wrong with discussing potential problems, and the current utility of the language should not stop us asking whether we could do better in future. FWIW, I use C++, not Rust or Swift, and I have a fair amount of knowledge and experience vested in it, but I think these questions are worth asking.
  - Rexxar 7y ago
    > I do not think it helps to think in emotional terms such as 'hate' I think 'hate' really represent the mind of some people (even if they are a minority) but even if we ignore this extreme, the level of irrationality in technical discussions is generally quite high. You need to have rational people to have a rational discussion. The sad reality is that a lot of technical discussions are only superficially rational and are often a political play to assert superiority on other people (it's true for languages, frameworks, code editors, methodologies, etc ... ).
jmole 7y ago
Question - How does one write microcontroller code (or other memory-mapped I/O code) using a memory-safe language?
- tedunangst 7y ago
  By calling unsafe code. :) The semantics and guarantees offered by the interface vary, but that's the short version.
  - Nelson69 7y ago
    I have over 10 years of professional C++ and helped teach a course on it in college. One of my observations, and I may be off, is that a fair number of C++ users tend to take on a kind of macho attitude about it: it's a hammer for every nail, if you make certain mistakes you shouldn't use it or maybe be programming at all, garbage collection and other safety apparatus are kind of like training wheels while the "big boys" don't need that sort of thing. I'm being a little snarky here, but if you are truly a macho developer, then crapping out that unsafe code in optimized assembly or C or something is a really really easy time to show off and shouldn't be such a big deal for such a seasoned developer. Instead, the question is always raised in this more insecure way: for that tiny percentage of the time you have to do some bit-banging (and it's usually pretty small and encapsulated on most embedded projects) you had might as well do the whole thing in C or C++.
    - hermitdev 7y ago
      I've over 15 years professional experience in C++, around 16 years in C#, and around 14 in Python, all overlapping. For me, it's about using the right tool for the job. It's not being a macho developer, but sometimes you need the hammer that C++ is, and you'll probably hit your thumb a few times using it.
  - User23 7y ago
    Often that unsafe code is assembly language.
shmerl 7y ago
> Nonetheless, the question simply must be how we can accomplish it, rather than if we should try. Even with the most modern C++ idioms available, the evidence is clear that, at scale, it's simply not possible to hold C++ right. So, how then? That's the main question indeed :)
User23 7y ago
For systems programming languages, safe by default with scoped unsafe code is a Pareto improvement on unsafe everywhere.
- pjmlp 7y ago
  A feature that exists since 1961, across several systems languages.
  - kiriakasis 7y ago
    I never understood this type of comments, is what you are trying to say something like: "It was already tried and failed, why is this time better" "Mainstream languages always end up not using it" "People should reference more the original works of the past" ... One of the many explainations of the name Rust is that it represents a collection of old ideas. What was the point you were trying to convey in specific?
    - pjmlp 7y ago
      People should reference more the original works of the past instead of rediscovering them
      - kaens 7y ago
        I think more rediscoveries may be references than you suspect, but in the cases that are rediscoveries there is a bit of a knowledge and discoverability issue for PL features for people who aren't PL nerds already. I'd love it if more people had a more solid understanding of the ideaspaces that have been covered in the PL landscape, but considering that most common paths to working in software (and even to creating and contributing to langs) don't involve needing to know PL history I'm not sure how to get there from here. If you have resources you think people should be utilizing here, please speak up.
        pjmlp 7y ago
        I keep posting them here. How I got to learn about them? Having a solid Informatics Engineering degree, with focus on systems programming, graphics and compilers, and a very nice university library. That was it, we had to hunt for books, compuserve, gopher and BBS were still a thing. Nowadays learning about the history of PL is a google/bing/... search away, a couple of seconds with access to plenty of scanned papers and conference proceddings since the early 60's, so one has to be quite lazy not to research them.
jasonhansel 7y ago
Can someone at least make a linter that ensures you only use a "safe" subset of C++?
- 0815test 7y ago
  The answer is essentially no, at least if you're seeking substantial levels of assurance or safety. Even the C++ Core Guidelines effort, https://github.com/isocpp/CppCoreGuidelines https://github.com/isocpp/CppCoreGuidelines which is the closest thing to what you describe and is driven by influential members of the ISO C++ community including B. Stroustrup, does not claim that they'll be able to make C++ memory safe.
- steveklabnik 7y ago
  The Core Guidelines are an attempt at this, but it’s not fully safe. Safer, which matters! But not safe. There isn’t really any useful safe subset of C++. If there were, Rust may never have been created in the first place.
  - ncmncm 7y ago
    This is not, in fact, the case. Back when Rust was begun, it had some merit, but C++ is a rapidly moving target. C++ still does not have an absolutely safe subset, but it has a safe-enough subset, and plenty of other merits that will ensure its continued competitiveness. Rust will continue improving, too, and someday may be as expressive as C++ is today, or perhaps even as expressive as C++ is then. That will be a good day, although by then some other language will be on the rise, its users hoping to displace C++ and, given enough luck and hard work, Rust. V could be interesting.
  - pjmlp 7y ago
    Still, C++ is good enough for the unsafe low level bindings of a Java/.NET application. Until Rust's tooling catches up with C++/CLI, C++/CX, C++/WinRT + .NET or Java + C++ (Eclipse/Netbeans/Oracle Studio), CUDA, Unreal/Unity, GLSL/HLSL/Metal Shaders allow for, it will stay as a safe way to write CLI apps and a couple of UNIX libs. I like the language and advocate it often, but I am also very pragmatic regarding the areas I and customers work on.
ycombonator 7y ago
"Don't be clever". Yes. In the CppCon 2017 opening keynote: The Learning and Teaching Modern C++. The accompagnying slide says "Don't be (too) clever" but I can't promounce parentheses :-). My point was to discourage overly clever code because "clever code" is hard to write, easy to get wrong, harder to maintain, and often no faster than simpler alternatives because it can be hard to optimize. - Bjarne Stroustrup
MiroF 7y ago
The stringview example is surprising and certainly something I could have fallen for. I feel like the lambda example is pretty contrived. If I was returning a lambda that was capturing values by reference, I would already be pretty wary of UB.
- umanwizard 7y ago
  I guess it comes down to the individual reader. I had to look at the lambda example several times to realize what the problem was with it. I guess my eyes just skim over the capture section unless I have some good reason to look at it. The string_view example, on the other hand, was immediately obviously wrong to me.
jandrewrogers 7y ago
A significant issue I have with C++ is that even if your code base is pure C++17, the standard library is a Frankenstein's monster of legacy and modern C++ mixed together that required many compromises to be made. A standard library that usefully showed off the full capabilities of C++17 in a clean way would have to jettison a fair amount of backward compatibility in modern C++ environments. I've noticed that more and more people like me have and use large alternative history "standard libraries" that add functionality, reimagine the design, and in some cases reimplement core components based on a modern C++ cleanroom. I've noticed that use of the standard library in code bases is shrinking as result. You can do a lot more with the language if you have a standard library that isn't shackled by its very long history.
- lallysingh 7y ago
  What legacy? It's not like there was a single "before time." There are problems coming up with all of it, because the underlying runtime model provides too few guarantees. We'll be plugging holes the rest of our natural lives.
  - millstone 7y ago
    No, the problem is NOT the underlying runtime model. In fact it's often the opposite: the STL tries to provide too much. An excellent example is std::unordered_map. This type was introduced to address perf problems with std::map. But unordered_map forces closed addressing, separate allocation, etc. which limit its performance. In return you get stronger iterator invalidation guarantees but these are rarely useful. Meanwhile Abseil's swiss tables, LLVM's DenseMap, etc. illustrate what a high-performance C++ hash table could be.
- hak8or 7y ago
  Can you or others post such alternative standard libraries? The only ones that come to mind are boost (which is a nightmarefor compile times and I feel is a mishmash of old and new) and googles absiel which I haven't actually tried enough to make an opinion about.
Animats 7y ago
The C++ people are trying to refit ownership to the language without adding a borrow checker. This is painful. They've made it possible to write code that expresses ownership, but they can't catch all the places where the abstraction leaks. string_view is really a non-mutable borrow. But the compiler does not know this.
- fooker 7y ago
  > but they can't catch all the places where the abstraction leaks. Why does static analysis not work here?
  - deleted 7y ago
    [deleted]
  - kllrnohj 7y ago
    It does, it's just a warning and not an error. And also experimental. But it does exist, and does catch some of these errors. Example: https://godbolt.org/z/CZTfSx https://godbolt.org/z/CZTfSx
    - humanrebar 7y ago
      I'd rather run diagnostics as a separate CI pass, so warnings work for me perfectly.
- pjmlp 7y ago
  Not quite true, Google and Microsoft are precisely adding a borrow checker to their static analysis tools. https://herbsutter.com/2018/09/20/lifetime-profile-v1-0-posted/ https://herbsutter.com/2018/09/20/lifetime-profile-v1-0-post...
- int_19h 7y ago
  It's still strictly better than a language with no borrow checker and no way to express ownership (other than comments), like C, or C++ itself before all the smart pointers.
sayusasugi 7y ago
Any HN post mentioning C++ will inevitably be invaded by the Rust Evangelism Strikeforce.
- wutbrodo 7y ago
  You picked a bizarre article to make that comment on...It's hardly irrelevant to the post, as the author's central thesis is that there's no case for choosing C++ over languages like Rust and Swift (he says as much in the article).
- throwupaway123 7y ago
  The Rust Evangelism Strikeforce only exists in completely inane comments like yours, maybe instead of posting memes you comment on the actual content of the article not the headline?
- insulanian 7y ago
  And rightly so! What's wrong with spreading awareness about safer alternative? If that wasn't the case in the past, we'd still be programming in Cobol and Fortran.
  - pjmlp 7y ago
    On the contrary, we had plenty of safer alternatives for systems programming, derived from Algol and PL/I. Then came an OS, with a symbolic price instead of the typical market prices of competing OSes, alongside source code tapes, and a systems programming language that was the "JavaScript" of system languages.
    - 0815test 7y ago
      The biggest factor was that the OS was written to run on minicomputers as opposed to big iron, and was written in a portable language. Thus it could seamlessly jump over to micros (as soon as these became powerful enough, of course), and even later on to embedded and "wearable" compute. You just can't do that unless you're writing in a highly flexible and highly portable language - more like the FORTRAN of systems languages than anything like JavaScript!
nitwit005 7y ago
The string_view issue has popped up even in relatively safe languages. Java's String class used to do something similar, where substring returned a String that referenced the original String object's internal array to avoid a copy. They gave up on it because too many people accidentally held a references to large strings and leaked memory that way.
- kccqzy 7y ago
  As far as I know, this is rather popular. Haskell's ByteString and Text still types do the same. So does Rust, where most of the time you are very consciously borrowing the original string instead of making copies.
foobar_ 7y ago
Can virtualisation solve this ? Is it possible to have a virtualised environment like Qubes but for programs ?
- jcelerier 7y ago
  yes, that's called a "process" in operating systems.
- simias 7y ago
  Virtualization can help reduce the harm caused by a misbehaving program but it won't magically make the program behave correctly. Having a program cause a memory violation and be killed by the OS is the best possible outcome in this case, it stops the program from doing any damage and you get a clear symptom of the problem for debugging. It's when the issue is not that obvious that you're in real trouble because it may start behaving erratically, corrupt data and be exploited by malicious actors to get access to resources that shouldn't be exposed.
pjmlp 7y ago
It is true, C++ has several warts some of them caused by the copy-paste compatibility with C. Which is both a blessing and a curse. A blessing as it allowed us Pascal/Ada/Modula refugees never to deal with what was already outdated, unsafe language by the early 90's. But also makes it relatively hard to write safe code when we cannot prevent team members, or third party libraries, to use Cisms on their code. Regarding the alternatives, Swift is definitly not an option outside Apple platforms. And even there, Apple still focus on C++ for IO Kit, Metal and LLVM based tooling. Rust, yes. Some day it might be, specially now with Google, Microsoft, Amazon, Dropbox,... adopting it across their stacks. However for many of us it still doesn't cover the use cases we use C++ for, so it is not like I will impose myself, the team and customers, a productivity pain, take the double amount of time that it takes to write a COM component or native bindings in C++ for .NET consumption just to feel good. When we get Visual Rust, with mixed mode debugging, Blend integration and a COM/UWP language projection for Rust, then yeah.
- masklinn 7y ago
  > It is true, C++ has several warts some of them caused by the copy-paste compatibility with C. I mean that's a bit of a cop-out given C++ has more non-C warts and UBs than it has C warts and UBs at this point. It's not just "copy-paste compatibility with C" which made std::unique_ptr or std::optional deref and UB.
  - pjmlp 7y ago
    Sure it is, because they need to be compatible with C pointer semantics. The large majority of C++ UB comes from compatibility with ISO C UB 200+ documented cases. And ISO C++ working group is trying to reduce the amount of UB in ISO C++, which is exactly the opposite of ISO C 2X ongoing proposals.
    - masklinn 7y ago
      > Sure it is, because they need to be compatible with C pointer semantics. They don't need to be compatible with unsafe / UB C pointer semantics, allowing them to both contain garbage and be deref'able were explicit decisions the C++ committees did not have to make but chose to.
systemBuilder 7y ago
Many of the problems he talks about come from the lunacy of the C++ compiler making all sorts of temporaries and calling hidden type conversion functions, making all sorts of assumptions that it should never ever ever make without being told by the programmer. That is why C will always be a better language than c++ on a fundamental level. In this area stroustrup took C in a bad direction.
fetbaffe 7y ago
Without any data to back this up, my guess is that there is no good reason to pick C++ for a new project except when the developer is already fluent in C++. Assume we have this abstract developer that has a good knowledge in programming theory but has no experience in programming languages. The developer starts a new project, but in what language? web: Don't see any reason for this. Exist lots of great alternatives. This is not really one of C++ strengths so is not that strange. desktop-GUI: Probably one of the biggest strengths of C++ is the Qt framework, it is solid choice. I can see this a possible choice. However with electron dominating & PWA:s becoming a more viable option it is probably much higher chance that a HTML/JS environment is picked instead, especially how it already dominates the web. And by using TypeScript you can do it an solid language. mobile apps: Most apps are written in some web technology or directly with Swift or Java. Qt has some support for this, but not sure how widely used. My experience with NDK was not pleasant. I can't really see this as a viable option. embedded: I don't do embedded, but my understanding is that plain C is much more common here & if faster development is needed you integrate something like Lua. Maybe? memory safe: use rust I guess. compiled binary: Use golang, no complicated buildstep. Parallellism: Better to use a language designed for this like erlang. Game development: For the majority of games today a scripting language like JavaScript or Lua is good enough. HTML/JS has some really good frameworks for game development today. 3D game development: Probably a good fit to use C++, but I think that C# with Unity is a much better choice. Great framework, good community, however C++ is not bad choice for this. Possible. Commandline tool: If the developer is building the next grep, C++ could fit that, but most commandline tools does not have that performance requirement, Probably do some HTTP, JSON decoding, DB access. Bash is good enough or any other dynamic language. Scientific: my understanding is that today this is mostly python or matlab. Maybe? System development (drivers etc): I know too little about this to make a good assessment, to be fair I put this as a possible choice. And if the developer do decides to use C++ for a new project, the initial cost is quite high to just understand the basics, even if he/she uses the latest C++ version. Copy constructors, lvalue & rvalue (xvalue, glvalue, prvalue...), move semantics, const refs, rvo, smart pointers, auto etc Any good arguments to pick C++ for a new project?
- pjmlp 7y ago
  NVidia is designing their GPUs with C++ in mind as source language. desktop-GUI: I guess you might be joking here with Electron, I rather use my GPU for something else other than blinking cursors. Even with Cocoa, UWP and WPF, the underlying UI shaders are written in C++. Embedded: Yes, C does rule over C++, which is a reason why embedded is so open to security exploits due to wrong manipulation of string and arrays. Parallellism: HPC, FinTech, GPGPU all domains where C++ rules for the time being. 3D game development: C++ is king here, even with Unity the core engine is written in C++. Yes many of us hope to see the day when Unity is 100% written in a mix of C# and HPC#, but even then, LLVM will be part of the stack. Scientific: Someone needs to write those Fortran and C++ libs called by Python and Matlab. System development: Google, Apple and Microsoft use C++ on their driver layers for their respective OSes. IDE tooling: C++ is known for not having IDEs that match what Java/.NET are capable of. Languages that want to take C++'s place, are even worse than C++ in IDE tooling.
IshKebab 7y ago
> Dereferencing a nullopt however, gives you an uninitialized value as a pointer, which can be a serious security issue. Is this really true? Surely it just gives you an uninitialised `int` (or whatever is in the `optional`)?
0xe2-0x9a-0x9b 7y ago
There is no call in the article for a deeper C++ code analysis by the compiler. Deeper analysis will be the future of C++ - the article fails to foresee this.
- notacoward 7y ago
  > Deeper analysis will be the future of C++ As if C++ compile times aren't crazy enough already.

326 points by neptvn 7y ago

deleted 7y ago

[deleted]

781 7y ago

There was an article recently about a behavior which in a recent version of C++ was made from defined behavior into undefined behavior, because making it undefined allowed for better compiler optimizations. I always thought that undefined behaviors were historical accidents. But apparently sometime people just say "hey, lets add a few more undefined behaviors" This is the insanity of C++

dman 7y ago
Can you please find a reference? That sounds interesting.
- tmyklebu 7y ago
  Not exactly what you asked for, but C11 added this bit that was not there in C99: An iteration statement whose controlling expression is not a constant expression, that performs no input/output operations, does not access volatile objects, and performs no synchronization or atomic operations in its body, controlling expression, or (in the case of a for statement) its expression, may be assumed by the implementation to terminate. And C++11 added this bit that wasn't there in C++03: A loop that, outside of the for-init-statement in the case of a for statement, - makes no calls to library I/O functions, and - does not access or modify volatile objects, and - performs no synchronization operations (1.10) or atomic operations (Clause 29) may be assumed by the implementation to terminate. [Note: This is intended to allow compiler transformations, such as removal of empty loops, even when termination cannot be proven. -- end note]
taspeotis 7y ago
I am happy to be proven wrong but I feel that they’d never change defined behavior to undefined. Unspecified to undefined sounds more likely. There’s this article [1] about compilers exploiting undefined behavior but ... it’s already undefined behavior. [1] https://devblogs.microsoft.com/oldnewthing/20140627-00/?p=633 https://devblogs.microsoft.com/oldnewthing/20140627-00/?p=63...
sbov 7y ago
This sounds wrong. You're probably thinking of undefined behavior that happened to behave the same across all available C++ compilers, so people began to rely on it. But since it was technically undefined behavior, optimizers were free to take advantage of it, and when they started to it smashed any code that relied on that undefined behavior behaving in a consistent way.
- zaphar 7y ago
  While technically correct, (which is the best kind of correct), the sad reality is that de-facto standards matter. Languages that understand this tend to be safer than languages that do not.
systemBuilder 7y ago
In the article the compiler noticed that because of the loop iterator reading the array a[i+1] ... under the assumption the program never indexed beyond the end of the array ... The compiler assumed the loop variable was always less than the limit and therefore changed the loop into an infinite loop. This is the insanity of some of the newer compilers which assume your program never performs an undefined behavior. They compile your mildly buggy slightly undefined code into shit*.

0xDEEPFAC 7y ago

What do you need saving from - Ada has existed for nearly 30 years now ; )

ajxs 7y ago
I came here to the comments to post this exact thing, haha. I'm very late to the Ada party, and I'm amazed at how ahead of its time this language was. It's still very usable and modern by today's standards.
- DoingIsLearning 7y ago
  > by today's standards You make it sound like Ada stopped in the 80's. They don't release standards in rapid succession but 'Ada 2012' has pretty much all of the features that people were asking for in C++ since 2011. The only issue (on top of the obvious lack of coolness and hype around it) is that professional grade Ada compilers/toolchain are still quite a high cost for single developers or small companies. AdaCore's business model is still pretty much focused on support contracts to big Aerospace/ATC/Defense clients.
  - ajxs 7y ago
    My comment was more addressing the general public misconceptions of the language. I showed some of my teammates the work I've been doing in it and they were shocked, expecting the language to look like COBOL. When I reference "today's standards", I was referring to the kinds of modern features people expect from a newer language. I haven't had too many problems using the community version of Gnat made by AdaCore, but I share many people's concerns with the main toolchain being developed by a private enterprise who commercialise it. The version of GCC bundled with Fedora Linux IIRC had an Ada toolchain out of the box too. The lack of runtime support for a wide range of architectures/boards was a bit of a bummer, but that's just a function of it's popularity I guess.
  - 0xDEEPFAC 7y ago
    Many of AdaCore's "community" versions are the full compiler and if they dont have builds available for your bareboard arch you can build it yourself or get one from gcc. The only difference is that use of the special "GNAT.X" packages outside the standard runtime are under a GPL restriction and you would be required to export those dependencies as a separate lib and do open dev on it. Otherwise you are free to sell or keep any trade secrets you want without giving AdaCore anything.

namirez 7y ago

This has been discussed extensively in the C++ community. I think if you need a very safe code, you shouldn't use the string_view or span without thinking about the potential consequences. These are added to the language to prevent memory allocation and data copy for performance critical software. Herb Sutter has concrete proposals to address this issue and Clang already supports them: https://www.infoworld.com/article/3307522/revised-proposal-could-solve-longstanding-c-bugs.html https://www.infoworld.com/article/3307522/revised-proposal-c...

wwright 7y ago
The thing is, Rust has tools that are easier to use _and_ have great performance _and_ prevent security and stability mistakes.
- the_trapper 7y ago
  However Rust is single vendor and single implementation, has a much smaller community and ecosystem than C++, is not standardized, and does not support all of the platforms and use cases that C++ does.
  - wwright 7y ago
    That’s very true. But all of those communities, ecosystems, standards, and use cases have an extreme learning curve and a very deep problem with security. :-)
    - the_trapper 7y ago
      Rust's learning curve isn't exactly a shallow one either. For the record I think Rust has a lot going for it, but it is not the C++ killer that many are touting it to be.
      - swiftcoder 7y ago
        It's a bona fide C++ killer for applications that are both security and performance critical. It's already gaining traction for those applications even within relatively conservative engineering organisations. That said, there are many performance-critical applications who are not security-critical, and in those I'd expect C/C++ to persist pretty much indefinitely. And many security-critical applications which are not performance-critical, and can perfectly well be served by garbage collected languages like Java/C#/Go.

sys_64738 7y ago

Today's C++ will be considered a cobbled together relic in a few C++ standards time periods!

ncmncm 7y ago
By then Rust will also seem a cobbled-together relic, and you will be chasing the new hotness. In the meantime, we are writing the code that makes the world work. In C++. By then, many will also be writing it in Rust, and you will be sneering at them, too. It has always bern easy to sneer at people busy making things work.

raphlinus 7y ago

From the article: > Dereferencing a nullptr gives a segfault (which is not a security issue, except in older kernels). I know a lot of people make that assumption, and compilers used to work that way pretty reliably, but I'm pretty confident it's not true. With undefined behavior, anything is possible.

_wmd 7y ago
Linux hit a related situation: a harmless null pointer dereference was treated by GCC as a signal that a subsequent isnull test could not be true, causing the test to be optimized away. https://lwn.net/Articles/575563/ https://lwn.net/Articles/575563/
- mjevans 7y ago
  My opinion on that, is that such code MUST NOT be optimized away. Instead it should be a compile error.
  - raphlinus 7y ago
    You might wish for that, but the ship has sailed. Undefined behavior means that the implementation can do whatever it can. That said, I do expect tools, both sanitizers and static analyzers to improve to detect more of these kinds of cases.
    - umanwizard 7y ago
      Well, not exactly. There are things that are UB according to the standard but that particular compilers give an option to make defined: see `-fwrapv`, for example.
    - AnimalMuppet 7y ago
      There have been static analyzers that will detect this for years. They report "check for null after use" or some such.
    - lmm 7y ago

leshow 7y ago

Rust and Swift have different definitions of memory safety, don't they?

0815test 7y ago
Yes, AIUI Swift does not ensure memory safety for concurrent code like Rust does. You have to expressly opt-in to concurrency-safety, and it's not checked by the compiler. Go definitely has this issue, which is admittedly bizarre for a language that's so often used to code network-oriented services making heavy use of concurrency.
- favorited 7y ago
  That's because Swift doesn't have a first-class concurrency story yet. I imagine that concurrency safety will be sorted out when Swift gets concurrency, but in the meantime all Swift concurrency is using C primitives like pthreads and libdispatch.
  - leshow 7y ago
    That sounds like it's going to be a mess. If they introduce compile time checks that have the same strictness as Rust it will break existing code. It seems like Swift has already done that a few times over.
    - favorited 7y ago
      Using a new language concurrency feature would require you to change your code anyway, the same way using any new feature would. And when the Elm/Rust-style ownership annotations are made public, they will be opt-in.
- mlindner 7y ago
  I find anyone using Go for networking code bizarre. It's bizarre to me the language ever caught on especially because all their design goals are explicitly the wrong goals. Their goal was to make a "simple like C" language which simply disguises the complexity in writing software. Go simply punts complexity to technical debt of any project and assumes you will throw out your code after a year of using it.

jclay 7y ago

I really don't get all the hate that C++ gets. The suggested alternatives in the article are Rust and Swift. What if you need to develop a cross platform GUI, that has a backend running a CUDA or OpenCL algorithm? For the former, you can use Qt, which isn't without it's warts, but is pretty tried and true in my experience (see KDE, VTK, etc). For the latter, you'll end up writing your CUDA code in C++ anyways. I guess you could go the route of writing bindings, but that is not without additional effort. Not that it won't happen for Rust, but C++ also has tooling suited for enterprise use that are largely unmatched in other languages (Visual Studio, Qt, etc). Sandboxing, static analysis, and fuzzing tools are also mostly built for C/C++ codebases. It's also an ISO standard language which makes it both a language full of warts due to decision by committee, but also a candidate for a stable, long-lasting language that will outlive many of us. (Try finding an ISO Standard Language you don't hate). Either way, C++ is certainly not for every project, but the articles scattered around the web claiming it should be superseded by Rust are plentiful. These opinion pieces make no attempt to credit C++ for when it does make sense to use. Despite it's quirks, it is still the most optimal way to program HPC applications or cross platform GUIs that are not Electron based. The security tools around it and the fact that it's an ISO standard language make it a solid choice for many enterprises.

mannykannot 7y ago
I do not think it helps to think in emotional terms such as 'hate'. There is nothing wrong with discussing potential problems, and the current utility of the language should not stop us asking whether we could do better in future. FWIW, I use C++, not Rust or Swift, and I have a fair amount of knowledge and experience vested in it, but I think these questions are worth asking.
- Rexxar 7y ago
  > I do not think it helps to think in emotional terms such as 'hate' I think 'hate' really represent the mind of some people (even if they are a minority) but even if we ignore this extreme, the level of irrationality in technical discussions is generally quite high. You need to have rational people to have a rational discussion. The sad reality is that a lot of technical discussions are only superficially rational and are often a political play to assert superiority on other people (it's true for languages, frameworks, code editors, methodologies, etc ... ).

jmole 7y ago

Question - How does one write microcontroller code (or other memory-mapped I/O code) using a memory-safe language?

tedunangst 7y ago
By calling unsafe code. :) The semantics and guarantees offered by the interface vary, but that's the short version.
- Nelson69 7y ago
  I have over 10 years of professional C++ and helped teach a course on it in college. One of my observations, and I may be off, is that a fair number of C++ users tend to take on a kind of macho attitude about it: it's a hammer for every nail, if you make certain mistakes you shouldn't use it or maybe be programming at all, garbage collection and other safety apparatus are kind of like training wheels while the "big boys" don't need that sort of thing. I'm being a little snarky here, but if you are truly a macho developer, then crapping out that unsafe code in optimized assembly or C or something is a really really easy time to show off and shouldn't be such a big deal for such a seasoned developer. Instead, the question is always raised in this more insecure way: for that tiny percentage of the time you have to do some bit-banging (and it's usually pretty small and encapsulated on most embedded projects) you had might as well do the whole thing in C or C++.
  - hermitdev 7y ago
    I've over 15 years professional experience in C++, around 16 years in C#, and around 14 in Python, all overlapping. For me, it's about using the right tool for the job. It's not being a macho developer, but sometimes you need the hammer that C++ is, and you'll probably hit your thumb a few times using it.
- User23 7y ago
  Often that unsafe code is assembly language.

shmerl 7y ago

> Nonetheless, the question simply must be how we can accomplish it, rather than if we should try. Even with the most modern C++ idioms available, the evidence is clear that, at scale, it's simply not possible to hold C++ right. So, how then? That's the main question indeed :)

User23 7y ago

For systems programming languages, safe by default with scoped unsafe code is a Pareto improvement on unsafe everywhere.

pjmlp 7y ago
A feature that exists since 1961, across several systems languages.
- kiriakasis 7y ago
  I never understood this type of comments, is what you are trying to say something like: "It was already tried and failed, why is this time better" "Mainstream languages always end up not using it" "People should reference more the original works of the past" ... One of the many explainations of the name Rust is that it represents a collection of old ideas. What was the point you were trying to convey in specific?
  - pjmlp 7y ago
    People should reference more the original works of the past instead of rediscovering them
    - kaens 7y ago
      I think more rediscoveries may be references than you suspect, but in the cases that are rediscoveries there is a bit of a knowledge and discoverability issue for PL features for people who aren't PL nerds already. I'd love it if more people had a more solid understanding of the ideaspaces that have been covered in the PL landscape, but considering that most common paths to working in software (and even to creating and contributing to langs) don't involve needing to know PL history I'm not sure how to get there from here. If you have resources you think people should be utilizing here, please speak up.
      - pjmlp 7y ago
        I keep posting them here. How I got to learn about them? Having a solid Informatics Engineering degree, with focus on systems programming, graphics and compilers, and a very nice university library. That was it, we had to hunt for books, compuserve, gopher and BBS were still a thing. Nowadays learning about the history of PL is a google/bing/... search away, a couple of seconds with access to plenty of scanned papers and conference proceddings since the early 60's, so one has to be quite lazy not to research them.

jasonhansel 7y ago

Can someone at least make a linter that ensures you only use a "safe" subset of C++?

0815test 7y ago
The answer is essentially no, at least if you're seeking substantial levels of assurance or safety. Even the C++ Core Guidelines effort, https://github.com/isocpp/CppCoreGuidelines https://github.com/isocpp/CppCoreGuidelines which is the closest thing to what you describe and is driven by influential members of the ISO C++ community including B. Stroustrup, does not claim that they'll be able to make C++ memory safe.
steveklabnik 7y ago
The Core Guidelines are an attempt at this, but it’s not fully safe. Safer, which matters! But not safe. There isn’t really any useful safe subset of C++. If there were, Rust may never have been created in the first place.
- ncmncm 7y ago
  This is not, in fact, the case. Back when Rust was begun, it had some merit, but C++ is a rapidly moving target. C++ still does not have an absolutely safe subset, but it has a safe-enough subset, and plenty of other merits that will ensure its continued competitiveness. Rust will continue improving, too, and someday may be as expressive as C++ is today, or perhaps even as expressive as C++ is then. That will be a good day, although by then some other language will be on the rise, its users hoping to displace C++ and, given enough luck and hard work, Rust. V could be interesting.
- pjmlp 7y ago
  Still, C++ is good enough for the unsafe low level bindings of a Java/.NET application. Until Rust's tooling catches up with C++/CLI, C++/CX, C++/WinRT + .NET or Java + C++ (Eclipse/Netbeans/Oracle Studio), CUDA, Unreal/Unity, GLSL/HLSL/Metal Shaders allow for, it will stay as a safe way to write CLI apps and a couple of UNIX libs. I like the language and advocate it often, but I am also very pragmatic regarding the areas I and customers work on.

ycombonator 7y ago

"Don't be clever". Yes. In the CppCon 2017 opening keynote: The Learning and Teaching Modern C++. The accompagnying slide says "Don't be (too) clever" but I can't promounce parentheses :-). My point was to discourage overly clever code because "clever code" is hard to write, easy to get wrong, harder to maintain, and often no faster than simpler alternatives because it can be hard to optimize. - Bjarne Stroustrup

MiroF 7y ago

The stringview example is surprising and certainly something I could have fallen for. I feel like the lambda example is pretty contrived. If I was returning a lambda that was capturing values by reference, I would already be pretty wary of UB.

umanwizard 7y ago
I guess it comes down to the individual reader. I had to look at the lambda example several times to realize what the problem was with it. I guess my eyes just skim over the capture section unless I have some good reason to look at it. The string_view example, on the other hand, was immediately obviously wrong to me.

jandrewrogers 7y ago

A significant issue I have with C++ is that even if your code base is pure C++17, the standard library is a Frankenstein's monster of legacy and modern C++ mixed together that required many compromises to be made. A standard library that usefully showed off the full capabilities of C++17 in a clean way would have to jettison a fair amount of backward compatibility in modern C++ environments. I've noticed that more and more people like me have and use large alternative history "standard libraries" that add functionality, reimagine the design, and in some cases reimplement core components based on a modern C++ cleanroom. I've noticed that use of the standard library in code bases is shrinking as result. You can do a lot more with the language if you have a standard library that isn't shackled by its very long history.

lallysingh 7y ago
What legacy? It's not like there was a single "before time." There are problems coming up with all of it, because the underlying runtime model provides too few guarantees. We'll be plugging holes the rest of our natural lives.
- millstone 7y ago
  No, the problem is NOT the underlying runtime model. In fact it's often the opposite: the STL tries to provide too much. An excellent example is std::unordered_map. This type was introduced to address perf problems with std::map. But unordered_map forces closed addressing, separate allocation, etc. which limit its performance. In return you get stronger iterator invalidation guarantees but these are rarely useful. Meanwhile Abseil's swiss tables, LLVM's DenseMap, etc. illustrate what a high-performance C++ hash table could be.
hak8or 7y ago
Can you or others post such alternative standard libraries? The only ones that come to mind are boost (which is a nightmarefor compile times and I feel is a mishmash of old and new) and googles absiel which I haven't actually tried enough to make an opinion about.

Animats 7y ago

The C++ people are trying to refit ownership to the language without adding a borrow checker. This is painful. They've made it possible to write code that expresses ownership, but they can't catch all the places where the abstraction leaks. string_view is really a non-mutable borrow. But the compiler does not know this.

fooker 7y ago
> but they can't catch all the places where the abstraction leaks. Why does static analysis not work here?
- deleted 7y ago
  [deleted]
- kllrnohj 7y ago
  It does, it's just a warning and not an error. And also experimental. But it does exist, and does catch some of these errors. Example: https://godbolt.org/z/CZTfSx https://godbolt.org/z/CZTfSx
  - humanrebar 7y ago
    I'd rather run diagnostics as a separate CI pass, so warnings work for me perfectly.
pjmlp 7y ago
Not quite true, Google and Microsoft are precisely adding a borrow checker to their static analysis tools. https://herbsutter.com/2018/09/20/lifetime-profile-v1-0-posted/ https://herbsutter.com/2018/09/20/lifetime-profile-v1-0-post...
int_19h 7y ago
It's still strictly better than a language with no borrow checker and no way to express ownership (other than comments), like C, or C++ itself before all the smart pointers.

sayusasugi 7y ago

Any HN post mentioning C++ will inevitably be invaded by the Rust Evangelism Strikeforce.

wutbrodo 7y ago
You picked a bizarre article to make that comment on...It's hardly irrelevant to the post, as the author's central thesis is that there's no case for choosing C++ over languages like Rust and Swift (he says as much in the article).
throwupaway123 7y ago
The Rust Evangelism Strikeforce only exists in completely inane comments like yours, maybe instead of posting memes you comment on the actual content of the article not the headline?
insulanian 7y ago
And rightly so! What's wrong with spreading awareness about safer alternative? If that wasn't the case in the past, we'd still be programming in Cobol and Fortran.
- pjmlp 7y ago
  On the contrary, we had plenty of safer alternatives for systems programming, derived from Algol and PL/I. Then came an OS, with a symbolic price instead of the typical market prices of competing OSes, alongside source code tapes, and a systems programming language that was the "JavaScript" of system languages.
  - 0815test 7y ago
    The biggest factor was that the OS was written to run on minicomputers as opposed to big iron, and was written in a portable language. Thus it could seamlessly jump over to micros (as soon as these became powerful enough, of course), and even later on to embedded and "wearable" compute. You just can't do that unless you're writing in a highly flexible and highly portable language - more like the FORTRAN of systems languages than anything like JavaScript!

nitwit005 7y ago

The string_view issue has popped up even in relatively safe languages. Java's String class used to do something similar, where substring returned a String that referenced the original String object's internal array to avoid a copy. They gave up on it because too many people accidentally held a references to large strings and leaked memory that way.

kccqzy 7y ago
As far as I know, this is rather popular. Haskell's ByteString and Text still types do the same. So does Rust, where most of the time you are very consciously borrowing the original string instead of making copies.

foobar_ 7y ago

Can virtualisation solve this ? Is it possible to have a virtualised environment like Qubes but for programs ?

jcelerier 7y ago
yes, that's called a "process" in operating systems.
simias 7y ago
Virtualization can help reduce the harm caused by a misbehaving program but it won't magically make the program behave correctly. Having a program cause a memory violation and be killed by the OS is the best possible outcome in this case, it stops the program from doing any damage and you get a clear symptom of the problem for debugging. It's when the issue is not that obvious that you're in real trouble because it may start behaving erratically, corrupt data and be exploited by malicious actors to get access to resources that shouldn't be exposed.

pjmlp 7y ago

It is true, C++ has several warts some of them caused by the copy-paste compatibility with C. Which is both a blessing and a curse. A blessing as it allowed us Pascal/Ada/Modula refugees never to deal with what was already outdated, unsafe language by the early 90's. But also makes it relatively hard to write safe code when we cannot prevent team members, or third party libraries, to use Cisms on their code. Regarding the alternatives, Swift is definitly not an option outside Apple platforms. And even there, Apple still focus on C++ for IO Kit, Metal and LLVM based tooling. Rust, yes. Some day it might be, specially now with Google, Microsoft, Amazon, Dropbox,... adopting it across their stacks. However for many of us it still doesn't cover the use cases we use C++ for, so it is not like I will impose myself, the team and customers, a productivity pain, take the double amount of time that it takes to write a COM component or native bindings in C++ for .NET consumption just to feel good. When we get Visual Rust, with mixed mode debugging, Blend integration and a COM/UWP language projection for Rust, then yeah.

masklinn 7y ago
> It is true, C++ has several warts some of them caused by the copy-paste compatibility with C. I mean that's a bit of a cop-out given C++ has more non-C warts and UBs than it has C warts and UBs at this point. It's not just "copy-paste compatibility with C" which made std::unique_ptr or std::optional deref and UB.
- pjmlp 7y ago
  Sure it is, because they need to be compatible with C pointer semantics. The large majority of C++ UB comes from compatibility with ISO C UB 200+ documented cases. And ISO C++ working group is trying to reduce the amount of UB in ISO C++, which is exactly the opposite of ISO C 2X ongoing proposals.
  - masklinn 7y ago
    > Sure it is, because they need to be compatible with C pointer semantics. They don't need to be compatible with unsafe / UB C pointer semantics, allowing them to both contain garbage and be deref'able were explicit decisions the C++ committees did not have to make but chose to.

systemBuilder 7y ago

Many of the problems he talks about come from the lunacy of the C++ compiler making all sorts of temporaries and calling hidden type conversion functions, making all sorts of assumptions that it should never ever ever make without being told by the programmer. That is why C will always be a better language than c++ on a fundamental level. In this area stroustrup took C in a bad direction.

fetbaffe 7y ago

Without any data to back this up, my guess is that there is no good reason to pick C++ for a new project except when the developer is already fluent in C++. Assume we have this abstract developer that has a good knowledge in programming theory but has no experience in programming languages. The developer starts a new project, but in what language? web: Don't see any reason for this. Exist lots of great alternatives. This is not really one of C++ strengths so is not that strange. desktop-GUI: Probably one of the biggest strengths of C++ is the Qt framework, it is solid choice. I can see this a possible choice. However with electron dominating & PWA:s becoming a more viable option it is probably much higher chance that a HTML/JS environment is picked instead, especially how it already dominates the web. And by using TypeScript you can do it an solid language. mobile apps: Most apps are written in some web technology or directly with Swift or Java. Qt has some support for this, but not sure how widely used. My experience with NDK was not pleasant. I can't really see this as a viable option. embedded: I don't do embedded, but my understanding is that plain C is much more common here & if faster development is needed you integrate something like Lua. Maybe? memory safe: use rust I guess. compiled binary: Use golang, no complicated buildstep. Parallellism: Better to use a language designed for this like erlang. Game development: For the majority of games today a scripting language like JavaScript or Lua is good enough. HTML/JS has some really good frameworks for game development today. 3D game development: Probably a good fit to use C++, but I think that C# with Unity is a much better choice. Great framework, good community, however C++ is not bad choice for this. Possible. Commandline tool: If the developer is building the next grep, C++ could fit that, but most commandline tools does not have that performance requirement, Probably do some HTTP, JSON decoding, DB access. Bash is good enough or any other dynamic language. Scientific: my understanding is that today this is mostly python or matlab. Maybe? System development (drivers etc): I know too little about this to make a good assessment, to be fair I put this as a possible choice. And if the developer do decides to use C++ for a new project, the initial cost is quite high to just understand the basics, even if he/she uses the latest C++ version. Copy constructors, lvalue & rvalue (xvalue, glvalue, prvalue...), move semantics, const refs, rvo, smart pointers, auto etc Any good arguments to pick C++ for a new project?

pjmlp 7y ago
NVidia is designing their GPUs with C++ in mind as source language. desktop-GUI: I guess you might be joking here with Electron, I rather use my GPU for something else other than blinking cursors. Even with Cocoa, UWP and WPF, the underlying UI shaders are written in C++. Embedded: Yes, C does rule over C++, which is a reason why embedded is so open to security exploits due to wrong manipulation of string and arrays. Parallellism: HPC, FinTech, GPGPU all domains where C++ rules for the time being. 3D game development: C++ is king here, even with Unity the core engine is written in C++. Yes many of us hope to see the day when Unity is 100% written in a mix of C# and HPC#, but even then, LLVM will be part of the stack. Scientific: Someone needs to write those Fortran and C++ libs called by Python and Matlab. System development: Google, Apple and Microsoft use C++ on their driver layers for their respective OSes. IDE tooling: C++ is known for not having IDEs that match what Java/.NET are capable of. Languages that want to take C++'s place, are even worse than C++ in IDE tooling.

IshKebab 7y ago

> Dereferencing a nullopt however, gives you an uninitialized value as a pointer, which can be a serious security issue. Is this really true? Surely it just gives you an uninitialised `int` (or whatever is in the `optional`)?

0xe2-0x9a-0x9b 7y ago

There is no call in the article for a deeper C++ code analysis by the compiler. Deeper analysis will be the future of C++ - the article fails to foresee this.

notacoward 7y ago
> Deeper analysis will be the future of C++ As if C++ compile times aren't crazy enough already.