Interview With Herb Sutter

Anonymous Coward writes "Herb Sutter, a C++ luminary, recently joined Microsoft's Developer Platform and Evangelism Division, where he acts as a liaison between Microsoft and the C++ developer community. In this interview he speaks about his new job, the role of C++ in the .NET framework, and the current state of C++."

Comments

New processor features?

[Andorion]

No mention of IA64, or X86-64 =( I'm really curious to know if compilers will be in place to exploit these platforms, ESPECIALLY IA64.

-Berj

(hyperthreading, too?)

Re:New processor features?

[Anonymous Coward]

Yes. But I'm not supposed to tell you that. ;-)

Anonymous Softie

Re:New processor features?

[Anonymous Coward]

Dear Anonymous Softie,

How do you sleep at night? How are you able to look yourself in the mirror each day, knowing full well how exploitive your employer is?

VC++ will provide what the community needs...

[GnomeKing]

My job definitely includes giving direct input into the feature set for future releases of Visual C++, to make sure that the product has what the C++ community needs. Note that by "the C++ community," I mean everyone who works for or with C++, on all compilers and platforms--that includes in-the-trenches systems and application developers

So... when are we going to see the linux kernel compiled on VC++?

Re:VC++ will provide what the community needs...

[sql*kitten]

So... when are we going to see the linux kernel compiled on VC++?

Oh, I guess that'll happen soon after kernel hackers throw away their free GCC and sign up for Visual Studio.NET :0)

Re:VC++ will provide what the community needs...

[x0n]

Nope, it definitely doesn't work.

c:\linux\src\kernel>nmake
Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 13.00.9466 for 80x86
Copyright (C) Microsoft Corporation 1984-2001. All rights reserved.

kernel.c
kernel.c(3) : error : Invalid token : expecting "(C)", found "GPL".

compile aborted.
c:\linux\src\kernel>

bugger.

Re:VC++ will provide what the community needs...

[TummyX]

So... when are we going to see the linux kernel compiled on VC++?


Considering the linux kernel uses non standardised GCC extensions...i doubt it.

Re:VC++ will provide what the community needs...

[larry bagina]

the inline assembly would have to be swapped over as well

VC uses a more straightforward inline asm, but the C/asm code isn't optimized (and VC scans the asm for registers affected and explicitly reloads them when you're done), and accessing variables passed in registers doesn't work.

__asm
{
xchg eax,myvar
}

Re:VC++ will provide what the community needs...

[Samrobb]

Considering the linux kernel uses non standardised GCC extensions...i doubt it.

At the MS PDC ~3-4 years ago, the VC development team was talking about giving "providers" the ability to integrate into the VC compiler. This would have given VC++ the same extensibility as C# (where you can define your own custom attributes, and write code that generates the IL for that attribute.)

My memory of this is, admitedly, hazy, but as I recall, this caused quite a stir (both for and against the idea.) Why bring it up? Well... MS has obviously at least thought about this over the past few years (both with C# and C++). If they really wanted to snarf market share from other compilers - including gcc - then providing the ability for end users to add arbitrary language extensions to VC++ (and minimize porting time) would be a pretty significant feature.

And, finally... if they did that, then you'd at least get around the problem non-standard gcc extensions in the kernel code. I'm sure many other problems would manifest themselves, though.

Re:VC++ will provide what the community needs...

[Anonymous Coward]

I'd settle for seeing the Compaq C compiler compile a kernel for my Alpha box. Why is it that
Compaq's compiler can create the kernel for NT 4.0, Tru64, and OpenVMS, but Linux _has_ to use all those assed-out gcc extensions?

Mmmm.... smart move, but seems a "bazaar" approach

[alapalaya]

MS made a smart move hiring one of the most famous C++ guru, and moderator of "Guru of the week" (GotW, here).
(The Exceptional C++ books are selections from the GoW series).
I really think that this will enhance the MS' C++ offer quality, and including the GotW thinkabout in its future design is a kind of "bazaar" approach!... Funny!

Re:First!

[ryszards]

An interesting point he makes about HTML being the best means for a cross platform interface for programs, C++ or otherwise.

I think he's right.

Also C++ being the best performing language in the .NET language suite is quite a suprise to me since I though C# got most development focus when creating the new tech.

Rys

Re:C++ expert

[alapalaya]

Please check the GotW site (here).
Here you can really check if you are a C++ expert. For instance, from the first Excexptional C++ book (here) you can find one of the deepest thinking about "exception safety".
Beleive me, I know tons of experienced C++ coders who don't know that a method who simply makes if-then-else and cout something on then and else branches can end in more than 20 different execution paths! (the topic is quite big, check the book... trust me, it's worth!)

Re:C++ expert

[Anonymous Coward]

how to write a C++ compiler in C? in asm? in 68K asm?

ANSI C++ compliance

[YeeHaW_Jelte]

I find it pretty strange that the same guy who is secretary in the standards committe now works for a company that market a definetly non-standard compatible C++ developement suite.
I've worked with Visual Studio in the past, and was always irritated by the microsoft-specific stuff and especially the automatically generated code, which is inserted at compilation time and thus can't be read or seen. I don't like using mystery code in my appilications.

Re:ANSI C++ compliance

[herwin]

My take is that MS is getting serious about standards compliance and quality in a number of areas. Hiring Herb is one of those high-profile actions that sends a message to the troops.

Re:ANSI C++ compliance

[jdennett]

You shouldn't find it so strange that a "guy which is secretary in the standards committee" works for a company which has recently declared its intention to change its ways and produce a fully conforming C++ compiler. Their internal build supports partial specialization now, and in fact most stuff other than export. It's finally getting to be about as compliant as compilers from other companies.

Did you know that Microsoft has relatively recently rejoined the C++ standards process, and even hosted the last ISO/ANSI C++ meeting? That's quite a turnaround.

After a little initial concern, I'm pleased to have someone with Herb's integrity working inside Microsoft. Over recent months (indeed, even before Herb joined MS) we've finally seen a willingness from Microsoft to discuss the flaws of VC++, and what they plan to do about it.

We can't assume that MS will play fair forever in this area, but we shouldn't assume that they'll double-cross the community. Much though the quality (or lack thereof) in VC++ annoyed me, I'm willing to give them the benefit of what little doubt is left. VC++7.0 is a step forward, and the next release is make-or-break in terms of the credibility of MS's C++ development team. If it's up with the leading group they'll have won the (possibly grudging) respect of large parts of the C++ community. If not, they might not get another chance so easily again.

Re:ANSI C++ compliance

[David Kennedy]

Get it right people; it's an ISO standard, not an ANSI standard. If nothing else this is a useful interview answer!

As for Herb Sutter - I believe him when he says he's to going to compromise his standards work. I don't believe MS, but Herb Sutter's books have earned him my respect.

Re:ANSI C++ compliance

[jdennett]

Get it right: it's both an ISO/IEC and an ANSI/ISO/IEC standard, and may well have been adopted by other national bodies as well.

The name on my copy is ISO/IEC 14882:1998, but I believe that in the US it's ANSI/ISO/IEC 14882:1998.

Cooperation between the ANSI C++ panel and the rest of the ISO C++ community is excellent, fortunately.

You're not wrong about Mr Sutter being trustworthy though, in my experience.

Re:ANSI C++ compliance

[PhilHibbs]

I was at the ACCU Conference that Herb mentions in his speech, and at the end of the first day there was a special last-minute session scheduled with Herb and Stan, called "Revelation on the road to redmond". It was quite interesting, and when Herb introduced the man who had implemented partial specialisation in Visual C++, there was a tremendous round of applause! And this was not a conference full of Microsoft flunkies, far from it.

The upshot is, MS have an internal build of MSVC that will compile Loki. It should be available around the end of this year.

Re:ANSI C++ compliance

[lkaos]

Well, the ISO standard and ANSI standard are identical except the ANSI standard is like $13 whereas the ISO standard is like $250.

So I have and follow the ANSI standard. Much nicer IMHO.

Re:ANSI C++ compliance

[Anonymous Brave Guy]

Well, the ISO standard and ANSI standard are identical except the ANSI standard is like $13 whereas the ISO standard is like $250.

Wrong way around, I think. ISO's electronic version is the cheap one; the only version available from ANSI, as far as I know, is the one that costs ~10x as much. Fortunately, there seem to be moves afoot for several standards agencies to make their material available for a sensible price, so hopefully this whole issue is moot.

Re:ANSI C++ compliance

[Anonymous Brave Guy]

Did you know that Microsoft has relatively recently rejoined the C++ standards process, and even hosted the last ISO/ANSI C++ meeting? That's quite a turnaround.

Indeed it is. However, coming from a company with a vast history of turnarounds in their past -- many of which have proven to be anything but in the interests of The Rest Of Us when faced with the test of time -- I think it's only fair that the rest of us be a little sceptical. Hiring people like Stan Lippman and Herb Sutter is not, in itself, going to turn around their whole program. I'm sure Herb and Stan have laudable intentions, and I wish them the best of luck at changing from within, but it'll be a while before I bet my career on it. When you can use C++ -- all of C++ -- with .NET and all the new toys, get back to me...

Much though the quality (or lack thereof) in VC++ annoyed me, I'm willing to give them the benefit of what little doubt is left.

You're more generous than me, I'm afraid. Y'see, I remember a few months back, when VC++.NET was going to be the one with all the improved standards compliance, and y'know what? It's almost as bad as VC++ 6. I've heard the song before, and it's getting a bit tired now.

Re:ANSI C++ compliance

[lkaos]

Your right. I just checked the cover page and it says (C) ISO.

Re:ANSI C++ compliance

[igrek]

That's interesting. Could you give an example of this misterious "automatically generated code"? But wait... you say it can't be read or seen... Hmm...

Re:ANSI C++ compliance

[kinga]

Herb wrote an article with Jim Hyslop on standards-conforming compilers: Conversations: So Who's the Portable Coder?. In it they address the loop variable scoping issue which plagued many C++ compilers (and was discussed on /. some time ago).

Re:ANSI C++ compliance

[jhyslop]

As for Herb Sutter - I believe him when he says he's to going to compromise his standards work.

I presume "to going to" should read "not going to"? :=)

And what about the Visual Studio .NET license?

[jamwyd]

Fair enough, but given that Herb Sutter is an authority and "evangelist" on C++ in general - how can he reconcile his new position with the new licenses MS are attaching to their development tools which seem to prohibit any GPL'd application (e.g. GCC) linking against their .NET library?

Re:And what about the Visual Studio .NET license?

[Anonymous Coward]

Easy. Bite me. --Herb

Re:And what about the Visual Studio .NET license?

[jhyslop]

