An unthinking programmer's guide to the new C++

So what’s all this about a new C++ standard, Verity? Why you asking me? I know nussing. I’m down to write ‘Porcine influenza — a programmer’s perspective’ this month. Don’t fib. Oh very well. The enthusiasts imprisoned in the ISO C++ bunker are reputedly on the point of lighting a white smoke bonfire to indicate they have a …

[nicholas22]

No shit sherlock

Without any productivity enhancements, c++ will just keep losing its developer base.

[Matt Bucknall]

Not one to be pedantic, but...

Don't you mean delayed until 7DA, or indeed until 7DF?

[Anonymous Coward]

Long wait...

"Actually the C-plus-plusers point out it could be delayed until 200A, or indeed until 200F".

Since 200A is equivalent to 8202 in decimal, that means we could be in for a 6193 year wait.

If 3D Realms hadn't just gone belly up, I'm sure there'd be a joke in there about the new C++ being used to write Duke Nukem Forever.

[Anonymous Coward]

I think

#define RIDICULOUS int i = {};

[Noogie Brown]

urgggh

let c++ die already. it really is a monstrosity.

[Anonymous Coward]

hehe great spoof article

imagine if someone were really to try and put those things into C++

[Anonymous Coward]

Square brackets

"...complete with a wonderful square bracket syntax for deciding which bits of local state will arise from the undead when the thing is called..."

Interesting. The C# compiler just decides on its own, which occasionally leads to curious bugs with anonymous methods if you aren't wide awake.

[A J Stiles]

Out-of-order loops

Been able to do this in Perl since forever:

#!/usr/bin/perl -w

use strict;

foreach (1,2,5,6,4,7..10) {

print "$_\n";

};

exit 0;

Nice to see another language catching up.

[Adrian Challinor]

concepts

I can't get the concept of a concept - may be my axioms are wrong.

[Pirate Dave]

If I wanted to do that, I would code in Pascal

You say that like it's a bad thing...

[Anton Ivanov]

Re: Out-of-order loops

Yeah,

After reading this tripe and comparing it to Perl I really want to see the justification C++ people put into calling Perl unreadable.

[danny_0x98]

Erlang?

Then there's some chance of grokking the new syntax. If you had chosen APL as the follow-up comfort language, then the hazard and "Abandon all hope" signs for this iteration of C++ would be boldly and definitively posted.

[Ken Hagan]

Hehe, great spoof comment

"hehe great spoof article

By Anonymous Coward Posted Thursday 7th May 2009 12:24 GMT

imagine if someone were really to try and put those things into C++"

Imagine if someone really didn't realise that they have done.

[Tony Hoyle]

It may be a joke piece but..

