C++ will be thrown on the same scrap heap Cobol was.
In your wishes. C++ enables one to write extremely low-level and extremely high-level code in the same language, there will always be people who understand and appreciate that. Even Cobol is far from dead, BTW.
Alt-Tab works very fine for alternating between a small number of windows, regardless of the total number, because they are hold in a LIFO stack. What I have seen from Linux users is that they tend to minimize their windows to get them away from blocking the screen, this would indeed ruin Alt-Tab as minimizing puts the window in the bottom of the Alt-Tab stack.
And of course all my windows are maximized, I do not like the tangled mess created by partially overlapping windows.
To shoot fish in a barrel the zero-terminated C strings was made to save one length-prefix byte and has cost the world a bazillion times more than the Y2K problem and every non-C programming language has abandoned it. But okay, that's an inherited problem.
Seriously, where do you see zero-terminated C strings in C++? It's not an inherited problem, it's a compatibility feature when interfacing C code.
My biggest gripe with C++ is that it's an OOP language without an object oriented memory model, unless you religiously follow RAII as a pattern or trace every execution path when the code changes you will have crazy leaks all over as you create and destroy objects.
No, C++ is not an OOP language (it just supports it to some extent), and yes, you need to follow RAII throughout and that's the one single most major strength of the language!
Particularly since there's no major platform pushing it, on Windows it's C#, on Mac/iOS it's Swift and in the enterprise and on Android it's Java, the embedded market is C and the web is pushing Javascript everywhere: But who's pushing for more C++? Almost nobody, as far as I can see.
That's a major point in favor of C++. It won't go away the next year because some company has decided to switch their preferred framework to some new strangely named new thing, or the language somehow gets sold to a megacorp who really does not care about it.
You say it's a language for experts, who can afford an expert for every change? How do you become an expert, if a junior C++ developer will fail spectacularly? What I'm saying is that just because it's challenging doesn't mean you're an expert, it just means you're doing it the hard way.
Not all software needs to be written in C++. But there are a lot of things which can be and are written in C++, including interpreters for all those new fancy languages.
If the servers get compromised then it's game over. That's the same with paper ballots, if the central office is corrupt then there is no trust in the results. It is true that there needs to be some trust in the state officials; electronic voting would probably not work in some other countries where 146% voter turnout or 99% single party wins are common. But that's not the problem with paper or technology, it's the problem with the state.
For detecting that there is something fishy happening you don't need 80% coverage. Even a handful of mismatches would create a huge media storm (assuming free press) and a detailed investigation would be started. The same would happen if the election results would not resemble any pre-election predictions or polls.
Paper ballots regularly get miscounted, intentionally or unintentionally. In totalitarian countries it's also easy to fake the paper ballots, any reports would be just ignored or silenced (see e.g. http://www.nytimes.com/2012/03... ). But this would require silenced press.
Estonia is currently at the 12-th place in the press freedom index (out of 180), which is a very different situation from e.g. Russia (place 148) or even US (place 46). What works in one country may not work in another.
All PCs are insecure, whether used with card readers or not.
That's why in Estonia you can double-check via a physically independent channel (smartphone app) that your vote reached the server correctly. Worked fine for me at the recent elections.
Yes, selfish pricks like you are indeed the reason the ad landscape has become so hostile. Excellent point.
I do not understand. It does not matter if I do not see ads or if I just ignore them, there will be the same zero benefit for the sellers/advertisers, so there is no rational reason for them to be against ad blockers.
If I want to buy something, I will search for it.
Categorising one of the most important images of the 20th century with child pornography is a problem. A big one.
Except it is not pornography. Pornography is defined as printed or visual material containing the explicit description or display of sexual organs or activity intended to stimulate sexual excitement.
Now if somebody really believes a photo of napalm victims is intended to stimulate sexual excitement, then I agree this person might have some big problems indeed.
Speaking of readability, here's an entertaining one I've been seeing more of in C:
if (result == SUCCESS) versus if (SUCCESS == result)
The rationale behind the second is that you don't end up accidentally assigning SUCCESS to result (eg, if (result = SUCCESS)). But I know that I find it weird to look at it the other way around. I want to know if the result was successful, not if successful was the result. Maybe it's an english thing.
I know that Xcode has been putting up warnings/errors for code that does assignments in if-statements and saying that if you really want to do that, wrap it in an extra layer of parentheses (eg, if ((booleanResult = Do_Something()))). I'm not sure this is somehow more clear that you're doing the assignment...
In proper C++ this would be
if (bool booleanResult = Do_Something()) {
or more usefully
if (AClass foo = PrepareFoo()) { DoSomethingWith(foo); }
This does not generate those assignment warnings, is in the right order for readability and does not need obscure extra parens.
In professional software development, the general idea is clear: if any non-functional change in a source code file makes it more readable and more maintainable, then it's good, and vice versa. You write the thing once and it has to be maintained for years. This is actually called code refactoring, which is part of several methodologies.
Code refactoring may mean either adding or deleting code. There ought to be a golden middle point somewhere where the code is neither too verbose nor too condensed.
There is a slight complication in that not every person agrees what is the most readable form for a program, but in general it's best to imagine that you may have a total autobiographical amnesia in the next day and still need to understand what the program does.
So, memcpy() does not work in C++? Did not know that.
Or strcpy() for that matter? Ah: you want to imply that one should use std::string?
Sorry, regarding buffer overruns C++ is as vulnerable as C.
memcpy() and strcpy() are not found in proper C++ programs (there is no need for them).
Anyway, memcpy is not the cause for buffer overruns. Buffer overruns appear when two pieces of code get confused about what is the actual size of the buffer. In C++, the actual size is stored right there inside the buffer object (e.g. std::vector or std::string), so the probability of confusion is greatly reduced.
strcpy() is vulnerable because it relies on the buffer size stored somewhere else in addition to the buffer management (i.e. malloc()), and these two locations may get inconsistent and cause confusion and bugs. Luckily, there is about zero reason to use strcpy() in C++.
Of course one can compile what is basically C code by a C++ compiler, but this does not mean one could not do better in C++, or that C++ is somehow tainted by allowing C code. One can write buggy code in any language, writing buggy C code in C++ is just one easy way to do that.
In these matters the only certainty is that there is nothing certain. -- Pliny the Elder