Licensing and standards conformance are two distinct issues. Licensing is likely not determined by the developers. It's probably the marketing and/or legal departments that determine the licensing. If you're really concerned about it, why not email Herb and ask him directly: hsutter@acm.org ?

Re:And what about the Visual Studio .NET license?

[clubin]

Can you point out the section in the VS.NET final license that prohibits this?

Re:And what about the Visual Studio .NET license?

[Black Jack Hyde]

how can he reconcile his new position with the new licenses MS are attaching to their development tools

That's easy. He does this every time he reconciles his checkbook, now replete with lots of M$ digits in front of the decimal point. Good for him, by the way.

Jack

Re:Bleh

[KingSlime]

Must you REALLY break the scroller? -_-; Would a mod kindly delete/edit this guy's post? It's annoyingly long.

yeah right

[Foss]

"The need for a flexible programming language that can handle everything from high-level abstraction to bit-twiddling, all unified within the same language, isn't going away anytime soon."

I think he forgot to add "because we have waaaay too many bugs to fix" at the end of that sentence. :)

Might just be me

[nervlord1]

It might just be me, but to me, it seems.. well.. wrong, for someone recommending the C++ standard to be part of ANY commercial company who's job it is to write C++ code.
Ok that sound's a bit silly on the surface but think about it: they might recommend specs that make thing's easier for them but harder for other's, or basically have a hidden agenda.
this is ESPECIALLY true for a company like Microsoft who.. well, Lets not kid ourselves Microsoft Apologists: rarely follow standards, and tend to "embrace and extend" the standards they do choose to follow. it just seems like a reciepe for a little underhanded.

But maybe i'm missing something, anyone want to make a constructive critism?

Re:Might just be me

[jdennett]

Sure, I'll take a crack at constructive criticism.

Most of those in the C++ standards group are employed by companies with an interest in how the standard works out. By the time it comes to voting on issues for inclusion in the standard, however, each country gets just one vote, so no company can impose its will; standardisation works by building concensus.

So, sure, Microsoft will be pushing for things which suit them. And likewise for Sun, Oracle, Comeau Computing, and any number of other companies. The ISO standards process isn't so easy to buy.

Re:Might just be me

[Harri]

it seems.. well.. wrong, for someone recommending the C++ standard to be part of ANY commercial company who's job it is to write C++ code.

The C++ language is _for_ people who write C++ code. Are you seriously suggesting that the majority of the users of a language should be banned from participating in the standards process, because they get money for doing their job?

I am hoping you really meant that the people who write the compilers should not be allowed input: but even this is impractical, since nobody wants a standard full of features which turn out in practice to be unimplementable.

Re:Might just be me

[nervlord1]

yer, as i said after i wrote that it sounded a bit silly, and i suppose it is.
but still, i stand by my no-compiler-writers people on there
(perhaps have one person whos entire job it is is to say "no, a compiler can't do that" is a good fix?)

Re:Might just be me

[jdennett]

Who, then, do you think would pay for the standardisation process? In our capitalist world, it just about has to be funded by those who stand to gain from it.

Re:Might just be me

[crudeboy]

it seems.. well.. wrong, for someone recommending the C++ standard to be part of ANY commercial company who's job it is to write C++ code.

I can't see that this is a problem, since the standard body consists of many people. It would be a problem if a majority of the standard body belonged to the same company and could force decisions, but I don't think that's the case here.

I don't think the fact that Kerningham & Ritchie worked for AT&T when C was born has been a problem and the same goes for Java with the ties to Sun (through Gosling, Joy et al).

I would think that it's a good thing that the people recommending standards work with the language.

Just my .2$

Re:Might just be me

[Cuthalion]

You're just plain wrong. Even assuming that you mean the people making compilers, not the people using C++. First of all, if you exclude the people who implement your standard from the decision process, if it turns out to be a nightmare to implement or whatever, then they all just ignore the standard. Secondly, they may have some insights onto what constitutes well-definedness for various standards issues (when you're looking at the problem from the other end, you see different things). Thirdly, the people making the compilers get a lot of feature requests from their users. They can provide a lot of useful information to the consortium. Fourth, any embrace and extend can be avoided by putting the useful features that Microsoft wishes to add to lure people to their compiler into the actual standard. If the standard does what people want, there'll be no reason to use nonstandard extensions. Also note that it's not Microsoft that added a whole nother pair of operators to C++, but GCC. (try fixing _THAT_ with a preprocessor macro)

I agree with the basic sentiment that any standards body should not be dominated by a single entity, be it Netscape, Microsoft, or Sun. Microsoft should have a say. So should the GCC team. So should Borland. If they can all agree on a standard that they each want to implement, the standard will be implemented faster and with stronger adherence.

Re:Might just be me

[Anonymous Coward]

Exactly. Anyone remember the Algol disaster?

Re:Might just be me

[jejones]

Eh? Aside from the unfortunate transput morass, Algol 68 is really a pretty small language. C++ is already vastly more convoluted than Algol 68 ever was (C++ books have taken over from Computer Shopper issues as instruments of deforestation; it doesn't appear to be possible to cover C++ in under 1-1.2K pages these days, and books just on STL or iostreams and locales run from nearly seven hundred to eight hundred pages)--and it's going to get bigger. Ah, well; it would take Dijkstra to really do justice to commenting on C++.

Migrating from VB to C#

[Quadrature]

I certainly hope that C# will be the destination of choice for a lot of today's Visual Basic application developers.

Do you think this is what MS had in mind when they developed the Common Language Runtime?

Hmmmm... Let's develop a runtime and a language that fits perfectly on top of it. Then, let's claim that any language can compile to this same runtime so we have a cross-language platform! Nevermind that they will have to forgo any features that aren't supported by the runtime or at least will have to hack around them. Eventually everyone will move to our perfect single language!

Even VB.NET falls into this category. It doesn't quite match the CLR as perfectly as C# does. I wonder how long until they try something similar C++... oh wait...

Not needed in the compiler

[samael]

All you need to do is make sure that the .NET VM itself works in IA64, and all code automatically works in it too.

Re:Not needed in the compiler

[jdennett]

But you're missing the fact that VC++7.0 can still generate non-.NET binaries. And the fact that it can is a Good Thing. .NET isn't going to be the whole world, and for some while yet it's still a fairly small corner of it.

Re:Mmmm.... smart move, but seems a "bazaar" appro

[jdennett]

Herb is the creator and sole mind behind the "Guru of the Week" series, not just one of a panel.

He's also a moderator of comp.lang.c++.moderated, and recently has also joined the comp.std.c++ moderation panel, on which I also sit.

His "Exceptional C++" and "More Exceptional C++" books are more than just printed copies of the GotW material, which is freely available online.
Exceptional C++ in particular is a fine book, and all truly serious C++ programmers should read it.

Re:Bong Head Photo

[Anonymous Coward]

no way. that's the infamous "gay handlebar mustache." if he were wearing one of those black leather hats, it would all make sense.

gcc compiling MFC?

[Anonymous Coward]

Just out of interest... can gcc compile MFC?

Guess what!

[Kj0n]

There really is a division within Microsoft with Evangelism in its name.

Look here for its press release.

FP?

[Anonymous Coward]

FP!

When does it stop

[FutureShoks]

So how long until I they start moving onto the other untainted languages? perl.NET? assembler.NET? english.NET? This is really going too far, really.

Re:When does it stop

[Anonymous Coward]

I was in one of those huge chain bookstores a couple of days ago. Here is the latest scoop.

There were dozens and dozens of new titles about something called asp.NET. I have no f**king idea what asp.NET is. However, it must be the latest trendy buzz. This was in Borders Books. They had as many books on asp.NET as they did on C++.

It seems so damn artificial. Why so many NEW titles on what otherwise would be an obscure topic. I swear that there must be some sort of payola from Microsoft to create "buzz" around some peculiar idea they want to push. In fact, despite the fact that nothing called ".NET" exists in reality or is used by anyone, the whole damn CS section is now dominated by books with the word ".NET" in the title. Who are the f**cking lemmings that buy this shit?

Check it out yourself. If you haven't walked into a brick and mortar bookstore recently, your jaw will drop at what you will see.

Re:When does it stop

[Anonymous Coward]

ASP.NET is for developing web pages. ASP (Active Server Pages) was the orginal technology and ASP.NET is the newest (and much improved version.)

ASP is very similar to Java Server Pages (JSP), (ASP came first, actually) and I would assume there is at least some resemblance in PHP. Perl/CGI, however, is a much different approach.

There is a great deal of interest in ASP.NET because many people have used ASP in the past, and ASP.NET provides many important improvements.

If you don't do web development or are committed to a different technology like JSP or Perl, then it would be of no interest to you.

Re:When does it stop

[Anonymous Coward]

Thanks for the information on ASP.NET. I was really amazed by the selection of titles available on that subject. I am more familiar with CGI and as I recall, at least at one time, asp was more Microsoft centric and not really all that cross-platform (I'm obviously not a web developer).

Re:When does it stop

[sinserve]

Well, I have seen a "COBOL .NET" book, and I am not making this up.

--

Re:When does it stop

[fuali]

Instead of screaming and whining and pointing fingers, why don't you pick up a book and find out what it is about.

I am now an ASP.NET developer (not exclusively). And everybody I know (even an objective-c developer) are looking at ASP.NET's API and features and are saying, "Wow, that is actually cool."

Before crying about it, and complaining about it why not learn about it.

Re:When does it stop

[Anonymous Coward]

nope, you can use COBOLSCRIPT, Perl, or whatever in your ASP pages, if you want.

Re:When does it stop

[Schnapple]

Yeah, Fujitsu stepped up and made NetCOBOL for .NET, even having tons of release candidates and betas availale prior to .NET's full release. One of the .NET credos (sp?) was that since so many different languages were going to point to the CLR, you could write in "any language" and make it work for .NET, and of course it would only be a small leap to make your COBOL programs work on the web.

I'm 25 and I work for the Student Information & Management System for a large university. We're still using COBOL on mainframes, kinda ironic for my first programming job. We're starting to migrate functionality to the web but a lot of the old fogies here COBOL until they die, plus we have tons and tons of legacy code. If we use the COBOL.NET bit then that would save tons of time and retraining.

For what we're doing here (and have been since 1985 apparently) COBOL does the job. You don't pitch something that works.

Oxymoron

[Anonymous Coward]

C++ luminaire

Throw money up in air, let rain down on head

[sam_handelman]

Penny Arcade reveals eternal thruths.

Way to go, Herb. If I could sell out for the kinda cash you must be raking in (suggestions - build giant bin, go swimming) I'd do it in a second. 99% of the personal criticsm is (already apparent) personal jealousy. This isn't a sinister plot to somehow subvert ANSI C++ to MS' evil ends. It's a good career move on his part.

from MS web site:
"Herb's involvement in the C++ community will allow Microsoft to better work with developers building great applications in C++ and ultimately help drive the direction of our Visual C++ .NET tool," said Eric Rudder, senior vice president of the Developer and Platform Evangelism Division at Microsoft.

i.e. he's a PR figurehead. MS seems to think people will care. Jokes on them. This is too bad, b/c some people are going to be forced to work on C++@.NET, and Herb writes good; if they put him in documentation I'd actually be pleased.

Re:Throw money up in air, let rain down on head

[blank]

a PR figurehead to whom? it seems like his job is to talk to the C++ developers and ask them what they need. he then figures out what is actually a good request for features and what is just wishful thinking and tries to get MS to deliver. In also doing that he's going to be getting VC++ standards compliant! so as i see it the only person that has to listen to him is the MS employees. he's more an C++ evangelist targeting MS than anyone else.

still, if he was a figurehead, he's pretty credible and i would listen to him.

it'll be great if he delivers on his promises. if VC++ becomes standards compliant even somewhat MS can't take that away. they will be forced to always support it for a very long time.

Re:Throw money up in air, let rain down on head

[Twister002]

Nobody gets "forced" to work in any language or on any platform. If you don't like the language, don't program in it.

"But Windows is the standard at my job, I'm forced to write one a windows platform and use .NET"

Get a different job then dork, if you can't find a job that will make you happy. Change careers, you can always program on your Linux/Unix/OSX box at home as a hobby if you really love programming.

Why does every programmer think that they are so important that the world must cater to them?
"Microsoft must go away because they are evil, they should change their languages because I don't like them"

Go play with your GCC compiler on your Linux box then. No one is "forced" to use any technology, you don't get put in jail or killed if you don't use Microsoft products. If you don't like what Microsoft does with VC++, don't use it. If you have to at your job and that doesn't make you happy, find another job. If you can't find a job programming on the Linux platform then either suck up and use MS products to make yourself money or find another career and make Linux programming your hobby.

Re:Throw money up in air, let rain down on head

[Anonymous Coward]

that comic is fucking retarded. go shoot yourself.

Re:Throw money up in air, let rain down on head

[Computer!]

Get a different job then dork

Here, here! No wonder everyone thinks programmers are whiny little geeks. Can you imagine? An entire community has sprung up around such esoteric issues as C++ standards compliance.

Hey, nerds: cut out the whining. It's making it harder for me to feed my kids. And get laid, so I can make more kids. Please mod parent up.

Good advice at end...

[zmower]

Always learn. Learn from the existing literature, C++ books and magazines and Web articles. They help you avoid reinventing well-known wheels. Learn different languages. They embody different ways of thinking. Learn different tools. They teach different ways of approaching problems. Most language zealots I've encountered think that their favorite language is the be-all and end-all, simply because they know few or no other languages. Know the various tools you have available to you, and you can do a much better job of selecting the right tools--plural, not singular--that will help you get your job done today.

All good advice. Doesn't the last bit make you think "i.e. use UNIX!" But why does this guy still prefer C++ over Java/Ada/Python/<insert your favourite language (except C!) here>?

<My C++ flame deleted.> What's the point? Use what you like but leave me to make my own choice. (I do have a C++ project so I know enough to know I don't like it!)

Re:C++ expert

[Anonymous Coward]

Beleive me, I know tons of experienced C++ coders who don't know that a method who simply makes if-then-else and cout something on then and else branches can end in more than 20 different execution paths! (the topic is quite big, check the book... trust me, it's worth!)

