The New C++: Lay down your guns, knives, and clubs

We do need new tools for multicore

I don't know if this new C++ is what we need, but there has been a need this past five years for a toolset that approaches the bare metal like C, but leverages the many core direction our processors are moving in.

Whatever the end product is, it should be able to handle heterogenous cores, because that's the direction platforms are moving in. Multiple different CPU cores, GPUs, hardware media decoders, varying forms of ALU, RNG's and PhysX units included in the silicon. The core system is getting revved these days far faster than before and with a lot of oddball things that didn't used to be considered part of the platform. The software tools are lagging these days, as dealing with this riotous mix always involves custom coding.

It's incredibly complex. I think we'll be groping about for an easy answer for a long time, and in the interim kernel coders are going to earn their money. More power to 'em. Whatever the answer is, it ain't Java, nor C#, nor COBOL.

D

El Reg seems to have been running lots of stries about Go recently. D goes largely unmentioned, which is a shame (mind you, understandable, the team behind Go have been much more savvy about getting the word out about what is a slightly more targeted and thus easier to explain language).

True. D invites ridicule with it's name, but version 2 does start to deliver: much like C++0X it's an attempt to adress the short comings of C++ (the difficulty of programming well) and, of course, concurrence, while retaining the performance and ultimate flexibility of a 'big' language as opposed to a Ruby etc.

Andrei Alexandrescu's book on D is worth a read - if only for its propensity to discuss the motivation behind the design of a language (he's been a driving force behind the version 2 revision of the language).

One solution to get more speed

Get rid of the copy constructor. Please! I know it sounds like a good idea on paper, but people just aren't going to use pointers when they have to put funny characters around them.

The point is, it's the idiots who need help, not the experts. Nobody who knows what they are doing will ever complain for having to put some extra code into some exotic or dangerous program part. However requiring the idiot to learn C and Assembler, as well as all the implementation details of that platform, just to avoid the biggest pitfalls, isn't going to work.

My point is: Unlike what many C++ programmers seem to believe, it is possible to have systems which are both easy to use/program and powerful and fast.

Whatever. When doing real work, I'll stick with K&R C and inline assembler ...

I don't want the compiler to tell me what I can & can't do with the hardware.

But then, I'm a hacker[1], not a sheep.

[1] Old jargon meaning, not modern journalistic meaning ...

C++ Garbage Collection

There is a good reason they still haven't added Garbage Collection to C++......... there would be nothing left. Boom Boom.

More importantly

What has been done to make the language more secure? Bad C code is responsible for a huge amount of the vulnerabilities found in OSes and their apps.

Whilst it's unfair to blame c++ directly there should be a huge focus on blocking the paths programmers can take that introduce such issues.

Up to a point, Lord Copper...

It's always amusing to notice the unstated assumptions built in to presentations like Sutter's. He says that the world is built on C++, but that's only the world of PCs really. Computing as entertainment, one might call it (to be slightly cynical). Meanwhile - you guessed it - the real world of industry and commerce does most of its sums on COBOL and CICS, as it has for the past 40 years or so. Including (ironically enough) the money mountains of Sutter and his pals at Microsoft. Ask any bank (I was going to say "any reliable, reputable bank" but let's not get into that right now) whether its core systems are written in C++ and you'll get a resounding "No".

Meanwhile safety-critical avionics and the like continue to be written in languages like Ada, which - while too boring for fashion-conscious developers - make it possible to write much more reliable and predictable software.

Lastly, please note that it's not helpful to tell us that C++ is faster at runtime than Java. What would be helpful would be to know how much faster it is, and what the tradeoffs are.

Built on C++, but at what cost?

The C language and its mutated spawn must rank as one of the worst viruses to hit the world of computing.

Don't get me wrong, C is a highly efficient systems implementation language (SIL), but like all of the SILs it is highly dangerous precisely because of its efficiency. When safely confined in a lab (in this case, Bell Labs) it was a powerful tool for good, but it inevitably escaped and infected the world of commercial computing. C++ was an attempt to attenuate the virus and make something less dangerous for application use, but in order to achieve more or less full backward compatibility it did nothing to address the underlying highly efficient but totally unsafe memory architecture.

Just as a "for instance" to demonstrate how dangerous (and ubiquitous) the C memory architecture is, ever heard the phrase "unchecked buffer vulnerability"? The vast majority of the 300,000+ Google hits are probably its handiwork. Well, of course they are really the handiwork of a programmer, but therein lies the problem. Safe C code is bigger, slower and can take longer to write - how many more disincentives do you want? This is why Intel, Microsoft and others have had to implement mitigation techniques such as data execution protection, address space layout randomization, structured exception handler overwrite protection, mandatory integrity control, etc. etc. etc.

