Follow Slashdot stories on Twitter


Forgot your password?
Programming IT Technology

Latest Proposals for C++0x 911

CodeDemon writes "It looks like the ISO/IEC JTC1/SC22/WG21 working group has made some headway in reviewing new proposals for the C++ language. The long anticipated upgrade for C++, C++0x, may be just around the corner. Head on over to check out the proposals yourself."
This discussion has been archived. No new comments can be posted.

Latest Proposals for C++0x

Comments Filter:
  • And I thought the next version of C would be +++... and then ++++
    • by Anonymous Coward on Friday July 11, 2003 @01:11PM (#6416671)
      C++H0--NO CARRIER!
    • And I thought the next version of C would be +++... and then ++++

      Well, since there was never a "C+" language, and you increment variables by one with "++" (hence the inherent joke in the name "c++"..."c incremented by one") a more logical construct would be (c++)++
    • c += 2 (Score:5, Funny)

      by Doomdark ( 136619 ) on Friday July 11, 2003 @01:22PM (#6416857) Homepage Journal
      Yeah, but that wouldn't be backwards compatible! (wouldn't compile with current compilers).

      So let's see; somebody else already proposed (c++)++ , which is a reasonable suggestion... but... um... how about "c += 2"? For now, it's as concise as the alternative, but going forward it will scale better (c += 3 vs ((c++)++)++ ).

    • by Davorama ( 11731 ) on Friday July 11, 2003 @01:31PM (#6416978) Journal
      Nah, it should become C double plus good...
    • by Anonymous Coward on Friday July 11, 2003 @01:50PM (#6417270)
      Hello Gentlemen,

      I'm a first year programming student at an Ivy League school and I've
      just finished my Visual Basic classes. This term I'll be moving onto
      C++. However I've noticed some issues with C++ that I'd like to
      discuss with the rest of the programming community. Please do not
      think of me as being technically ignorant. In addition to VB, I am
      very skilled at HTML programming, one of the most challenging
      languages out there!

      C++ is based on a concept known as Object Oriented Programming. In
      this style of programming (also known as OOPS in the coding community)
      a programmer builds "objects" or "glasses" out of his code, and then
      manipulates these "glasses". Since I'm assuming that you, dear reader,
      are as skilled at programming as I am, I'll skip further explanation
      of these "glasses".

      Please allow me to make a brief aside here and discuss the origins C++
      for a moment. My research shows that this language is one of the
      oldest languages in existence, pre-dating even assembly! It was
      created in the early 70s when AT&T began looking for a new language to
      write BSD, its Unix Operation System (later on, other companies would
      "borrow" the BSD source code to build both Solaris and Linux!)
      Interestingly, the name C++ is a pun by the creator of the language.
      When the first beta was released, it was remarked that the language
      would be graded as a C+, because of how hideously complex and unwieldy
      it was. The extra plus was tacked on during a later release when some
      of these issues were fixed. The language would still be graded a C,
      but it was the highest C possible! Truly a clever name for this

      Back to the topic on hand, I feel that C++ - despite its flaws - has
      been a very valuable tool to the world of computers. Unfortunately
      its starting to show its age, and I feel that it should be
      retired, as COBOL, ADA and Smalltalk seem to have been. Recently I've
      become acquainted with another language that's quite recently been
      developed. Its one that promises to greatly simplify programming. This
      new language is called C.

      Although syntactically borrowing a great deal from its predecessor
      C++, C greatly simplifies things (thus its name, which hints at its
      simpler nature by striping off the clunky double-pluses.) Its biggest
      strength is that it abandons an OOPS-style of programming. No more
      awkward "objects" or "glasses". Instead C uses what are called
      structs. Vaguely similar to a C++ "glass", a struct does away with
      anachronisms like inheritance, namespaces and the whole
      private/public/protected/friend access issues of its variables and
      routines. By freeing the programmer from the requirement to juggle all
      these issues, the coder can focus on implementing his algorithm and
      rapidly developing his application.

      While C lacks the speed and robustness of C++, I think these are petty
      issues. Given the speed of modern computers, the relative sluggishness
      of C shouldn't be an issue. Robustness and stability will occur as C
      becomes more pervasive amongst the programming community and it
      becomes more fine-tuned. Eventually C should have stability rivaling
      that of C++.

      I'm hoping to see C adopted as the de facto standard of programming.
      Based on what I've learned of this language, the future seems very
      bright indeed for C! Eventually, many years from now, perhaps we'll
      even see an operating system coded in this language.

      Thank you for your time. Your feedback is greatly appreciated.

      Egg Troll
    • by robbo ( 4388 ) <> on Friday July 11, 2003 @01:57PM (#6417347)
      If C++==D then the next gen should be E. Actually, if we count pre and post ISO standards, we've moved on to F, which is a fine letter, imho. F, of course will add the exponentiation operator **, so we can compute F**k. ;-)
      • Actually, to make the new F language worthy of being successor of C++, it's probably better idea to overload ^ to be the exponentiation operator, so as to confuce everybody.
    • by Cinematique ( 167333 ) on Friday July 11, 2003 @02:05PM (#6417465)
      It'd be like eBay feedback...

      Great language!! Would code in again!!! C++++++++++++++++++

  • why not... (Score:3, Funny)

    by darth_MALL ( 657218 ) on Friday July 11, 2003 @01:10PM (#6416665)
    ...make it like grade school and just give the poor bastard a "B". Enough already ;)
  • by newsdee ( 629448 ) on Friday July 11, 2003 @01:11PM (#6416674) Homepage Journal
    It may be a no-brainer for many of you, but can somebody enlighten me on why the name is C++0x? AFAIK C++ was named as such to indicate it was "more than C" [C++ is C = C+1 for the unlikely few who wouldn't know]. Is this the same kind of nomenclature (0x is zero in Hex), or is it something pronunciation-based ("plusox"?)...

  • by Dark Lord Seth ( 584963 ) on Friday July 11, 2003 @01:11PM (#6416680) Journal
    ISO/IEC JTC1/SC22/WG21

    Someone try to say that ten times fast!

  • C++0x ? (Score:5, Funny)

    by Cipster ( 623378 ) on Friday July 11, 2003 @01:11PM (#6416682)
    Sounds like the l33t version of C++
    The hardest part is deschiphering the comments...
  • Alan (Score:4, Funny)

    by grub ( 11606 ) <> on Friday July 11, 2003 @01:12PM (#6416697) Homepage Journal

    What does Alan C++0x think of this?
  • C++0x? (Score:5, Funny)

    by Anonymous Coward on Friday July 11, 2003 @01:14PM (#6416723)
    You mean...the successor ISN'T C#?!

    I've...I've been living a lie...

  • by Surak ( 18578 ) * <surak AT mailblocks DOT com> on Friday July 11, 2003 @01:15PM (#6416743) Homepage Journal
    Honestly, I don't see how this is a big improvement. You have, basically:

    struct somestruct {
    int a;
    int [3]; //3 pad bytes
    int b;


    struct somestruct {
    int a;
    int pad[3]; // 3 pad bytes, do not use
    int b;

    The only thing its really saving you is the variable name, and its giving you an extra check at compile time to ensure you don't use the 'pad' array. Which shouldn't be a problem with proper variable naming and documentation, right?
    • by Abcd1234 ( 188840 ) on Friday July 11, 2003 @01:23PM (#6416874) Homepage
      Okay, I'm normally not a vocal C++ basher (although I do dislike the language), but this is a really excellent example of the kind of cruft that has made it into C++. It's like everyone and their dog had some pet feature they wanted included in the standard, and the result is a huge mess of stuff that most people won't use but the compiler is forced to support.

      I suppose this is what happens when you allow a programming language to be designed by a committee...
    • by crow ( 16139 )
      I've wanted this feature for many years, but mostly in the context of structs and unions.

      Suppose I have:

      struct foo {
      int i;
      struct bar {
      int j;
      int k;
      } s;
      } n;

      Now to reference j, I have to say n.s.j. But why not leave the s out so that I can just reference n.j?

      This becomes really useful is when you have a huge project and you decide that some element of a struct should be made into a union. Now you wouldn't have to change every reference throughout your project (or use
  • COBOL (Score:5, Funny)

    by mikeee ( 137160 ) on Friday July 11, 2003 @01:16PM (#6416753)
    I'm still waiting for the object-oriented business programming language, "ADD 1 TO COBOL".
  • by elwinc ( 663074 ) on Friday July 11, 2003 @01:16PM (#6416763)
    I think what C and C++ really lack is the option to turn on array range checking. Sure you can drop a couple grand for a purify [] license or learn to use valgrind, [] but it should be an easy-to-switch compiler option.
    • Uum... ElectricFence [] is a library that implements malloc, that check that you don't go over any bounds in dynamically allocated variables. Does a few other checks too (like double free). Link it with your project (or use LD_PRELOAD) and that's it.

      Works for C, but probably can be made to work with C++ too by writing an operator new that uses malloc() internally. Not sure if glibc actually does that.

  • learn from Java (Score:3, Insightful)

    by Karma Sucks ( 127136 ) on Friday July 11, 2003 @01:20PM (#6416825)
    I think C++ needs stuff *removed* more than it needs anything added.
    • hehe.. sorta (Score:5, Insightful)

      by Cthefuture ( 665326 ) on Friday July 11, 2003 @01:35PM (#6417037)
      I can understand where you're coming from. C++ is a complex beast. I've been using some form of C++ for over 10 years (well before it was standardised) and I still don't understand everything about it.

      With that said, it's an extremely powerful and flexible language. Very much more powerful than Java or C#. The complexity is mostly due to its flexibility. You can do (almost) anything with it. Of course, we can argue whether that's good or bad.

      I think C++ can learn from Java though. The default should be to pass all non-built-in-type function parameters by const reference and the programmer has to specify otherwise (basically opposite of the way it is now). That would clean up the code a whole lot since 99% of the time that's what you want anyway. And the standard C++ library should have some sort of garbage collector available.

      Another problem I have with C++ is that even with all its power you have no way to get to the "left hand" variable of operations. For example, if you have a matrix class you can overload the "+" operator so that you can do things like "matrix3 = matrix1 + matrix2". However, that's not going to be very efficient (assuming that's why you're using C++ in the first place) because there is no way to get to the matrix3 variable from inside the + operator. That forces you to use a temporary variable to add the two matrices then copy by value the whole matrix after adding matrix1 and matrix2. There are tricks around this problem but none are clean.
      • Re:hehe.. sorta (Score:3, Interesting)

        by dusanv ( 256645 )
        "matrix3 = matrix1 + matrix2". However, that's not going to be very efficient (assuming that's why you're using C++ in the first place) because there is no way to get to the matrix3 variable from inside the + operator.

        Why in the world would you want access to matrix3 from the plus operator???
        • Re:hehe.. sorta (Score:4, Informative)

          by IthnkImParanoid ( 410494 ) on Friday July 11, 2003 @02:44PM (#6417841)
          Why in the world would you want access to matrix3 from the plus operator???

          To fill the matrix (which we assume is large enough to make copying the values expensive) directly, instead of copying it into a temporary matrix with the overloaded '+' operator then copying it over with the overloaded '=' operator. You could do

          MatrixAdd(const matrix& m1, const matrix& m2, matrix& result);

          but then what's the point of overloaded operators?
          • Isn't it obvious? (Score:3, Insightful)

            by Gorimek ( 61128 )
            but then what's the point of overloaded operators?

            Well, I think the obvious answer is: NONE

            I'm sorry, but operator overloading is one of the most gratuitous and depraved features to make it into the language. And it's not just needlessly pretty, but causes all kinds of subtle errors. From not being able to be sure what "a + b" actually does, to disabling the guaranteed evaluation order in boolean expressions.
    • by devphil ( 51341 ) on Friday July 11, 2003 @01:43PM (#6417169) Homepage

      The most popular suggestion, during the original standards process, was: every time someone proposes a new feature, they have to also propose an existing feature to be removed.

      The followup suggestion: every time someone proposes a new feature, they have to donate a kidney. This ensures that proposals will be given serious thought, and that a serious idiot can only propose, at worst, two extensions.

      No, I'm not joking. Those were some of the suggestions that received rare unanamous agreement.

      Seriously, everyone on the committee, from Stroustrup and Koenig on out, agrees that the language is too complicated. They even said so before it was standardized. But...

      Let's hear your suggestions on which stuff should be removed. Remember that no matter what you choose, people somewhere are currently using it, and you will break their code. No matter what you change, it will cause incompatabilities, which future generations of /. will then bitch and moan about.

      Also, since compiler vendors don't like pissing off their customers, they can't really completely remove stuff even when the standard says it's okay.

      • Who cares? (Score:5, Informative)

        by KalvinB ( 205500 ) on Friday July 11, 2003 @03:26PM (#6418280) Homepage
        The extra bloat in Visual Basic is forced into my projects wether I use it or not.

        C++ on the other hand can have all the extra stuff it wants and it doesn't affect my project. If I don't wan to use templates or whatever, I don't have to. And the compiler won't force me to include anything.

        Whining about C++ having too many features is like bitching that Baskin Robbins has too many flavors. Nobody is forcing you to buy them.

  • by Eustace Tilley ( 23991 ) * <> on Friday July 11, 2003 @01:21PM (#6416848) Journal
    I liked this, which supports "Quality of Implementation:"

    The development cycle of embedded software does not easily lend itself to the trial-and-error style of programming and debugging, so a stubborn C++ compiler that catches as many errors as possible at compile-time significantly reduces the dependence on run-time debugging, executable run-time support and compile/download/test cycles.

    This saves untold hours at the test bench, not to mention strain on PROM sockets.

    Williams, Stephen, cited by Lois Goldthwaite in her Technical Report on C++ Performance []
  • Compiler Compliance (Score:4, Interesting)

    by wideBlueSkies ( 618979 ) on Friday July 11, 2003 @01:23PM (#6416870) Journal
    I haven't read all the proposals, hence my early post, but the subjects look interesting. It'll be cool to see what makes it to the final standard.

    But that's not why I'm posting.

    It's nice to read about all the standards processes, and I can appreciate all the great work that these bodies perform. But after the standards are completed, and everyone goes home, it seems to take years for the compiler writers to implement the standards properly.

    I'm not trying to slam the poor developers who have to implement the changes. But yet, it seems that the standards bodies don't seem to take acutual usage of the last set of changes into account before proposing the next set of standards.

    What I mean is this: Take C++ 97. OK? How many of us have actually used a 100% compliant compiler, and used the latest features? Not too many. I know I haven't. But it seems to me that the language masters want to go ahead and move C++ along without getting real feedback from developers about how useful the language changes are.

    It's almost like the big boys are saying "well, it'd be nice to have X, Y, and Z in the language" instead of "you know, everybody hates the way we did A, B, and C back in 97. Lets think about fixing that". The language masters, IMHO are basing the next round of changes on their experiences, not the experiences of the developer community at large.

    C++ is already a big complicated language. Maybe the standards process should slow down a bit and give us ordinary developers a few more years to catch up.
  • SCO (Score:5, Interesting)

    by ikewillis ( 586793 ) on Friday July 11, 2003 @01:25PM (#6416900) Homepage
    Watch out, SCO thinks it owns C++ []:

    MozillaQuest Magazine: C++ appears to be one of the properties that SCO acquired through Novell's acquisition of AT&T's UNIX Systems Laboratories and subsequent purchase of Novell's UNIX interests by SCO. At this time most Linux and/or GNU/Linux distributions include C++ compilers and editors. Is this something for which SCO currently charges? If so, just what are the current arrangements? If not, will C++ licensing and enforcement be added to SCO's licensing and enforcement program?

    Blake Stowell: 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.

    MozillaQuest Magazine: How about GNU C++? Does GNU C++ use SCO IP? If so, could SCO license and/or charge for use of its IP in GNU C++?

    Blake Stowell: I honestly don't know.

    • How can SCO own the language? I can see them owning an implementation of the compliler and libraries but the actual language? Come on, that doesn't compute, especially since it has been ANSI standardized.
  • More on D (Score:5, Insightful)

    by Randolpho ( 628485 ) on Friday July 11, 2003 @01:28PM (#6416938) Homepage Journal
    I know talking about D is already redundant on this article, but I'd like to anyway. Improving c++ is great, but where c++ *really* needs improvements is the syntax. It's time for c++ to move into the 90s and get rid of the preprocessor. It's unnecessary with modern compilers, and it's a pain in the ass.

    One of the stated goals on the .pdf file linked is to make c++ easier to learn, but many of the syntactic kludges in c++ (like the preprocessor and the differences between a pointer and a reference) confuse the hell out of newbies. It's time to adopt a syntax more like Java while retaining the power of native compilation and library creation that c++ gives.

    In short, it really *is* time to move to D.
    • Re:More on D (Score:3, Insightful)

      by gbjbaanb ( 229885 )
      why get rid of the preprocessor? every C++ programmer finds it useful, and if the argument is that you can create obscure and unmaintainable code with it - well, you don't need the preprocessor to do that!

      Yeah, we need a java-like syntax so you too can create lots of debug info in programs with 'if (global_debug==1) ' rather than the infinitely more efficient #ifdef DEBUG.

      I think some people have problems with practical features of the language - sure, we can make it 'elegant' (like they read somewhere t
      • Re:More on D (Score:3, Insightful)

        by HeghmoH ( 13204 )
        Yeah, we need a java-like syntax so you too can create lots of debug info in programs with 'if (global_debug==1) ' rather than the infinitely more efficient #ifdef DEBUG.

        I'm pretty sure Java guarantees that if the conditional of an if is known at compile-time (as it would be in this case), then the if will be optimized out of your code. Just like an #ifdef. So, nice straw-man, but the two constructs are equally efficient.
  • by exp(pi*sqrt(163)) ( 613870 ) on Friday July 11, 2003 @01:31PM (#6416976) Journal
    ...proposals. Without metaprogramming C++ really is glorified C. But with metaprogramming C++ becomes an entirely new system. The template system is computationally complete (see here [] for what that means) and so important work can be shifted to compile time. That doesn't just mean computing the answer at compile time, that would be silly. It means procedurally building and optimizing code. For example we all know that C is slower than FORTRAN because pointers (lacking in FORTRAN) bring in variable aliasing problems that stop the compilers reliably optimizing. C++ metaprogramming allows us to claw back some of that loss by intelligently building optimized math routines at compile time. See Blitz++ [] for examples. The net effect is the speed of Fortran combined with readable high level references to array and vector objects.

    Unfortunately metaprogramming is a pain in C++. One of the biggest problems is the lack of reflection in C++ that would allow template metaprograms to easily determine type information. Some of the new proposals would remedy that issue. Also the use of local classes in templates, that is sorely lacking in the current standard, would be a great boon for such techniques.

    And maybe one day there will be many more C++ textbooks that don't just relegate templates to half a paragraph in the "advanced techniques" section. Templates are fundamental to C++. If you don't use the benefits of C++ then C++ really isn't that interesting a language. No wonder so many people propose using C rather than C++. It's like programming in Lisp but refusing to use list datastructures.

    • No wonder so many people propose using C rather than C++.

      One reason C is so popular today is that it reached a critical threshold in abstraction: it isn't assembly code. C can be learned very quickly, and, given that prior programmers weren't too supidly clever, C-based programs can be easy to learn. I say "stupidly clever" because some people really do try to shoehorn functions into structures (oooo...I make C object-like) or use the preprocessor as if they have to, because it's there.

      C, used as inte
  • by Jack Greenbaum ( 7020 ) on Friday July 11, 2003 @01:32PM (#6417001) Homepage Journal
    One big advantage of Java is that it is a platform, not just a language. You don't have to reinvent the wheel for basic things like threading that modern systems do. In the pdf [] linked from the article Stroustrup proposes filling out the standard library in ways that Java already does, and think this is a good thing. STL was a start in that direction, but every C++ system I come accross seems to do threading and many other common operation over again (pwlib [] used in openh323 [] for example). I'm glad to see the C++ world recognize this type of developer need.
  • by mcc ( 14761 ) <> on Friday July 11, 2003 @01:38PM (#6417088) Homepage
    So, are they ever going to do anything about the Fragile Base Class problem? I don't see anything related in those proposals.

    I'm tired, so forgive me if i explain this poorly, but C++ has this issue where, since object methods are really just function pointers, if you have class A that is shipped as a library or API, and class B which inherits from class A and is part of some third-party program, and the people who make class A add a private method or private variable to class A and then re-ship their libraries, every existing binary containing class B breaks becuase C++ just slaps a struct containing Bs methods and variables at the end of A, and becuase the size of A has changed the offsets have all changed.

    This is horrible. This completely negates the purposes of encapsulization and information hiding, which is the entire reason you'd be writing an OO API in the first place, and leads to anyone attempting to create a C++ API doing horrible workarounds [] like sticking a whole bunch of dead space in the form of methods named, for example, "reserved_23" at the end of every class they make, just so that in case later they have to add a method or instance variable they'll have a little bit of room to do so without breaking everyone who's ever inherited from them.

    Until they fix this, and until they reach the point where there is some kind of standard String class that everyone uses (as is, there are an untold number of String classes, one for just about every major C++ API, and so from what i've seen people rarely if ever store their strings as anything other than c-strings just because in the end, all they're going to do with their strings is pass them to other c or c++ libraries.. who expect to be given c-strings..), I will continue to consider C++ to be more or less a huge joke that can be used as a high-level oo programming language, but only by coincidence.

    Also note that they still are not even considering adding any sort of real reflection into the language, nor are they considering adding a real, robust macro system despite the fact people clearly want one (or else they wouldn't be trying to metaprogram the C++ template system to be a macro system!). It would be nice to be able to typedef a single variable type that acts as a template, though.. that's a good innovation, if i'm reading that right. Anything that minimizes the contact I have with the C++ template system makes me happy. (If it were up to me, they would add ML-like syntax where you can say something like 'typedef myinttype = int | long | IntegerClass | BigInt;' and it would automatically generate the templates for me whenever i used a myinttype in a function.) Of course, considering how long the major compiler makers took to all implement C++ in a standard fashion (the STL doesn't really even seem standard across all the platforms i use, yet), it will probably be a long time before i can safely use any C++0x features :P

    I will, however, support the spread of C++0x, just becuase that will make it the first major language whose name is written in leetspeak.
  • I like (Score:3, Interesting)

    by Hard_Code ( 49548 ) on Friday July 11, 2003 @01:39PM (#6417108)
    N1420 Class Namespaces
    N1428 Dynamic Library Support in C++

    Coming from Java (well, I did do a bit of introductory C++), one of the things that really bugs me, is the aesthetic of looking at the soup of classname::function implementation declarations. Class namespaces would clean this up considerably and make things much easier to read and more manageable (Java packages and classes are basically namespaces, and this concept confers very well). I also like the dynamic library support (another thing that is automatic in Java)...the worst thing is having to code native OS-specific macros, extern "C" DECLSPEC(dllexport) BLAH BLAH F'ING BLAH. Dynamic libraries are a ubiquitous concept and support should be built in. Leave it to the compiler to figure out what that actually *means* for a given OS. There is no performance benefit in making a human code this.

    Further library standardization would of course really helps to have a standard library (even if it is not the BEST one), since it avoids balkenization, which makes skills truly portable ("C++ developer eh? well do you know how to use the Frobnitz Super Fantastic library? No? Shame."), and programs reusable (by other humans).
  • by Anonymous Coward on Friday July 11, 2003 @01:41PM (#6417132)
    After working on the internals of the Std C++ library for several years I can honestly say that C++ is the biggest mess ever. The ANSI C++ committee is now trying to patch the language into a frankenstein version of Java.

    Unfortunately with Java 1.5, some of C++ is corrupting Java, mainly the completely academic confusing implementation of C++'s templates. Why not go for a more easier to understand concept of templates as implemented by languages such as Haskell?
  • by Necroman ( 61604 ) on Friday July 11, 2003 @01:44PM (#6417178)
    If this standard does go through, aht GNU supports it via gcc or what have you, this will help companies in a big way.

    The company I worked for used to write our software in C++, but moved over to java 3 or 4 years ago for the cross platform abaility of this. There are so many core parts of a program that are system dependent, that supporting 8 different operating systems in C++ is impossible without a standard library of some sorts. Add a standard socket structure will be very nice, and most OSs have very different ways of handling this. Threading is also the other huge issue with crossplatform, there is near zero standard on out threading works in C++.

    The one thing that the new C++ proposal is missing is a standard widget/windowing commands. But there is no good way to make standard libraries for something like that, the best if to create a general class to create and control widgets, then write the system specific code for each OS you want it to run on.

    It's something I'm looking forward to.
  • Noooooooo! (Score:5, Insightful)

    by timeOday ( 582209 ) on Friday July 11, 2003 @01:46PM (#6417201)
    In practice, C++ is finally getting to the point where various compilers accept the same code. That after 15 years or so. Now they want to shake it up again?
    • Re:Noooooooo! (Score:5, Insightful)

      by be-fan ( 61476 ) on Friday July 11, 2003 @02:11PM (#6417526)
      Its only been about 5 years since C++ 98 was standardized. And GCC has been very complient for about a year now, so it took 4 years for complient compilers to come out. That's really not *that* bad, considering that the latest push for complience was driven by the new wave of "Modern C++" techniques, which surfaced relatively recently. Further, a lot of the new proposals use pre-existing solutions (the Boost libraries are a big help here) and all the code that was added for template support seems to have some reusability value. See Vandervoode's comments about his C++ metacode extension, and how relativley easy it was to implement in the EDG C++ front-end, thanks to all the existing infrastructure.
  • by Conspiracy_Of_Doves ( 236787 ) on Friday July 11, 2003 @01:47PM (#6417225)
    is that with C++ it's harder to shoot yourself in the foot, but when you do you end up blowing your whole leg off... With C++0x will it be nearly impossible, but when it does happen you end up blowing up the whole city?
  • by PDHoss ( 141657 ) on Friday July 11, 2003 @01:54PM (#6417318)
    T33N 8abes ready for your h0t C++0x !!!
  • Cool (Score:5, Interesting)

    by be-fan ( 61476 ) on Friday July 11, 2003 @02:00PM (#6417392)
    Modern C++ really is a cool language. Its hardly clean, and its a big beast to learn, but (IMHO) it allows a great deal of abstraction without sacrificing much (if any) performance. Personally, I'd like to see the following features in C++ 0x.

    1) Metafunctions. Like Lisp macros, they allow code-generation at compile time. They're less flexible, because they don't allow access to the AST, but they're much better than the current template-metaprogramming kludge.
    2) Lambdas. Even if we don't get true lambdas, with continuations and closures, but I'd like to see some sort of anonymous functions. The STL desperately requires it. Overall, I'd like to see more functional stuff get into the language. Unlike many of the other features discussed, lambdas and higher order functions really need language-level support to work well.
    3) Type inference. There is a proposal to allow a new use of the auto keyword like such:
    auto x = new int;
    The compiler will automatically detect that 'x' should be an int*. I've wanted this feature from the minute I saw stuff like:
    int* i = new int;
    Its so redundant! I'm surprised that Java (whose simple semantics would make type inference much easier) still makes you do stuff like:
    foo i = new foo;
    An additional motiviation is that:
    vector::iterator i = vec.begin()
    can be shortened to:
    auto i = vec.begin();
    C++ is seriously eating into the horizontal space, thanks to namespaces and nested typedefs and whatnot, and type inference would go a long way in alleviating some of that pain.

    The nice thing about these features is they keep with C++'s philosophy. Most of the complexity here is in the compiler --- there is no overhead in the generated code.
  • C++0x? (Score:3, Funny)

    by zephc ( 225327 ) on Friday July 11, 2003 @02:02PM (#6417418)
    how about a much cuter name, like "Snugglums" or "Bwumpie-poo"?
  • by Chris Hall ( 5155 ) on Friday July 11, 2003 @02:08PM (#6417497) Homepage

    Rather than just rushing into designing yet more features for the language, shouldn't existing proposals such as This 5-year-old proposal for overloading [] be taken into consideration? :-)

  • Hmm...0x or 1x? (Score:3, Interesting)

    by clary ( 141424 ) on Friday July 11, 2003 @02:21PM (#6417632)
    Can I be considered an old-timer for remembering when Fortran 90 was still the Fortran 8X proposal?
  • Why? (Score:3, Insightful)

    by GnuVince ( 623231 ) on Friday July 11, 2003 @02:23PM (#6417650)
    I keep hoping that C++'s use will shrink and that the language will be replaced by a more dynamic language for user applications (Smalltalk, Lisp, Python, etc.) It seems that a new standard might renew some people's desire to write static applications, which might now be a good thing.

    I recently started messing with Squeak [] and I think that it is the kind of thing programming language should try to mimic: an easy to use, very dynamic environment. Let's take computing to a new level, leave the 90s behind please.

"No, no, I don't mind being called the smartest man in the world. I just wish it wasn't this one." -- Adrian Veidt/Ozymandias, WATCHMEN