If your C++ syntax is anything like your English syntax, I'd be surprised if you could get hello_world.c to compile.

C# or C--?

[GdoL]

For MS he now is a C# expert and evangelist. Why get the good guys from C++ unless they wanted them to switch to C#?

One Target?

[Komarosu]

Maybe now with him joining the MS team he can maybe push for more compatabilty between the compiler sets. I know theres alot of G++ and VC++ extensions that people would like to see in both sets. Maybe one day this may make porting apps specialised for one compiler to another easier. Just my 2 cents :)

Re:Bleh

[yatest5]

Must you REALLY break the scroller? -_-; Would a mod kindly delete/edit this guy's post? It's annoyingly long.

Are you saying a troll's post is annoying? Best tell him, and sure thats not what he meant to do...

C++ is *not* a good cross-platform language

[evbergen]

From the article:

"Q: Standard C++ doesn't support modern programming concepts such as multithreading, distributed computing, components, and persistence. The result is a plethora of proprietary libraries and platform-dependent frameworks that make cross-platform development in C++ nearly impossible. Is Standard C++ still relevant? Which features would you like to see added to the language in the future?

A: Again, these questions arise from an overstated premise. Thousands of companies are routinely writing and shipping cross-platform software written in C++. Claiming that it's "nearly impossible" doesn't change the fact that we've been doing it for years. The one big area I can think of where portability is genuinely difficult is one the question didn't mention -- GUIs. GUI portability is a problem in all languages, unless you give up writing rich GUIs and write only simple and limited ones. Interestingly, despite some languages' attempts to "standardize" cross-platform GUI libraries, the best and most successful solution for cross-platform GUIs is not a code library at all, but HTML."

Well, that proves the point, doesn't it -- HTML + JavaScript is apparently a "language" that people find better suited to define standard, cross-platform GUIs in than C++!

The reason may very well be that C++ GUIs tend to they tie in to too many features of the underlying platform to be portable. If you /do/ want portabilty, you're on your own: you'll have to invent your own abstraction layer in order to achieve it. Obviously, some succeed better than others in that respect, and as he says, it doesn't keep people from trying.

It seems that any language that uses a runtime (for HTML+JavaScript, that's the browser; for Java, that's the JVM; for Scheme, that's Emacs :P), is much better for offering cross-platform services and libraries, simply because the burden does not lie upon each and every individual library developer anymore to create a platform abstraction layer. That only has to be done once, by the runtime.

Really, this is not exactly a mind-shattering concept (USCD-Pascal on p-Code anyone?)

Not that the current state of affairs with HTML+Javascript or Java gives much reason to feel content, but I *definitely* still see the point of having a runtime that offers a standard, special-purpose language to define GUIs.

However, I think the API for such a runtime should be viewed more as a data protocol than as a set of language-specific functions to call.

And *that* really applies to more than just GUIs: there really is a need for portable APIs that are not tied to any language these days, if you look at those complex, horrible 800lb monstrosities like Corba, COM or .NET. But I think the reason why these are so big and ugly is because they want to make it possible to put the interface at every conceivable place. Of course the interfaces will be complex if you do that.

Why not focus on *data-centric* APIs instead, that are intended to be put where the interface is as thin as possible, and build them as efficient and robust as an internet protocol should be?

If you're thinking of XML now, that may be close, but I really can't see how XML is the most efficient and easy-to-implement way of transmitting trees of attribute/value pairs. It's too difficult and slow to parse, to start using it as a transport for local subsystem calls as well, and contains too much redundancy, such as named close tags.

What the Internet and your local system needs is a good OSI layer 5. Is HTTP + XML really the best thing we can come up with?

Re:C++ is *not* a good cross-platform language

[Frequanaut]

Personally, I found it amazing that he completely blew off a perfectly legitimate question like this.

I work for a company that ships a dbms on 12+ different platforms. We've had to license a gui toolkit and write our own threading library, nevermind the lack of binary interface standards.

The c++ committee needs to get their heads out of the clouds and actually talk to developers rather than listen to others in their ivory towers.

People criticize java for being too closed, but at least sun listens and has process in place to insure their users are heard.

Re:C++ is *not* a good cross-platform language

[Anonymous Coward]

Why did you write your own threading library?

You could have used one of several free ones: boost, ACE, et al or paid for one, e.g. RogueWave.

Of course writng your own is more fun, but there's on way you can claim you *had* to.

Re:C++ is *not* a good cross-platform language

[Harri]

Personally, I found it amazing that he completely blew off a perfectly legitimate question like this.

Hello, he linked to an article of his describing how a great number of these issues are slated to be sorted out in the next standard! How is that "blowing it off"?

And, by the by, the C++ committee isn't a bunch of lawyers and accountants or something: it's made up of C++ developers, compiler writers and so forth. If you want to get your point across, go to a committee meeting! There's little use in complaining that the people who could actually be bothered to go aren't following your agenda.

Re:C++ is *not* a good cross-platform language

[Frequanaut]

Damn, I missed that link. my bad.

However, I did subscribe to the mail list, and I di follow it loosely (note the tense). As for the makeup of the comittee, it's not *really* made up of developers. Compiler writers yes, typical developers no. (No one ever said it consisted of lawyers or accountants).

Compiler writers obviously have a different agenda than developers.
Where as a compiler writer would prefer those features that are easier to implements, I would prefer those that are easier to use.

Re:C++ is *not* a good cross-platform language

[Nicolay77]

"a plethora of proprietary libraries " ?

Open source crossplatform GUI (and threads and some other things) Library for C++:

wxWindows

Re:C++ is *not* a good cross-platform language

[spitzak]

Excellent point that the API should be a data protocol or otherwise simplified.

GUI api design today seems to me to be equivalent to the interfaces to file systems in the 1960's. At that time you had to know exactly what device and structure of the file you were going to use, you had to use a completely different set of calls for each file, and "pip" (the equivalent of "cp") was far larger than any other application on the system. In modern GUI interfaces you have windows, menus, buttons, canvases, etc, and printers, all with vastly different interfaces (MicroSoft's GDI is not quite a solution although I certainly admit it is better than the situation on Unix), and COM and Corba, etc, are the equivalent of PIP and enormously complicated.

In 1970 the Multics/Unix people came up with the open/read/write/seek interface to files. I'm sure then there was huge gnashing of teeth and complaints that people would write all kinds of inefficient databases and there would be "inconsistent interfaces" that would "confuse users" and all the other attacks that are levied against any attempt to simplify the GUI today. Well it turns out they were wrong, the simple interface works and resulted in more powerful databases than anybody ever imagined, and that interface designed in 1970 can be used today on huge arrays of networked computers and on disks the size of which was unimaginable then.

We need the same thing in GUI today. I don't know if there is much hope as it requires a powerful force to implement it. MicroSoft could, but ActiveX is the exact opposite, it is enormously complex and basically requires all of Windows to be implemented (there would be little complaint if in fact a slow emulator like Mesa could be written for ActiveX, but the design makes it impossible). Everything else I see is an attempt to make "toolkits" be part of the OS (ie Berlin and Qt Embedded and Atheos) and I think is going to make things worse. I don't know if it is possible for a solution to appear today.

