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!

ISO C++ Committee Approves C++0x Final Draft

Soulskill posted more than 3 years ago | from the and-so-quickly dept.

Programming 375

Randyll writes "On the 25th, in Madrid, Spain, the ISO C++ committee approved a Final Draft International Standard (FDIS) for the C++ programming language. This means that the proposed changes to the new standard so far known as C++0x are now final. The finalization of the standard itself, i.e. updating the working draft and transmitting the final draft to ITTF, is due to be completed during the summer, after which the standard is going to be published, to be known as C++ 2011. With the previous ISO C++ standard dating back to 2003 and C++0x having been for over eight years in development, the implementation of the standard is already well underway in the GCC and Visual C++ compilers. Bjarne Stroustrup, the creator of C++, maintains a handy FAQ of the new standard."

cancel ×

375 comments

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

Yay for C++'0B (1, Redundant)

sabre (79070) | more than 3 years ago | (#35624506)

Enough said!

-Chris

Re:Yay for C++'0B (1)

JAlexoi (1085785) | more than 3 years ago | (#35624670)

And soon enough, just in 2021 we will have the C++1x.
WTF People?! Rename it already!.. The 201th decade is over, 202 is here!

Question (-1, Troll)

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

Given that C++ is to C as cancer is to lung. Does this new standard constitute an advanced and terminal stage?

Re:Question (4, Insightful)

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

As someone who has written software using GObject, FUCK YOU.

Re:Question (1, Insightful)

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

If C++ is cancer to C's something, that something is also cancer. Or maybe AIDS.

I have a love-hate relationship with C++, but one thing that I more-on-less don't waver on is the fact that I would much rather write in C++ than in C for... basically anything.

Re:Question (3, Interesting)

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

I think you can easily determine the competence of any programmer by how much they hate their primary language. I've never seen this rule fail when it comes to C++. Almost every expert modern C++ programmer I've met thinks C++ is unsurpassed in a few important areas - yet they can bitch about the language for as long as you keep them talking.

Re:Question (-1)

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

+5 Insightful AND Funny!

The first guy to put a pretty face on machine code is the winner. This stuff here is for children. Unfortunately, as the world can see, it leads to bad habits, and nothing about how the machine works is learned. If you people can't deal, keep your busboy job at the Brown Derby...

sigh (0)

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

My collection of C++ books from Addison Wesley (who has apparently cornered the market for C++ books above intro level) has just become obsolete. Most likely new editions for most of them will be coming out over the next couple years.

Re:sigh (1)

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

They aren't obselete yet. There's probably another year or two before you can expect the latest version of MSVC to have support for most of the features (and that's if they even get it into the next version!), and a couple years after that (depending on your taste) before you are likely to be able to reasonably demand "you must use a compiler that supports C++0x."

The situation in GCC-land is better because they've been more on-the-ball with releasing support for the new features, but even they have a way to go yet (4.6, released yesterday, just added support for 3 new features including nullptr), and you don't have to go too far back before there's basically no support.

Re:sigh (1)

shutdown -p now (807394) | more than 3 years ago | (#35624812)

There's probably another year or two before you can expect the latest version of MSVC to have support for most of the features (and that's if they even get it into the next version!)

There are already quite enough C++0x features in VC++2010 to invalidate a lot of old techniques and rules: it has lambdas, rvalue references, and decltype/auto. Lambdas make STL much more attractive to use, so you're going to see more of that (but that should be covered well by existing books, and lambdas themselves are easy to understand). But rvalue references and decltype open a whole new dimension for generic code and template metaprogramming. Combined with new rules for SFINAE, you can now make substitution failures on pretty much any expression - which is a very messy but working way to get "contracts" (and combine with static_assert for good error messages).

Don't forget also that it's more than the language alone, it's also the library. All the new threading stuff is big deal.

Like a zombie (3, Insightful)

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

C++ just keeps on going, eating the brains out of anyone who dares to use it. When template metaprogramming was invented, the language should have been internationally banned by treaty. Now with lambdas, garbage collection, rvalue references, and a host of other features, C++ should be officially classed as a Weapon of Mass Destruction.

Re:Like a zombie (0)

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

Garbage collection? Did I miss something?

Also BRAAAIIIINNNNSSSSSSSS

Re:Like a zombie (0)

JAlexoi (1085785) | more than 3 years ago | (#35624680)

See... Buffer overflow is still there or is it properly uninitialized char**? GC is probably from something else.

Re:Like a zombie (1)

d6 (1944790) | more than 3 years ago | (#35625244)

you know, for the folks that never understood what a memory leak is.

next version, we get rid of pointers :P

Re:Like a zombie (1)

turgid (580780) | more than 3 years ago | (#35624744)

C++ should be officially classed as a Weapon of Mass Destruction

It's also a Cruel and Unusual Punishment for those of us who try to earn a living writing code.

Re:Like a zombie (0)

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

Just because a language has incomprehensible features doesn't mean you have to use them. C++ may give you enough rope to hang yourself, but you are the one putting your head in the noose.

Re:Like a zombie (1)

MichaelSmith (789609) | more than 3 years ago | (#35625046)

C++ may give you enough rope to hang yourself, but you are the one putting your head in the noose.

Not if you work for a large software company. Some idiot could use c++ to write incomprehensible code, then leave or be sacked. You get the job of maintaining the ever so clever rubbish he left behind.

Re:Like a zombie (0)

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

Not if you work for a large software company. Some idiot could use c++ to write incomprehensible code, then leave or be sacked. You get the job of maintaining the ever so clever rubbish he left behind.

For you guys that think C++ is hard or incomprehensible, please, for the good of mankind, change your line of work. You're not worthy of calling yourselves programmers.

Re:Like a zombie (1)

shutdown -p now (807394) | more than 3 years ago | (#35624828)

Now with lambdas, garbage collection, rvalue references, and a host of other features, C++ should be officially classed as a Weapon of Mass Destruction.

That's why C++ is so awesome - it's a WMD that can be wielded by a single man. Granted, this gives the whole new meaning to the expression "shoot your own foot", but once you get past that, you can shoot so many other things in very spectacular way!

I only hope that user-defined literals are still in (there was a proposal to take them out). ~

None of your business! (4, Insightful)

Chemisor (97276) | more than 3 years ago | (#35624882)

Yes, you hate C++. We get it. Instead of complaining about it so much, just don't use it, stick to your own favorite language, whatever it may be, and leave C++ alone. There are plenty of us who love C++ and wouldn't give it up for anything. We mind our own business, write great code, and try to avoid complaining about whatever it is you are using. Please try to do the same.

Re:None of your business! (1)

betterunixthanunix (980855) | more than 3 years ago | (#35624938)

The problem is that C++ dominates the industry; people who want to use a different language, even when they can list every good reason for making that decision, often find that the pressure to stick with C++ is too much to overcome. A lot of people simply refuse to hear the arguments about better languages for a particular project, or are afraid of being unable to find programmers who know something that is not C++ (or similar enough, like Java), or do not want to have to write interfaces for an existing C++ codebase.

Re:None of your business! (0)

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

leave C++ alone.

Oww. Wrong mental image.

Re:None of your business! (3, Funny)

mfnickster (182520) | more than 3 years ago | (#35625082)

How fucking dare anyone out there make fun of C++ after all it has been through!?

What you don't realize is that C++ is making you all this money, and all you do is write a bunch of crap about it!

Leave Bjarne alone!! You're lucky he even publishes an FAQ for you BASTARDS!!

Speaking of professionalism, since when is it professional to publicly bash a language whose standard is going through a hard time?

Anyone that has a problem with C++ you deal with ME, because it's not well right now!

Re:Like a zombie (5, Informative)

Zandamesh (1689334) | more than 3 years ago | (#35624900)

C++ just keeps on going, eating the brains out of anyone who dares to use it. When template metaprogramming was invented, the language should have been internationally banned by treaty. Now with lambdas, garbage collection, rvalue references, and a host of other features, C++ should be officially classed as a Weapon of Mass Destruction.

It's because there isn't a good replacement for it. The only programming language that I know of that _really_ replaces C++ is D, I did a bit of research on it a while ago, it's great. Better than the C++ language in almost every aspect. But D has problems as well, just not in the language design department. There is no working D IDE, you can't find a lot about it online, the language has not 100% stabilized yet, only has backwards compatibility with C, and many other things that we take for granted in the C++ language.

Anyway, what I'm trying to say is that D is a well designed language that could potentially replace C++ better than any other language.

Re:Like a zombie (1)

euroq (1818100) | more than 3 years ago | (#35625038)

So glad to hear that some people actually know about D! D is great. This new C++0x crap is awful:

        template
        class tuple
                : private tuple { // here is the recursion // Basically, a tuple stores its head (first (type/value) pair // and derives from the tuple of its tail (the rest ofthe (type/value) pairs. // Note that the type is encoded in the type, not stored as data
                typedef tuple inherited;
        public:
                tuple() { } // default: the empty tuple // Construct tuple from separate arguments:
                tuple(typename add_const_reference::type v, typename add_const_reference::type... vtail)
                        : m_head(v), inherited(vtail...) { } // Construct tuple from another tuple:
                template
                tuple(const tuple& other)
                : m_head(other.head()), inherited(other.tail()) { }

                template
                tuple& operator=(const tuple& other) // assignment
                {
                        m_head = other.head();
                        tail() = other.tail();
                        return *this;
                }

                typename add_reference::type head() { return m_head; }
                typename add_reference::type head() const { return m_head; }

                inherited& tail() { return *this; }
                const inherited& tail() const { return *this; }
        protected:
                Head m_head;
        }

        tuple tt("hello",{1,2,3,4},1.2);
        string h = tt.head(); // "hello"
        tuple,double> t2 = tt.tail(); // {{1,2,3,4},1.2};

D does a marvelous job fixing the syntax and the shortcomings of C++. Also, there's NO PREPROCESSOR! (Before you jump on this, there is nothing you can't do in D that you could do with a C preprocessor) Also, there is an environment for D in Eclipse.

Re:Like a zombie (0)

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

Next time run a replace-search on your code substituting < with &lt; and > with &gt;. Actually, it's better to use a website like pastebin [anonymouse.org] .

Re:Like a zombie (1)

the linux geek (799780) | more than 3 years ago | (#35625118)

Too bad the D development process is screwed up. 1.x was never really finished/stabilized, there's no community consensus on standard library, and 2.x appears to be going nowhere good.

dnf and C++0x in same year? (0)

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

...faints...

Re:dnf and C++0x in same year? (0)

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

Maybe the DNF devs were waiting for C++0x so they could clean up some spaghetti code. Once Linux Desktop achieves 10 percent market penetration they'll be able to secure the funding they need to ship.

That's what C++0x means (1)

pavon (30274) | more than 3 years ago | (#35624614)

I've been reading about C++0x for years now, and never realized that the 0x referred to a new revision of C++ to be released in 200X, until I just now saw the FAQ entry about C++1x. I assumed it was some odd inside reference to hex number prefix that I just didn't get. I thought the Y2K bug incident had purged everyone who didn't use full dates :)

Re:That's what C++0x means (0)

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

To discover the meaning of stuff like this on your own, you can try potential explanations in your head until you find one that seems right.

Looks like in this case you are able to recognise that "C++ to be released in 200X" is a good explanation when you see it, but the problem was that you couldn't imagine it in the first place. I suggest that from now on you think more and imagine more. Many other discoveries await you!

C'mon Python Users tell us why (-1)

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

C++ is bad, not easy to program and inferiour to C#, Java and of course Python.

Re:C'mon Python Users tell us why (1, Insightful)

binarylarry (1338699) | more than 3 years ago | (#35624682)

Even naive C++ is much, much, much faster than Python and is even capable of supporting multiple threads.

It's much faster than C# and slightly faster than Java code as well.

Re:C'mon Python Users tell us why (1)

chichilalescu (1647065) | more than 3 years ago | (#35624748)

I cheat. I write python code that writes its own plain C code, compiles it then executes it. this way, I work once to write a C template, that I then reuse through a high level language. and when I combine the advantages of python (sympy for instance) with the speed of C, I get stuff that is ridiculously faster than what I did before. in the sense that I don't work a lot to write it, and I don't wait around a lot for it to actually run afterwards.
working with numerical simulations, I'm allowed to cheat this way...

Re:C'mon Python Users tell us why (1)

binarylarry (1338699) | more than 3 years ago | (#35624842)

So basically, you get around Python's performance limitations... by using C instead.

Way to go!

Re:C'mon Python Users tell us why (1)

Lord Crc (151920) | more than 3 years ago | (#35625254)

So basically, you get around Python's performance limitations... by using C instead.

It's a very nice idea which brings the best of both worlds. FEniCS [fenicsproject.org] , an open-source finite element framework , uses pretty much the same technique to allow one to set up the simulation in Python, yet get the speed of hand-optimized C++ code.

And using Python capabilities one can write code which is much closer to the underlying math, which significantly improves the usability. Here's the core of an example [fenicsproject.org] using FEniCS:

V = FunctionSpace(mesh, 'CG', 1)
 
# Define variational problem
v = TestFunction(V)
u = TrialFunction(V)
f = Constant(-6.0)
a = inner(grad(u), grad(v))*dx
L = f*v*dx
 
# Compute solution
problem = VariationalProblem(a, L, bc)
u = problem.solve()

When calling solve() the problem is converted to C++ code, compiled as a module, imported and executed, all on the fly. The C++ generator can optimize for special cases, for example in the code above it knows that "f" is a constant function.

Why treat everything as a nail when you don't have to?

Re:C'mon Python Users tell us why (0)

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

>Python

You spelled "Lisp" wrong.

Re:C'mon Python Users tell us why (-1)

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

I fart in your general direction!

My first question. (1, Interesting)

140Mandak262Jamuna (970587) | more than 3 years ago | (#35624658)

Will they resolve the question of std::list::size() function's speed? It is constant O(1) in Visual C++ implementation. In gcc people are arguing over fine distinctions between "shall" and "will" or something equally esoteric. As it stands in Linux it is Order(N). I am not kidding. My code was scaling fine in Visual C++ going form 10 elements to 10 million elements in a nice predictable N*Log(N) curve. It was frustrating to debug the scaling loss in Linux and to finally realize, the root cause of the trouble was the break conditional evaluation in the for loop. And everyone is refusing to fix the damn thing for six years. We were paying maintenance to RedHat. And they were also giving us the lawyer talk instead a fix.

Ref: http://gcc.gnu.org/ml/libstdc++/2005-11/msg00219.html [gnu.org]

Re:My first question. (4, Insightful)

PhrostyMcByte (589271) | more than 3 years ago | (#35624730)

There was nothing for RedHat to fix -- you were relying on undefined behavior. list's size() complexity is still undefined in C++0x. You're expected to use iterators and empty() when you want defined complexity.

Re:My first question. (0)

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

From SGI's doc:

size_type size() const

Returns the size of the list. Note: you should not assume that this function is constant time. It is permitted to be O(N), where N is the number of elements in the list. If you wish to test whether a list is empty, you should write L.empty() rather than L.size() == 0.

------------------
I agree with you though, O(N) does seem kinda brain dead. Obviously, an implementation of a list needs a header in order to support methods like back() and push_back().

This is what happens with standardization committees. Some compiler vendor insists that they do it some crazy assed way, have always done it that way and they have hundreds of paying customers, so everyone has to live with a suboptimal spec.

Re:My first question. (1)

shutdown -p now (807394) | more than 3 years ago | (#35624836)

SGI docs do not represent the Standard, however.

Re:My first question. (4, Interesting)

insane_coder (1027926) | more than 3 years ago | (#35625004)

See Effective STL Item 5. If size() is constant, then splice() must be implemented in a slower manner. Therefore, whether size() for std::list is constant or not depends on whether you want a fast or slow splice(), and that's up to the implementation. So conversely, you'll see that splice() in Visual C++ is quite slow.

Re:My first question. (1)

insane_coder (1027926) | more than 3 years ago | (#35625240)

Er sorry, meant to say Item 4.

Re:My first question. (0)

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

Well, it's a list. If all the elements are the same size then it's trivial to track insertions and deletions with a single member variable. The size function is just m_elements*element_size().

If the list is heterogeneous, then I suppose you could track the size of each element on insertion and deletion. You'd have to track the size of the list as well as the number of elements. Then it's still O(1) to get the size of the list.

You pay the penalty of two integers in each list when you do this. If the lists are being used to form a tree with a lot of branches, perhaps this penalty matters.

In a classic list, you just have to traverse each element and add stuff. As always, it's a tradeoff. If you don't mind extra memory for each list object, and O(1) size matters to you, then it shouldn't be too much work to subclass the list, override insert, delete, and any other function that mods the list.

So. Not knowing much more than that, and having only skimmed the discussion you linked I think that perhaps having a simple list that requires O(N) size lookup isn't so bad. The Microsoft implementation covers the more common case but if the size of the list object itself matters to you, then how do you get rid of the tracking members which presumeably exist in each Microsoft list object?

Re:My first question. (1)

Rockoon (1252108) | more than 3 years ago | (#35624970)

Here we are talking about wasting one more machine word per list for performance reasons, in a structure that wastes two machine words per list element for performance reasons.

size() should not be a member of std::list at all if the O(n) crowd is to be listened to, for its inclusion is then only a trap to be fallen into.

Re:My first question. (0)

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

Well, it's a list. If all the elements are the same size then it's trivial to track insertions and deletions with a single member variable. The size function is just m_elements*element_size().

If the list is heterogeneous, then I suppose you could track the size of each element on insertion and deletion. You'd have to track the size of the list as well as the number of elements. Then it's still O(1) to get the size of the list.

I would say the obvious result would be element count in the list and not sum of sizes of each element (did not check official description).

Yes, count() would make it more obvious what size() means but in case of std::list, you only have one type of elements so it's a matter semantics mostly.

My worthless opinion if anyone cares..

Re:My first question. (1)

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

The reason behind is easy. When one use a lnked list, one usually does not need to know its size frequently. Therefore counting the number of element is pretty much redundant and a performance hog in most application.

If you really need to know the size of the list, then you can do the accounting manually. It is not hard at all to do.

I am personnally very happy that std::list does not know its size. Because I never need this information and I would hate having to rewrite list just to kick the accounting out.

I understand your experience was frustrating, but most porting operation leads to stupid bugs or behavior like that.

Re:My first question. (1)

shutdown -p now (807394) | more than 3 years ago | (#35624908)

Actually, the reason why size() is O(N) in gcc is because, if you have a counter in the list itself, then splicing [microsoft.com] the tail of another list into yours becomes an O(n) operation (because you need to count how many elements are there to splice to update the counter). Thus, you either have O(1) size(), or O(1) splice(), but not both. VC and gcc had different ideas about which one of those operations is more common.

Having the counter itself is hardly a space or performance hog, especially given that std::list is a doubly linked list, but is actually used where a singly linked one would do in the majority of cases in C++ programs (since C++03 didn't offer a singly linked list container; now we hve std::forward_list in C++0x). Keeping those back pointers around and updating them is much more of a hog than a single counter.

Anyway, in my opinion the strongest argument in favor of O(1) size() is that all other containers are O(1). Thus generic code can reliably use it regardless of type of container.

Re:My first question. (1)

Rockoon (1252108) | more than 3 years ago | (#35625022)

When one use a lnked list, one usually does not need to know its size frequently. Therefore counting the number of element is pretty much redundant and a performance hog in most application.

The implementation is a doubly linked list. Setting a backwards pointer on every element is pretty much redundant and a performance hog in most applications, that only iterate forwards.

Re:My first question. (1)

mmcuh (1088773) | more than 3 years ago | (#35625210)

If that's an issue it's an issue with the specification, not the implementation. std::list is specified to have bidirectional iterators, and you can't get those without backward links.

Re:My first question. (1)

MichaelSmith (789609) | more than 3 years ago | (#35625110)

most porting operation leads to stupid bugs or behavior like that.

Who ports these days? Java is more portable by virtue of the VM. C is more portable by virtue of its simplicity.

Re:My first question. (1)

betterunixthanunix (980855) | more than 3 years ago | (#35624782)

Do not rely on undefined behavior, and these things will not be a problem.

Re:My first question. (1)

joesteeve (2002048) | more than 3 years ago | (#35624902)

Yay.. I am not the only one who got bit by this one. :)

I had assumed that std::list::size() was O(1) .. Was 'enlightened' when, two threads jumping around a container segfaulted, costing me a couple of sleepless nights.

I agree to "sticking with the standard".

Re:My first question. (0)

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

two threads jumping around a container segfaulted, costing me a couple of sleepless nights.

If misinterpreting a complexity guarantee caused your program to segfault, you had more problems than just performance.

I agree to "sticking with the standard".

The standard says empty() is constant time, whereas size() "should be" constant time. There is clearly some wiggle room. That said, the splice() method that libstdc++ does in constant time is allowed to be linear.

The GCC folks are technically "sticking with the standard" even if they've failed to follow the principle of least surprise.

Re:My first question. (0)

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

And this is why code re-use is not always a good thing.

This is exactly why you'll look at the source code to any of John Carmack's games and notice he re-invented the wheel (for things like data structures, common algorithms, etc) for a very good reason, rarely using anything from the C standard library and never using the STL. More control.

Re:My first question. (3, Interesting)

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

std::list::size() is O(N) because making it O(1) makes splice O(N).

Re:My first question. (1)

Just Some Guy (3352) | more than 3 years ago | (#35625206)

Leaping into the middle of the conversation: why? It seems like you could implement caching logic like:

  1. Initialize lists with size=0 and known_size=true.
  2. When adding elements, if known_size=true, size+=1.
  3. When size() is called, if known_size==true, return size. Else, set size=countedsize() and set known_size=true.
  4. When splice() is called, set known_size=false.

Voila. size() is O(1) almost always, except immediately after a splice(). In the worst case, it'd be O(n) immediately after a splice(), but only the first time - and then it'd revert to O(1) behavior.

Why wouldn't that work?

Re:My first question. (4, Insightful)

shutdown -p now (807394) | more than 3 years ago | (#35624932)

Will they resolve the question of std::list::size() function's speed?

Yes. From the most recent C++0x FCD, 23.l2.1[container.requirements.general] table:

Expression: a.size()
Return type: size_type
Operational semantics: distance(a.begin(), a.end())
Assertion/note pre-/post-condition: -
Complexity: constant

Re:My first question. (1)

PhrostyMcByte (589271) | more than 3 years ago | (#35625042)

Cool! I wonder when that was introduced, I didn't catch it.

Re:My first question. (2)

shutdown -p now (807394) | more than 3 years ago | (#35625156)

Seems to be N2909 [open-std.org] , revised as N2923 [open-std.org] , and voted into the draft [open-std.org] in July 2009.

On a side note, the new std::forward_list does not have size() at all, so for those scenarios where having size is superfluous (either because you don't want to pay the overhead of an extra size_t for an empty list, or because you want to splice ranges), you can use forward_list for best performance.

Re:My first question. (0)

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

If you're doing cross platform support use STLPort instead of your compiler's implementation. And STLPort outperforms Visual Studio 2010's implementation in our application, so that is a nice benefit too!

Thank you Bjarne (2)

whiteboy86 (1930018) | more than 3 years ago | (#35624738)

Nothing comes close to C++ in terms of versatility, features, speed and overall professional appeal.

Re:Thank you Bjarne (3, Interesting)

betterunixthanunix (980855) | more than 3 years ago | (#35624800)

I would say that Common Lisp, with a decent compiler and some attention paid to code efficiency, is most certainly a contender on all of the above. The main selling point of C++ now is habit -- large amounts of existing C++ code and lots of programmers who were trained to use C++.

Re:Thank you Bjarne (0)

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

Professional appeal? Lisp? Yeah sure.

Re:Thank you Bjarne (0)

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

Except Common Lisp is a fucking pain with completely ass-backward syntax. It should die a swift death.

Bravo! (0)

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

Nothing comes close to C++ in terms of versatility, features, speed and overall professional appeal.

The way you put that, the uneducated reader may have mistaken it for a compliment.

Clearly... (-1, Troll)

giuseppemag (1100721) | more than 3 years ago | (#35624746)

...it's not dead yet!

What a pity. So many interesting modern languages to choose from and still people are working on this mismatched fossil.

Re:Clearly... (1)

Chemisor (97276) | more than 3 years ago | (#35624910)

Clearly we see something about it you don't. You are welcome to love your "interesting modern languages", while we love our C++. We certainly have no obligation to help you with yours.

Re:Clearly... (0)

giuseppemag (1100721) | more than 3 years ago | (#35625060)

Yes, because the world needs more segmentation faults. And BTW I have been forced many times to use C++ in my work. I know a shitload about it, especially the various tricks about the template system; the removal of concepts from the standard proves that C++ is, has always been, and will always been a mismatched bunch of tricks held together with duct tape.

Of course you are entitled to your opinion; I know many great programs/programmers exclusively made/working with C++, so I am not implying that the language forces bad programs or diseducates developers. Unfortunately I believe that the absence of a clean idiomatic C++, the proliferation of more or less incompatible coding styles, the confusing compatibility with C (C++ is often used as "C with classes") and the excessively small standard library (I believe that anything found in Boost should never be removed from the language) make C++ an ugly creature. Once again, though, great and fast programs have been made with it, so I understand how many developers might love the feeling of power and control that C++ gives with respect to safer but more constrained languages such as C# or Java or even further ML or Haskell...

New C++ spec.... (1)

kmdrtako (1971832) | more than 3 years ago | (#35624776)

TL;DNR

C++ has had its day (-1, Flamebait)

turgid (580780) | more than 3 years ago | (#35624788)

C++ was one of those languages that needed to come about if only for the industry to see, out of all of the "great ideas" what would work and wouldn't in practice.

C++ continues to mushroom, becoming ever more cumbersome. In the mean time, simpler (and arguably better) languages have come (and gone).

It's time to move on.

Re:C++ has had its day (1)

msobkow (48369) | more than 3 years ago | (#35624858)

Actually I'm looking forward to re-learning C++ after GCC et. al. are updated and the spec is finalized. They've added a great deal to the standard libraries, the syntax, and the collections/containers since I last worked with C++. I've no need for C++ -- it's just something I want to do for fun.

Re:C++ has had its day (0)

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

Please do tell which languages do you believe are "simpler (and arguably better" than C++.

Re:C++ has had its day (1)

turgid (580780) | more than 3 years ago | (#35624934)

Scheme, Java, Ruby, Python, D, C.

I can't understand why anyone would start a new project in C++. The only reason anyone could seriously consider it is if they have to maintain or enhance an existing C++ code base.

Re:C++ has had its day (1)

betterunixthanunix (980855) | more than 3 years ago | (#35625036)

I can't understand why anyone would start a new project in C++. The only reason anyone could seriously consider it is if they have to maintain or enhance an existing C++ code base.

While I agree with the sentiment, the reason people keep using C++ is pretty clear: habit. Everyone knows C++ or some very similar language, there is a lot of legacy C++ code, and people are still being trained to write code in C++ (or some similar language). If you were starting a new project and you said, "Let's use Scheme," half the people in the meeting would say they had never written a single Scheme program, and that they did not have time to learn it, and that it would be easier to just use C++ (or something similar). You could list every technical advantage that Scheme has over C++ and it would not make any difference.

Do not underestimate the friction that you face when it comes to C++ and similar languages.

Re:C++ has had its day (1)

turgid (580780) | more than 3 years ago | (#35625122)

Do not underestimate the friction that you face when it comes to C++ and similar languages.

I was in exactly this situation this week on a training course where we had ~12 hours to do an entire project.

We had 1 non-programmer on the team (of 6), one "software architect" and the other 4 of us were "software engineers." 4 of them wanted to use C++. I convinced them to do it in bash. Only one had sort of done some bourne shell a long time ago.

We got it done, and it worked. If we'd done it in C++ I dare say we'd still have been struggling to get it to compile by the deadline.

I organised things and coached them. They were impressed, and very surprised at how simple it turned out.

Re:C++ has had its day (1)

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

Just to play devil's advocate, I'd like to argue for C++ a bit. I don't completely buy my arguments here, but at the same time, I don't think it's ridiculous to use C++ for some stuff, and for some rare projects, it's a decidedly reasonable choice.

C++ sits in an area that is reasonably unique amongst languages. It is very performant (unlike Scheme, Ruby, and Python), but it also has an ability to support very rich abstractions (unlike Java and C). What other language doesn't not give you closures, but yet gives you enough syntax to make an approximation that is even as close as, say, boost::lambda? There's no reference counting provided by the C++ runtime, but it gives you enough tools that you can build your own reference counting.

There are very few languages that can claim both the speed and flexibility of C++. The only one that would be familiar to most programmers is D -- and the tool support there is not exactly stellar. About the only other languages I would say has characteristics comparable to those are Common Lisp and Haskell.

As a final point, I find it interesting that you put C into your list. If you said "I want you to do this project, and you can pick between Java and C++" or "between Python and C++" I'd have to ask for more details first, and think about it. I think I disagree with a lot of people on this point, but if you gave said "you have the choice between C and C++", I'd pick C++ in an instant with almost no qualifications. Yes, C is simpler than C++ -- but I don't think it's worth it. RAII alone is enough of a killer feature to mean that I will likely never choose plain C for any project where I have any freedom in the matter.

Re:C++ has had its day (1)

turgid (580780) | more than 3 years ago | (#35625180)

C++ sits in an area that is reasonably unique amongst languages. It is very performant (unlike Scheme, Ruby, and Python), but it also has an ability to support very rich abstractions (unlike Java and C).

True, but it hasn't been done at all well in C++. That's why I said that C++ had to happen so that people could see which ideas would work and which wouldn't.

I'm not at all convinced by these arguments. I'd much rather write performance-critical code in something like C, and the clever stuff in a much higher language.

For a trivial and contrived example, I get a lot done on my personal projects in C and bash.

I've used PERL, looked at scheme, python and ruby. I've done a bit of Java, and for quickly hacking together OOP stuff, I love it. It's so easy, it's wonderful.

I've had to learn a lot about C++ for my work. Luckily, I only have to use it mostly for writing unit tests, but some of our code base is in (not very pretty) C++ hacked together in a hurry.

Sometime soon I will try writing some D. I've done some background reading, and I really like what I see so far.

Your devil's advocacy is dutifully acknowleged.

Re:C++ has had its day (1)

euroq (1818100) | more than 3 years ago | (#35625100)

Agree 100% with your post.

Although technically you simply cannot do many types of programming projects with most of those languages because they are not systems-level like C/C++ are. So one may argue that those languages can't be compared to C++... except for one: D, a vastly superior language to C++ and which is also systems-level.

Re:C++ has had its day (0)

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

If you were writing an triple-A game from scratch, including a new game engine and tools and targeting multiple platforms, the most likely language would be C++. Garbage collected bytecode languages are too slow, while C does not provide adequate support for programming in the large.

Re:C++ has had its day (1)

gmueckl (950314) | more than 3 years ago | (#35625238)

Neither Java, Ruby nor Python are true contenders to C++ when it ever comes down to raw performance. They are surely more elegantly designed languages, although they have their own sets of flaws. D is an interesting language with many good ideas, but there's no decent IDE support for it and there's the standard library confusion as well (and the incompatibilities between D1 and D2). Once compilers like GDC are mature enough it'll actually be usable for serious work.

Well, C is sort of fine if you stick to really procedural code and don't do things like reinventing OO like gtk+ does (I hate that). And I really can't say anything about Scheme.

Bottom line; There's a place for C++ in between all of these languages you name: C++ programs can be amazingly fast if done right (no virtual machine and more importantly, no GC getting in the way at exactly the wrong time) and easier to get right than equivalent C programs if you're able to sacrifice some performance - you're able to do that in 90% of your code on average).

Re:C++ has had its day (1)

Daniel Phillips (238627) | more than 3 years ago | (#35625096)

Almost any computer language is simpler than C++. If you don't know that, you haven't explored it much. As for better... well I have switched pretty much exclusively to C++ now. Love, hate.

Re:C++ has had its day (0)

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

You're right. Like back to C or pure assembler.

Re:C++ has had its day (1)

turgid (580780) | more than 3 years ago | (#35625058)

You're right. Like back to C or pure assembler.

Indeed. There's so much you can do with well-written C and good libraries quicker, more reliably, more simply and much more efficiently than in C++.

With C you have a chance of being able to read and understand your source code 6 months after you wrote it. The syntax is relatively clean, If you're into syntax-highlighting editors, they usually get it right.

There aren't the ABI headaches that come with C++. The compiled code is smaller and faster.

C can fit inside your head. Unless you have an IQ of 250 and infinite time, you are never going to learn enough of C++ to become an expert.

C programs are more likely to run correctly.

Don't get me started on C++ references and const....

I write C++ when I am paid to. I write everything else for fun (mostly C and bash).

Re:C++ has had its day (1)

jopsen (885607) | more than 3 years ago | (#35625228)

It's time to move on.

If you want to write efficient code (have control of all allocations, etc) with some OOP sugar, C++ is a fairly decent choice...

And with some coding guidelines, C++ is not bad for application development either... I would rather use Qt/C++ than C#/Windows.Forms for GUI applications... Mainly because of Qt though, but C++ is not dead... It's a perfectly fine tool for many projects... Choose a tool that is right for the job...
And C++ is certainly still an important tool, what other well established fairly-low-level languages with OOP support do you find ?

Stroustrup C++ 'interview' (5, Funny)

moco (222985) | more than 3 years ago | (#35624796)

http://www-users.cs.york.ac.uk/susan/joke/cpp.htm

This one still makes me laugh

Borland too (1)

grilled-cheese (889107) | more than 3 years ago | (#35624810)

Borland [embarcadero.com] has also had support for parts of the C++0x spec for some time now [embarcadero.com] .

D is C++ redesigned (5, Interesting)

peterhil (472239) | more than 3 years ago | (#35624830)

Given all the negative comments about the complexity and misfeatures of C++, I one day decided to take a good look at D programming language [wikipedia.org] .

I know Ruby, Python and Common Lisp, and as I have used Ruby's NArray and NumPy quite much, I appreciate that D language has first class Array objects and vector operations for arrays built into the language. D is also compatible with C and has two-way bridge for Objective-C. The version 2 also supports functional programming.

Overall, D seems to have taken good influences from dynamic programming languages like Ruby and Python.
I wonder why D isn't more popular? Maybe the division of the standard libraries is a big factor?

PS. I have been looking a similar library to NumPy for Common Lisp, but GSLL just doesn't cut it and Matlisp only handles two-dimensional matrices. Of course you can use map, but iterating even slices of two-dimensional matrices with map can be a hassle and is much more verbose than having a good iterator abstraction.

Re:D is C++ redesigned (1)

turgid (580780) | more than 3 years ago | (#35624860)

Someone with a clue!

Re:D is C++ redesigned (2, Interesting)

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

I like D as well. The elimination of many screwy cases from C++ and ability to just link up with C or ASM object files for speed is very nice.

It takes time for languages to gain followers, tools, maturity and stability. Python was started in the early 90s. Ruby was in 1995. I hope D and Perl 6 both become at least semi-mainstream programming languages.

Re:D is C++ redesigned (3, Interesting)

man_of_mr_e (217855) | more than 3 years ago | (#35625246)

D is not as popular because it largely only appeals to C++ developers who want a better C++. However, unlike C++, D is not standardized by any standards body, so the language can change on a whim by the author. There is also only one real implementation of D, as opposed by having support by multiple vendors (most likely, this is a function of its lack of standardization. Corporations don't want to take on writing compilers for non-standard languages).

Certainly, lack of standardization hasn't prevented other languages, such as Java in the past, but look what happened there. Microsoft was litigated out of the market, and now Oracle is sueing Google and possibly others. This is not very commercial compiler friendly.

There would likely be questions of intellectual property that need to be answered, and grants or licenses of such IP to ensure that third party vendors won't get sued. Yes, I know they say it's open source, but i doubt it has had a full audit and due dilligence done on whether or not it violates any IP.

Don't get me wrong, what they've done with D has been fantastic. I think Walter needs to seriously consider submitting it to a standards body if he wants to go anywhere with it.

Constructors should have names (0)

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

We need to be able to write &T::T, just like we can do &T::somemethod and finally build dependency injection in C++.

Nice! (2)

friedmud (512466) | more than 3 years ago | (#35624944)

As someone who spends all day developing a C++ library for massively parallel engineering simulation.... I'm really excited about this announcement. My team has played with some of the early C++0x features in Intel's compiler and GCC and we're definitely going to be adopting a few of them, but can't commit ourselves until they are a bit more universally available.... which now, they hopefully will be.

C++ certainly still has it's strong points over many other languages... especially when you need that cross section of good OO design and performance (like we do). There are many things I love using Python for but there a also a TON of times I need complete control over everything in order to get the most out of the machine I'm using.

Re:Nice! (0)

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

There are many things I love using Python for but there a also a TON of times I need complete control over everything in order to get the most out of the machine I'm using.

You already mentioned C++ and Python, so which language do you use for that?

reviewing fake math, history, weather, wmd (-1)

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

enemies? none of what's presented is the least bit accurate. not even the body counts.

look out, the truth is representing itself, & it's accuracy, resulting in it's honesty mandate kicking in. there's a chance it may get out this time?

money, real estate, religion, fear, ego. any one of these 'features' can outweigh the right to life of many, except the chosen ones.

can't find this post where it was left last. must be deleted/meaningless compared to stuff that matters? space problem?

ret.4star.gen.hero, or hired goon psycho killer? (Score:0)mynutswon; the holycost may not be questioned

hard to tell? fog of tax free (for some) war can do that? did we say tax free? pardon, the non-taxpayers actually profit ($billionerrors$) on the heavy weapon (keeping ALL sides supplied including mexico) murder massacre business outings. so that's good?

we support the views of this former person
http://www.youtube.com/watch?v=TY2DKzastu8&NR=1&feature=fvwp ("stop killing")

we do not support the material in this cnn propaganda video from yesterday
http://www.youtube.com/watch?v=BXB75IK6pL4 ("we can win this, with my help")

same guy? clone? confused? we must focus... on the images. we must....saw a picture of one of those godaffy psycho-killer freaks being paraded around our military bases (may have paid for them, along with our holycost tithing's) like royalty, only to become our very worst 'enemy' just weaks/leaks later? focus-pocus?

++curmudgeon; (5, Funny)

mpaque (655244) | more than 3 years ago | (#35624998)

Ah, it's articles like this that make me so glad I'm retired!

C++ programmers have it too easy. Why, in C we had to code our own bugs. C++ programmers just inherit them!

Still no designated initializers (1)

Daniel Phillips (238627) | more than 3 years ago | (#35625048)

Some monster warts not addressed, like no designated intializers, no flexible arrays. Some backwards progress like the idiotic narrowing errors in cases like { 1, 2 } for an array of floats. But in general, a better language, I switched to -std=gnu++0x a few months back.

ANN: The++ (0)

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

After years of work, we are pleased to announce the++, a successor to the hugely popular english determiner "the". Although many people in recent times have been happy to use "the" as a determiner, we have worked hard to extend the semantics into verb, adverbial and noun forms. Thus; The the the the.

We have strived to create a professional and expressive tool and sincerely hope that english speakers and writers alike will get as much pleasure from using the++ as we had in creating it.

In closing, the++ allows the the the and the the. It is the correct the the the if the the the the clearly understood.

C++ is the worst lang except for all the others (0)

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

I hate C++. I have so many objections to it that I can't even list them here reasonably.

However, there is nothing that can replace it. Everything fails on some account or another. C++ lets you have high level power without sacrificing extremely low level control. No virtual machine, sandbox, or GC'ed language can do that.

So yes, it's a horrible language. But yes, I'm on a team writing an OpenGL based game engine, and we're using C++, because it's the only reasonable choice. We need exact control over bitfield layouts, we need inline assembly, we need good GL bindings, and so on.

Load More Comments
Slashdot Login

Need an Account?

Forgot your password?