So will we ever see an end to this outbreak? Probably not in the foreseeable future. Abstracting the memory architecture into something inherently safer (à la .NET and others) is one way to go, but ultimately the runtime systems will have been written in C++ and so are vulnerable.

Not so

""Apple's Mac OS X, Adobe Illustrator, Facebook, Google's Chrome browser, the Apache MapReduce clustered data-processing architecture, Microsoft Windows 7 and Internet Explorer, Firefox, and MySQL – to name just a handful – are written in part or in their entirety with C++""

Can't be sure about all of the above but as has been mentioned OS X is mainly C and assembler like most OS's (e.g Windows and Linux kernels) -- sure there are C++ items in there but mainly all heavy-lifting is C and assembler. Same as Phototshop -- lots and lots of in-line assembler. MySQL is almost all C with some C++.

Windows: C++, kernel is in C

Mac: Objective C, kernel is in C (IO PnP subsystem is Embedded C++)

Linux: Most things are in C, many user apps are in Python (KDE is all C++ I think)

C and OC ain't C++.

Language syntax??

Look, if we didn't have the C-like syntax, we would be stuck with something like Fortran or (god forbid) Cobol (try that for a systems language!). Even Algol-60 is bad, and try to implement Algol-68 (has anybody really done this?). Sorry the C-like syntax is here to stay, or else you get "significant white space".

As for C++, why bother. I defer to someone more expert on the subject: <http://harmful.cat-v.org/software/c++/linus>.

When I look at C++ vs. C, another thing I look at are the volumes written by the "authors" of the language. K&R is about 1/2 inch thick. Bjarne's book on C++ is about three times as thick, and really doesn't describe the language as it has lots of: "// ..." comments, and incomplete "discussions" of the language. C you can understand from what you are looking at. Look at C++ source, and the code you need to understand the code could be many modules away, for the "+" operator even!

Lastly, a famous quote: "The thing about standards is that there are so many of them."

C syntax here to stay?

Years back I did a fair amount of coding in xBASE, an English-like language, and found that I could write substantial routines and often have them work first time, with ZERO bugs. I'd defy any coder to claim that to be possible In C-based languages.

It's interesting to compare the entrenched nature of C syntax with user-interface development, where the opposite paradigm prevails. No qualms about willy-nilly change, change for change's sake, or even ill-advised change there. Yet, in coding, we're told that we MUST stick with a donkeys-years old way of entering code, and woe betide anyone who even suggests that an alternative might be better.

It occurs to me that soon we will be communicating reliably with computers in spoken language. If we haven't modernized our coding syntax by that time, coders will effectively bar themselves from making use of such developments. Which would be one singularly ludicrous situation, would it not?

Neww C++ and it's Microsoft connections

I do sincerely hope that if Herb Sutter is amoung many C++ ISO group members from Microsoft, that the language standard is not corrupted - even subtly - as has been done to the severe detriment of other languages - like the Microsoft license of Java, or their "Iron-" iterations of Ruby, Python and PHP, as just a few examples.

The technology industry or their clients of technology, meaning the whole world, can no longer afford - in the twenty first century to endure the draconian behavior of Microsoft in attempting - and sometimes succeeding - to force shape technology in their own mold, and ultimately breaking everything and thus setting back technological progress many years.

Everyone is sick and tired of that.

The World runs On COBOL

Games and Wanker Ware run on C++.

Unless you want dancing monkeys. That's Jabba.

Hmm ...

Still no standard library / keywords for multithreading / synchronization though ? (Something akin to Java's (Concurrent Pascal's) would have been welcome ... ).

It seems that the basic idea (by Brinch Hansen, Hoare, ...) from the 1970s of "safe" languages, that is, trading some runtime speed for an easier implementation still fails to catch on :). While waiting for that, libmudflap (BoundsChecker,...) can be used to achieve similar results with C/C++ (for test/development), in practice, catching a bunch of bugs "free". These days many of the actual runtime environments can support these for weeding out bugs, for an embedded system without a MMU and/or the memory to spare one should be able to run (most) of the same code on a workstation for testing purposes (extra work for setting up some kind of a simulation though).

Originally I owe the above insight to converting a 1990s real-mode x86 (DOS) C (C++) system to 286/16-bit protected mode (DOS extender providing an enviroment like 16-bit protected mode Win 3.x) . As a side effect I ended up with a system where most logical pieces of memory had an individual, HW bounds check at runtime. The amount of bugs this catched was quite phenomenal, and, importantly I was able to set up an exeception dump facility which allowed me to trace a run-time exeception, even one that would happen only every once in a blue moon back to the source line and machine instruction. With the CPU register values it was usually easy enough to figure out what had gone wrong (the typical fix being adding an explicit bounds check to array access: unchecked, these are may crash the system down the line when it is involved with some other section of code entirely ...).