Re:C++ is *not* a good cross-platform language

[Anonymous Coward]

I work for a company that ships a dbms on 12+ different platforms. We've had to license a gui toolkit and write our own threading library, nevermind the lack of binary interface standards

One, a GUI and a threading model are not part of the C++ language. If you want a language that comes with a standard GUI toolkit and threading model then there's Java, for example.

Two, the C++ committee work on the language specification, not its implementation. You'll have to convince compiler writers if you want a binary (?!) interface standard (for each processor X).

Don't condemn the language just because you don't like how your company solved its portability problem.

Re:C++ is *not* a good cross-platform language

[olau]

Have you ever followed the discussion on comp.lang.c++.moderated or comp.std.c++? You'd know you are wrong in implying the comittee is biased towards "easy solutions", if you did. Most of these people spend lots of time writing articles on how to use the language most effectively.

Re:C++ is *not* a good cross-platform language

[Anonymous Coward]

Bill, I'm surprised you didn't mention FLTK :) as an example of a decent cross-platform toolkit. It's simple & it works !

Re:C++ is *not* a good cross-platform language

[FishBrando]

It seems that any language that uses a runtime (for HTML+JavaScript, that's the browser; for Java, that's the JVM; for Scheme, that's Emacs :P), is much better for offering cross-platform services and libraries, simply because the burden does not lie upon each and every individual library developer anymore to create a platform abstraction layer. That only has to be done once, by the runtime.

Agreed that a runtime can be made platform-specific, but isn't this just another abstraction layer? What is the difference between the runtime and an abstraction layer for GUIs in C++, in terms of cross-platform GUIs?

And *that* really applies to more than just GUIs: there really is a need for portable APIs that are not tied to any language these days, if you look at those complex, horrible 800lb monstrosities like Corba, COM or .NET. But I think the reason why these are so big and ugly is because they want to make it possible to put the interface at every conceivable place. Of course the interfaces will be complex if you do that.

The strange part is that you've mentioned three of the most famous portable APIs (or, more accurately, API protocols) that are not tied to any language - as examples of why we need portable APIs that are not tied to any language. And they are, as you said, 800lb gorillas. And can you elaborate on "put the interface at every conceivable place"? All of these API protocols have a well-defined interface layer.

Why not focus on *data-centric* APIs instead, that are intended to be put where the interface is as thin as possible, and build them as efficient and robust as an internet protocol should be?

Can you elaborate on this idea? I like it, but I'm not sure I'm completely following your "thin as possible" line of thinking (what does that mean?) And why should it be like an internet protocol?

Re:C++ is *not* a good cross-platform language

[spitzak]

Yes but I would still like a lower level so that implementing fltk was a relatively trivial operation.

Right now writing fltk is like writing a text editor where the only interface to the disk is the disk blocks, I would spend a lot more time figuring out the file system and trying to correctly cooperate with other programs, than writing useful things into the text editor.

Re:C++ is *not* a good cross-platform language

[evbergen]

Agreed that a runtime can be made platform-specific, but isn't this just another abstraction layer? What is the difference between the runtime and an abstraction layer for GUIs in C++, in terms of cross-platform GUIs?

Of course a runtime is just another abstraction layer. But the thing is that a runtime that provides a virtual platform, shields the program that runs on it from the real host platform. As such, the portability problem is solved separately from the main problem. Remember that I'm not arguing that cross-platform GUIs are impossible in C++, I just say that a language such as C or C++ that has the API of the host platform as its primary toolbox, encourages you to write single-platform applications, and makes it hard(er) to do cross-platform ones.

The strange part is that you've mentioned three of the most famous portable APIs (or, more accurately, API protocols) that are not tied to any language - as examples of why we need portable APIs that are not tied to any language.

That's not strange, that illustrating my point: apparently there is a need for such things. But I think they're following an approach that to me seems needlessly complicated.

And they are, as you said, 800lb gorillas.

That's my objection to them.

And can you elaborate on "put the interface at every conceivable place"?

That's the cause of it as I see it. These protocols allow you to define the interface between any two objects, i.e. they support each and every inter-object communications scheme you can think of supported by every conceivable language. You can export any native object, so to speak, and expose it to the outside world, without limits in functionality.

Can you elaborate on this idea? [data-centric APIs] I like it, but I'm not sure I'm completely following your "thin as possible" line of thinking (what does that mean?)

Well, defining an API in terms of pure data messages encourages you to place the interface between your components in such a way that you need the least amount of different message types, and the smallest number of (interrogation) transactions before doing the actual work.

An API defined in terms of function/method calls that look the same as local ones, doesn't make it seem like much of a problem to have lots and lots of calls from component A to B and from B to A, because it doesn't put the fact that each call must be put through that big remote object layer, firmly in your conscience while developing.

And why should it be like an internet protocol?

Well, because they tend to be simple, lightweight and robust, and also because of the difference in philosophy when you compare them to protocols originating in the telco world. Those former are designed in terms of black boxes and the exact way they perform their function first, and then you look at the information they need to pass between them for each to perform its particular function. Naturally, the resulting protocol will express a lot of how the design and implementation of those black boxes turned out.

But for most internet protocols the intelligence is put more in the data, and the messages themselves tend to get designed in detail before the endpoints are. You basically imagine what each side of the 'wire' theoretically needs to know of the other, and design a way as simple and generic as possible to transmit that information, and you design the black boxes at the endpoints as a next step. Of course this is overstating things a bit in practice, but you get the idea.

The difference is that you're not modeling the protocol to some specific, already designed, detailed endpoint implementation, but to a generic model you've got in your head. Such a protocol will in most cases allow alternative implementations to be done much more easily, and you can see from the number of different implementations for most internet protocols that this is true.

What am I getting at with this? Simply this. Messages (data) are *much* more portable than code libraries; you only need to sort out relatively easy endianness and word size issues, and you're done. So an API defined in those terms will always be much more portable than APIs defined in terms of *functions*, which will always be tied to a particular language, whether that's a native language such as C++, a language that runs on a virtual platform such as Java, or a complex abstract interface description language such as IDL.

If a protocol or API is so complex that the easiest way to port it to a new platform/language is to port a particular code library that implements it to a new platform/language, then it has failed as a protocol, IMHO.

Re:C++ is *not* a good cross-platform language

[evbergen]

Ugh. Typo.

"And why should it be like an internet protocol?

Well, because they tend to be simple, lightweight and robust, and also because of the difference in philosophy when you compare them to protocols originating in the telco world. Those former are designed in terms of black boxes and the exact way they perform their function first, [...]"

In the last sentence, stike 'former'. I'm referring to the telco protocols, not the internet ones.

Re:C++ is *not* a good cross-platform language

[Anonymous Coward]

You are funny.
Somebody somewhere has to hit the metal and I just happened to think that GDI level is just about right.
You ARE supposed to sweat while implementing fltk so I don't have to suffer later while using it.

Hm...

[Sam Lowry]

There is an option is MSVC which is called Disable language extensions but which in fact makes the compiler more C99-compliant.

I think, the first step this guy sould make is to rename this option into Enable Microsoft C++ extensions and make it disabled by default.

Re:Hm...

[egott]

I vote for replacing -nologo with its inverse first. Another good switch would be "-please-dont-core-dump-on-syntax-errors".

Yeah, okay...

[Anonymous Coward]

But does this article have anything to do with C++ ?

reguardless

[f00zbll]

No matter what people think of him going to MS, the man knows his C++. Merit is what counts people, not where you sit at work, or the name attached to your business card. The only thing worth keeping is ones integrity and work ethic. Companies, languages and platforms come and go, so don't get too attached to the latest fad.

Re:Question 1

[knulleke]

I understand all too well that my employer forces me to use java. Being a c++ guy this makes my stomach turn. I consider java to be one of the darkest forces in nature. Invented to crush attempts at being intelligent.

Anyone got a real job for me?

He always had a soft spot.

[antoniol]

His webpage is Frontpage generated.

Re:He always had a soft spot.

[fishebulb]

or since he is a C++ guru, he doesnt care about html, it seems pretty reasonable. im glad he is more concerned with providing great C++ info than worrying about his webpage html

What about the learning curve?

[smittyoneeach]

Regarding namespaces

It just creates useless typing overhead. After all, there's nothing wrong with the liberal use of using-directives when there aren't any name ambiguities, and why tell people to always manually resolve names even when there is no name collision to resolve?

Not to start a flamewar here, Herb, but this idea seems to help in a similar way a decent variable naming convention helps. Additional information, embedded in the code, (with the resulting maintenance hassles) has the potential to save a lot of time during maintenance and when you have a new hire.

The reply might be that such meta-information belongs in a design document. Fair enough, yet you've merely re-located a requirement, not obviated it.

I guess with an infinite budget we could just hire an army of gurus who sneeze, emitting code that compiles on any platform with nary a warning... :)

Re:What about the learning curve?

[Anonymous Coward]

Read the interview. He's talking about coding guidelines which prohibit using directives and/or declarations everywhere: e.g. a using std; placed inside a cpp file or even better inside a function definition, where it can't possibly contaminate other compilation units.

OTOH, anyone putting a using directive (especially at global scope) in a header file deserves to be shot, of course.

Herb deprecating the use of namespaces might make a good Twilight Zone++ episode... :-)

What about C99?

[Anonymous Coward]

Nothing was mentioned about the impact that the changes in the C language in C99 would make on C++. Given that currently they're incompatable
and that a lot of C++ coders are actually C coders who happen to use a C++ compiler to compile their C code it might have been a useful
point to bring up.

Blue ski?

[kubrick]

That's the data it's my job to distill -- to separate patterns from noise, well-thought-out requests from blue-ski wish lists

Blue skis? Man, I could really go a pair of those. Of course, looks like I won't be getting any from Microsoft... :)

Re:Blue ski?

[gowen]

He meant Brewski

Re:Blue ski?

[Anonymous Coward]

He is Canadian after all.

Re:C++ expert

[Anonymous Coward]

Make that hello_world.cpp

non-standard features

[Anonymous Coward]

It's kinda sad to see how hard everyone is being on MSVC++ for it's non-conformance and extra features, when by default the beloved and free g++ does the same thing. g++ doesn't become a strictly ANSI compilant compiler until you start throwing switches (-pedantic for one). There are plenty of non-standard pitfalls to get caught in otherwise...

There are NO standard compliant c++ compilers

[pommiekiwifruit]

no compiler on any platform will compile all of the boost and loki libraries, not even gcc on linux.

But many compiler vendors are seeking to increase their compliance. Hey, it's not a toy language :-)

Re:There are NO standard compliant c++ compilers

