Become a fan of Slashdot on Facebook

 


Forgot your password?
Close
typodupeerror
×
Programming

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

Posted by Soulskill from the and-so-quickly dept.
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."
This discussion has been archived. No new comments can be posted.

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

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

Comments Filter:

  • Yay for C++'0B (Score:2, Redundant)

    by sabre ( 79070 )

    Enough said!

    -Chris

    • 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!

    • Re:Yay for C++ 0x7DB; // FTFY (Score:5, Insightful)

      by VortexCortex ( 1117377 ) <VortexCortex AT ... trograde DOT com> on Saturday March 26, 2011 @05:34PM (#35625280)

      Enough said!

      -Chris

      Incorrect. The year 2011 A.D. is 7DB Hexadecimal A.D. Ergo, if you're going to abbreviate the numeral using the last two digits you should be heralding C++'DB or simply shorten it to C++'B.

      Note: Due to the fact that legacy versions are abbreviated as YEAR mod 100 in radix (base) 10, the new hexadecimal notation should include the a prefix or suffix indicating the radix in use. For quite some time there has existed such a hexadecimal radix prefix in C and C++: 0x

      Thus:
      Hurray for C++ 0xB;
      (Also note the above line does not parse as valid statement in C++, even though the ++ operator actually does take a dummy int parameter as the right-hand-side to differentiate it from the ++C; prefix increment operator.
      operator++(int){ /* WTF! */ };

      For meatball's sake people, even the ++ operator is a kludge in C++? [wikipedia.org] ( "C++" translates to "C (with kludges)" to me.)

      Even without any #define macros present, I still can't tell what a single snippet of C++ code is going to do. (Does the simple statement: C++; open a temporary file, and record the number of increments or throw an exception? Should I wrap all such statements in a try / catch block!?) If you haven't studied the entire inheritance graph of the type that the C variable is declared as, there is really no way (beside a debugger) to know what will happen next. (What if a pointer is to a polymorphic class? *my_ptr->operator++(42); Now, it's not supposed to do anything with that "dummy" 42 value, the base type doesn't but a subclass might...)

      Don't get me wrong, I code in C++ every day, and prefer it to C, but it surprises me just how messed up things have been allowed to get because we're shoe-horning in features into an existing syntax instead of just creating a new language that has less kludges.

      int main() {
      int my_var_a( 1 ); //Constructed an int "object" by calling it's "constructor"
      // ^^^ Uh.. OK ints are object-ified now.
      int my_var_b(); // DOES NOT call the int object's empty constructor.
      my_var_b = 10; // ERROR, the previous line declares a function.
      return my_var_a;
      }
      ^^^^^^ Declares a new function in the function/method body WTF? (because C lets you do that, for better or worse... )
      use: int myvar; to "instantiate" a new int "object" using the empty constructor instead... So, why can't I subclass an int? class my_number : public int { ... }; ARGH.

      Look, it's clearly time to stop hacking extra features into the language, or stop letting it be hindered by legacy C conventions / syntax. I think that C++ could be much better than it is if it weren't pandering to C coders... It's too bad that we started down that path with C++, there's far too much time and energy invested to reboot it now.

      I'm glad for some of the new C++ features, but at this point there's not much to celebrate for me -- Doing without for so long has caused us to create our own systems: the C++0x garbage collector is incompatible with my multi-threaded hybrid strategy (pool / slab & heap-like) memory manager (thank Spaghetti Monster, theirs is optional), I already have a ton of code that uses my cross platform multi-threading libraries, we've been using a HashContainer for over 10 years in our company...

      C++0x7DB adoption to us means: "Oh great, they finally got around to standardizing all these things we've needed for years and made ourselves -- It's going to be a headache writing new code that conforms to the new standard while remaining compatible with our current code-base."

      (And there was much rejoicing: "... yay... ")

      • Even without any #define macros present, I still can't tell what a single snippet of C++ code is going to do. (Does the simple statement: C++; open a temporary file, and record the number of increments or throw an exception?

        to be fair, all the other 'oo' languages don't let you do that either, and C can give you the same problems if you're using #defines (C's equivalent to operator overloading :) )

        At least in C++, you can look at the header file for the class definition and see what its doing. In languages

      • Just as a side note, regarding "objectified int" - the term "object" in C++ standard actually comes from plain C, and doesn't have much to do with objects in OO sense. I'll just quote the C99 spec:

        3. Terms, definitions, and symbols
        For the purposes of this International Standard, the following definitions apply. ...
        3.14 object
        region of data storage in the execution environment, the contents of which can represent values

    • Enough said!

      -Chris

      Olly Olly 0x 'an C

  • Like a zombie (Score:3, Insightful)

    by russotto ( 537200 ) on Saturday March 26, 2011 @03:59PM (#35624592) Journal

    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: (Score:2)

      by turgid ( 580780 )

      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.

    • 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). ~

      • Re: (Score:2)

        by narcc ( 412956 )

        you can shoot so many other things in very spectacular way!

        The most popular is shooting the guy who maintains your old code, in the head, by his own hand.

        • It's so easy it's not even sporting. You don't even need C++ for that.

          // Suck that, bitches!
          #define true false

          Bonus points for tucking it away into some build script as a compiler switch instead. Double bonus when build scripts are generated.

    • None of your business! (Score:5, Insightful)

      by Chemisor ( 97276 ) on Saturday March 26, 2011 @04:36PM (#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.

      • 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

    • Re:Like a zombie (Score:5, Informative)

      by Zandamesh ( 1689334 ) on Saturday March 26, 2011 @04:38PM (#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.

      • 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.
    • OK, so C++ is a little heavy on the features available but guess what; they're only available features, not compulsory features. If you just want to do a couple of classes, C++ can do that fine. If you want to program with all that stuff you hate, C++ can do that fine too. You just have to choose what to use in your code and write it accordingly.

  • 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 :)

  • 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 troubl

    • Re:My first question. (Score:5, Insightful)

      by PhrostyMcByte ( 589271 ) <phrosty@gmail.com> on Saturday March 26, 2011 @04:16PM (#35624730) Homepage
      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.
      • This is what I call the lawyer talk. I don't want a run around. I am not checking for size() == 0. I need to know the number of elements in the list. The standards allow splice() to be O(N). Most people expect size() to be O(1) that is how they interpret the standards. Making splice() O(N) to give size() in O(1) is the reasonable and user friendly thing to do. Hiding behind opaque english, using lawyer talk and blaming the user is antagonizing the user.

        • This is what I call the lawyer talk. I don't want a run around. I am not checking for size() == 0. I need to know the number of elements in the list. The standards allow splice() to be O(N). Most people expect size() to be O(1) that is how they interpret the standards. Making splice() O(N) to give size() in O(1) is the reasonable and user friendly thing to do. Hiding behind opaque english, using lawyer talk and blaming the user is antagonizing the user.

          Mate, you need to pay attention to your own sig. The C++ standard is clear on where big O performance is prescribed. Where it is not, don't make assumptions. This is not some grand conspiracy against you, just suck it up and fix your code.

        • Making splice() O(N) to give size() in O(1) is the reasonable and user friendly thing to do.

          No, that's not reasonable. If std::list doesn't track size internally, it is still possible to have an O(1) size() equivalent by tracking it yourself. If it does track size internally, it becomes impossible to have an O(1) splice() equivalent. That's very important for moving sections of memory around in a resource-constrained environment.

    • Re: (Score:2)

      by godrik ( 1287354 )

      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.

      • 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 i

        • The lack of a singly-linked list is aggravating, but I'm guessing the reason for not providing one was that simple things like deleting a specified node blow up to O(N) because of the need to update a pointer in the inaccessible (except by iterating from the beginning) preceeding node. I.e., if there's no elegant way to do a simple thing, just don't provide it at all, and tag everybody with the overhead of a doubly-linked list and its often superfluous back-pointers.

          Anyway, thanks to the Powers That Be for

      • 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: (Score:2)

          by mmcuh ( 1088773 )
          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.

      • 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.

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

    • Re:My first question. (Score:4, Interesting)

      by russotto ( 537200 ) on Saturday March 26, 2011 @04:43PM (#35624928) Journal
      std::list::size() is O(N) because making it O(1) makes splice O(N).

      • 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 fi

        • Because undefined (as in changing depending on the circumstances) complexity is worse than "always the same but depending on the implementation".

          • Because undefined (as in changing depending on the circumstances) complexity is worse than "always the same but depending on the implementation".

            I'm sorry, but I reject that outright. Optimizing compilers have been surprising us with unexpected gains for years, but as long as they don't worsen the situation, no one minds. I can't think of a situation where an optimization that falls back to the default behavior in the absolute worst case but offers a nice speedup in others is a bad thing.

            I don't claim that I'm a supergenius and that I spent 30 seconds solving a problem that the libstdc++ guys have been working on for years, but I don't accept that t

        • Re: (Score:2)

          by MORB ( 793798 )

          It's easy to wrap std::list to do that yourself. What you propose would mean that if you get a list passed from some other opaque part of the code you have no way to predict whether size will be O(1) or O(n), because it may or may not be the result of a splice.

          Plus like it is now allows the spec to make simple and clear complexity promises (list::size() is O(n), splice is O(1)) without having to specify how the implementation should work in too much detail.

          • Plus like it is now allows the spec to make simple and clear complexity promises (list::size() is O(n), splice is O(1)) without having to specify how the implementation should work in too much detail.

            If you still document it as being O(n), but it's actually O(1) most of the time, I promise you no one will mind.

    • Re:My first question. (Score:5, Insightful)

      by shutdown -p now ( 807394 ) on Saturday March 26, 2011 @04:43PM (#35624932) Journal

      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

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

        • 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: (Score:3, Interesting)

        by Pontobart ( 2027250 )
        I hope the GCC guys will not follow this change. This would mean that lots of programs will break at runtime. I use splice() extensively and rely on the constant behaviour given by stdlibc++. Without this std::list is a completely useless class :)

  • Thank you Bjarne (Score:3)

    by whiteboy86 ( 1930018 ) on Saturday March 26, 2011 @04:16PM (#35624738)
    Nothing comes close to C++ in terms of versatility, features, speed and overall professional appeal.

  • Stroustrup C++ 'interview' (Score:5, Funny)

    by moco ( 222985 ) on Saturday March 26, 2011 @04:23PM (#35624796)

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

    This one still makes me laugh

  • D is C++ redesigned (Score:5, Interesting)

    by peterhil ( 472239 ) on Saturday March 26, 2011 @04:28PM (#35624830) Homepage

    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: (Score:2, Interesting)

      by Anonymous Coward

      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 (Score:4, Interesting)

      by man_of_mr_e ( 217855 ) on Saturday March 26, 2011 @05:29PM (#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.

      • Also, before anyone climbs down my throat about the gnu d compiler and the .net d compiler, these are really just ports of the main D code, not entirely new implemenations. That's what I meant by only one real implementation.

  • Nice! (Score:3)

    by friedmud ( 512466 ) on Saturday March 26, 2011 @04:45PM (#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.

  • ++curmudgeon; (Score:5, Funny)

    by mpaque ( 655244 ) on Saturday March 26, 2011 @04:54PM (#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!

  • 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.

    • Re: (Score:2)

      by mmcuh ( 1088773 )
      By flexible arrays, do you mean the variable-length arrays from C99? There is really no reason to use arrays in C++. For resizable containers you have std::vector, for fixed-size ones there is now std::array. Access times and cache properties are identical, since both of them are specified to store the data as a contiguous array internally. They don't have the stupid special problems that raw arrays do (can't be copied or assigned to directly, quietly decay to pointers when used as function arguments) but

      • I did indeed mean flexible arrays. I did not know about std::array, maybe it really is always better than classic C arrays. But I am skeptical, I will try it and see. In any case, there is no plausible excuse for not supporting variable arrays, especially in their role as function arguments. They are required for C99 anyway, which typically uses the same back end as C++.

  • How do you pronounce 'C++0x', and why does my modem keep resetting when I type it?

    • How do you pronounce 'C++0x', and why does my modem keep resetting when I type it?

      The answer to both is the same: nerdgasm

  • C++ Final ISO Draft approved?

    That's like that couple who has been together for 20 years
    and has a couple of high-school age kids
    telling you that they just decided to get married.

  • Brilliant. It was bad enough in job interviews when they try to catch you out on your knowledge of the obscure bits of C++ that nobody ever uses, and now there's a whole new level of complex syntax, pitfalls and gotchas to deal with. C++ is turning into a warty freakshow. I could even start to forgive Python's idiotic indentation nonsense at this rate.

Slashdot Top Deals

"jackpot: you may have an unneccessary change record" -- message from "diff"

Close