C++ - way too complicated

It's possible to write code in c++ that is completely unreadable by anyone but an expert in the language - some STL code comes to mind. It's also possible to make it readable, but I am not sure that is the norm. I wrote a large program in it 10 years ago and when that was over I swore never again. My experience is that with C++ you spend a lot time on the language and not working on the problem.

Yawn

Will C++0x have a consistent bit-width data types across CPUs? I bet not, given you need a language completely detached from C for that!

Will C* code and data structures continue to break as new *-endian CPUs come out, like between 8-bit, 16-bit, 32-bit, 64-bit, X-bit CPUs and all that horrid data-type and data structure macro hacking (e.g. for Microsoft and other OS's) because there is no VM to abstract away this native hacking? I bet so!

Will we continue to see the absurdity of buffer overflows and null pointer bugs because of the inherently unsafe memory model of the C/C++* family of 'bare metal' languages, especially in common C/C++ libraries and OS's? Of course!

Most of the Microsoft security issues relate to this inherently unsafe memory model, the rest are higher level issues like SQL injection exploits.

How long before there are fully usable and stable compilers and IDEs for common OS's for C++0x? 5 to 10 years, or never.

In that time, advances in Java or other higher level languages will have rendered it even more irrelevant, maybe even for OS and driver coding.

Objective-C is kludge which is only relevant to Apple platforms, thus irrelevant to most application developers. Apple is part of an expensive lifestyle fad and has a limited lifespan, so beware about investing much of your life with them.

C++ vs other languages

I love C++, because I can write large, complex applications for some projects but if I want to bring a program up on bare metal I can do it in just a few lines of assembler. You just set your stack, call all your static constructors and that's about it.

It's a pity because C++ v1.0 only really needed operator overloading, out-of-scope destructor calling, and the class notation. It could lose inheritance, exceptions, RTTI, STL and still be incredibly useful, even as a SIL. I'm guessing that while the C++ standards committee were dotting every I and crossing every T, huge amounts of insecure C code got written. Perhaps if they had just produced a decent string class with everything you need, like CStrings Get/ReleaseBuffer(), Python's startswith() and endwith(), and ability to construct from either unicode or ascii strings like CComBSTR, perhaps a default 1k string buffer, and then copy-on-write system when it overflows, then maybe it would be just too useful to not use and you wouldn't get all these died in the wool C hackers coming up with rather specious arguments against C++. Linus might have used it for his kernel, and a bunch of other developers wouldn't be put off by the 'space-age' features that people seem to like abusing, damaging readability and sometimes even run-time efficiency.

I know you can get all kinds of clever things with the Boost libraries but that's not really the point. Python, Java and other languages, even if slower seem give you what you need instead of what some academic-types think you want, and that's what I see as the main problem with C++.

I'm not looking forward to a new C++ compiler. It looks like it'll give me virtually nothing I'll use so I may as well stick with the threading abstractions I'm already using, and compilers that I know and understand for all the major platforms.

@Tom Reg

"My experience is that with C++ you spend a lot time on the language and not working on the problem."

My experience is that programmers work on the problem and the code at the same time - that's the problem.

There is a world outside Cobol

ADD TRANSACTION-AMOUNT TO LEDGER-BALANCE works but -

"ADD THE FLOATING POINT ABSOLUTE OF THE PHASE OF THE INPUT SIGNAL IN RECEIVER 7 OF BLOCK 3 OF RACK 12 TO THE ACCUMULATED SUM OF THE PHASE DIFFERENCE IN THE MAXIMUM ENTROPY FUNCTION UNLESS THE COMPLEX PART OF THE BASELINE IS MORE THAN ..."

Is probably easier to put in as a formula.

Yea, ok....

And you people who say the world isn't built on C++, but is instead built on Java, Python, Cobol, or whatever. which language do you think was used to create all of those? C/C++ is the foundation stone of pretty much everything IT, even your mobile device.

C++: an octopus made by nailing extra legs to a dog

"PL/I and Ada started out with all the bloat, were very daunting languages, and got bad reputations (deservedly). C++ has shown that if you slowly bloat up a language over a period of years, people don't seem to mind as much." -- James Hague

And for even more C++ quotes, see:

http://harmful.cat-v.org/software/c++/

Portability is being forgotten here

Sutter's claim that the standard gave you portability is revisionist history. To conform to a standard, you need a good set of tests; to benefit from a standard, you need compilers that pass them. Plum-Hall may have had the former but most compilers fell woefully short on the latter. Substantial rework was required going from one compiler to another -- even on the same architecture. It was not pleasant.

I have not programmed in C++ for a while so I do not even know if conformance results are even available nowadays. Back in the day, Sun's compiler was closest, followed by Borland.