Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

An Interview With C++ Creator Bjarne Stroustrup

CmdrTaco posted more than 3 years ago | from the add-an-extra-plus dept.

Programming 509

DevTool writes "Bjarne Stroustrup talks about the imminent C++0x standard and the forthcoming features it brings, the difficulties of standardizing programming languages in general, the calculated risks that the standards committee can afford to take with new features, and even his own New Year's resolutions."

cancel ×

509 comments

Sorry! There are no comments related to the filter you selected.

First Penis (-1)

Anonymous Coward | more than 3 years ago | (#34838810)

What what, up the butt?

Trivial Count: 2 (0)

Anonymous Coward | more than 3 years ago | (#34838826)

Only two usages of "trivial" in that article? Needs to be fluffed up a bit.

Re:Trivial Count: 2 (2)

MrEricSir (398214) | more than 3 years ago | (#34838990)

We could add more, it would be a trivial change.

C++0when? (3, Informative)

fishexe (168879) | more than 3 years ago | (#34838840)

Of course by this point it really should be called the imminent C++1x standard.

Re:C++0when? (3, Funny)

Anonymous Coward | more than 3 years ago | (#34838874)

No, it's going to be called C++0xc or 0xd.

Re:C++0when? (-1)

Anonymous Coward | more than 3 years ago | (#34838898)

If you rotate & rearrange the letters you get 0 xkcd.

Re:C++0when? (1)

fishexe (168879) | more than 3 years ago | (#34838942)

Where do you get the k?

Re:C++0when? (1)

Anonymous Coward | more than 3 years ago | (#34839026)

two '+' and a pair of scissors...

Re:C++0when? (0)

Anonymous Coward | more than 3 years ago | (#34839052)

He took it from your response.

Re:C++0when? (1)

Cryacin (657549) | more than 3 years ago | (#34839058)

Buffer overrun

Re:C++0when? (1)

Imagix (695350) | more than 3 years ago | (#34839010)

Not if you use a hex digit.... C++0B ....

Re:C++0when? (1)

vondo (303621) | more than 3 years ago | (#34839040)

As Bjarne himself says, "The x is hexadecimal"

Re:C++0when? (1)

bradgoodman (964302) | more than 3 years ago | (#34839152)

Hey...At least it'll be finalized before Duke Nukem Forever... [knock on wood]

c++ 1x sucks (-1)

Anonymous Coward | more than 3 years ago | (#34838850)

honestly, they should have fixed the stl (dropping vector bool packing, adding hashed tables) and fixed the template >> ambiguity and called it a day. Oh, and the new auto keyword. Every time I read of some new feature or proposal, I throw up a little. It's like they're trying to destroy the language.

Re:c++ 1x sucks (2)

wiredlogic (135348) | more than 3 years ago | (#34838902)

They should have added nullptr 20 years ago. It's always amusing to read about C++'s design for type safety when we've been forced to sling around magic '0' literals all this time because someone got their panties in a bunch over automatic casting of void*.

yeah, void* was destroyed (3, Insightful)

r00t (33219) | more than 3 years ago | (#34839216)

Early C++ introduced void* and it was good. C adopted it.

Then C++ took away the automatic casting, I guess about the time C++ was first standardized. OK, now what is the point? The value of void* is gone. Now we write code with nasty casts. We can even hide the nasty casts in macros. Oh joy.

C remains fairly sane. There haven't been any serious fuckups since the trigraph disaster which no compiler enables by default. C99 is damn nice in fact.

Re:c++ 1x sucks (1)

DMiax (915735) | more than 3 years ago | (#34839288)

It's a long time before anyone starts to use nullptr. NULL is still shorter to type and too entrenched in the documentation. What I do not understand is why tey kept NULL there.

Is there any reason not to break backward compatibility? If there is any of that in some legacy code you can split your codebase in two and compile with different versions. Other languages break legacy code at every version and still manage to stay around. I think this is because every code big enough that you cannot rewrite is probably modular. I am usually against patching instead of fixing, especially on something that should be used by everyone. Of course I never designed a language, so maybe I am wrong...

Re:c++ 1x sucks (1)

jythie (914043) | more than 3 years ago | (#34838920)

Sadly, designers do not have much interest in 'fixing' things when they can design new stuff AND increase the number of places their design can be used. That is the problem with C++... the people steering it want a language to solve all problems, and increasingly it becomes worse at solving any,.. or at minimal the increasing number of solutions to any given problem embedded in C++ makes understanding it more and more difficult.

Re:c++ 1x sucks (-1)

Anonymous Coward | more than 3 years ago | (#34839066)

Every time I read of some new feature or proposal, I throw up a little. It's like they're trying to destroy the language.

Does anyone actually use any of the features of C++?

My experience with C++ developers in the late 90's was that 99% of them knew only a tiny, tiny percentage of the language. The majority of C++ developers in my experience just cut-n-paste code around without really having any clue what it was really doing or how any of it really worked. And, it seemed intuitively obvious to me at the time that the more that's added to the language, the less likely that anyone will really understand what they're doing.

But looking back on it, I'm not sure if that was because C++ was so insanely compex. Maybe a lot of programmers are just cut-n-paste programmers. Maybe it doesn't matter for a ot of programmers if they're using a language that takes a couple of hours to learn really, really well (like Scratch), or a couple of months (like Java), or a couple of years (like C++) -- they're just not going to bother to learn.

I suppose now there are so many more languages to choose from, most of those sub-standard developers aren't stuck using C++ anymore. Maybe they all use PHP or Visual Basic now. But I suspect that you'll still find a lot of crufty old maintenance programmers that have no idea how much of the code they're maintaining works, and I suspect that the complexity of C++ is a big part of that difficulty.

Re:c++ 1x sucks (1)

FuckingNickName (1362625) | more than 3 years ago | (#34839286)

My experience with C++ developers in the late 90's was that 99% of them knew only a tiny, tiny percentage of the language.

My experience is that 99% of people muddle through life with a combination of hubris and clandestine effort.

A similar proportion express that their knowledge and talent is well above average and insist that almost every challenge is trivial.

This group is overrepresented on Slashdot.

Re:c++ 1x sucks (1)

David Greene (463) | more than 3 years ago | (#34839512)

Does anyone actually use any of the features of C++?

Yes. So far I've used:

  • Right angle brackets
  • shared_ptr
  • unique_ptr
  • binders
  • Variadic templates
  • auto

And that's just in my own code, not counting features that libraries use (rvalue references, for example). I'd use a lot more if they were implemented in g++.

The next C++ standard is going to be a huge improvement in usability, especially for writing generic code.

Multi-processor Extensions (0)

Script Cat (832717) | more than 3 years ago | (#34838860)

I want some efficient use of multiprocessor systems. When can expect to see this implemented in G++ or similar?

Re:Multi-processor Extensions (1)

arth1 (260657) | more than 3 years ago | (#34838944)

What's stopping you?
Or do you want abstractions built-in to the language, and not the implementation?

Re:Multi-processor Extensions (1)

jythie (914043) | more than 3 years ago | (#34839038)

Some people do not seem satisfied unless it is built into the language via special syntax.... even though existing libraries do the job just fine.
Then again I have noticed a lot of people (and schools) seem to be allergic to threading.

Re:Multi-processor Extensions (1)

Short Circuit (52384) | more than 3 years ago | (#34839132)

I want some efficient use of multiprocessor systems.

For which processor classes, and which problem domains? The more flexibility you want, the more you'll sacrifice in efficiency/engineer-time or efficiency/computer-time.

Re:Multi-processor Extensions (3, Informative)

lgw (121541) | more than 3 years ago | (#34839456)

The std::thread and std::async libraries should give you all the tools you need in a plaform-independent way. The popular compiler vendors seem to be eager for C++0x - once the standard is official, Visual Studio will do a patch, and I'm sure G++ will beat them to release. Many of the C++0x features are already there with the -std=gnu++0x option to G++, though I'm not sure if that includes the threading stuff.

I Guess... (1)

GreenSeven (1970506) | more than 3 years ago | (#34838884)

I never realized that the standard for C++ hadn't been updated in 13 years... Seems like a long time for a language that popular. Then again, if the standard doesn't change, old code should be supported for a longer period of time. Any thoughts on if this is a benefit?

Re:I Guess... (0)

Anonymous Coward | more than 3 years ago | (#34839382)

>I never realized that the standard for C++ hadn't been updated in 13 years

>Seems like a long time for a language that popular

I guess that's the reason why :o)

Why embed tabs in the code examples? (0)

Anonymous Coward | more than 3 years ago | (#34838888)

which idiot would embed tabs in the code examples? typical kalev fail.

Too little and too much, way too late (1, Flamebait)

Rogerborg (306625) | more than 3 years ago | (#34838918)

There's still a market for low level C programmers, and for Java, C#, Perl, Python, VB, and just about everything else, but who uses C++ these days? Games developers, a few corporate app maintainers and... uh... hang on...

Note carefully: I love C++, with all its fragmentation, bloat, gotchas and non-standard-standard-libraries, but really, it's a niche language now, kept alive by beardy wierdies and a few caffeine soaked kids who'll burn out and end up writing SQL for banks in a couple of years. Interesting, but hardly news that matters.

Re:Too little and too much, way too late (2)

0100010001010011 (652467) | more than 3 years ago | (#34838960)

XBMC [xbmc.org]
GitHub Source. [github.com]

Re:Too little and too much, way too late (1)

FunkyELF (609131) | more than 3 years ago | (#34839466)

It only uses C++ because it was originally XBMP (xbox media player) which had to be built using an illegally obtained XDK where C and C++ were the only choices.
Had other languages been available, I'm sure it would've been written using them.

Re:Too little and too much, way too late (3, Insightful)

Anonymous Coward | more than 3 years ago | (#34839068)

Not that I disagree with your feelings but QT is a major C++ magnet -- of course you could argue that QT is a language on its own, not really C++.

Re:Too little and too much, way too late (0)

Anonymous Coward | more than 3 years ago | (#34839298)

Why? Just because of some auto-generated code (moc) for signals/slots?

Re:Too little and too much, way too late (2)

jythie (914043) | more than 3 years ago | (#34839080)

I don't know, I see a LOT of C++ job postings. Most desktop and server application (designed for sale) development is still done in C++, and it is pretty common in middleware.

Re:Too little and too much, way too late (5, Informative)

JBMcB (73720) | more than 3 years ago | (#34839192)

> Games developers, a few corporate app maintainers and...

Most Mozilla project applications including Firefox.. Pretty much all of KDE and some of GNOME. WebKit. Google Chrome. Opera. A good chunk of OpenOffice. Most Adobe applications. Most Microsoft desktop applications including Internet Explorer. CUPS. The Qt toolkit and pretty much everything that uses it. MySQL. Autodesk Maya. Winamp.

I wouldn't say a *few* corporate apps are written in C++, I'd say pretty much every major desktop app that's undergone a major re-write within the last two decades is probably C++.

Re:Too little and too much, way too late (3, Informative)

derGoldstein (1494129) | more than 3 years ago | (#34839418)

Let's ask Bjarne the same question: List of C++ Applications [att.com]
Chop off half of the software applications on that list, at random -- can you still use your computer now? How about the internet?

Re:Too little and too much, way too late (1)

derGoldstein (1494129) | more than 3 years ago | (#34839508)

Just a clarification... I meant to reply to the parent post. I just had a brain fart because I read the line "but who uses C++ these days?" and starting seizing and foaming at the mouth, and I pressed the wrong "Reply to This" button.
Man, that was high-quality flamebait.

(I use C++ for almost everything in which the environment *lets* me use it, so I was the right target I guess)

Re:Too little and too much, way too late (1)

wondafucka (621502) | more than 3 years ago | (#34839468)

> Games developers, a few corporate app maintainers and...

Most Mozilla project applications including Firefox.. Pretty much all of KDE and some of GNOME. WebKit. Google Chrome. Opera. A good chunk of OpenOffice. Most Adobe applications. Most Microsoft desktop applications including Internet Explorer. CUPS. The Qt toolkit and pretty much everything that uses it. MySQL. Autodesk Maya. Winamp.

I wouldn't say a *few* corporate apps are written in C++, I'd say pretty much every major desktop app that's undergone a major re-write within the last two decades is probably C++.

...National Instruments, Teradyne, pretty much any hardware interface vendor will provide a C++ instrument driver. All your pretty toys and joys of modern life have components that are tested and researched using the language. (Unless they are using LabView, but let's not go there).

Re:Too little and too much, way too late (2)

capnchicken (664317) | more than 3 years ago | (#34839202)

I concur with your anecdotal evidence with my own observations and I share your opinions. But it seems like its moot compared to some of the hard data [regulargeek.com] I've seen in the past. [tiobe.com] . It may be trending down, but it's not down yet.

I believe it is also a regional thing, C# seems to dominate the Mid-Western US with Java domination on the US coasts. With C++ being, well, elsewhere out of my ethnocentric regionalisms. Again, just my own personal anecdotal evidence.

Re:Too little and too much, way too late (4, Insightful)

mswhippingboy (754599) | more than 3 years ago | (#34839264)

There's still a market for low level C programmers, and for Java, C#, Perl, Python, VB, and just about everything else, but who uses C++ these days? Games developers, a few corporate app maintainers and... uh... hang on...

Not sure if you're being facetious or not here, but C++ is consistently in the top 3 languages (the others being C and Java) in terms of popularity and usage. It's well above PHP, C#, Perl, Python, VB, Obj-C, and so on. I realize that stats from Tiobe index, Sourceforge, Langpop and other sources are merely an educated guess as to what people are really using, but the fact that nearly all agree on these three languages as being the top contenders seems to add credibility to their accuracy. It certainly beats the opinion of some individuals who are biased toward their favorite (or least favorite) languages.

kept alive by beardy wierdies and a few caffeine soaked kids who'll burn out and end up writing SQL for banks in a couple of years

Hey wait a minute! I resemble that remark!

Re:Too little and too much, way too late (0)

Anonymous Coward | more than 3 years ago | (#34839516)

>I realize that stats from Tiobe index, Sourceforge, Langpop and other sources are merely an educated guess as to what people are really using

Ask the slashdot crowd what programming language people are using is like asking customers in McDonald's about nouveau cuisine.

Re:Too little and too much, way too late (1)

derGoldstein (1494129) | more than 3 years ago | (#34839582)

...It certainly beats the opinion of some individuals who are biased toward their favorite (or least favorite) languages.

I'd also say it's less religious. I mean compare C++ programmers to Java programmers, or, dare I mention -- Perl programmers (and I used to program in both for years... Criticism of the languages themselves was not taken well).

Re:Too little and too much, way too late (1)

Is0m0rph (819726) | more than 3 years ago | (#34839556)

What are you talking about? There's tons of work in the US for C++ developers. My job right now for a large company has everything written in C++. C++ is everywhere in the controls and semiconductor industries too.

Re:Too little and too much, way too late (0)

Anonymous Coward | more than 3 years ago | (#34839598)

Device drivers, operating system libraries, compilers, tons of retail software, etc. etc.

In fact, libraries that provide a C header file may actually be implemented in C++. I agree with the fact that C++ is barely used in corporate applications anymore in favor of RAD-flavored languages, but most everything else is still done in C++.

/puke (0)

jimmerz28 (1928616) | more than 3 years ago | (#34838936)

I think they could use a graphic designer for "The number one developer site!".

Re:/puke (2)

Eudial (590661) | more than 3 years ago | (#34839076)

Don't judge a website by the stylesheet.

Is C++ ever the right tool for the job? (4, Interesting)

ron_ivi (607351) | more than 3 years ago | (#34838952)

It seems to me that most tasks that seem good for C++ would be better handled using a mix of an easier-to-program language (Ruby, Python, heck even lisp or smalltalk or anything else) with C extensions.

IMHO C++ seems not very good at very low-level programming; since with C++ it's not always obvious what a compiler might want to do with '+' thanks to operator overloading and rather convoluted implicit casting rules. In C you're using a pretty good tool for low-level programmings (especially with a dialect where you can sneak in a few assembly calls where you need to). In Ruby you're using a reasonably nice and efficient to develop in OO language. With the incredible ease of writing C extensions for Ruby, it's easy to use the best tool for each part of the job you're doing. The only compelling reason to use C++ I can think of is if some political policy forces you to use a single language for an entire project; and then I guess C++ not quite as clunky as java or c#.

( though I'm kinda repeating myself - a longer rant I made on slashdot about the pains of C++ years ago is here http://slashdot.org/comments.pl?sid=100202&cid=8540772 [slashdot.org] . An even more condemning annoyance about C++ is that thanks to so many convoluted tricks in the language, most people who claim C++ knowledge don't actually know it, as evidenced by the comments in that old thread )

Re:Is C++ ever the right tool for the job? (0)

dkleinsc (563838) | more than 3 years ago | (#34839062)

I started in on C++ as my second programming language, back in my larval days on a classic IBM PC.

My first impression of it was "Wow, this OOP stuff is fantastic, it makes everything so much more clear!" My second impression of it once I started to build more complex things was "Yeaargh, this is so inconsistent and confusing!".

So I switched to something easier, and learned old-school Intel assembler which I used to mess around with DOS internals.

Re:Is C++ ever the right tool for the job? (1)

Prune (557140) | more than 3 years ago | (#34839482)

So let's see--you basically wrote that high level programming is confusing compared to assembly. Well yes, primitive operations like mov and sub and push are indeed quite trivial to reason about compared to multiple inheritance and template metaprogramming. So? Flying to the moon is more complicated than driving to the local Walmart as well--it doesn't make it any less worthy.

Re:Is C++ ever the right tool for the job? (4, Insightful)

EsbenMoseHansen (731150) | more than 3 years ago | (#34839074)

I tried to use ruby for a while, but ended up back with C++. I couldn't live without static typing, as it turned out, and also C++ had more libraries leading to faster development (for me, at least).

C++ is the worst language, excepting every other language I have tried. And I am happy about the new features, they should make coding much nicer.

Re:Is C++ ever the right tool for the job? (0)

Anonymous Coward | more than 3 years ago | (#34839090)

Is this a joke?

Re:Is C++ ever the right tool for the job? (3, Funny)

Monkeedude1212 (1560403) | more than 3 years ago | (#34839306)

No. THIS is a joke.

Two bytes meet. The first byte asks, “Are you ill?”
The second byte replies, “No, just feeling a bit off.”

Re:Is C++ ever the right tool for the job? (1)

Monkeedude1212 (1560403) | more than 3 years ago | (#34839130)

The only compelling reason to use C++ I can think of is if some political policy forces you to use a single language for an entire project;

I think you answered your own question there.

I've found that a lot of 'outsourced' programming jobs go to people who only know one language. And that language tends to be C++, because its easier to teach someone 1 language than it is to teach them the theory and how it applies to 5 languages.

Re:Is C++ ever the right tool for the job? (0)

Anonymous Coward | more than 3 years ago | (#34839148)

If you want to use an OO language for an embedded system, especially real-time embedded systems like aircraft, C++ is still a good option. With C, you're constantly forcing the language if you want to apply OO principles in a meaningful way (especially if you can't trust some of your programmers to follow it carefully, as in my group). Something like Ruby or Python is obviously out, as are Java, C#, etc.—the very things that make those so nice are what rule them out from use in an environment like that. There are other languages that might do the trick, but—as in the case of C before it—one of the most compelling arguments for C++ is its ubiiquity and the wide availability of support and tools for it.

Re:Is C++ ever the right tool for the job? (4, Informative)

godrik (1287354) | more than 3 years ago | (#34839156)

I aggree that people tend to do too many things in C++ (me first). However, there are quite some place where C++ should be used. Mainly gaming engines and high performance computing. You NEED low level programming to deal with that. They could be written in C. But numerous C++ programming techniques (mainly template mechanism) makes it much easier to program. You could not get reusable algorithm accross multiple data type with efficient compile-time type checking at no runtime cost without templates. You could do it with macros but you will have terrible compilation problem if you screw up. Or you could use inheritance but will pay the cost at runtime.

Re:Is C++ ever the right tool for the job? (1)

robbyjo (315601) | more than 3 years ago | (#34839190)

Yes. C++ (and Java) are indispensable for scientific software. In scientific software, the spec is ever changing as the science progresses and hence the flexibility to morph the programs as needed and maintainability are of paramount importance. On the other hand, we need the speed.

Some of these can be resolved by invoking ready-made C libraries and then called in higher level languages such as Python or R or Matlab. However, in many occasions, this luxury isn't available (e.g., Markov Chain Monte Carlo simulations or custom EM algorithm).

Oh God! (0)

Anonymous Coward | more than 3 years ago | (#34839236)

...if some political policy forces you to use a single language for an entire project...

Oh God!

I have never seen a software project that used "the right tool for the job" - different languages for different for different parts of the system - that wasn't: overly complex, buggy as all hell, and a complete bitch to debug and to understand.

Here you are, debugging the C++ code and all of a sudden, it makes a call to an interpreted language module (kicking off the interpreter in the process) and you can't step in and follow WTF is going on. You're back to printing out to console or a file to see what's going on. Of course, the first several times in doing that isn't enough so you're constantly adding more "print" statements.

I once had a system that had a Java Swing UI, a C++ module that did something, that called a Perl module because, according to the original developer Perl is the only language for processing text, which then went back up the chain to the Java UI which then made JDBC calls into Oracle (with its own SQL code) and then back. It was buggy, ugly, slow as fucking hell, and the end user eventually scrapped everything (and canned everyone in the process) and bought something off the shelf.

tl;dr: Writing a system in one language is perfectly acceptable and this "right too for the job" only applies to trades people. Languages are just syntax and they all end up as ones and zeros in the end.

Re:Is C++ ever the right tool for the job? (2, Insightful)

Anonymous Coward | more than 3 years ago | (#34839320)

No offense but you have to be stupid to not know what + does. If it does something unexpected, chances are you wrote it incorrectly yourself, or are using a terrible library that has undocumented operators that are working incorrectly on top of that. It's not the languages fault when programmers code like retards.

Re:Is C++ ever the right tool for the job? (1)

GreatBunzinni (642500) | more than 3 years ago | (#34839338)

You have to take into account the absolute pain which is to manage a multi-language project, let alone debug any problem. Moreover, the level of mind-numbing bloatedness which interpreted languages such as those you described (ruby, python and the like) may, in your opinion, make a language a bit easier to program in, but in practical terms it leads to terribly bloated software which, unless you are running a high end desktop, runs mind-numbingly slow when compared with native, 100% C++ apps.

Re:Is C++ ever the right tool for the job? (5, Informative)

mswhippingboy (754599) | more than 3 years ago | (#34839464)

It seems to me that most tasks that seem good for C++ would be better handled using a mix of an easier-to-program language (Ruby, Python, heck even lisp or smalltalk or anything else) with C extensions.

IMHO C++ seems not very good at very low-level programming; since with C++ it's not always obvious what a compiler might want to do with '+' thanks to operator overloading and rather convoluted implicit casting rules. In C you're using a pretty good tool for low-level programmings (especially with a dialect where you can sneak in a few assembly calls where you need to). In Ruby you're using a reasonably nice and efficient to develop in OO language. With the incredible ease of writing C extensions for Ruby, it's easy to use the best tool for each part of the job you're doing. The only compelling reason to use C++ I can think of is if some political policy forces you to use a single language for an entire project; and then I guess C++ not quite as clunky as java or c#.

( though I'm kinda repeating myself - a longer rant I made on slashdot about the pains of C++ years ago is here http://slashdot.org/comments.pl?sid=100202&cid=8540772 [slashdot.org] . An even more condemning annoyance about C++ is that thanks to so many convoluted tricks in the language, most people who claim C++ knowledge don't actually know it, as evidenced by the comments in that old thread )

I disagree on several points. C is great for low level programming, but many times you want to use OO rather than procedural programming. C++ allows you to do exactly the same low level programming you can do in C (including inline-assembler if needed), but also offers the ability to design in OO. I can't think of a good reason not to use C++ rather than C unless it is a simple monolithic (preferably small) project. Mixing languages brings a whole other set of headaches (including staffing issues). Ruby, Python or other languages are fine and have their place, but I can't imagine using them for systems level programming anymore than I would use C++ to build a web application. Languages like Python, Ruby, (errr.. LISP? - there is considerable debate over whether LISP is even a true "programming language" but rather an alternate implementation of a Turing machine, but I digress) are orders of a magnitude too slow to be used as systems programming languages.

Re:Is C++ ever the right tool for the job? (5, Informative)

EvanED (569694) | more than 3 years ago | (#34839484)

I used to be a huge C++ fan, though that has waned over the years as I've used better-designed languages and have also seen other people struggle with C++'s testier features.

That said -- I'd still take C++ over plain C for essentially anything in a heartbeat. (Basically the only exception would be stuff like microcontroller programming or other environments where there isn't really a good C++ compiler.) RAII alone is enough to seal that deal.

I don't buy most of the arguments of C over C++. For instance, take your statement that "IMHO C++ seems not very good at very low-level programming; since with C++ it's not always obvious what a compiler might want to do with '+' thanks to operator overloading and rather convoluted implicit casting rules."

But with modern compilers, I feel it's already very not obvious what the compiler is going to do with your code. What function calls are inlined? What loops are unrolled? For what I think is a reasonably dramatic example of this, take the following snippet:

int main(int argc, char** argv) {
    int y = 50;
    if (argc > 1) {
        y = 100;
    }
    return y;
}

and compile with optimization on. Look at the resulting assembly. There's no branch! (I'm assuming a variant of x86 or x64 here.)

If you're on a 64-bit system with GCC you'll probably see a cmov (conditional move) instruction, which kind of makes sense. But you don't even need that instruction to be available for it to omit an actual control-flow jump. Recompile with -m32 and look at the assembly again. Much longer, but still no branch. Instead, it uses one of the setxx instructions (setg in my case) and a bit of bit twiddling.

In my opinion, today's optimizers make the generated code so far removed from what you type into your editor that saying "+ can do anything!" is a drop in the bucket.

Re:Is C++ ever the right tool for the job? (-1)

Anonymous Coward | more than 3 years ago | (#34839536)

Oh wah.

"Ooooooo noooo, this language is too hard to program in"

You sound like a big fag. Know what? We don't want you programming in C++ because if you're the type to bitch and complain because something is hard then you aren't good enough to program in C++. C++ is meant to build PROGRAMMERS out of boys like you. Yeah plenty can't handle it but this he do, they write code for big bucks. Big important code that runs shit. No some fag ass Ruby on Rails web delivered stupidity.

The shit that runs the shit that runs Ruby? Fuckin C++.

Re:Is C++ ever the right tool for the job? (2)

Prune (557140) | more than 3 years ago | (#34839546)

Indeed, C++ is just as easy as C to use for low-level programming, as not only do you have the option of inline assembly which mixes easily with the rest of your code, but you even rarely need to resort to it as in the major compilers (MSVC, gcc, Intel C++) there is a plethora of compiler intrinsics which almost directly map to assembly instructions while providing a type-safe interface. It's quite easy to write synchronization primitives, for example, using interlocked operation intrinsics--while the same have a nice object-oriented interface. Just because C++ is large and has a multitude of features in no way implies that you need to try to use all of these features. You might as well complain that the library has too many books! It's ultimately a matter of programmer discipline; stop shifting the blame.

Make it stop..... (3, Interesting)

jythie (914043) | more than 3 years ago | (#34838984)

Stop trying to add more redundant features to C++... it is already getting progressively harder for C++ programmers to read each other's code and teach newbies what something means.

All this does is result in yet more more syntactic sugar to teach people in order to accomplish the same tasks they can already do with the older standards, and yet another round of relearning so you can tell what someone who learned a 'neat new trick' is doing. And of course you STILL need to teach the old methods to newbies so they can understand C++ code that they have to maintain.

Seriously.. this really does not help.

Re:Make it stop..... (0)

Anonymous Coward | more than 3 years ago | (#34839108)

Agree.
The impression I get from the WG is that they have no idea where the language should be going, or how to solve the existing problems and unsolved corner cases created by indiscriminately adding features. So their solution is to add even more features.

Re:Make it stop..... (2)

EsbenMoseHansen (731150) | more than 3 years ago | (#34839154)

Some of us wants them. For you that do not, pass std=c++98 to gcc and be happy. Think of it as a new language :)

Re:Make it stop..... (1)

jythie (914043) | more than 3 years ago | (#34839218)

The problem with this is, we end up with a fractured language were 'I know C++' communicates less and less to a potential employer or team. One of the nightmares I had dealing with a C++ project even a few years ago was everyone's code looked (and worked) so differently according to when they learned the language to the point they could not maintain each others code. The only solution ends up being forcing a standard of 'which version of C++ we will use', which then results in holy wars and retraining when you bring in more people.

Re:Make it stop..... (1)

EsbenMoseHansen (731150) | more than 3 years ago | (#34839430)

This will be the, what, second standard? Third? And besides the new libraries, it's not that many new hard-to-grok features that are added. Actually, I can only think of lambda, but a language without lambda is an atrocity. Is there any particular feature you are thinking of? Have you read the wikipedia page?

I have worked on a number of projects, usually as some sort of project lead or technical lead. I have had problems with people who could not grok C++ (though not many), but I have not had the problem you describe, which just shows how lucky I am ;)

In my humble opinion the biggest problem I have had over the years is to get people to search for a freaking library instead of trying to do everything themselves. Admittedly, that is not a problem specific to C++.

Re:Make it stop..... (0)

Anonymous Coward | more than 3 years ago | (#34839578)

>The only solution ends up being forcing a standard of 'which version of C++ we will use', which then results in holy wars and retraining when you bring in more people.

They're called coding standards. Implement them.

Re:Make it stop..... (1)

Anonymous Coward | more than 3 years ago | (#34839284)

What do you mean when you say "newbies" and "syntactic sugar"?

Sorry, I stopped tracking changes to the English language several decades ago.

Re:Make it stop..... (1)

Korin43 (881732) | more than 3 years ago | (#34839302)

Some of us like it when language designers make things easier for us.


for each(int i : some_container) { // do things
}

vs:


for(std::container_type::iterator i = some_container.begin(); i != some_container.end(); i++) { // do things
}

One of those is immediately obvious and one takes a second to think about. Who cares if you have to learn one new piece of syntax in a language you'll use for decades?

That said, I see the standard library improvements as more interesting (mainly multithreading and hash tables). Sure you could do those before, but now you have guaranteed portability to any platform that full supports C++, with no checks to see what's available.

Re:Make it stop..... (1)

Korin43 (881732) | more than 3 years ago | (#34839316)

Er.. for the "for each" part, I mean just "for". I was confused by Microsoft extentions.

Re:Make it stop..... (1)

russotto (537200) | more than 3 years ago | (#34839428)

for(std::container_type::iterator i = some_container.begin(); i != some_container.end(); i++) { // do things
}

This is just one of MANY reasons C++ needs to die. Just about every interaction with the STL is like this. And suppose you're going through multiple parallel containers (what python calls "zip")? Then the new sugar doesn't work except for one container.

C++ is the language which allows you to just about anything, but nothing that is all of complex, clear, and efficient. No amount of hacked-on extras are going to solve the problem.

Re:Make it stop..... (1)

Korin43 (881732) | more than 3 years ago | (#34839570)

Sounds like they could fix that by adding a 'zip' function ;)

Re:Make it stop..... (0)

Anonymous Coward | more than 3 years ago | (#34839424)

It makes me think that there might be some value in rigorously specifying a standard subset of C++0x. I mean... my impression is that nobody is really using the entirety of the C++ language; everybody uses a set of core features, and pick-and-chooses the more specialized functions.

In a group project, it might be a good idea to define features that may be used across the board, and separate them from features (say, operator overloading, or some of the weirder template stuff) that should be used only if there's a strong reason, and well-flagged and documented.

Re:Make it stop..... (1)

noidentity (188756) | more than 3 years ago | (#34839494)

You can already do it all with assembler, so it's all syntactic sugar. Presumably, they add it where they believe it will result in a net benefit. If you read the interview, you'll find there aren't many significant features, more refinement of current ones. R-value references seem the main addition, but this is mostly of interest to library authors (as most features are); users simply get cleaner library interfaces to use, not having to worry as much about avoiding copying of large objects.

Re:Make it stop..... (1)

russotto (537200) | more than 3 years ago | (#34839572)

You can already do it all with assembler, so it's all syntactic sugar. Presumably, they add it where they believe it will result in a net benefit.

The problem is it's been added in a haphazard way. This is a language where a major feature (template metaprogramming) occurred _by accident_.

Re:Make it stop..... (1)

lederhosen (612610) | more than 3 years ago | (#34839554)

I do not agree. most of the changes are good, and really needed. They will make programs easier to read and add expressiveness. How can you be against things like auto variables and lambda expressions?

Re:Make it stop..... (1)

Prune (557140) | more than 3 years ago | (#34839592)

Taking the "syntactic sugar" argument to its conclusion, everything above machine language is syntactic sugar. Accomplish the same task you can already do with an older standard? You can accomplish the same task with any turing-complete language. Such as assembly. Basically, your argument fails a pretty basic sanity check because, by extension, it implies that punched cards are as good as a high-level language.

I always wanted to say this in public : (1)

unity100 (970058) | more than 3 years ago | (#34839064)

C plüzs plüsz ...

Re:I always wanted to say this in public : (0)

Anonymous Coward | more than 3 years ago | (#34839256)

You're so right. My turn now:

Tschi piu piu ...

Re:I always wanted to say this in public : (0)

Anonymous Coward | more than 3 years ago | (#34839266)

Szí plász plász?

Re:I always wanted to say this in public : (1)

unity100 (970058) | more than 3 years ago | (#34839438)

aaaah. apparently czech is the best.

Interview (5, Funny)

Mongoose Disciple (722373) | more than 3 years ago | (#34839078)

I always preferred this [chunder.com] interview with Bjarne Stroustrup.

(Yes, I know it's not real, but...)

Re:Interview (1)

Anonymous Coward | more than 3 years ago | (#34839212)

Or this [abstrusegoose.com] tutorial on how to teach yourself C++ in 21 days.

Re:Interview (4, Insightful)

Prune (557140) | more than 3 years ago | (#34839394)

I wrote C for about 5 years and then switched to C++ with which I've stuck for the last dozen years. With that perspective, the article you linked to is such a lousy attempt at humor that it made me cringe. C++ has, like many other large entities with significant history, become a bit messy due to the need for legacy support given its huge installed base. This does not mean that you cannot write neat programs with it! It's easy to blame the language instead of the software developer. It is just a matter of a bit of attention and discipline to do great stuff with C++ even while using what some may refer to its more esoteric features like template metaprogramming etc. I could never give up things like multiple inheritance, which may require a bit of care during usage, but I've found to be the way to go in many situations. The majority of the C++0x additions are very welcome as well. What's really needed is a completely modern reference text that minimizes time spent on legacy issues. It's basically the same situation with OpenGL, which has become much larger in the 3.x and 4.x versions, while still supporting all the legacy code--and there is no proper reference so one usually sees a messy mix of 2.x and 3/4.x in most current projects, rather than a clean, organized design following the most recent variant. A proper text (other than the standards document itself) would make a huge difference.

Could they not have named it something sensible? (2)

LordNacho (1909280) | more than 3 years ago | (#34839092)

See-plus-plus-zero-ex doesn't really roll off the tongue. How about something a bit easier? Super-C, C-flat, Cmega+ or something lame that people can actually say.

(Here's your queue to explain to me what the proper pronunciation is. AND the reason for picking such a weird name)

Re:Could they not have named it something sensible (1)

Anonymous Coward | more than 3 years ago | (#34839296)

Sigh. Why do we still have to go through this? That is the designation to distinguish when you are talking about the new standard. That is NOT its name. The language is still just C++. ALL ISO language standards committees do this. When the new standard comes out, the language will be called C++. You write things like C++03 and C++0x or C90 and C99 to distinguish between them.

Re:Could they not have named it something sensible (3, Informative)

Korin43 (881732) | more than 3 years ago | (#34839328)

Because it's still just C++. C++0x is just one particular version, like C++98 or C++03. Java 1.6.23 doesn't exactly roll off the tongue either.

Re:Could they not have named it something sensible (0)

Anonymous Coward | more than 3 years ago | (#34839336)

C++-oh-X is as easy to say as any of your suggestions, and the word is "cue" you weak-minded trumpster.

Your queue (0)

Anonymous Coward | more than 3 years ago | (#34839532)

Actually it is my cue to inform you that you used the wrong word that sounds like the letter 'Q'.

Last interview (0)

Anonymous Coward | more than 3 years ago | (#34839094)

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

Slashdotted, here is article text (4, Funny)

Anonymous Coward | more than 3 years ago | (#34839258)

Interviewer: Well, it's been a few years since you changed the
world of software design, how does it feel, looking back?

Stroustrup: Actually, I was thinking about those days, just before
you arrived. Do you remember? Everyone was writing 'C'
and, the trouble was, they were pretty damn good at it.
Universities got pretty good at teaching it, too. They were
turning out competent - I stress the word 'competent' -
graduates at a phenomenal rate. That's what caused the
problem.

Interviewer: Problem?

Stroustrup: Yes, problem. Remember when everyone wrote Cobol?

Interviewer: Of course, I did too

Stroustrup: Well, in the beginning, these guys were like demi-gods.
Their salaries were high, and they were treated like
royalty.

Interviewer: Those were the days, eh?

Stroustrup: Right. So what happened? IBM got sick of it, and
invested millions in training programmers, till they were a
dime a dozen.

Interviewer: That's why I got out. Salaries dropped within a year,
to the point where being a journalist actually paid better.

Stroustrup: Exactly. Well, the same happened with 'C' programmers.

Interviewer: I see, but what's the point?

Stroustrup: Well, one day, when I was sitting in my office, I
thought of this little scheme, which would redress the
balance a little. I thought 'I wonder what would happen, if
there were a language so complicated, so difficult to learn,
that nobody would ever be able to swamp the market with
programmers? Actually, I got some of the ideas from X10,
you know, X windows. That was such a bitch of a graphics
system, that it only just ran on those Sun 3/60 things.
They had all the ingredients for what I wanted. A really
ridiculously complex syntax, obscure functions, and
pseudo-OO structure. Even now, nobody writes raw X-windows
code. Motif is the only way to go if you want to retain
your sanity.

Interviewer: You're kidding...?

Stroustrup: Not a bit of it. In fact, there was another problem.
Unix was written in 'C', which meant that any 'C' programmer
could very easily become a systems programmer. Remember
what a mainframe systems programmer used to earn?

Interviewer: You bet I do, that's what I used to do.

Stroustrup: OK, so this new language had to divorce itself from
Unix, by hiding all the system calls that bound the two
together so nicely. This would enable guys who only knew
about DOS to earn a decent living too.

Interviewer: I don't believe you said that...

Stroustrup: Well, it's been long enough, now, and I believe most
people have figured out for themselves that C++ is a waste
of time but, I must say, it's taken them a lot longer than I
thought it would.

Interviewer: So how exactly did you do it?

Stroustrup: It was only supposed to be a joke, I never thought
people would take the book seriously. Anyone with half a
brain can see that object-oriented programming is
counter-intuitive, illogical and inefficient.

Interviewer: What?

Stroustrup: And as for 're-useable code' - when did you ever hear
of a company re-using its code?

Interviewer: Well, never, actually, but...

Stroustrup: There you are then. Mind you, a few tried, in the
early days. There was this Oregon company - Mentor
Graphics, I think they were called - really caught a cold
trying to rewrite everything in C++ in about '90 or '91. I
felt sorry for them really, but I thought people would learn
from their mistakes.

Interviewer: Obviously, they didn't?

Stroustrup: Not in the slightest. Trouble is, most companies
hush-up all their major blunders, and explaining a $30
million loss to the shareholders would have been difficult.
Give them their due, though, they made it work in the end.

Interviewer: They did? Well, there you are then, it proves O-O
works.

Stroustrup: Well, almost. The executable was so huge, it took
five minutes to load, on an HP workstation, with 128MB of
RAM. Then it ran like treacle. Actually, I thought this
would be a major stumbling-block, and I'd get found out
within a week, but nobody cared. Sun and HP were only too
glad to sell enormously powerful boxes, with huge resources
just to run trivial programs. You know, when we had our
first C++ compiler, at AT&T, I compiled 'Hello World', and
couldn't believe the size of the executable. 2.1MB

Interviewer: What? Well, compilers have come a long way, since then.

Stroustrup: They have? Try it on the latest version of g++ - you
won't get much change out of half a megabyte. Also, there
are several quite recent examples for you, from all over the
world. British Telecom had a major disaster on their hands
but, luckily, managed to scrap the whole thing and start
again. They were luckier than Australian Telecom. Now I
hear that Siemens is building a dinosaur, and getting more
and more worried as the size of the hardware gets bigger, to
accommodate the executables. Isn't multiple inheritance a joy?

Interviewer: Yes, but C++ is basically a sound language.

Stroustrup: You really believe that, don't you? Have you ever sat
down and worked on a C++ project? Here's what happens:
First, I've put in enough pitfalls to make sure that only
the most trivial projects will work first time. Take
operator overloading. At the end of the project, almost
every module has it, usually, because guys feel they really
should do it, as it was in their training course. The same
operator then means something totally different in every
module. Try pulling that lot together, when you have a
hundred or so modules. And as for data hiding. God, I
sometimes can't help laughing when I hear about the problems
companies have making their modules talk to each other. I
think the word 'synergistic' was specially invented to twist
the knife in a project manager's ribs.

Interviewer: I have to say, I'm beginning to be quite appalled at
all this. You say you did it to raise programmers'
salaries? That's obscene.

Stroustrup: Not really. Everyone has a choice. I didn't expect
the thing to get so much out of hand. Anyway, I basically
succeeded. C++ is dying off now, but programmers still get
high salaries - especially those poor devils who have to
maintain all this crap. You do realise, it's impossible to
maintain a large C++ software module if you didn't actually
write it?

Interviewer: How come?

Stroustrup: You are out of touch, aren't you? Remember the
typedef?

Interviewer: Yes, of course.

Stroustrup: Remember how long it took to grope through the header
files only to find that 'RoofRaised' was a double precision
number? Well, imagine how long it takes to find all the
implicit typedefs in all the Classes in a major project.

Interviewer: So how do you reckon you've succeeded?

Stroustrup: Remember the length of the average-sized 'C' project?
About 6 months. Not nearly long enough for a guy with a
wife and kids to earn enough to have a decent standard of
living. Take the same project, design it in C++ and what do
you get? I'll tell you. One to two years. Isn't that
great? All that job security, just through one mistake of
judgement. And another thing. The universities haven't
been teaching 'C' for such a long time, there's now a
shortage of decent 'C' programmers. Especially those who
know anything about Unix systems programming. How many guys
would know what to do with 'malloc', when they've used 'new'
all these years - and never bothered to check the return
code. In fact, most C++ programmers throw away their return
codes. Whatever happened to good ol' '-1'? At least you
knew you had an error, without bogging the thing down in all
that 'throw' 'catch' 'try' stuff.

Interviewer: But, surely, inheritance does save a lot of time?

Stroustrup: Does it? Have you ever noticed the difference between
a 'C' project plan, and a C++ project plan? The planning
stage for a C++ project is three times as long. Precisely
to make sure that everything which should be inherited is,
and what shouldn't isn't. Then, they still get it wrong.
Whoever heard of memory leaks in a 'C' program? Now finding
them is a major industry. Most companies give up, and send
the product out, knowing it leaks like a sieve, simply to
avoid the expense of tracking them all down.

Interviewer: There are tools...

Stroustrup: Most of which were written in C++.

Interviewer: If we publish this, you'll probably get lynched, you
do realise that?

Stroustrup: I doubt it. As I said, C++ is way past its peak now,
and no company in its right mind would start a C++ project
without a pilot trial. That should convince them that it's
the road to disaster. If not, they deserve all they get. You
know, I tried to convince Dennis Ritchie to rewrite Unix in
C++.

Interviewer: Oh my God. What did he say?

Stroustrup: Well, luckily, he has a good sense of humor. I think
both he and Brian figured out what I was doing, in the early
days, but never let on. He said he'd help me write a C++
version of DOS, if I was interested.

Interviewer: Were you?

Stroustrup: Actually, I did write DOS in C++, I'll give you a demo
when we're through. I have it running on a Sparc 20 in the
computer room. Goes like a rocket on 4 CPU's, and only
takes up 70 megs of disk.

Interviewer: What's it like on a PC?

Stroustrup: Now you're kidding. Haven't you ever seen Windows '95?
I think of that as my biggest success. Nearly blew the game
before I was ready, though.

Interviewer: You know, that idea of a Unix++ has really got me
thinking. Somewhere out there, there's a guy going to try
it.

Stroustrup: Not after they read this interview.

Interviewer: I'm sorry, but I don't see us being able to publish
any of this.

Stroustrup: But it's the story of the century. I only want to be
remembered by my fellow programmers, for what I've done for
them. You know how much a C++ guy can get these days?

Interviewer: Last I heard, a really top guy is worth $70 - $80 an
hour.

Stroustrup: See? And I bet he earns it. Keeping track of all the
gotchas I put into C++ is no easy job. And, as I said
before, every C++ programmer feels bound by some mystic
promise to use every damn element of the language on every
project. Actually, that really annoys me sometimes, even
though it serves my original purpose. I almost like the
language after all this time.

Interviewer: You mean you didn't before?

Stroustrup: Hated it. It even looks clumsy, don't you agree? But
when the book royalties started to come in... well, you get
the picture.

Interviewer: Just a minute. What about references? You must
admit, you improved on 'C' pointers.

Stroustrup: Hmm. I've always wondered about that. Originally, I
thought I had. Then, one day I was discussing this with a
guy who'd written C++ from the beginning. He said he could
never remember whether his variables were referenced or
dereferenced, so he always used pointers. He said the
little asterisk always reminded him.

Interviewer: Well, at this point, I usually say 'thank you very
much' but it hardly seems adequate.

Stroustrup: Promise me you'll publish this. My conscience is
getting the better of me these days.

Interviewer: I'll let you know, but I think I know what my editor
will say.

Stroustrup: Who'd believe it anyway? Although, can you send me a
copy of that tape?

Interviewer: I can do that.

The problem with C++ is it's too powerful (1)

GodfatherofSoul (174979) | more than 3 years ago | (#34839272)

And, we all know that power corrupts. So, when Joe Shortcut figures out that he can overload the '=' operator to slice his ham sandwich, you invariably end up with illogical, non-intuitively behaving code. Plus, the language in an effort to be ultimately configurable, doesn't take care of some menial, repetitive tasks. That opens the door for insanely dangerous, obscure bugs like object slicing. I wish that the standards community would have just drawn a line in the sand and said "OK, here's the cleaned up, modern version that we made practical at the expense of esoteric powers."

That being said, I have total respect for what Stroustrup accomplished in context.

Re:The problem with C++ is it's too powerful (1)

EsbenMoseHansen (731150) | more than 3 years ago | (#34839548)

I never understood the first complaint. Yes, you can make = or + or whatever do crazy thing you like, but that goes for every function call. I remember debugging some (Java code, but that is besides the point) where the programmer had decided that getFoo() should actually change the internal state of the object in such a way that calling getFoo() twice totally screwed up the program. That was every bit as bad as if he has overloaded operator- to do the same.

Slicing, I agree, is a real problem, though I have seldom encountered it in real life. Perhaps because I like to keep all but my leaf classes abstract, which more or less eliminates the slicing problem.

Re:The problem with C++ is it's too powerful (1)

poppopret (1740742) | more than 3 years ago | (#34839562)

Overloading '=' is nothing. People overload '()' even. (yes, the parentheses) People overload ',' and '->' and worse.

Linking (3, Interesting)

MrEricSir (398214) | more than 3 years ago | (#34839276)

The biggest beef I have with C++ is linking.

Linking to a library that was compiled in a different C++ compiler (or even a different version of the compiler you have) is somewhere between painful and downright impossible; this is because function name mangling was never standardized and the core libraries are often incompatible.

Couldn't they standardize this in C++? It would make life so much nicer for those who deal in binaries.

C++0x compiled! (4, Funny)

hackingbear (988354) | more than 3 years ago | (#34839294)

According to Wikipedia, "C++0x" is pronounced "see plus plus oh ex" [wikipedia.org] . After three rounds of macro preprocessing, four expansions of template substitutions, and reversing five levels of dynamic cast operator overloads, the name is eventually compiled to something readable: C plus plus? Oh, my ex-programming language!.

C++0x? (0)

Anonymous Coward | more than 3 years ago | (#34839490)

Cocks?

Load More Comments
Slashdot Login

Need an Account?

Forgot your password?

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>