[Progoth]

no compiler on any platform will compile all of the boost and loki libraries, not even gcc on linux.

ok, what is this Loki? I read "Loki" in the interview, and instantly was extremely confused. and it looks like it has 2 mentions on /., but no explanation.

am I missing something obvious?

Re:There are NO standard compliant c++ compilers

[Harri]

It's the library that comes with this book

http://cseng.aw.com/book/0,3828,0201704315,00.ht ml

It uses enough of the corners of the language that most compilers have problems compiling it.

The book itself is very very good: all experienced C++ developers ought to read it.

this reminds me of

[teslatug]

Developers Developers Developers

hi, i have a C++ question

[Anonymous Coward]

What's the best way to implement the "finally" clause for exceptions? Having to "free the new thing" twice is completely anathema to good coding practice. try { // make something new } catch (Exception e) { // free the new thing // exit routine } // free the new thing

Re:hi, i have a C++ question

[Anonymous Coward]

How about allocating the object on the stack or statically?

try
{
C c;
if(something)
throw X();
}
catch (X& x)
{
//nothing to delete
}

If you need a dynamic array, use a vector or any other suitable container allocated on the stack.
So many bugs, unncessary complications and inefficiencies would be eliminated if programmers realized that C++, unlike Java, doesn't force you to allocate objects on the heap.

Re:hi, i have a C++ question

[asincero]

Just having a nakid dumb pointer point to memory allocated off the free store is generally frowned upon these days. You should wrap up the dumb pointer inside a smart pointer. The standard comes with one, std::auto_ptr. However, that one doesn't work with dynamically allocated arrays (but then again, why the hell are you using an array instead of a container?). It also has some less-than-obvious semantics involving what happens when you do a copy of the smart pointer and when you do assignment of said smart pointer.

Some example code:

try {
std::auto_ptr o(new MyClass());
o->doSomethingNeat();
}
catch(...) {
// handle exceptions
}

Here, the memory allocated is automatically free'd when the scope in which the smart pointer is declared goes out-of-scope. The reason for this is pretty simple: std::auto_ptr is a stack allocated object. Destructors for stack allocated objects are guaranteed (more or less) to be called. The destructor for std::auto_ptr does the delete on the wrapped dumb pointer.

You can probably see how you can extend this mechanism to implement more advanced forms of garbage collection. In fact, the Boost library has a set of smart pointer classes which does exactly that (using reference counting).

- Arcadio

Re:hi, i have a C++ question

[elflord]

Wrap your dynamic pointers in handle classes, like reference counted, or clone() based smart pointers. If you need to do a lot of cleanup in catch blocks, it's often a sign that your code is not granular enough.

Re:Question 1

[Anonymous Coward]

Yes, professional whiner.

Just quit complaining and make your own job...

[Anonymous Coward]

oh wait that would entail taking risk on your part. No one forced you to take a job programming in java. Simply quit.

VC++ improved!

[GdoL]

I think now you will begin to see a better VC++, on the limit they will open it and converge to ANSI and ISO standards.

'embrace and extend' explained

[Anonymous Coward]

Cut the anti-MS FUD flak about MS doing something evil in extending an adopted programming language specifications.

So, in your world, MS must get the entire standards comittee to agree that a MS proposed language extension is good before implementing it.

I'm glad you want to slow down the evolution of programming langauages.
I don't seem to remember Sun getting Java fully adopted and approved by a standards board before releasing the first version.

Get over it, people will extend and adapt current specifications as they want to.

I will never understand...

[Dixie_Flatline]

...What the deal is with C++. It's a terrible language with NO pre-thought design (Stroustroup has said in interviews that he doesn't think it's necessary to design a language before writing it) that is so badly broken that nobody has EVER made a fully compliant compiler (or, indeed, is even CAPABLE of making a fully complaint compiler). Herb Sutter says that you should go out and learn lots of languages if you want to be a better (C++) programmer, but the only thing that other languages taught me was how BAD C++ really is. I'm desperately hoping for C# to take over. Everything I've seen makes it a fair step up on C++. Java is a fine language, if you use it properly, and Squeak (http://www.squeak.org) Smalltalk is fun, simple programming. Objective-C is great for people that want to program in an object oriented, C based language, and there are legions of other languages that get barely used, even though they're super good.

I program in C++, but I don't think I'll ever like it. The language is too big, too complicated, and gives bad programmers too many ways to blow their feet clean off. I believe in the original C language philosophy. Small, simple, fast, powerful.

Re:I will never understand...

[Anonymous Coward]

C is like a nice samurai sword, simple, fast, elegant and deadly, C# comes in as a rude woodden club. In the hand of an experienced programmer, C++ comes like the light sword in the hand of a jedi-warrior. The difference is sometimes only seen when facing serious enemies.

Re:I will never understand...

[descubes]

...What the deal is with C++. It's a terrible language with NO pre-thought design

Then do something about it! This 55000 lines project has received exactly two (2) outside contributions (to the makefiles :-) in its two years of existence as an open source project. And yet everybody keeps complaining how C++ is bad! I'm keeping it in the >90% percentile at SourceForge, but all by myself. Where is the community when you need it?

Re:I will never understand...

[21mhz]

Exactly. The reason why C++ sucks so badly is precisely because it is "a flexible programming language that can handle everything from high-level abstraction to bit-twiddling, all unified within the same language".

Preaching on in the software-development-is-an-evolution style: life itself teaches us that the systems that stand the test of time are usually composed of clearly separated simple components or layers, each fit for its own set of tasks. An overly complex intermingled system has lesser chances to change in order to match new challenges, where a layered/componentized system simply tosses aside parts that became unusable and picks up new, better ones. Or uses both kinds if there's still a need.

Fortunately, we have good tools that do each his own thing well and delimit responsibilities nicely. Whenever you need low-level twiddling, write functions in C, hooked up to your high-level application platform. Whenever you want to avoid writing boilerplate code, use an automated generator, e.g. an IDL compiler or a wizard from your favourite IDE, then fill in the blanks -- or edit it down to tiniest bits, if you so desire. C++ borgs all this into an incomprehensible heap of techniques that conceal stuff from the programmer's eye, and no compiler vendor has ever implemented these in clean and uniform manner. If you want
clear implementation independance, portability or compactness, you have to restrict the used feature set and jump through hoops nearly as much as you have to do with C. Java is much much better at this, because it doesn't go into stuff where C reigns.

And no, don't tell me about how templates are good. I'd better learn how to reuse code with reasonable type abstraction and thus improve locality than let identical template instantiations infest my libraries.

Re:I will never understand...

[Anonymous Brave Guy]

Preaching on in the software-development-is-an-evolution style: life itself teaches us that the systems that stand the test of time are usually composed of clearly separated simple components or layers, each fit for its own set of tasks.

So, are you claiming that it's not possible to write good, modular code in C++, or that C++ has not stood the test of time? If the former, then how come it's the language of choice for so much large-scale development? If the latter, well, get back to me if Java survives another twenty years without a major library overhaul, or C# survives twenty years at all.

And no, don't tell me about how templates are good. I'd better learn how to reuse code with reasonable type abstraction and thus improve locality than let identical template instantiations infest my libraries.

Your prejudice and/or ignorance are showing. The very point of templates is that they allow you to separate concerns. This is true from the simple generic containers and algorithms found in the C++ library through to the state-of-the-art research into expression templates, policy classes, etc.

Re:I will never understand...

[UnknownSoldier]

> What the deal is with C++.

Sounds like you haven't read:
- "Desin and Evolution of C++" by Stroustrup and/or
- "Multi-Paradigm Design for C++" by James Coplien.

C++ is WAY better then C

1 - It's a better C (better type checking, cleans up that cruft with typedef struct {}, etc)
2 - Supports OOP synatix natively (Yes, you *can* do OOP in C, but it's tedious)
3 - Supports generic programming (templates)

> but the only thing that other languages taught me was how BAD C++ really is.

True enough. Also, interesting, is that when I learnt C++, it showed me how bad C is.

I agree learning multiple languages is always "A Good Thing" -- you get exposed to new idioms and design patterns.

> I believe in the original C language philosophy. Small, simple, fast, powerful.

So why not use just the C subset of C++? You'd gain all advantage and no disadvantages.

Cheers

Re:I will never understand...

[Dixie_Flatline]

I do, in fact, do what you suggest, and use the C subset of C++. :)

I'd rather be using Objective-C, though. It always stuns me that an excellent language like Obj-C (or even Smalltalk, for that matter) never really got popular, and an extremely complicated language with a few benefits over C got super popular.

Re:I will never understand...

[elflord]

I'd rather be using Objective-C, though. It always stuns me that an excellent language like Obj-C (or even Smalltalk, for that matter) never really got popular, and an extremely complicated language with a few benefits over C got super popula

May I suggest you do some research into how and why C++ became popular ? C++ has an enormous number of benefits over C. To suggest otherwise is laughably ignorant. Thinks like built in support for OOP, parametrised types, and even a useful, well designed set of container classes are in themselves an enormous benefit.

As for Obj C and Smalltalk, you disingeneously claim they are "better than" C++. They are not. They embrace different design tradeoffs to C++. Smalltalk and Obj C offer little or nothing in the way of static checking, which can be problematic when developing and debugging large applications.

Re:I will never understand...

[21mhz]

So, are you claiming that it's not possible to write good, modular code in C++, or that C++ has not stood the test of time? If the former, then how come it's the language of choice for so much large-scale development?

It's definitely not the language of choice among open-source developers, especially when shared libraries are concerned (e.g. GNOME is a large-scale project composed of small cozy things that, surprise, work with each other). For an example of the reverse, consider Sablotron vs. libxslt.
The former is built using all C++ whiz-bang features one can get and weighs a ton, and the latter is in plain old C using GObject for OO features. After a continuous PITA with Sablotron, the PHP team decides to ditch it in favor of libxslt. Moral: never let students, who are itching to apply the recent killer techniques to everything they can reach, to design real stuff.

Your prejudice and/or ignorance are showing. The very point of templates is that they allow you to separate concerns. This is true from the simple generic containers and algorithms found in the C++ library through to the state-of-the-art research into expression templates, policy classes, etc.

Fine, but why all this have to be jammed in one language with pointers and dumb C-style compilation? This generic stuff involves a lot of declarations that need to be instantiated somewhere. For simple inlined things like, say, the iterator-based copy algorithm it is probably OK (except, I can write a for loop myself, damit!). With all of the declarative power, the implementation matters are specified too vaguely for a grown-up C compiler. I guess this is the reason why Gabber (a neat Jabber client built over GTK--, using a lot of std template stuff) compiles a file per minute and the executable is 3.5 times larger than galeon-bin.