I can actually see the point of &&, if I'm reading the joke right.. returning a complex object is a bit of a pain currently - you either have to copy or use pointers to some stored object. I presume it's intended as some kind of language analogy to a smart pointer, without having to write your own (everyone who's used C++ for a while probably has a smartpointer class somewhere).

The rest of the stuff is howlingly bad.. auto encourages lazy programming and would be a bug magnet (you can't even argue it for templates.. those should be typedefed). I can't even parse the curly brackets joke..

If anything, a new version of C++ should simplify it.. there's too much duplication where they decided to slightly change something that was already in C just to make it 'different'.

[Rock Lobster]

@ Ken

imagine if someone couldn't tell an ordinary comment apart from a joke comment

[IHateWearingATie]

I used to code in C and C++...

... and I didn't understand a thing in the article or the comments. I must truly have passed to the Pointy Haired side.

Pointers...I think I remember them...

[Anonymous Coward]

Mmmmm, yup ...

... this article sums up rather nicely why I loathe and detest C++ with the burning passion of a million, red-hot suns.

Kind of vindicates my continued use of Perl and Java or, in some cases, Plain Old C.

It's the one with K&R first edition in the pocket.

[Brian Miller]

Sounds like C-- instead of C++

A while back I was working with a fellow who regarded himself as a total C++ guru. He would put try-catch around functions that didn't throw, and things like that. Now I see that C++ is doing its best to behave like a dynamically interpreted language. If you want to write in Perl, why not just do it?

Oh, and C++ still has to be fully compatible with K&R.

[amanfromMars]

Paranoids Corner ....SchizophrenIQs Retreat ...... Sanity's Redoubt

Verily I say, King Egg Fooey for Chip Stewards ...... and AI NEUKlearer Lead .... with the Full PerlyGatesPython Monty in Stealthy Cloud Cover, Verity?

Think of IT as an ESPecial Phormation of Special Post Modern Relationships and Light Years ahead of Hieroglyphics and Lost Covenant Arks.

Step into the Parlour, says the Spider to the Fly ..... "'Tis the prettiest little parlour

That ever you did spy."? :-) ...... http://ingeb.org/songs/thespide.html

Life is AIdDynamic Game, Full of Future Plans for Universal Players/Movers and Shakers.

[Jerome]

@ Rock Lobster

Imagine the entire comments section buried in such a mire of postmodern meta-irony that no-one can tell what's going on, or indeed even recall what the original article was about.

[Anonymous Coward]

No Thanks

I'll stick to C.

I don't want inheritance or templates.

All I want are my lovely pointers and the ability to use them.

Everything else is for sissys.

[easyk]

I like C++

Am I wierd? After using boost for a couple years and eliminating most of my OS dependencies between QNX, Linux and Windows I really began to appreciate the power C++ gives to library developers. Most of the complex constructs in C++ are only used where needed and then hidden away in a library or class so you can have neat and easy to understand code while still having powerful full control code under the hood. Besides Perl performs poorly for device drivers.

[E]

I read a quote from

... K or R a few years ago, where it was said "Now that C++ has got away from us..."

He was IIRC talking about template metaprogramming vs 'just solve the programming problem at hand.'

I dunno about this stuff. Tempates are great if sometimes obscure. The STL is great, Boost is mostly great, but it's kinda like the sermon on the mount: I don't claim to understand all of it.

Some of the other stuff looks like angels dancing on the head of a pin. Trying to be all things to all people generally results in a big mess. KISS applies here.

int i = 0; // OK

int i = {}; // WTF? What obscure subtlety is this syntax addressing?

auto fn(int foo) { ... }; // Most C++ programmers *like* C++ strong typing. Why break it?

The right hand reference && thing (wrong name?) does make some sense though.

Editors: let's have a K or R or K'n'R icon!

[Colin Barfoot]

gawdelpus

So rather than removing all the half-arsed parts they thought they'd add some more, and not just silly academic additions, no, they'll be "Improving Standard C++ for the Physics Community".

I notice that members of the old crowd are still there: Francis Glassborow (remember him Verity?), Herb Sutter, P.J. Plauger. Seems like a cosy get together for old time's sake. One for road.

[Frumious Bandersnatch]

ha you almost had me there

Until the bit about lambda functions! Now if only they'd implement first-order closures ...

[Boris the Cockroach]

Yikes its alive

I've looked into both C and C++ (and the m$ version too) and came to the conclusion that the designers of both C and C++ just wanted a language that used all those unused symbols on a keyboard...

Boris

mmm Java

[Peter Geoghegan]

Questioning the motives of C++ haters

Concepts, or concept checking, explicate the implicit interface of templates. They are a way of ameliorating the problem of templates producing terrible error messages when used incorrectly. Prominent C++ pundit Scott Meyers, well known in the C++ community as the author of the "Effective C++" series, has questioned the necessity of concept checking in the new standard.

The whole point of supporting initialiser lists (the { } syntax) is to allow classes, particularly containers such as std::vector to be initalised like arrays. i.e.:

std::vector<int> container = { 5, 6, 7, 8};

This previously wasn't possible.

References aren't pointless. They are safer than pointers, in that they cannot be null, must be initialised, and their value cannot be changed once initialised - They become an "alternative name" for the value, as oppose to some distinct construct that points to the value. This facilitates operator overloading, and simplifies code. If it wasn't for references, you'd have to de-reference the pointer returned by the operator:

my_class a, b;

...

my_class c = *(a + b); // returns a pointer that is de-referenced - defeats the purpose of operator overloading

As against:

my_class c = a + b; // exploits user's intuition of what + ought to mean

C++ certainly has more than its fair share of warts, but can we please see an article written by someone that understands the rationale behind the introduction of C++0x's new features?

I have plenty of criticism I could make of C++ in general, and C++0x in particular, but I feel most of C++'s defects can be attributed to historical reasons, or the fact that major sub parts don't gel together flawlessly. It seems to me that often the shrillness of the criticism you hear of it posted anonymously on the internet is in direct inverse proportion to the poster's actual knowledge of the subject - typically, they make sweeping remarks like "C++ is shit", or "C++ is to C as lung cancer is to lung", whatever that means. Why is it shit? If it is shit, how do you account for the fact that many major projects have successfully been completed in C++, among them GoogleFS, Photoshop, Firefox and openoffice.org - are the organisations that created those project just stupid? What would you write, say, photoshop in if you were starting from scratch? I suspect that these people's needs ( I suspect that they're web application developers and Java/C# developers that produce middle of the road business apps) are not best addressed by C++ in any case, but perhaps if they tried a modern C++ framework like Qt or WxWidgets they'd find that many of the oft-repeated put-downs are overstated, outdated, or just false (example: C++ is the only language that combines higher level abstractions with manual memory management, which is bad. Ever hear of RAII, or for that matter Ada?). Some of these same criticisms can be made of C (most prominently, things about the inherent dangers of native code), but people don't criticise C because Unix is C and Unix is cool and I'm a hacker. The difference with C++ is that you don't have to use C's low level constructs like char pointers for strings, or printf statements - there's always a much better, safer alternative.

A common, and valid, criticism of C++ is that it poorly encapsulates compilation units, necessitating recompiling client code when a class's definition is changed. That's the price you pay for the speed of having true local variables on the stack - the size of the class must be known in advance of compilation. The greater point illustrated by this example is that, essentially, C++ addresses the needs of a large (though largely reticent) group of people with a particular set of requirements that want the particular set of trade-offs that are least bad to them. Could there be, in principle, a language that better addresses *their* needs or preferences? Definitely. Is there one? For most of them, no. The number of people using C++ is not currently in decline (it was a few years ago), it just isn't growing as fast as the user base of other languages (source: Bjarne Stroustrup's website).

[Martin]

@I read a quote from

So there are now three different syntaxs to set a variable

int i = 0; // but you still can't do this in the ctor

i(0), // need to do it this way in the initialisation list

int i = {}; // useful if int is redefined I suppose

[Anonymous Coward]

Hmmm

Even to the initiated these features look like a bit of a hard sell. However, anyone put off by the enhancements isn't in the market for C++ in the first place, so that is probably as is should be. I don't see C++ losing it's 'expert only' status anytime soon (which is laughable if you can remember when there wasn't really much of an alternative).

Some things are just complicated and other things are needlessly complicate (COM programming in C anyone?), but if you want to get the most from your machine you have to go beyond the average.

What will be interesting will be to see what new compiled language eventually comes along to properly challenge C++ (Digital Mars D seems like the obvious one a the moment, but that has its own issues). That isn't likely to happen anytime soon I would say.

If the new C++ features have you reeling in horror, then gues what - it obviously isn't for you. Just like device driver or OS kernel programming isn't for everyone.

[Robert Synnott]

@Brian Miller

"Oh, and C++ still has to be fully compatible with K&R." - C++ has _never_ been fully compatible with K&R. Never ever.

[Anonymous Coward]

@E

Fair comments. Yes, int i = {} is pretty bizzare I agree and I sympathise with 'angels dancing on the head of a pin' comment. I think it's undeniable that there are elements of this as C++ gets more sophisticated!

However, I think the auto keyword will be fine if it is implemented sensibly. The whole point is that you still have strong typing, but you no longer have to type an essay to define a complex type (and yes, I do religiously use typedef, but that is hardly the point).

At least the comments haven't degenerated into a total flame-fest yet!

[Ralph]

Replies miss the point

As I read it, the article is intended to be humorous rather than a serious critique of C++. It's funny even for a C++ developer if you can momentarily detach yourself from understanding why these changes were made and what they achieve. But can we be spared the harsh replies? C++ is very good for specific purposes, as every other language is good in the right context. For those who understand and appreciate the language, these replies sound like email neophytes scoffing at the @ symbol in an address as if it were obvious to all how stupid it is.

[Anonymous Coward]

@Peter Geoghegan

Yeah, bring on the rants! Excellent!

As much as I agree, the problem is it's pointless trying to convert the 'it's too hard' crowd. They've already closed their minds to the whole conversation. The trouble is C++ take concepts from many other languages and fans of those other languages resent it.

Observe all the hate from C programmers and functional programmers alike.

As Bjarne himself stated, inside C++ is a smaller, cleaner language struggling to get out. With the new standard that struggle can only be harder I guess, but it certainly doesn't diminish the good work done in creating it.

As you obviously realise from your other comments, C++ will continue to flourish on its own merits - but this isn't 1993 and never will be (yes, I realise you also realise this!)

Regards

[BlueGreen]

@Peter Geoghegan

a decade+ ago I spent a week trying to get a tiny test prog (one or two hefty lines of STL) running using the early STL with metrowerks C++.

I lost. Broken compiler, broken STL. It put me off for life.

I can handle C++ and welcomed some of it but the tangled, obtuse, spiny and obstreperous mass of the language eats too deeply into my limited cognitive reservoir, which I prefer to keep for tackling the quite-sufficient complexities of app development.

The cost of using it is too high for me so, no ta if I can help it.

[Werner McGoole]

When you're in a hole

Stop digging!

[Anonymous Coward]

@Brian Miller

"Oh, and C++ still has to be fully compatible with K&R."

Rubbish. C++ has never ever been K&R compatible (whatever you mean by "compatible").

Even C does not need to adhere too closely to the original K&R spec. Lots of weird so-called "illegal" code compiles just fine and dandy. Depends on what you're trying to do. That's kinda the point, y'see?

[Anonymous Coward]

C++ is the orchestra

it is designed to keep developers in jobs for as long as they like or for how long the money lasts.

All these features are valid for certain types of problems, and for problems people have yet to really define.

C++ is normally not the language to choose for any particular thing if you are responsible for the budget, but if you had to only use one environment for everything then C++ would be it.

[Mr Larrington]

@Ralph

It's funny even if you know sweet FA about C And All Its Spawn, which to me is about as comprehensible as Ancient Greek.

Now, where di I leave my FORTRAN compiler?

[Richie]

CORAL66

"And you can make for loops in a style I last saw in CORAL 66, where one provides the list of values the loop variable takes."

MATLAB and R both do this. You pass in an array of whatever you like, and the language iterates over each element.

MATLAB style:

for i = [1 3 69 -7]

% something

end

R style:

for(i in c(1 3 69 -7))

{

# something

}

[Anonymous Coward]

...and my Java 2p worth...

for ( int i : new int[] { 1, 2, 5, 7 } ) {

// nothing new here...

}

[Bruce]

This is all well and good...

... but what does Kevlin think?

[Kevlin Henney]

What does Kevlin think?

On a really good day, a great many things. On a not-so-good day, very little.

But what do I think about C++0x? On the whole, the wrong thing at the wrong time.

Kevlin

[JP Strauss]

haha

HTML kicks C++'s ass.

[Steve Evans]

At this rate...

...by 2010 every C++ project is going to have to be supplied with it's own Rosetta stone!

/me rapidly returns to the nice structured and strictly typed world of Delphi where basic operators are still words.

Ahhh... That's better... *sigh*

[Anonymous Coward]

SAPPEUR

Check http://www.sappeur.eu. That is real innovation on top of C++:

-Safe as Java

-Trace Garbage, don't collect

-All pointers are Smart Pointers

-multithreading is made explicit in the Type System

-Array access is always checked

-Heap and Stack are safe

-References can (and should) be used

Save Energy and conserve Money - use SAPPEUR !

[E]

@Anonymous Coward

"...the auto keyword will be fine if it is implemented sensibly. The whole point is that you still have strong typing, but you no longer have to type an essay to define a complex type..."

I conclude I need to spend a bit more time understanding the auto keyword. It seemed to me it was sort of a 'variant', like in VB. Your comment contradicts this. Thanks.

[E]

@Colin Barfoot

The thing about C++ (and to a good degree C also) is that it is a very open ended language. So you can do all this wild stuff with it that Stroustrup maybe never dreamed of. The people you mention are IMHO people of good faith. In scientific computing FORTRAN has lost some ground to C++ - so adding complex numbers and such is a good idea.

What really convinced me C++ was worth learning and using was it's combination of flexibility and expressiveness and compactness (compared to most other languages at the time). That's what hooked me about C too.

But, hey, the ability of a language to express increasingly subtle things gives us arm-chair language designers something to talk about, eh? 90% or 95% of C++ programmers and C++ programs will not use the more esoteric new features. But where they are useful, nothing is wrong with having them.

My $0.02.

[E]

@Anton Ivanov

Unreadable: there's the potential problem. It does seem to me that the proposed changes will introduce greater scope for unreadability. Haha, so the compsci profs teaching C++ courses will have to come up with new programming rules to go alongside "Do not use goto".

[E]

Last comment

Someone pointed out above that the article was probably more a humour piece than a critique of the language. I agree.

Now, if you want to read something funny about a programming language, go find a copy of the Intercal programmer's guide. Suspend criticism and just read. You'll probably laugh your *ss off!

[Anonymous Coward]

A sad day

I read the piece and despite not having touched a line of code in about 18 years I still laughed and got the jokes. I'm even more geek than I imagined.

Mine is the one with "'m really not THAT much of a geek" printed on the back.

[jake]

@Greg Fleming

"Even C does not need to adhere too closely to the original K&R spec. Lots of weird so-called "illegal" code compiles just fine and dandy. Depends on what you're trying to do. That's kinda the point, y'see?"

Exactly. I code in most of the common languages, but C is my goto language[1]. I want to control the compiler, I don't want the compiler telling me what I can and can't do ... Especially when I'm writing close to the hardware (kernel/monitor stuff & device drivers). Before anyone asks, yes I still hand massage in assembler occasionally. I'm an old fart, remember?

[1] Pun intended.

[Anonymous Coward]

Too much choice

I hate it when they keep adding new features to a language, I feel compelled that I must use them or else I will be left behind. I've only begrudgingly started using generics in C#, blah <lick out tongue> to nasty Lambda expressions.

As for C++, I gave up at copy constructors, thanks but no thanks, I'll stick to my lovely C.

Alien, as this is what C++ seems to be.

[A J Stiles]

Operator Overloading == FAIL

Operator Overloading is a recipe for fail. Don't even go there. An operator should mean one thing, and one thing only.

In JavaScript, the "+" operator is overloaded. You think it means add numbers; but it can also mean concatenate strings, like the . operator in Perl and PHP. But JS, like Perl and PHP, doesn't distinguish between numbers and strings. So you can think you're incrementing a value; but if the interpreter thinks it was a string as opposed to a number, you end up multiplying it by ten and then incrementing it.

I have now resorted to subtracting negative numbers whenever I want to add, and concatenating an extra "" between strings.

And to those smug b******s among you who will inevitably say "It's not an issue with overloaded opewators, it's an issue with dynamic typing. If attempting to add a number and a stwing thwew an exception, thereby forcing you to perform explicit type-conversion, it wouldn't be a pwoblem" : you're half-right, but why the hell should I have to tell the computer what's a string and what's a number? It's a freaking computer and it ought to be able to work that out for itself, dammit.

[Michael Strorm]

@Greg Fleming

"Even C does not need to adhere too closely to the original K&R spec. Lots of weird so-called "illegal" code compiles just fine and dandy."

Do you mean the original- and now quite old- K&R C from the first edition of the K&R book? That was- while useful- at most a de facto standard and in practice there was still variation between versions of C. Hence (I assume) the need for the ANSI C89 standard, which most modern compilers are based on, and with which compatibility would be more important.

(Ironically, the second edition of K&R describes ANSI C89, not K&R C).

As far as the ANSI C89 standard goes, it depends what you consider "illegal" code. C89 tends to describe many things as "undefined"; i.e. you can do them, but it makes no guarantees as to what might happen if you do.

Your program might work as you expected; or it might work in a way that reflected your particular OS/compiler/computer architecture (i.e. it might give different results on another machine). Or it might crash on your machine.

Your compiler might- or might not- specify what such code would do and whether you could compile it; C89 itself wouldn't cover such matters though.

So it's quite possible that you could compile and run "illegal" C89 code- you just can't expect that to happen across every C89-compliant compiler.

[Rich]

Constant functions

Just to be constructive for once, I like the way you can make functions constant. Handy in embedded programming where you want minimal codesize and readability.

[Anonymous Coward]

@ Michael Strorm

Precisely. The whole question of fitness for purpose does rather hinge on various compiler implementations more than the original or subsequently revised language specification.

The theory is that every compiler should strictly adhere to the latest standard for the language, but implementations do vary quite a lot.

Given that those who program in C tend to favour one compiler over another because _this_ will compile in _that_ while it won't in _other_ tends to reinforce that -- otherwise it would make any difference which compiler you chose. Clearly this is not really the case.

C (and derived) languages tend to be unforgiving in areas that don't matter where, perversely, they blithely allow the most freakish (but in terms of logic, completely valid) code to pass through anyway in really important places. I welcome rigidity but I also value versatility as well.

Remember that C and C++ can be totally dictated to by which headers I pop in -- I'm not _obliged_ to use the standard STDIO or any other headers, for example. C and its derivatives are designed to merely offer a high-level language abstraction for the native features of a given CPU architecture, nothing more. In this respect its pretty good and does what it does in quite a natural way.

[Nigel]

Loops

The author says, "And you can make for loops in a style I last saw in CORAL 66" OK, I know it's supposed to be humour, but this is actually how loops are done in many (most?) modern scripting languages, such as Python . ( for i in [1,2,5,4] ) It's not a gimmick, it's the Right Thing. The list can also be an iterator (which is how you do the C-type loops, for i in range(1,10) ), and most importantly, instead of counting out an integer sequence and then de-referencing each element of an array or iterable structure, you just say "for x in array" . It's error-proof (of if it's calling the iterator method of an object behind the scenes, at least the right iteration thing is coded by the author of the object, not the user thereof, and debugged once and for ever).

Imitation may be the sincerest form of flattery, but I can't see the point of trying to do things in a compiled language that are natural only in an interpreted one. Write the high-level control stuff in Python (or Perl if you really must ... beauty versus the beast, but both work). Write the stuff that actually crunches data and needs to go fast in C. Scripting (interpreted) languages have huge advantages for rapid development and cool run-time tricks, and for the outer levels of the code, a threefold efficiency penalty is hardly ever significant. For inner levels where speed matters, vanilla C runs faster.

[Anonymous Coward]

LOL Erlang

Funny 'coz I was having the same thoughts end of last year.

[jake]

@A J Stiles

"but why the hell should I have to tell the computer what's a string and what's a number? It's a freaking computer and it ought to be able to work that out for itself, dammit."

<patience mode=on>

Because, AJ, computers can't think for themselves. You have to tell them what to do. Explicitly.

</patience>

[Martin Usher]

Please can I have my Algol68 back?

C++ started out life as an honest pre-processor for everyone's favorite systems programming language (which had accidentally slipped into role of applications language after PCs became common). Its morphed into a monster. Its still possible to write decent code in it but for the most part when I see C++ I cringe -- its invariably pretentious spaghetti.

I, too, try to push people at Python or other modern scripting languages for user programs. Clean, portable and really difficult to screw up. For systems work C will do for the most part; you've got to know what you're doing at that level so just throwing source code at the problem and hoping the compiler knows what its doing (which is invariably not the case) won't work. C++ I just put up with -- you can't ague with its fanboyz, I can't be bothered playing specmanship pissing contests with them (I just know that there's lots of them, they're always late and their output is invariably buggy).

Flame away.....

[Peter Geoghegan]

@Martin Usher - gross inaccuracies

"C++ started out life as an honest pre-processor for everyone's favorite systems programming language (which had accidentally slipped into role of applications language after PCs became common)."

Stroustrup's original compiler that partially implemented the language (as it existed then), cfront, created at Bell labs in 1983 was implemented as a preprocessor, back when C++ was known as "C with classes" and was considered highly academic. So what? The stated goal of Stroustrup from the beginning was that C++ was "designed to provide Simula’s facilities for program organization together with C’s efficiency and flexibility for systems programming." The suggestion that C++ "accidentally slipped into role of applications language after PCs became common" is preposterous - it became dominant because it popularised generic and object orientated programming for systems and application programming, and there wasn't anything better at the time. For many domains, there continues to be nothing better.

"I, too, try to push people at Python or other modern scripting languages for user programs."

I too code in Python, and think it's great. I think that it often makes sense to use RAD tools or scripting languages, especially given that they can be extended with C++ where necessary through the use of boost.python. Bram Cohen's original BitTorrent client was written (and refined) in Python, but the BitTorrent inc (formerly uTorrent) client is written in C++. Why? Because if it was written in Python, or even Java, it would be at a commercially disadvantage to other, faster clients that are written in C++, and users must have a python interpreter on their computer or a JVM. Sure, that performance difference is a feature that must be evaluated on its own merits just like every other feature, but it often still matters, as in this case. People talk about garbage collection

You are treating C++ as an extension to C, which betrays an ignorance on your part. If you really want to annoy a C++ person, use the term "C/C++". As I've already said in a previous post, C++ is much safer than C. It's quite possible to know C++ and not know C, because C forces the user to use dynamically allocated arrays, return codes, macros, extensive casting, weaker typing (when you use malloc in C++, it returns a void pointer. When you use new is C++, it returns a pointer of the requested type. If you use malloc in C++, you must explicitly cast the void pointer to the desired type), and does not provide safe abstractions like the standard containers, or allow you to create your own safe abstractions through idioms like RAII and language features like templates.

C++ haters often imagine that C++ code has mallocs haphazardly placed everywhere as with C, coupled with high level abstractions, which actually would be dangerous. C++ programmers know to use abstractions like the standard containers, and RAII to avoid "sullying their hands" (as I believe Scott Meyers put it) with explicit memory management wherever possible. This makes memory leaks extremely rare in practice, and makes the supposed panacea of garbage collection look unattractive.

[Anonymous Coward]

void *self, *referential; referential = self; self = referential;

In 30 years of programming, I have lost count of the number of languages I have used either commercially or for fun. The programming language choice, for the most part, is irrelevant. If the hard thing about you work day is the programming language and not the thing you are actually writing - maybe its time to find a new career path. Do you really find C 'hard'? Do you really find the notion of a pointer difficult to grasp? It seems peculiar to the programming community the amount of almost religious zeal they have for the tools they use. Do mechanics feel the same ways about their spanners? Do some mechanics refuse to use socket sets because they are a bit 'difficult' to understand? Are they really mechanics if they do?

In my many years of programming I haven't come across a single new language that can do something that C can't do or be made, quite trivially, to do. I am backed up by the fact that a lot of these new languages are written in C! In the end, programming is merely a syntactic reflection of how our brains solve a problem. Perhaps different problem solving approaches can be better represented with appropriate languages. But what's important is your ability to solve the problem and not which spanner you used to do it.

[BlueGreen]

@AC 08:28

I partly agree that the strength is in the programmer not the language but claiming it can all be done in C, trivially, is nutz.

So, a challenge!

Ignoring one vital aspect of readability (cos that's incompatible with what follows), write something small for me that exhibits use of

* OO, in the form of inheritance, virtual funcs etc. (the usual)

* multiple dispatch

* multithreading (that's easy, but...) *with* thread safety by use of totally immutable functions, and, because purely functional style programming generates garbage in immense quantities:

* garbage collection to pick up the dead pieces and recycle them.

All by hand. Preprocessor us is fine. Using a conservative GC like great circle etc. isn't allowed as 1) you didn't write it and 2) it won't work.

Whatever you do I can do it faster, better, more readably, more efficiently and just plain nicer in dylan (which I haven't touched for years, but anyway).

2nd thoughts: I don't know if OO as I'm familiar with it works with pure functional stuff (probably does but I've no experience with it), so let's split it into 2 and you can choose either: OO+MD or MT with immutability+GC. Makes it easier, surely.

Kettle's on, mate...

[Anonymous Coward]

@ Blue Green from AC 08:28

OK - done it. I called it 'Java'.

[jake]

@Blue Green & @AC 12:04

Blue Green wrote: "Whatever you do I can do it faster, better, more readably, more efficiently and just plain nicer in dylan (which I haven't touched for years, but anyway)."

Dylan? DYLAN??? The bastard child of Scheme/Lisp & ALGOL? I learned Dylan out of curiosity a little over 15 years ago, but never found a use for it ... in my mind it's a solution looking for a problem that probably doesn't exist. No doubt that's why Apple dropped it years ago.

AC: Good answer. Bad language, but good answer :-)

[BlueGreen]

@Jake

I wonder, does anyone read my posts before replying? AC said this: "In my many years of programming I haven't come across a single new language that can do something that C can't do or be made, quite trivially, to do." And hence my challenge -- in C. I'll repeat that, in C.

Now it may be that AC had written a working Java compiler/interpreter in C and was prepared to put that forward as a kind of DSL for my challenge, and I would have admitted he had won (overlooking that Java doesn't do multimethods), but otherwise I can't see how his answer fits anything I said and my challenge still stands.

As for your comments on Dylan, it was described by an expert as being a dialect of scheme. If you don't like it, do it in lisp (you have experience in lisp IIRC). I didn't mention this because I have no experience with lisp, whereas I do with Dylan.

I don't much like Dylan syntax, but Java is just terrible -- what kind of language requires you to write out the type of everything *in full*, without being able to denote a full type with a straightforward name -- it gets bloody awful with templates. In C++ at least you can typedef, in Java you can't and you can't even clean it up with a preprocessor because they removed it as cpp was 'abused' (translation: 10,000,000 numpty programmers didn't have a clue so they took it out).

When Java has closures (not the hack using anonymous classes), proper support for functional programming and a decent syntax (preferably extensible like Dylan with hygienic macros) then maybe you'll have a point.

[BlueGreen]

@jake again

A couple of examples of java syntactic crapness from a public tutorial:

CleanUp<IllegalAccessException,DisconnectTask> cleaner = new CleanUp<IllegalAccessException,DisconnectTask>();

-and-

Triple<? extends Collection<?>> q = new Triple<List<? extends Number>>();

The second is a bit contrived but not much. The first is quite viable. If they can't even get that right... FFS someone in the generics development team must have said *something* at the time...

[Shakje]

SAPPEUR

Seems interesting, but only interesting at most. Saying reference counting is better than garbage collection is interesting, I wouldn't say that it's necessarily better, and presumably you'll still end up with the same problem of things going out of scope later if you don't scope properly (which is quite possible). I don't see the real advantage of this other than as far as order of destructors.

Integrity of pointers - yay!

Generics - why replace templates? Templates are fantastic.

Allocating on the stack - different how?

Multiple Inheritance - I find it annoying that you would remove a feature because people find it difficult to understand. You might as well remove complex maths in case people don't understand it.

Operator Overloading - syntactic sugar or not, if you understand it it's sensible and not misused. If you don't understand it you may well not get that it doesn't need to be misused.

Multithreading - yay! Does it work?

Safe casts - actually using C++ casts will not let you cast anything into anything, that's C-style casts.

Array bounds checking - cool, I guess I can get rid of those pesky vectors now (!?!?)

The problem is that it's limiting the language because some people don't use it properly. You know that it won't be taken up by the mainstream, and those same people will continue using C++ so that they can continue abusing it. The people who will suffer from using it will be the people that use the language well and sensibly and are limited by the 'safety net' that SAPPEUR provides.

[E]

Threads

[I don't care what language any of you like to code in. Doubtless I like some of them and can't stand others. Debating the identity of The One True Language is bootless.]

I've seen some stuff suggesting C++0.42x, if you will, is to have threads built in. Now here is something worth debating. Threads are AFAIK always operating system or virtual machine artifacts. Something like Java can have explicit thread support because it runs in a VM. C++ by contrast does not: it runs on the metal, and whatever thread model the metal & OS support can be exposed to C++ as a library (you know, posix threads, sun threads, linux threads, userland thread systems, etc). So adding explicit thread support to C++ seems pretty weird given that C++ does not define an execution environment.

If the idea is an abstraction wrapper that covers all possible threading systems, it is still a weird idea. One picks a thread system for it's characteristics: a wrapper just hides the details and specifics, makes it harder to use the thread system. Maybe a crappy comparison, but... did you ever program Windows GUIs with Win32 and then tried to move to MFC: what was fairly clean and reasonably sparse became opaque and baroque.

[Mark Tyndall]

Re: Operator Overloading

@A J Stiles:

overloading *should* be used to assist the user's intuition. So, a complex number class can use

a = b + c;

d = e * (b + c);

and not

a = b.addto( c );

d = e.multipliedby( b.addto( c ) );

which becomes a maelstrom of nastiness for even moderately complicated equations.

[E]

Clarifications, with apologies to M. Stob

Shamelessly nicked from an interview with Mr. Stroustrup.

1) Compare:

int i = {};

to:

vector greats = { "Newton", "Darwin", "Archimedes", "Bohr" };

2) Compare:

auto i = 0;

to:

for (auto p = v.begin(); p!=v.end(); ++p) cout << *p << '\n';

The auto says that the type of p is to be that of its initializer (v.begin())

---

My addition:

In the auto case you've already declared it somewhere. Presumably we will have to be a bit careful about saying 0.0 for double and 0.0f for float. Thus auto is not DWIM, as I first understood it to be. {} for an integral tyoe thus means 0, but for a non-integral type must present correct structure.

[jake]

@BlueGreen & @E

BG: I can code in most common languages, if I must. My comments on Dylan are from memory, I haven't even looked at Dylan in over a decade. It's still the bastard child of Scheme/Lisp & ALGOL, all of which I've made a living with, regardless. That, and the fact that Apple dropped it like a hot rock because it was prretty much useless in the great scheme of things were my only real points.

Re-read my comment to AC vis-à-vis Java. I don't like Java. Never have, despite making a lot of money with it. I found AC's answer to be kind of amusing nonetheless.

E: [I agree with your preface. [Pardon this colophon, BG]]

[Shakje]

Re: Threads

Just because it's specific to a library implementation doesn't make it wrong. Most of us don't choose threading models, we just use the one that the OS we're coding for lumbers us with, and all the threading support does is to standardise thread usage so that you don't have to worry about stupid different ways of doing it.

[Jack]

Same old C++:

... if you are shit, then you will write shit, but if you are _the_ shit, well, that's OK then. Someone up there wrote that they thought auto was like VB's variant 'type', and I suppose it can be used that way, but that's not why it was included.

My feeling is though that new features really confuse matters. Maybe I'm still at a _very_ educational stage of my development, but beyond C++'s complex inheritance, it oftens seems to me that C++ is a deliberate obfuscation of things you can do very reasonably in C.

C++ wants to be all things to certain kinds of programmer, but for most applications, C would actually be better, because its closer to assembly and therefore very controllable. Isn't control what C++ programmers crave?