×

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!

Bjarne Stroustrup Previews C++0x

ScuttleMonkey posted more than 8 years ago | from the tired-of-the-word-committee dept.

Programming 741

Szplug writes "Bjarne Stroustrup has a sneak peek at the additions to C++ that he expects will be completed (hopefully) by 2009. Included are language-defined threads, optional garbage collection, some automatic type deduction, and template concepts. From the article: 'The list of current proposals is still quite modest and not anywhere as ambitious as I'd like. However, more proposals are being considered and more libraries will appear either as part of the C++0x standard itself or as further committee technical reports.'"

cancel ×
This is a preview of your comment

No Comment Title Entered

Anonymous Coward 1 minute ago

No Comment Entered

741 comments

Worth it? (1, Insightful)

Max Romantschuk (132276) | more than 8 years ago | (#14383604)

Having programmed in numerous languages I can't help wonder if it's really worth it. There's a reason why languages come and go. Bolting on new features might be more like treating the symptoms rather than the cause?

Time will tell, I guess.

Re:Worth it? (4, Insightful)

Anonymous Coward | more than 8 years ago | (#14383666)

There's a reason why languages come and go.

I agree that ADA and FORTRAN are out and Java and Python are in, but isn't C/C++ an expection?

C/C++ have been around for many years and show no signs of going away - C++ was initially developed in 1983, while C itself hails from the early 1970s - and they're still popular to this day. And, of course, C++ "bolted on new features" to C. In fact, C++ was initially called 'C with classes'.

As far as I'm concerned, as long as C++ is "the standard language" in so many places we may as well make it not suck in comparison to other languages, which we can do by appropriating the nice features of those other languages.

Just my $0.02,

Michael

Re:Worth it? (5, Insightful)

Greyfox (87712) | more than 8 years ago | (#14383723)

C++ is evolving via committee, so its growth tends to be both slow and seemingly ridiculously complex. Also usually for the better though. The last major change I recall seeing from them added templates and exceptions. Arguably neither was necessary for the language, but I think both additions helped it out. Since then folks like Alexandrescu have been doing nifty things with those features, and the boost library is based on a lot of that work. From what I can tell, the committee is actually looking at that work and are shaping C++ in a way that tries to help it in the future. Thats much better than having them go off and do their own thing without looking at what the community is doing.

C++ is a tremendously type safe language, to the point where every time I work with it I feel like about 90% of the work I do is in accounting for type. Most of that work is thrown away after the code has been compiled, too, but it does make for a rock solid program if you do it right. It seems to deliver on a lot of the promise of ADA, really. If they can improve access to its features without compromising that type safety, I'm all for it.

Re:Worth it? (4, Insightful)

frantzdb (22281) | more than 8 years ago | (#14383763)

C++ is a tremendously type safe language, to the point where every time I work with it I feel like about 90% of the work I do is in accounting for type. Most of that work is thrown away after the code has been compiled, too, but it does make for a rock solid program if you do it right.
From my experience using C++ in the field, I basically agree. While type safety can be a headache, there are many errors that strong typing eliminates entirely, almost to the point that "if it compiles, it's correct". While much type information is "thrown away" at compile time, I always find that careful consideration of type is necessary to correctly implement something large. When I have trouble mapping the problem domain onto a strictly-typed mental model, it generally means I really don't understand the problem.

Re:Worth it? (2, Informative)

LucidBeast (601749) | more than 8 years ago | (#14383764)

To us stuffy old farts things keep moving way too fast. I just got gazillion errors from the spanking new compiler, because the scope change to the variables declared inside for loops.

from the... (-1, Redundant)

Anonymous Coward | more than 8 years ago | (#14383610)

wtf-is-a-paradigm-anyway dept.

What a name! (4, Interesting)

Caspian (99221) | more than 8 years ago | (#14383612)

"C" was an unusual enough name for a language. Then "C++", which makes sense to you or I but would only mystify a non-geek. Now "C++0x"? How is that even pronounced? "See Plus Plus Zero Ecks"? Or maybe just "C...ocks"?

Names like this serve to only further mystify computing and programming among the non-geek population.

Re:What a name! (1)

melonman (608440) | more than 8 years ago | (#14383630)

Sounds like a great name if it is supposed to appeal to C programmers. What would you call it? Brenda? Somehow I can't see C ever catching on with the non-geek population.

Also, I was assuming that it would be called C++09 once the launch date is sorted out. Or should that be C+=9?

Re:What a name! (1)

Arimus (198136) | more than 8 years ago | (#14383675)

If it is C++09 should we read it as (C++)09 or C(++09) (in case of the later why not just C10?)

Re:What a name! (1)

Caspian (99221) | more than 8 years ago | (#14383819)

What would you call it? Brenda?
Actually, I think Brenda would be a fine name for a programming language! And giving a programming language a female name would attract a lot more eager young males to the field...

Re:What a name! (1)

melonman (608440) | more than 8 years ago | (#14383851)

Hmm, I don't think C is the place to start. After all, as Kerningham and Richie say, C is a small language, and young males tend to go for... well, something a bit more bloated. Maybe PHP?

Re:What a name! (2, Informative)

gravij (685575) | more than 8 years ago | (#14383631)

Seems like the 0x will be replaced with the year it is ratified by the ISO, eg. 09. The same as the ISO standard C++98.

Re:What a name! (1)

lhorn (528432) | more than 8 years ago | (#14383648)

Personally I went immidiately with the second pronounciation, it is easy to remember and fits my sense/level of humour...

Re:What a name! (3, Funny)

RedNovember (887384) | more than 8 years ago | (#14383671)

You thought that was a weird name, yet you didn't blink at Bjarne Stroustrup?

As us unfortunate VBers would say, GeekFactor.Value = True

Re:What a name! (5, Insightful)

swillden (191260) | more than 8 years ago | (#14383701)

Now "C++0x"? How is that even pronounced? "See Plus Plus Zero Ecks"? Or maybe just "C...ocks"?

Actually, the correct pronunciation will be "See Plus Plus". The name of the language won't change, just as C is just called C, even though K&R C, C89 and C99 are quite different animals.

Re:What a name! (1)

Kawahee (901497) | more than 8 years ago | (#14383714)

It's C++0x because it will be released within 2000 to 2010. The ISO C++ standard is, as stated in the article, C++98.

Re:What a name! (2, Funny)

famebait (450028) | more than 8 years ago | (#14383744)

Or maybe just "C...ocks"?

Definitely. That way, all the losers who haven't moved on to modern languages by 2009 can be known as

[drum roll]

            C++0x-suckers!

Re:What a name! (1)

alex4u2nv (869827) | more than 8 years ago | (#14383940)

CEX

with 0x being the prefix for hex numbers,
I can see C++0x being pronouced as cex or sex =p
or maybe I live in the gutter w/ the rest of geeks!

Hey baby, wanna write that program in C++0x(sex) =p

Heh (-1, Troll)

gowen (141411) | more than 8 years ago | (#14383613)

The efficiency of the basic language features ... make the use of libraries attractive in an incredibly broad set of application areas and reduce the need for new language features.
Translation : C++ will continue to be a highly useful language, as long as some other sucker does all the hard work. Thanks Bjarne, your dedication to keeping core C++ about as functional as assembly language (without the speed) is highly admirable.

Re:Heh (1)

Mung Victim (821757) | more than 8 years ago | (#14383702)

Translation : C++ will continue to be a highly useful language, as long as some other sucker does all the hard work

'Some other sucker' being the hundreds of C++ experts across the world who contribute to the C++ Standard Library and others (e.g. Boost). What would you prefer - Stroustrup does it all single-handed?

As the article says, C++ is a 'general-purpose programming language with a bias towards systems programming'. If the libraries were lumped in with the core language, C++ would be a much less flexible and less appropriate tool for those kind of tasks.

Re:Heh (3, Insightful)

mrsbrisby (60242) | more than 8 years ago | (#14383777)

What would you prefer - Stroustrup does it all single-handed?

It might be nice if he could.

Stroustrup lives in a fantasy world where the only reason C++ isn't as fast as C, or produce as small of assembly as C is because of the compilers- which he conveniently disavowes responsibility for.

Compare to Objective-C: You'll note that these new C++ "concepts" feature are extremely similar to Objective-C's "protocols"- only not only can a moderate programmer produce a fast Objective-C compiler, they'll know exactly where it can be slowed down and why.

It'll also already be able to do these things in C++ that are so new and innovative.

Meanwhile, some C++ compilers can make "cout << 1 << endl;" slow- and others only do it when the programmer tries to make their own "cout" like device.

If the libraries were lumped in with the core language, C++ would be a much less flexible and less appropriate tool for those kind [systems programming] of tasks.

No, it's if those libraries imposed greater responsibilities on the runtime. As it stands, the C++ runtime already has an awful lot to do- albeit less than Java or Objective-C.

Worse still: The C++ runtime isn't a peer to your own code as it is in Objective-C: With Objective-C you can interact with the runtime as if it were regular library calls.

C has a mountain of library code available, and the functionality of that library code drives new extensions to the C core language (TLS extensions, for example)

But then, C has almost zero runtime (and if you reject certain extensions: it actually has no runtime), and that's what makes it suitable for systems programming.

I don't think C++ is now, or ever was (or with the way these "extensions" keep showing up) - or ever will be suitable for Systems Programming.

Because the C++ programmer infrequently can understand what his runtime is doing- and is not encouraged to know the interface by which C++ does it's magic (because nobody knows- they're still trying to figure out how to make some C++ magic work in a way that isn't slow)- a C++ systems programmer needs a C++ runtime. Nobody has one in systems-space, so the C++ programmer (which isn't a programmer of C++) needs to write it.

The inventor of C++ can't even do this, but any moderate programmer could do this for Objective-C.

Re:Heh (4, Insightful)

Kjella (173770) | more than 8 years ago | (#14383857)

Translation : C++ will continue to be a highly useful language, as long as some other sucker does all the hard work.

Well, the power of most languages is in the libraries anyway. What is Java or C# without the standard libraries? I program in C++/Qt and rarely if ever touch all that is ugly about C++. The very few places I allocate memory myself for operation with other code I check it rigorously, Qt objects handle themselves. I use QString and QBytearray and never have issues with zero-termination or buffer overflows. Signals and slots will never crash on a dangling pointer. The new Qt4 containers with foreach are brilliant. So yeah, core C++ may be functionally poor but if you need the equivalent of java or C# it's a library away.

Kjella

How about a stable language spec ? (0)

Anonymous Coward | more than 8 years ago | (#14383617)

Seems that the famous interview [wku.edu] was spot on. Remember OpenBSD has only one C++ package, and that has a good reason.

2009? (0, Flamebait)

Anonymous Coward | more than 8 years ago | (#14383622)

Does anyone expect to still be using C++ in 2009?

Re:2009? (1)

indifferent children (842621) | more than 8 years ago | (#14383673)

Yes. Even if a better language comes along in the next few years, it will take more than three years (probably more than fifteen years) for C++ to stop being common.

Re:2009? (5, Insightful)

frantzdb (22281) | more than 8 years ago | (#14383720)

I doubt Google, Adobe, or many of the thousands of other companies depening on C++ will be throwing their code base away any time soon. Rather, they will want their C++ code to be more robust and more managable. The features the article lists all seem to do this.

(See Stroustrup's C++ Applications page [att.com] for more.)

Re:2009? (0)

Anonymous Coward | more than 8 years ago | (#14383820)

Yeah I predicted this response. People still use COBOL codebases, after all.

But what you seem to be saying is that it's better to update a C++ codebase to C++09 than to rewrite that code in a modern language. Is it really?

(BTW, congratulations to whichever C++ apologist moderated a question about C++ as "flamebait")

Re:2009? (1)

famebait (450028) | more than 8 years ago | (#14383732)

There'll be good money in it in a few years, when noone who graduated this century masters it, and all the non-masochists have moved on too, but stuff still needs to be maintained. The old COBOL story all over again.

Here's an offer (-1, Flamebait)

KZigurs (638781) | more than 8 years ago | (#14383628)

Take what we have now, add whatever we want, for fucking christ sake get something coherent out of it and call it C+++.

Results could be better than just adding a few additional patches keeping the previous crud. And think about the possibilities that writing and publishing a whole bunch of new "definite" books would create ;)

Re:Here's an offer (0)

Anonymous Coward | more than 8 years ago | (#14383656)

You mean D?

Re:Here's an offer (1)

jejones (115979) | more than 8 years ago | (#14383709)

Take what we have now, add whatever we want, for fucking christ sake get something coherent out of it and call it C+++.

How can one add to something incoherent and get a coherent result?

C++0x R0x0rZ (-1, Flamebait)

bbzzdd (769894) | more than 8 years ago | (#14383637)

included are language-defined threads, optional garbage collection, some automatic type deduction, and template concepts.

I liked it when it was called -- Java! But seriously, C++ is a bunch of crap grafted on C, now he wants to graft more crap onto C++? It's like Frankenstein meets the Reanimator at this point.

Re:C++0x R0x0rZ (0)

Anonymous Coward | more than 8 years ago | (#14383738)

Aw, has diddums been playing with the grown-ups things again?

Make Bjarne leave it alone! (-1, Flamebait)

Anonymous Coward | more than 8 years ago | (#14383638)

A few years ago the C++ powers that be decided to overhaul streams and change namespaces. These changes forced millions of lines of C++ code to be rewriten, but they *ADDED NO FUNCTION WHATOSEVER*. This was Syntactic Sugar. I know this, because I lived through it. There was no reason for these changes, other than I presume bored Ivory Tower Academics or Has-beens wanting to feel important again.

I did try and find out who these powers that be are, but could never find out. However it's a reasonable bet Bjarne had something to do with it. Memo to Bjarne: LEAVE THE BLOODY THING ALONE! We real programmers have real work to do, and your buggering around to do has added nothing. Imagine if K&R came back and redesigned C every few years; It would have killed the language. Bjarne, C++ was nice, but now you're it's worst enemy. Sod off and leave us people with a real job alone, huh? We don't need you. Do us a favour and get lost.

Re:Make Bjarne leave it alone! (1)

AuMatar (183847) | more than 8 years ago | (#14383743)

They do redefine C every few years, the last time was in 99. Of course, the changes were minor. The biggest one I remember was that // is now a comment, and a few other tweaks. No whole features added.

Re:Make Bjarne leave it alone! (1)

lordholm (649770) | more than 8 years ago | (#14383792)

No features??? Try complex numbers, inline functions (i.e. typesafe macros) and variable declarations which does not have to follow the start of a scope and restricted pointers.

C++ is... (0)

Anonymous Coward | more than 8 years ago | (#14383641)

proof that not everything from Bell Labs is brilliant.

You f4il it (-1, Offtopic)

Anonymous Coward | more than 8 years ago | (#14383644)

I'll have offended Where it was when When I sttod for To deliver what,

Should've just done it in Python/Ruby anyways (3, Interesting)

psavo (162634) | more than 8 years ago | (#14383653)

What I started to hate in C++/Java/C# is that there's no easy and standard-conforming way to express complex data 'inline'. Yeah, it's cleaner to make it XML and load it runtime, but there's no simple+quick way to do that either.

Hell, you can't event put known non-uniform data in C++ vector without doing it one-by-one.

Downhill at a fast rate (0, Troll)

mustafap (452510) | more than 8 years ago | (#14383655)

I still think C++ was invented as a joke. I mean, fancy allowing standard operators to be overloaded. And reference variables? I now have to carefully examine very function prototype when I need to know if a function call might have side effects.

And now garbage collection? That just a feature to fix poorly written code.

When I found the C language, I stopped looking. Ah well.

Re:Downhill at a fast rate (5, Funny)

famebait (450028) | more than 8 years ago | (#14383722)

Tell me about it! And those fancy editor thingamajiggs? A-phoooey! Real Programmers use cat(1) and do it right the first time!

Re:Downhill at a fast rate (2, Insightful)

jcr (53032) | more than 8 years ago | (#14383724)

I still think C++ was invented as a joke.

Not a joke, a research project. Thus, Stroustrup's willingness to include any "feature" that someone suggests: "Oh sure, we'll put that in and see how it works out."

The upshot is a language that is accreted instead of designed.

When I found the C language, I stopped looking. Ah well.

Too bad.

-jcr

Re:Downhill at a fast rate (2, Informative)

mustafap (452510) | more than 8 years ago | (#14383804)

>> When I found the C language, I stopped looking. Ah well.
> Too bad.

I guess I should have qualified my comment, really. I suppose in part it comes down to what problems one is trying to solve. I'm an embedded designer, working on small systems. Assembly and C turned out to be the right tools for the job. So I guess I should really have qualified my rant with "in my line of work".

The red mist has lifted now!

Re:Downhill at a fast rate (0)

Anonymous Coward | more than 8 years ago | (#14383737)

When I found the C language, I stopped looking. Ah well.

Amen to that.

When started programming with C, first. Now, ~16 years later I still write code in C.

Sure, I tried Java, C#, C++ and the other slow/non-portable/closed crap. But I figured these languages are all meant for servlets or just _average_ CS students who wouldn't cut it otherwise.

There was a funny comment [slashdot.org] about this some time ago.

Re:Downhill at a fast rate (2, Insightful)

BenjyD (316700) | more than 8 years ago | (#14383793)

It's not that hard to see if there's a 'const' in the function prototype, is it?

Re:Downhill at a fast rate (1)

ObsessiveMathsFreak (773371) | more than 8 years ago | (#14383802)

When I found the C language, I stopped looking. Ah well.

Go hack mplayers source code, and then come back saying that. C++ might not be a panaeca, but danm, C code can get very, very, very ugly sometimes.

Re:Downhill at a fast rate (2, Interesting)

Anonymous Coward | more than 8 years ago | (#14383830)

It can get ugly, if it isn't designed.
But if you spend just a little up-front design time, it is also very easy to create nice clean code.

Refactoring C after a year of development is not that hard.
Refactoring C++ after a year of development can be impossible.
Did you say reuse? Bah.

I'd just like to point out - we own it (4, Funny)

Anonymous Coward | more than 8 years ago | (#14383657)

"And C++ programming languages, we own those, have licensed them out multiple times, obviously. We have a lot of royalties coming to us from C++."

http://techupdate.zdnet.com/techupdate/stories/mai n/0,14179,2877578,00.html [zdnet.com]

You know where to send your royalty checks.

Thanks
Darl McBride

Don't worry - We'll license you case-by-case (4, Funny)

Anonymous Coward | more than 8 years ago | (#14383907)

http://www.mozillaquest.com/Linux03/ScoSource-02_S tory03.html [mozillaquest.com]

"C++ is one of the properties that SCO owns today and we frequently are approached by customers who wish to license C++ from us and we do charge for that. Those arrangements are done on a case-by-case basis with each customer and are not disclosed publicly. C++ licensing is currently part of SCO's SCOsource licensing program."

Thanks
Blake Stowell

I think it is obvious (1, Funny)

Anonymous Coward | more than 8 years ago | (#14383664)

I think it is obvious that this guy has no idea what he is talking about when talking about C++.

what a stupid name (-1, Offtopic)

Anonymous Coward | more than 8 years ago | (#14383679)

What a stupid name for a programming language!
Could you spend a while to invent better one?
Thanks.

Adding new features is not always an improvement (4, Insightful)

Frans Faase (648933) | more than 8 years ago | (#14383681)

The art of making a programming language lies in giving it just enough features to make everything possible that you want without making thing possible that you want. I feel that at the moment C++ already allows to much "wierd" things that you do not really need in practice. I am affraid that adding new features and new language constructs only will make things worse, not better.

I also have come to realize that if there is one bad thing in C++ than it is this preprocessing which it inherited from C. Especially in a large project the trouble of including the right files and linking against the matching libraries becomes a pain in the ass. In this respect I would like C++ be more like Java (or TurboPascal for the matter) where interface declarations and compiled code are unified. At the moment moving around code from one DLL to another is a lot of work, while in my perception, it could have been completely transparent from the users point of view.

I do realize that keeping backwards compatibility was one of the design features of C++, and that it also determined the success of C. But as many C++ tools are now able to make use of precompiled headers, it seems that the problem should be able to be done away with.

Re:Adding new features is not always an improvemen (1)

mwvdlee (775178) | more than 8 years ago | (#14383870)

The thing is that one of C++ main design points is that it should be able to do everything a computer can do; it is a system programming language.

That is why it will always include features which will force the programmer to think whilst typing, unlike in Java (my current job) which is a lot easier but won't allow such low level access to the computer.

As for the preprocessor issue you describe; it's type-safety.

Re:Adding new features is not always an improvemen (1)

DJStealth (103231) | more than 8 years ago | (#14383902)

At the very least, the new name could be Y2K compliant.
C++09 doesn't seem to do that. At this rate, they'll still be making updates in 2109, so maybe they should clear the ambiguity and rename it from C++0x to C++200x

More features - is that what C++ really needs? (5, Insightful)

JackDW (904211) | more than 8 years ago | (#14383683)

I'm a long-time fan of C and C++, but I've been converted to Python recently. Endlessly copying the C model is a bad idea. C++ did it, Perl did it, then Java copied C++, and all are perfectly servicable languages, but they are not clean, simple or pretty.

If we want to write complex and secure programs quickly, we need better languages, and more features does not mean better.

Re:More features - is that what C++ really needs? (1)

ForeverFaithless (894809) | more than 8 years ago | (#14383750)

Python is neat until you discover the power of Ruby. Give it a try, you won't look back.

Re:More features - is that what C++ really needs? (1, Funny)

ObsessiveMathsFreak (773371) | more than 8 years ago | (#14383833)

Ruby is OK until you stumble upon 'Rails. Then the addiction truely takes hold.

Re:More features - is that what C++ really needs? (0)

Anonymous Coward | more than 8 years ago | (#14383934)

Rails is all very well, but wait till you try out VBA macros. Then the power is turely in your hands.

Re:More features - is that what C++ really needs? (3, Insightful)

masklinn (823351) | more than 8 years ago | (#14383898)

Sorry, I have.

Ruby and Python are more or less equivalent languages, extremely similar in most constructs and ways of life, and rougly 90% of the "differences" between the languages boil down to syntactic sugar.

And please, I beg you, don't bring Blocks in this by saying something as stupid as "woohoo, blocks are liek magic, no one else has it, they're cruise control for greatness", blocks are anonymous functions period (in the Functional Programming sense of the term, e.g. functions with closures that are first-class objects), the concept is more than 30 years old... (and not OO at all, meaning that the "top of the line" feature of the OO herald language is purely functional).

Ruby is an extremely fine dynamically strongly typed language with an extreme object orientation, Python is likewise. None of them is "better than the other one" in an absolute sense and claiming the opposide is stupid, the one you choose is purely a matter of taste. You prefer Ruby? good for you, I prefer Python, and that makes neither "the ultimate language".

This fucking ruby hype is becoming extremely tiring, and doesn't help Ruby.

End of the rant

C++09??? (2, Funny)

mwvdlee (775178) | more than 8 years ago | (#14383687)

The work on C++0x has entered a decisive phase. The ISO C++ committee aims for C++0x to become C++09.
C++ octal-9???

Illuminating! Awe-inspiring! Flamebait! Jailbait! (-1, Offtopic)

Anonymous Coward | more than 8 years ago | (#14383771)

All rolled into one. Yes, octal my dear Watson.

That's a number rooted in base-8 for you dweeb-wannabes.

TR1 (0)

Anonymous Coward | more than 8 years ago | (#14383688)

If you are a C++ developer, check out Scott Meyer's webpage on the TR1 additions: http://aristeia.com/EC3E/TR1_info.html [aristeia.com]

Much of this functionality is already available in gcc4. The includes are stuffed in the TR1 subdirectory (#include ) and all the functionality is stuffed in the std::tr1 namespace (std::tr1::array).

Naming... (-1, Troll)

Anonymous Coward | more than 8 years ago | (#14383697)

C++0x

Who did that? A retard who uses to work with Buzz- and Powerwords?

The "++" didn't really make sence before (why 2 of them?). Now, there is a 0x...

Fuck this... I haven't read the article and already lost interest...

objective-c make it better (0)

baux (194041) | more than 8 years ago | (#14383700)

Objective-c has this feature since 20 eyars, and obviusly better and more consistent design as a true C superset. Steve jobs had a great idea to use
it for it's next generation mac stuff.

Slashdot interview? (5, Interesting)

nyri (132206) | more than 8 years ago | (#14383710)

How about having a slashdot interview about C++0x with Strousrup? I think it would be a good forum to gain more insights about C++ and a fine possibility to allow a community (in this case the slashdot readers) to make and to vote on feature proposals.

This has brought out the C++ haters (5, Insightful)

MeridianOnTheLake (691931) | more than 8 years ago | (#14383711)

This has really brought out the C++ haters. Still, most commercial applications, games, utilities, OS's, etc are still written in C++ (or a combination of C and C++). There is a reason for this; it is because C++ is both incredibly effective and extremely efficient. Sure, its possible to create artificial benchmarks that prove otherwise, but in te real world where performance counts, people use C++. But when they want flexibility they go for Ruby or Python or something similar. If you want outstanding applications, you use an outstanding language like C++. If you want average applications, you use an average language like Java.

Re:This has brought out the C++ haters (2, Funny)

ultrabot (200914) | more than 8 years ago | (#14383779)

This has really brought out the C++ haters. Still, most commercial applications, games, utilities, OS's, etc are still written in C++ (or a combination of C and C++).

And the guys who write those apps are the very ones who hate C++.

You have to use C++ for a couple of years to truly, honestly hate the language.

Re:This has brought out the C++ haters (1, Interesting)

Decaff (42676) | more than 8 years ago | (#14383855)

Still, most commercial applications, games, utilities, OS's, etc are still written in C++ (or a combination of C and C++).

No, they aren't. C/C++ is still used for the widest range of applications, but in terms of numbers of commercial applications right now, Java dominates.

Sure, its possible to create artificial benchmarks that prove otherwise, but in te real world where performance counts, people use C++.

I'm afraid that is increasingly not the case anymore. For example, Boeing have requested that all new development is in Java, even for real-time mission-critical high-performance work. The reason they give is that Java is simply a more productive language to work with. You may not agree with them, but this is what is happening.

Lots of detractors here (4, Interesting)

Dante Shamest (813622) | more than 8 years ago | (#14383717)

But considering that lots of OSS projects like Firefox and KDE still use C++, not to mention commercial games like World of Warcraft, C++ probably does have some saving merits.

Re:Lots of detractors here (1)

Shillo (64681) | more than 8 years ago | (#14383925)

This is a surprise? C++ is what many of us use at work. Of course we hate it. :)

My wish-list for c++ (4, Insightful)

Eternal Annoyance (815010) | more than 8 years ago | (#14383718)

property keyword: Used that in object-pascal (the language sucks otherwise). Just define a read and write function, make a property which calls those functions and you can go ahead. Very simple in use (less bug prone), fast to implement and nice on the compiler. While you can achieve the same in c++ it's not as clean and friendly on the compiler.

interface and implementation (both are keywords, comes from pascal) section: lets get rid of seperate header and code files. The idea is aged, inefficient and doesn't help clarity nor ease of coding.

Bit-arrays: yesyes, I know. Boost contains a class which does that. But I think it would be so much nicer if the language had that feature.

Re:My wish-list for c++ (1)

mrsbrisby (60242) | more than 8 years ago | (#14383788)

Properties are worthless and good at hiding side effects.

Interface/Implementation split is good- Objective-C does that. Maybe you should consider that.

Bit arrays are dead simple in C, and boost::'s version is complicated as hell. What exactly did you have in mind?

Re:My wish-list for c++ (1)

masklinn (823351) | more than 8 years ago | (#14383915)

Properties are worthless and good at hiding side effects.

Properties are a tool, their main goal is to ensure a pure abstraction of the class interface (properties are virtual members, meaning that the outside of the object cannot know and doesn't care wether an attribute is "real" or "virtualized" and they're very good at that, and at allowing clean and straightforward construct with readable syntaxes.

As every tool (C++ operator overloading debacle), they can be abused, badly. That doesn't mean they're *bad*, no more than an oven is inherently bad just because you can burn babies alive in it.

Re:My wish-list for c++ (1)

markov_chain (202465) | more than 8 years ago | (#14383921)

interface and implementation (both are keywords, comes from pascal) section: lets get rid of seperate header and code files. The idea is aged, inefficient and doesn't help clarity nor ease of coding.

The only thing I agree about is that the idea is old :) Headers make things vastly more efficient when dealing with system libraries; it would be crazy to compile everything (Didn't Turbo Pascal split things up?). Further, putting an explicit line between interface and implementation helps both clarity and ease of coding.

the state of being advanced (1)

digitaldc (879047) | more than 8 years ago | (#14383725)

In my opinion, many people are trying too hard to be clever and advanced.

I was advanced once, but unfortunately it just left me waiting for everyone else to catch up.

Sigh (0, Flamebait)

nickos (91443) | more than 8 years ago | (#14383769)

Take a look at the some of the posts round here - sadly it looks like the typical Slashdot poster is pretty stupid these days :(

run-time compiling? (0)

slavik1337 (705019) | more than 8 years ago | (#14383775)

how about adding a run-time compile feature? how about being able to read in a string and use that as a variable name? (hash table with pointer/reference?)

Re:run-time compiling? (1)

xcham (200708) | more than 8 years ago | (#14383896)

Sure; let's add in closures, inline FORTRAN support and programmer mind-reading too.

Just get rid of it altogether (1, Interesting)

sillybilly (668960) | more than 8 years ago | (#14383787)

What I'd really like is a fully vertical programming environment that's more humane, lets me get to the bare metal if I want to, or be very lazy and high level, if I want to, it would do assembler, C, C++, and higher than C++ level, a set of languages where I know what each statement expands to in the lower level, where the compiler sort of holds my hand, and shows me what's going on, and I'd rather have a more plain english compiler output even if it's not optimized, or if it's optimized and difficult to follow the jumps, then a plain english description of why it's doing it. What happens when I write a statement and get a bug is too much behind the scenes for me, too much of a smoke and mirrors, too cryptic. I'm lazy and prefer writing programs the easy way, in very high level languages, say in basic, python and perl, unfortunately they lack performance because most are interpreted. There should be a way to do high level without interpretation, but instead compiling into lower level stuff, after all, instructions in one language should have a 1 to 1 matching of what happens in another language, or there could be such an optimized matching. If I was allowed to constantly inspect what each high level construct translates to in the lower level language that's still higher than assembler, in a human readable form, that could improve the overall performance and bug issues for all the levels of programming, because if there is a problem, a bug, the programmer could inspect and figure it out and submit patches. I find myself learning things mostly when I'm involved with a task at hand, if I didn't have a problem, I'd never learn about something. I'm sure most people are intelligent enough to figure things out if they really need to, but they have no transparent and easy way these days, it's all or nothing, C++ to straight assembler, and they are stuck with starting off writing a program in a difficult and low level language because that's all you can do - once you made choice and settled on a language, or even a set of libraries, you're stuck with it, and if you don't like the language code, you're welcome to look at the compiler output in assembler. I'd rather see some smoother transition layers, something that starts out very nonverbose and progressively gets more verbose and difficult as you go lower on the layers. Something that starts out as simply as drawing a few diagrams to generate some very high level code, almost in plain english, that a compiler translates into C++, that I can look at, and even see what C++ would translate into in C, and then C into assembler. Some Microchip PIC c compilers retain the original C code next to the assembler part, so it's readable what's going on. Even dotnet that's an interpreted language, that too can list the bytecode next to the original code. I'd like to see what happens, all the way to the bare metal. Yes compiling time would go up, but you could skip intermediate stages if you wanted to. One of the worst things these days is that there is no single programming environment where I can sit down and 'own' the computer, without working my ass off, unless I want to. An environment that debugs the speed of the code, shows you what happens where, what code consumes a lot of memory, what code portion took how many milliseconds to execute, and with this constant feedback, I could concentrate my efforts on the portions I'd like to concentrate on. You could have the 4 level layers called C-02, C-01, C+00, C+01, C+02, etc. C-02 equivalent to the architecture layer, C-01 to the C layer, C+00 to what currently C++ is, C+01 to something like basic or python, and C+02 to some diagramming software (like VB/VBA macro record or Visio or something similarly super-easy). You could then directly compile C+02 to C-02 if C+02 diagramming software is all you know, or go deeper in the in-between levels, depending on how much elbow-grease you'd like to put in and what your skill level is, you could go from C+02 to C+01 to C+00, each code expandable if it has a hand-coded equivalent, or just using the default implementation. There should be dialects in each layer, that can easily translate down one level, something like both pascal and C++ and fortran could go to C and to assembler. The verbosity should decide where each language belongs, you could have C+00 level Pascal or Basic, and C+02 level, depending on how windows-api-like they sound, how verbose they get. You'd have a huge amount of improvement at all levels of software simply because a million eyes developing a compiler would see more, just like a million users at wikipedia can do a lot of work that would cost huge money otherwise, but everyone pitching in a little bit is not too difficult, when you already got something to start with. At all these points you would have a proper software examiner that visualizes timing, memory consumption, reads/writes, because clock cycles matter, and ease of use matters, and you should be able to start out easy, and if the program grows, you could invest more time into tweaking it at lower levels, something written in say basic or python shouldn't have to be abandoned because it needs to be rewritten from scratch in something more proper. And you'd have a lot more programs if the initial prototype creation is very easy, and then you figure out what you really need as you go. I don't like mysteries, black boxes, I like to see assembler, but I'm too lazy to write in assembler. One of the biggest gripes with C++ is that it's too mysterious compared to C, the errors are too cryptic and abstract, C translates into asm equivalents a lot more clearly, while it's nowhere as easy as VB, where you click click, drag-drop and it works, who cares if it's not proper, but it works, and works means very much in a business world where a piece of software developed in 5 minutes is worth a lot more than one not developed at all therefore not working, because it would take 4 years dedicated education plus 3 months to even come up with a plan and a team to do it all, and by the time they get to it, the business has went through bankruptcy, merged and spun off itself 5 times, managers have been replaced 10 times, and whatever you started on is no longer applicable anyway, but you're still doing it, because nobody realized you are, and they forgot to tell you to stop. 5 minute diagram toss-together's have a lot of virtues if they fix a problem you have and they fix it now. And having something to start with to improve on is a lot easier than starting from scratch and having to program for 3 weeks nonstop fueled by the hope that at the end of 3 weeks, when you compile, the whole thing will miraculously work. It's a lot nicer when you can constantly look, and get feedback that yes, it worked when you diagrammed it, yes, it still works, oops, you made it faster but broke it there, why, let's figure out, okay, it works again. It's a lot more pleasant experience when you have the present feedback of success, compared to some future goal, and you'd have to pay programmer less if they enjoyed the whole experience, like chess players like playing chess, instead of being a programmer automatically meaning that you are a masochist who enjoys pain and suffering, because programming is so tortuos and mentally taxing. See http://en.wikipedia.org/wiki/Flow_%28psychology%29 [wikipedia.org] Speaking and language isn't tortuos, and most people can pretty accurately describe what they mean in english or other languages. Unfortunately the processor speaks 0's and 1's, does not speak the human languages, but there should be some more continuity and ease going from one extreme to the other, from human to machine, some smoother transition.

Re:Just get rid of it altogether (1)

ForeverFaithless (894809) | more than 8 years ago | (#14383812)

Dude, have you ever heard of text formatting?

Re:Just get rid of it altogether (1)

Slow Smurf (839532) | more than 8 years ago | (#14383832)

If you don't preview and use the default option, it removes line breaks that you may have seen in the comment box.

Re:Just get rid of it altogether (2, Funny)

Anonymous Coward | more than 8 years ago | (#14383920)

"Dude, have you ever heard of text formatting?"

As a die-hard C/C++ fan, he figures redundant whitespace will just compile out in the end.

The GUI. (2, Insightful)

nighty5 (615965) | more than 8 years ago | (#14383798)

I was pleased to notice that Bjarne Stroustrup has acknowledged that they won't be pursuing to include a GUI framework into the new C++ standard.

Although this might be considered a disappointment, his citing the fact of low resources, time and money are best spent in other areas. Lets get something out the door that we can use now instead of waiting for the GUI. I'm no C++ expert, as a matter of fact I'm only into about 400 pages of my first teaching book ;)

Nobody will deny the power of some of the C++ GUI's out there, QT is probably best of breed. Its probably good to have commerical interest in the GUI space, since the desktop is forever evolving faster than a C++ committee could handle.

Re:The GUI. (2, Interesting)

ObsessiveMathsFreak (773371) | more than 8 years ago | (#14383858)

Nobody will deny the power of some of the C++ GUI's out there, QT is probably best of breed.

Using a procedural, compiled programming languague for GUI's is a fundamentally flawed concept to begin with. If you want to create a user interface, just use HTML, XUL, XAML whatever. 300+ lines of Visual C++ code just to display hello world is indicative of an underlying problem.

Re:The GUI. (3, Insightful)

trollable (928694) | more than 8 years ago | (#14383933)

300+ lines of Visual C++

If you're right, WTF would you want to use a MS product? You can do a hello world in C++ with just 3 lines (TUI) or 12 (GUI with QT).

Concerning XML-based GUI descriptors, it is in general not smaller. It is smaller to define and place the components but things goes wrong when you have to manage events. In fact, from my experience, a GUI in HTML+JS, C++/QT and Java/Swing has more or less the same number of SLOC.

C++ template concepts vs. C# generics constraints (2, Informative)

dalleboy (539331) | more than 8 years ago | (#14383806)

The difficulty in the design of "concept" is to maintain the flexibility of templates so that we don't require template arguments to fit into class hierarchies or require all operations to be accessed through virtual functions (as for Java and C# generics). In "generics", an argument must be of a class derived from an interface (the C++ equivalent to "interface" is "abstract class") specified in the definition of the generic. That means that all generic argument types must fit into a hierarchy. That takes foresight. For example, if you write a generic and I define a class, people can't use my class as an argument to your generic unless I knew about the interface you specified and had derived my class from it. That's rigid.

C++ template concepts are no better (or worse for that matter) than C# generics constraints, they only bind differently: C++ binds to a name, C# binds to an interface. Both are equally rigid. Both require foresight. In C++ you don't have to derive your class from a specific interface, but on the other hand you still need to implement the function knowing what name it will be accessed through (i.e. should it be named begin or Begin or GetBegin).

Re:C++ template concepts vs. C# generics constrain (1)

Rakshasa Taisab (244699) | more than 8 years ago | (#14383892)

I think you have missed, or underestimated the effects, of having to pre-define the interface rather than just using it. In C++ you just write the template code, in C# you need to have an interface defined. How many do you think get a bit lazy and use a more generic interface that includes constraints not nessesarily used in the specific function call?

Threads Cannot be Implemented as a Library (3, Interesting)

putko (753330) | more than 8 years ago | (#14383813)

It is good for a language to have threads "built in". As mentioned in this paper, "Threads Cannot Be Implemented as a Library": http://www.hpl.hp.com/techreports/2004/HPL-2004-20 9.pdf [hp.com]

if you do threads in a library, you run into problems with semantics or performance. Semantic problems == compiler breaks your multithreaded program. Performance problmes == compiler does naive translation of program, terrible performance.

Bjarney the Dinosaur (0)

Anonymous Coward | more than 8 years ago | (#14383817)

Hi Guys.

The rumours are true. I have been bored, so I thought you should all rearrange your furniture.

I've decided to change { } for the more traditional begin-end. Don't worry. In the next version after this version I will change it to something else.

I've also decided to change streams again. This time three functions will not be supported. You guess which three!

I thought I might add some new namespaces. You will now have to prefix every reserved word with BjarneIsCool. For example, BjarneIsCool::for (BjarneIsCool::i=0; i10; i++).

I've also decided to make "i" a reserved word. Global Search and Replace is your friend!

Yeah, I know some of you might be cursing me for this, but on the bright side, unlike those poor COBOL-Y2K programmers, I *am* keeping you all employed.

Your BjarneIsCool::friend,
Bjarne!

Re:Bjarney the Dinosaur (0)

ObsessiveMathsFreak (773371) | more than 8 years ago | (#14383885)

I've also decided to change streams again. This time three functions will not be supported. You guess which three!

Hah! Hoisted by your own petard Stroustrup!! Your creation turns against you! It's now an easy matter to implement legacy_io::cin , legacy_io::cout , legacy_io::cerr and still pass their references in a void pointer array!! Haha!
Load More Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

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>
Sign up for Slashdot Newsletters
Create a Slashdot Account

Loading...