Face it, C++ is a big ugly trade-off. And it works like any trade-off does: well for things that it was established for (huge monolithic apps with time-constrained development cycles), but sucks for anything that does not fit in the frame.

Proof he's a nut

[Sabalon]

From his document about things to be added to the C++ standard - talking about Random Number Generators:

RNGs are used all the time for all sorts of things, from unimportant things like generating die rolls in a board game, to important modeling applications like generating random input for stock market simulations, to vital and crucial and easy-to-get-wrong security applications like creating unguessable input for cryptographically secure secret key generation.

So...the die rolls are unimportant eh? Yeah...this guy has lost it. :)-

C99

[The Bungi]

It's interesting (and I guess troubling?) that Herb didn't talk about C99 ( everyone ready for C99?) in the context of VC++'s future.

Microsoft definitely needs to boldly go where C++0x goes, which will be in part derived from C99. C99 is cool. Can you say "complex"? Yeah =)

I just hope VC++'s next compiler is the last one that is not compliant... it's too freaking painful sometimes.

Wrong

[Anonymous Coward]

Bzzzzt. Bullshit. Comeau compiles all of Boost and all of Loki. Comeau is fully ISO compliant except for "export", and "export" is on its way quite soon.

C++ compliance: still a dream

[descubes]

It's great to see that Microsoft considers people like Herb to improve the quality of their C++ implementation.

It's sad that after more than 10 years, C++ compilers all over the place still have a lot of trouble compiling C++ code. It's already bad enough that C++ is too difficult for most programmers. It's definitely a severe problem for C++ that most compilers can't deal with advanced C++, and fail compiling things like Loki. And yes, I'm talking about G++ too :-)

What draws people to Java is not only the simplicity of the language for programmers. It's also the fact that most compilers have no trouble compiling your code on all platform. I think that's a point that most C++ folks (including Herb in the article) fail to understand. But to get this, you give up many handy features, notably templates.

I personally believe that there is another way, and that new programming languages are still a good idea.

Re:C++ compliance: still a dream

[SerpentMage]

I have to agree with you entirely. I am a C++ programmer by heart. But lately I have been doing quite a bit of Java again. Wow, does it work cross-platform. I am using a Windows Intel Notebook and a Linux PowerBook from Apple. Only with Java can I move sources and binaries from one machine to another without any problems.

In C++ the Open Source community seems to have stuck its head up its butt in complexity. Take for example building a Open Source application. First we run autoconf, then ./configure and then finally we build. Of course lets not forget to include libtool and the likes. PEOPLE what are doing, making work for themselves?

I have dropped the entire notion of using make files and other things. I ended up using ANT to build C++ programs. What a cool tool. Here is something that was re-engineered and it ends up as being a better project management of sources, executables, etc. And what is ANT written in? Java!

C++ needs to get back to the drawing board and start things over and make things simpler! Java have and so has .NET...

Sad to (Really Sad) to say it, but if C++ does not simplify it will run out of steam.

Re:C++ compliance: still a dream

[elflord]

It's sad that after more than 10 years, C++ compilers all over the place still have a lot of trouble compiling C++ code.

ANSI/ISO is still only 3 years old. Features to support code like Loki (templates, partial specialisations, MI) were not a part of the original AT&T implementation. So a big part of the problem is that it's been a moving target. But then, this is true of most useful languages in their early stages. C for example was standardised in 1989, 18 years after Bell implemented it.

What draws people to Java is not only the simplicity of the language for programmers.

The simplicity is a tradeoff. Java trades compile time optimisations, performance and static type safety for simplicity. This is not "better", or "worse", it's just "different".

Note that Java, like C++, is still very much a moving target.

It's also the fact that most compilers have no trouble compiling your code on all platform.

Java has its share of version compatibility issues, caused by the fact that it's a moving target. It's also worth noting that a lot ot the "different compilers" license code from Sun. Look how long it's taking for a (working!) free implementation of java on Linux to appear.

I think that's a point that most C++ folks (including Herb in the article) fail to understand.

On the contrary, Herb is insightful to understand that other languages also have their advantages. He's a strong advocate of learning other programming languages.

I personally believe that there is another way [sf.net], and that new programming languages [sf.net] are still a good idea.

Matz (the Ruby guy) said in response to "why another language", that if someone found Ruby useful, that was a good enough reason for him. I think this is a good philosophy.

Read the book

[pommiekiwifruit]

because some job interview questions I sat recently were taken directly from the book/site :-)

Argh, the difference between implicit and explicit copy construction and direct construction :-/

That must be very recent then

[pommiekiwifruit]

Since the compiler status page on www.boost.org dated 7 Feb 2002, testing Comeau C++ 4.2.45 beta 2 with libcomo beta 14 claims that it fails several tests. Not having the compiler myself I do not know whether or not this is significant. I know my day-to-day compiler fares much much worse.

However, Greg Comeau thinks that the forthcoming version 4.3.0 plus dinkumware libs will be compliant, which is a very good thing. Well, it is the oldest extant c++ compiler after all (15 years old?). I've only been writing C++ commercially for 12 years, so it predates my knowledge.

I thought this said...

[Anonymous Coward]

At first glance I thought the title read Irish Stew With Herb Butter...

Oh well, I guess I have to stop reading /. at lunch time ;)

Is there a need for such a "flexible" language?

[BobTheWonderMonkey]

The need for a flexible programming language that can handle everything from high-level abstraction to bit-twiddling, all unified within the same language, isn't going away anytime soon.

C'mon, there is absolutely no need for a language like that! You should use the right tool for the job, and lemme tell you, C++ is not necessarily the right tool. To whit, applications that should not be written in C++:

• high-performance embedded applications
• text processing applications
• Hello, World!

Seriously, though, an programmer who has only one tool in their toolbox is a waste of space. I swear, the world must look like it's made of nothing but nails to this guy, 'cuz all he has in his toolbox is a big freakin' hammer...

Re:Is there a need for such a "flexible" language?

[jdennett]

FUD. C++ for embedded work is perfectly sensible, if the tools aren't crud. C++ is known as the second best language for any given job -- but in actual fact that often makes it the best when you've taken the non-technical factors into account.

And yes, I have used a wide range of languages professionally. I know about choosing the right tool for the job. It's just that C++ is usually eliminated, when it is, because people believe myths, not because of valid reasons (which do sometimes exist).

The HTML + JavaScript thing

[Anonymous Brave Guy]

Well, that proves the point, doesn't it -- HTML + JavaScript is apparently a "language" that people find better suited to define standard, cross-platform GUIs in than C++!

HTML + JavaScript is a better cross-platform interface than just about any other currently in existence. That's why it's so popular as a combination.

OTOH, I'd love to see you write a full-blown word processor or a 3D FPS game in HTML and JavaScript.

Re:The HTML + JavaScript thing

[evbergen]

> OTOH, I'd love to see you write a full-blown word processor or a 3D FPS game in HTML and JavaScript.

Exactly. That's why we need something that's much more lightweight, and that's why I said technologies such as XML-RPC are not going to solve the API-as-a-protocol problem.

Something that's a well-balanced rebirth of the X windows protocol, DPS or Apple's Display PDF and HTML + JavaScript combined, that is expressive enough to define much of a GUI in, and at the same time lightweight enough to allow things like games to work.

Oh well, you've got to have dreams, don't you.

That's because you don't want to hear...

[Anonymous Brave Guy]

It's a terrible language with NO pre-thought design...

Interesting, then, that its history is so well-documented, and Stroustrup himself has written a whole book on how the language was designed, the rationale behind each feature that was, or was not, provided, and other historical reasoning behind decisions that were made. Where's the Java or C# equivalent?

...that is so badly broken that nobody has EVER made a fully compliant compiler (or, indeed, is even CAPABLE of making a fully complaint compiler...

Well, except for the currently-under-test Comeau compiler, which provides just about everything there is, and the internal code at MS, which is rumoured to support pretty much everything except export, anyway.

I'm desperately hoping for C# to take over. Everything I've seen makes it a fair step up on C++.

Y'know what? I really hope you're wrong. But unlike you, I'm going to justify my position.

Firstly, I work at a software development house, and on a MLOC C++ project. Our clients just hired a new whizzkid just like you. They provided all the latest tools, and he's come up with this really cool interface using C# and .NET. The only slight problem is that, unlike many other languages, he can't figure out how to use the 500,000 lines of rigorously tested mathematics we've accumulated over the past decade, so his code is utterly useless. Had he written in any number of other languages that were designed to communicate freely rather than locking you into a pet framework with much hype but little real support, he wouldn't just have cost them thousands of pounds for a cute but useless prototype. So, that's one thing where C# has a long way to go to catch C++.

There are many more. The obvious and boring example is templates and the standard library. Then there are all the portability issues, but I suppose they don't count because .NET and the CLR are portable and support many platforms, languages, days of the week, etc. There's the teensy-weensy little issue of performance, which is pretty much untested in C# and .NET as yet. Don't you think the Java developers might have learned a trick or two in the past few years? There's the insistence on everything being an object, single inheritance and a common root, all of which are as flawed as they have ever been. And in return we have what? A garbage collector? They could at least have learned from Java's mistakes and provided a decent mechanism for managing other resources -- which C++ has had for years -- but they seem to have forgotten that people also need to close files, release locks, share databases and such. I could go on, but what's the point? You're obviously massively prejudiced and unwilling to make the effort to get anything worthwhile out of C++, so why bother?

Oh, and bad programmers can blow their feet off in every language I've ever written. Still, at least in C++, good programmers can be great.

Re:That's because you don't want to hear...

[Anonymous Coward]

The only slight problem is that, unlike many other languages, he can't figure out how to use the 500,000 lines of rigorously tested mathematics we've accumulated over the past decade, so his code is utterly useless.

I'm assuming these 500K lines of code are compiled into libraries. He couldn't figure out how to marshall a call from C# to a dll? Doesn't sound like a .NET whizkid to me -- or even much of a Windows developer.

Re:That's because you don't want to hear...

[Dixie_Flatline]

I'm really interested in reading that book. I've found it, and when I get the time, I'll buy it and read it. However, I have read that he doesn't think that you have to design a language before you sit down and write it. This seems to fit the current state of C++, since bad design decisions are being squirrelled out and ironed over later.

When I say nobody has ever made a fully compliant compiler, I mean that. The standard is huge, and at last estimation, it appeared that there must be an error in the grammar. I'd provide a link to the comment and the author who was a compiler programmer, but /. doesn't archive anything under 4 letters, making it hard to search for C++ comments. :P

I've programmed in C, Java, Objective-C and Smalltalk (among other things, but those are the ones that are relevant) and each of them has something that offers itself as a better solution than C++. Above all, each of them has a clearer and less convoluted syntax. Java, Smalltalk, and Objective-C all offer (in my opinion, in any case) a superior object model to C++.

I write C++ code every day. I write it, and I don't like it. I admit, I'm not a master at the language, but the amount of work it would take to do so seems somewhat ludicrous. By comparison, it's easy to master C, Smalltalk and Obj-C because of the tight design and relative smallness of the languages in comparison to C++.

I agree that bad programmers will always find a way to do damage, but C++ gives far more ammunition than most languages. Every syntactic structure is another noose to hang yourself with.

The fact of the matter is that you don't need a language like C++ to to big projects, write complicated systems, or have a flexible system. I'd argue that Objective-C and it's runtime system are far more flexible, easier to program, and have done a good job at implementing a complex system (ie. OSX). Check through the /. archives on topics like OSX and Objective-C. Many more eloquent people than me can tell you what's right with Obj-C and what's wrong with C++. Even better, go and pick up a book on Objective-C, and see for yourself.

I won't lie to you, and deny that I'm biased against C++. But I'm biased against it for the same reason I don't like Windows. It's too big, it's too complicated, and there are better alternatives. But this is all just my opinion. Take it or leave it.

I'll leave you with this quote that has always appealed to me:

"If you think C++ is not overly complicated, just what is a protected abstract virtual base pure virtual private destructor and when was the last time you needed one?" --Tom Cargin (C++ Journal, Fall 1990)

Re:That's because you don't want to hear...

[elflord]

Above all, each of them has a clearer and less convoluted syntax. Java, Smalltalk, and Objective-C all offer (in my opinion, in any case) a superior object model to C++.

The "cleanliness" and "superior object model" is a design tradeoff, it is not superior design. For example, you can be more consistent by not having the notion of "values" versus "references" versus "pointers" that you have in C++. But having these things offers compatibility with C, better performance, and a language that offers more in the way of static checking. This "elegance" you speak of does have some real world benefits, but the tight static checking and high performance offered by C++ also have real world benefits, and MLOC multi platform applications exist as proof of concept.

I admit, I'm not a master at the language, but the amount of work it would take to do so seems somewhat ludicrous.

Perhaps you should do some reading (-;

By comparison, it's easy to master C,

Depends on what you mean by "master". If "master" requires that you are capable of writing object oriented code, then it's really not that easy to "master" C. It's actually harder, because using encapsulation, modules, polymorphism and objects takes some discipline and skill. Any idiot can write fortran in C, but that's not "mastering" it.

Smalltalk and Obj-C because of the tight design and relative smallness of the languages in comparison to C++.

The apparent simplicity of these languages is a design tradeoff. There are a lot of good reasons why C++ did not choose the saqme tradeoffs, and they are all documented in Design and Evolution.

I agree that bad programmers will always find a way to do damage, but C++ gives far more ammunition than most languages. Every syntactic structure is another noose to hang yourself with.

Any useful tool can be abused.

The fact of the matter is that you don't need a language like C++ to to big projects, write complicated systems, or have a flexible system.

The fact of the matter is that C++ works very well for precisely this.

I'd argue that Objective-C and it's runtime system are far more flexible, easier to program, and have done a good job at implementing a complex system (ie. OSX).

Being "flexible" and "easy to program" is not necessarily a good thing for implementing large scale software. I'm not sure which parts of OSX are written in ObjC, but that sort of object model certainly works well in GUI components.

Many more eloquent people than me can tell you what's right with Obj-C and what's wrong with C++.

So what ? Many eloquent people can explain what's right with fascism and what's wrong with democracy. That doesn't make it true.

If you think C++ is not overly complicated, just what is a protected abstract virtual base pure virtual private destructor and when was the last time you needed one

So where does he say that we should stop using C++ and start using objective C instead ?

BTW, I know what it is, and I've never needed it.

Re:That's because you don't want to hear...

[cookd]

VC7.1 is not perfectly compliant, as you seem to assume. However, it is a lot better than any of the previous versions, and it is basically as compliant as I will ever need it to be.

Which leaves three questions: Why did it take so long? What is now there? What is still missing? Why is it still missing?

Short version of the answers:

Priorities, moving-target standards, and a need to avoid breaking legacy code too quickly.

Partial specialization works (YAY!), STL is now completely implemented (YAY!), and VC now passes about 98% (IIRC) of some standard suite whose name I don't know.

"throws" specifications for functions are still pretty much ignored. Some other stuff that means nothing to me isn't there (which is why I can't name the specific features that aren't there -- they didn't mean anything to me).

Why are they still not compliant? Because a lot of people are like me (ignorant?) and would prefer that MS spends more time on other stuff besides esoteric standards compliance features that I will NEVER use.

Longer (rambling?) answer: I wrote one, but decided it was stupid. So just take the short answer.

And yes, there were four questions, not three. So I was never that good at math; sue me!

All opinions and statements given in this post are those of ME and in no way reflect the opinions of my employer or my mom's dog. The "facts" might even be wrong. So take this all with the appropriate quantity of sodium chloride.Thanks.

Re:That's because you don't want to hear...

[Anonymous Brave Guy]

VC7.1 is not perfectly compliant, as you seem to assume. However, it is a lot better than any of the previous versions, and it is basically as compliant as I will ever need it to be.

I make no such assumption. However, as a number of people have pointed out in this very thread, the internal MS build is looking a lot better than previously. And the Comeau compiler is very near perfect compliance. That's its big selling point, and they put there money where their mouth is to an extent, by making a trial version available on-line.

As for the compliance on esoteric features, I take your (and MS') point entirely; if they want my money, their job is to provide a tool that's useful to me in writing my code. Fortunately, as Herb Sutter himself pointed out in the various interviews he did when joining MS, they are well aware of this, and their priorities will reflect it.

Re:That's because you don't want to hear...

[Anonymous Brave Guy]

I'm really interested in reading that book. I've found it, and when I get the time, I'll buy it and read it. However, I have read that he doesn't think that you have to design a language before you sit down and write it. This seems to fit the current state of C++, since bad design decisions are being squirrelled out and ironed over later.

Please do read D&E. You seem to be trying to keep an open mind in the face of bad experience, for which I commend you. I think reading the book would explain a lot of the reasoning you aren't aware of, and perhaps change your perception of C++ a bit.

As for the things to be ironed out, yes, there are certainly problems with the first standard. However, there are remarkably few serious ones; by far the most work on the new standard is going into the new library extensions, to fix glaring omissions like multitasking support, regular expressions, etc. And in fairness, many of the other language specifications (Java, C#, etc) would suffer the same problems when faced with criticism as rigorous as the C++ standard has received. Some of the loopholes (e.g., the DDD problem) they've written out of the languages by dropping features (e.g. MI), which is fair enough. Others, though, they just plain gloss over. Sadly, hiding a problem does not necessarily make it go away.

When I say nobody has ever made a fully compliant compiler, I mean that. The standard is huge, and at last estimation, it appeared that there must be an error in the grammar.

There are a number of such problems; the reference-to-a-reference issue is a common example. OTOH, at least they're being fixed. And again, don't forget that all the other languages have similar flaws, or just gloss over issues completely. How is Java's support for floating point maths these days, anyway? ;-)

I've programmed in C, Java, Objective-C and Smalltalk (among other things, but those are the ones that are relevant) and each of them has something that offers itself as a better solution than C++.

That may be the case. However, does any of them provide the combination of features as well as C++ does, or even provide it at all? If not, it's not really a fair comparison.

Above all, each of them has a clearer and less convoluted syntax.

That's harsh. The vast majority of problems with C++'s syntax come from C, not C++. The only real exceptions are references (designed to match C's pointers) and templates (designed to work with the preprocessors available when they were first implemented). I'm sure that, if writing the language from scratch and without compatibility considerations, Stroustrup would have considered alternatives. In fairness to him, he didn't have that luxury, and it's easy to criticise theoretically imperfect decisions made under practicality constraints.

Java, Smalltalk, and Objective-C all offer (in my opinion, in any case) a superior object model to C++.

We'll just have to agree to disagree on that one, then. Personally, I don't buy the hype about single-inheritance single-root hierarchies. They get used because they're simple, not because they're powerful. If that floats your boat, no problem, but let's be clear about what we're saying.

The fact of the matter is that you don't need a language like C++ to to big projects, write complicated systems, or have a flexible system.

Of course not. Then again, you don't really need high level languages at all, since you could just do it all in assembler. Any high-level language is designed to make things easier, and some languages make some things easier than others. The point, surely, is the trade-offs that are made in doing so. OO, for example, makes some things much simpler than they might be. On the other hand, it has well-documented but rarely-acknowledged limitations, particularly as implemented by many popular languages today. You pays your money (or downloads :-)) and takes your choice...

"If you think C++ is not overly complicated, just what is a protected abstract virtual base pure virtual private destructor and when was the last time you needed one?" --Tom Cargin (C++ Journal, Fall 1990)

(It's Cargill, by the way.) I think that's unfair in the context of today's C++, as is much of what Cargill wrote back then when faced with the test of time (c.f. the difficulty of writing exception-safe code when faced with techniques developed over the past few years). In particular, while I know what one of those is (actually, it's a mistake, since C++ does not define the term "abstract" in that context; it's an OO term, not a C++ one) and have never used one in practice, I have used each of abstract classes, virtual base classes, pure virtual destructors, private destructors and even protected inheritance quite legitimately at some point. I have never chosen to use the combination, but each of the features has value in its own right, and it would be more complicated to exclude probably-meaningless combinations than to just leave them be as orthogonal concepts.

As I said, please read the book. Contrary to what you seem to have concluded, a lot of thought went in to each and every one of these features, and they are the way they are for a reason. That's why C++ is such a powerful language for those who make the effort. It's not, and was never intended to be, a simple language for those who are undemanding, so it's a bit unfair to judge it in that light.

Re:That's because you don't want to hear...

[Dixie_Flatline]

I'll pick it up after I'm finished re-reading 'Object-Oriented Programming' by Timothy Budd. This discussion reminded me that I wanted to brush up on things like polymorphism, and method lookup.

As an aside, and a minor gripe, why does C++ have to go and break away from a perfectly good way of referring to things? Methods, Instance Variables, Class Variables...what was wrong with those? Instead, we have to have 'member functions'. Bleah. :)

That may be the case. However, does any of them provide the combination of features as well as C++ does, or even provide it at all? If not, it's not really a fair comparison.

I personally believe that Obj-C is a reasonable replacement for C++. Not only do you have the common C syntax to fall back on, but I've found the benefits of dynamic binding hard to part with. Among other things, the 'black box' container problem that was classically an issue in C++ (I've heard that this has been fixed) was never a problem in Obj-C (or Java, or Smalltalk...) That's the example that most immediately comes to mind, though I'm sure you can think of others. Keep in mind that I don't think that multiple inheritance is really in any way an advantage, and I feel the simplicity of polymorphism in Obj-C a great benefit.

Of course not. Then again, you don't really need high level languages at all, since you could just do it all in assembler. Any high-level language is designed to make things easier, and some languages make some things easier than others. The point, surely, is the trade- offs that are made in doing so.

The best way I had C++ and Obj-C compared to me once was that C++ is convenience for the computer, and Obj-C is convenience for the programmer. I will not deny that Obj-C has significant overhead in comparison to C++ (the necessity of at least a minimal run-time system is one of the things that I think damaged its acceptance) in most cases, and C++ is a seriously performance oriented language. However, I think that the convolutions that you have to go through to get the performance that you want aren't a reasonable trade off in most instances to ease of programming. Objective-C is, for all intents and purposes, syntactic sugar. With the increases in power of todays computers, I heartily feel that a programming language that goes out of its way to maximize programmer efficiency is a superior one. I'm sure we'll always need a language like C++ around for those that need maximum performance, but languages that let you get things done quickly without a lot of hoop-jumping may be come more important in the near future.

Finally, you're probably the first person that I've ever talked to that knew what that was. I have a friend that taught labs in University in C++, and by all estimations, he's a pretty reasonable programmer. Not only did he not know what that was off the top of his head, he recently told me that one of the reasons he likes C++ is because he can STILL walk into work, and learn something new about the language, even after all these years. Languages are tools. I don't think I should be learning new things about my screwdriver years after I started using it.

I suppose what this amounts to is that I belong in a different language camp. I love OO, and I believe the language should work for the programmer, and not the other way around. You will, of course, argue that C++ DOES work for you, but all my readings inevitably bring me to the conclusion that the programmer is constantly working for (and around) the language.

If you'd like to discuss this further, email me. I'm not big on this format of conversation. :)

Re:That's because you don't want to hear...

[cookd]

Grin. I guessed as much, which is why I said "seem." The tone of the post seemed to indicate that it was perfectly compliant, and I just wanted to clarify the point.

Anyway, it's all good.

bullshit.

[feldkamp]

This is complete nonsense. C++ is NOT a bad language. If you've ever heard Bjarne talk, you would know that he has a powerful mind for design, and his research background gives him the practical experience to build a great language.

C++ is big. C++ is complicated. But these features do not make it a poor language. Rather, it takes a better programmer to effectively use C++.

And you believe in the "C language philosophy"? The C language philosophy was "hey guys, I'm tired of porting assembler from machine to machine, let's generalize it". C is not faster than C++. At all. If you are a horrible C++ programmer, and completely missuse the more advanced features of C++, well, then C might be faster.

And powerful? C is not powerful. Powerful is the STL - being able to use hyper-efficient genralized data structures with very little effort, and having that code be portable to virtually every platform you could dream of. Powerful is built-in exception handling.

I have seen the future; No C++, C#, C@, C$ or C%

[Anonymous Coward]

I love C but hate C++ b'se no one follows the standards. It is so bad one wonders why they even waste time trying.
I studied C++ in college (under heavy protest to the instructors, deans ...whoever could listen, they later saw the light and moved to Java). Naturally they were extremely strict with the coding standards.

I got a job updating C++ code that turned out to be a mesh of C/C++ and any other dialect in between.
Forget about the compiler differences. These were the kind of coders who use Cout/Cin in C!.
To make matters worse I saw similar code snippets in the "Dr.Dobbs" magazine.
Now, I know many of you do this & recognize the benefits. But why bother with standards in the first place?

What I want is a language I can use anywhere to truly create Rapid Applications.
A productive language that enables me to spend more time designing than coding.
One that gives me a lot of control. (i.e. One that does it my way and not the M$, Sun or Borland way.)
In short, I want to talk to the machine and have it do what I want instantly.
A language so natural that 10yr old can understand it.

I realize newer languages like Java/ C# are striving to achieve this but that's a further waste of time.
We waste a lot of resources learning them and their ever-changing standards that no one follows.
Those resources could be well spent developing designs, patterns, e.t.c.

We should develop software with the languages we use daily.
As a person who speaks 5 different languages with at least 2 dialects of each, the last thing I need is another language just to communicate with a dumb machine. (B'se the machine is dumb & doesn't understand me is lame.)

That's what M$ & Herb Sutter should be focusing on.

Give us the means to talk to our IDEs in plain language and have them translate (crunch out the code) everything for the dumb machine.
The developer should not be bothered with that!

How can that be obtained?
Well, use your imagination...:-)

All I can say is that in a few months I will be developing software from a sunny beach with just a cell phone and a stick to draw designs in the sand.
Happy coding.

Apples and oranges (and contribution)

[devphil]

You seem to assume that being a C++ evangelist means that one must be an open source evangelist as well.

His new position seems to be that MS should strive to make their compiler ISO-compliant. Great. Nowhere in the ISO C++ standard -- nowhere in all 768 pages -- does it say that the compiler must also be OSS-friendly.

Would it surprise you to learn that Microsoft employees occasionally contribute code to GCC, in order to help binary compatibility? Granted it's never going to be fully binary compatible, since the Visual C++ vtbl layout is patented, but POD structs can be.

Re:I have seen the future; No C++, C#, C@, C$ or C

[elflord]

I love C but hate C++ b'se no one follows the standards.

This is factually inaccurate in the extreme. Everyone follows the standards. Meaning that they're still playing catch-up. The standard was new in 1998, so if you have much experience, then there wasn't an official C++ standard when you took your first course.

We waste a lot of resources learning them and their ever-changing standards that no one follows. Those resources could be well spent developing designs, patterns, e.t.c.

This is a false either-or dichotomy. Time is spent developing this stuff, but this doesn't mean we shouldn't develop new espresso machines.

Give us the means to talk to our IDEs in plain language and have them translate (crunch out the code) everything for the dumb machine. The developer should not be bothered with that!

The problem is that you need to be able to express your ideas in a coherent, logical format. The machine can't do your thinking for you. Having finished grad school in math, where you don't need to write code, only state your ideas clearly, it's simply not as easy as a superficial glance might make one think. Most people can't do that. If they could, they'd be orders of magnitude more productive, and software wouldn't have any bugs (yeah, right)

Who cares?

[Alex Belits]

C++ standard is stabilized, its proper implementation is nowhere in sight (especially by Microsoft, no matter what they proclaim as their goal -- was February supposed to be the month the whole company had to spend entirely on fixing security bugs?), so it doesn't matter what those people are doing.

Of course absolutely idiotic idea that someone's cumbersome library is a part of the language, gives a lot of fuel to the "progress", but I hope, programmers will learn soon that TEMPLATES EXIST FOR THEM TO USE, NOT TO MAKE STL WORK. That will, of course, happen when enough smart people will start using C++ -- right now C++ is mostly being used by people too dumb to use C, or ones that had misfortune to get some crippling course that teaches C++ without C, thus making otherwise good language a domain of ignorant people.

OS developers?

[Anonymous Brave Guy]

It's definitely not the language of choice among open-source developers...

Sorry, that's not a very convincing argument. Open source developers are (a) a tiny subset of the whole group of developers, (b) motivated as much by fun as by the power or technical soundness of their tools ("Ooooh, shiny new features in a nice-sounding language") and (c) frequently not experienced enough to judge a language on its technical merit anyway. Of course, there are exceptions, but surely you'll admit that most OS developers fall into this group. Given that, it's not surprising that C++ is not the language of choice. It's too hard for most hobbyists to make the effort to get the best out of it. When writing good code that stays good pays your rent, you look at things differently.

Face it, C++ is a big ugly trade-off.

Sure. But it's a big, superficially ugly, powerful trade-off. The underlying models in C++, and the things you can do with them if you need to, are literally years ahead of the Javas and C#s of this world. From that point of view, C++ is a beautiful thing indeed; it all depends on your perspective.

Java tradeoffs

[21mhz]

Java trades compile time optimisations, performance and static type safety for simplicity.

Also for just-in-time dynamic optimizations, memory management safety, "run-anywhere" (well, declared at least) and standardized distribution/deployment form.

Matz (the Ruby guy) said in response to "why another language", that if someone found Ruby useful, that was a good enough reason for him. I think this is a good philosophy.

I, personally, believe that the future belongs to dynamic P-code languages such as Ruby and Python. They have clean "native" interfaces, so if you want full speed, you get to the C API and hack away. Or, if you're willing to trade some more performance for the benefits of Java, use Jython.

Re:Java tradeoffs

[elflord]

Also for just-in-time dynamic optimizations, memory management safety, "run-anywhere" (well, declared at least) and standardized distribution/deployment form.

These are useful to varying degrees. GC is very useful, though it's not a magic bullet, and it comes at a high price.

I, personally, believe that the future belongs to dynamic P-code languages such as Ruby and Python. They have clean "native" interfaces, so if you want full speed, you get to the C API and hack away. Or, if you're willing to trade some more performance for the benefits of Java, use Jython.

That's like sayign that the future belongs to screwdrivers, and everyone is going to stop using hammers. I don't buy it. There's more advantages than just speed to a language like C++. Static type checking is extremely useful for large applications.

Python and Ruby are not competitors of C++, they are collaboraters.

you get to the C API and hack away.

Writing objects in C is one hell of a headache. Given the relative ease with which one can put Ruby and Python bindings on C++, C++ makes a better choice for a "low level" language to work in tandem with python or ruby. For example, it's much easier to write a matrix library in C++ than it is to do the same in C (and no-one in their right mind would write low level matrix ops in Ruby or Python, unless developer time was in very short supply, or there was an abundance of spare CPU cycles)

Re:Java tradeoffs

[Ayende Rahien]

*Shudder*, I still think that I've somewhere a spare matrix I wrote a long time ago as an experiment.
Gawd, talk about an ugly thing.
It had about 5 methods, and 6,00 LOC.

Python/Ruby bindings

[21mhz]

Given the relative ease with which one can put Ruby and Python bindings on C++, C++ makes a better choice for a "low level" language to work in tandem with python or ruby.

Until there is the C++ ABI standard agreed upon and most compilers (actually, g++ alone would be enough) implement it, I won't touch any extension .so's built of C++.

For example, it's much easier to write a matrix library in C++ than it is to do the same in C

Ironically, we've already got NumPy.

Granted, C++ is not going away anytime soon, I myself program in it for a living, but it's not a magic bullet either.