Slashdot Mirror


Latest Proposals for C++0x

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

137 of 911 comments (clear)

  1. It keeps going and going.... by deman1985 · · Score: 4, Funny

    And I thought the next version of C would be +++... and then ++++

    1. Re:It keeps going and going.... by Anonymous Coward · · Score: 4, Funny

      C++H0--NO CARRIER!

    2. Re:It keeps going and going.... by bluethundr · · Score: 2, Informative

      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++)++

      --
      Quod scripsi, scripsi.
    3. Re:It keeps going and going.... by kevinank · · Score: 5, Funny
      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++)++

      I'm rooting for C+=2.

      --
      LibBT: BitTorrent for C - small - fast - clean (Now Versio
    4. Re:It keeps going and going.... by MouseR · · Score: 4, Funny

      Actually, I would have chosen ++c++;

    5. Re:It keeps going and going.... by Davorama · · Score: 4, Funny

      Nah, it should become C double plus good...

      --

      Davo -- Free speech, free software, AND free beer.

    6. Re:It keeps going and going.... by Cinematique · · Score: 4, Funny

      It'd be like eBay feedback...

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

    7. Re:It keeps going and going.... by Speare · · Score: 4, Funny

      And the other joke of an Object-Oriented COBOL being named, ADD ONE TO COBOL.

      --
      [ .sig file not found ]
    8. Re:It keeps going and going.... by j7953 · · Score: 4, Funny
      hence the inherent joke in the name "c++"..."c incremented by one"

      Yes, but it's postincrement, so the result is still C without any added value ;-)

      --
      Sig (appended to the end of comments I post, 54 chars)
    9. Re:It keeps going and going.... by clarkcox3 · · Score: 2, Interesting

      Except that

      (C++)++ invokes undefined behavior, because you're altering the same variable twice before the next sequence point.

      --
      There are no tiger attacks in my area and it's all because this rock I'm holding keeps the tigers away.
    10. Re:It keeps going and going.... by Sri+Lumpa · · Score: 2, Funny

      Or depending on your point of view "C double plus ungood". Let the flamewars begin!

      --
      "The obvious mathematical breakthrough would be development of an easy way to factor large prime numbers." Bill Gates,
  2. why not... by darth_MALL · · Score: 3, Funny

    ...make it like grade school and just give the poor bastard a "B". Enough already ;)

    1. Re:why not... by Tony+Hoyle · · Score: 3, Informative

      B actually existed... it was the language that predated C.

      I've no idea if there was an A though.

    2. Re:why not... by mattdm · · Score: 3, Informative

      The B programming language stemmed from one called BCPL. Therefore, the logical successor is P, not D.

  3. where does the name come from? by newsdee · · Score: 3, Interesting

    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"?)...

    1. Re:where does the name come from? by Joe+Decker · · Score: 5, Informative

      Language revs are often referred to by the year of the completion of their standardizatioin (e.g., C++98.) The next C++ would presumably be somewhere in this decade, e.g., C++05 or so, but of course nobody is sure what year the work would be completed in, ergo C++0x.

    2. Re:where does the name come from? by the_2nd_coming · · Score: 2, Informative

      ummm...no.

      C++98
      C++0x.....the x will be replaced by a numberal for the year that the standard will finaly be ratified.

      --



      I am the Alpha and the Omega-3
    3. Re:where does the name come from? by alefbet · · Score: 4, Interesting

      The current version of C++ is often referred to as C++ 98 because it was finalized in 1998. The next standard should be finalized around 2007ish, so it's sometimes informally referred to as C++0x (think Windows 9x).

      --

      A hack is just an idiom waiting for wider use.
    4. Re:where does the name come from? by MrCocktail · · Score: 5, Insightful

      I too read it as "C++ followed by some hex number to be named later", but after skimming very quickly through the proposal, it seems they meant "C++ (20)0x, where x depends on whatever year the spec/implementation/whatever is released". Or, at least, that's what I think it means.

    5. Re:where does the name come from? by grub · · Score: 3, Funny


      "C++ is to C as Lung Cancer is to Lung"
      - a sig I read on slashdot

      --
      Trolling is a art,
    6. Re:where does the name come from? by JanneM · · Score: 3, Funny

      Hmm. Obscure notation, explained indirectly in a section about something else. Yep, it's a good notation for C++ versioning all right.

      --
      Trust the Computer. The Computer is your friend.
    7. Re:where does the name come from? by Mignon · · Score: 4, Funny
      C++98 ... C++05

      Didn't we learn anything from Y2K? How am I going to tell the difference betwen code written to the C++ 2005 standard and the C++ 1905 standard?

    8. Re:where does the name come from? by jdennett · · Score: 2, Informative

      Yes, it's C++0x for 2000-and-something, because we hope to get the next major revision of the C++ Standard out before 2010. A minor revision is going through the process of being published around now, but that just fixes defects in C++98, as the original ANSI/ISO/IEC 14882:1998 standard is informally know.

    9. Re:where does the name come from? by jdennett · · Score: 2, Informative

      The original C++ is informally known as C++98, because it is defined by the International Standard ISO/IEC 14882:1998 (also adopted by ANSI).

      A minor update to that standard will be published very shortly, depending on how the ISO machine works. That won't be what we're calling C++0x, it'll just be fixes for errors in C++98.

      C++0x is the name given to the next major version of the C++ Standard, and it's some years away yet: expect 'x' to be large! Between now than and then there will be a "technical report", proposing extensions to the C++ library. It is likely to be widely supported, but a "technical report" (often abbreviated to TR) doesn't have the weight of a full ISO standard.

      I really ought to update the comp.std.c++ FAQ to cover this...

  4. Supercalifragilisticexpialidocious! by Dark+Lord+Seth · · Score: 5, Funny
    ISO/IEC JTC1/SC22/WG21

    Someone try to say that ten times fast!

    1. Re:Supercalifragilisticexpialidocious! by paradesign · · Score: 2, Funny
      cheater! i bet you copy/pasted it ten times fast.

      yes, this is supposed to be funny

      --
      I want 2D games back.
  5. C++0x ? by Cipster · · Score: 5, Funny

    Sounds like the l33t version of C++
    The hardest part is deschiphering the comments...

  6. Re:Whatever. by addaon · · Score: 2, Informative

    Um... C is C(\+)*.

    --

    I've had this sig for three days.
  7. Alan by grub · · Score: 4, Funny


    What does Alan C++0x think of this?

    --
    Trolling is a art,
    1. Re:Alan by Alan+C++0x · · Score: 2, Funny

      I'll allow it
      /Mills Lane

  8. Why C didn't progress to D.. by Peter+Cooper · · Score: 2, Interesting

    Everyone knows the history of C, coming from B, which came from A. Sure, an object-oriented version of C might be C++.. but why are we progressing onto C++0x (which reads like 'cocks' to me, anyone else??)? Isn't it time for D? Or is this a marketing/branding thing?

    Either way, it doesn't look too exciting judging from these proposals. It's certainly nothing on the scale of Perl 6 compared to Perl 5, so yeah, maybe I've answered my own question. This is just a routine standards adjustment, rather than a real 'development.'

    1. Re:Why C didn't progress to D.. by vidarh · · Score: 2, Informative
      Sigh... C descended from BCPL, hence the long standing joke from before C++ of whether the next language would be called D or P. However C++0x isn't a new language, it is the working name for the next version of the C++ standard, just as previous C standards are nicknamed C89 and C99 after the language and year they were completed, and the previous version of the C++ standard is often referred to as C++98. The "0x" is meant to reflex that the new version of the standard is likely to be done sometime this decade, without tieing anyone down to a specific year.

      So the "right around the corner" in the article is perhaps a little bit optimistic - they've just barely started working on the new version.

    2. Re:Why C didn't progress to D.. by td · · Score: 4, Informative

      B didn't come from anything called A, but from a language called bon, named for Ken Thompson's wife Bonnie. (At least, that's what Ken says, but he's famous for pulling the legs of people who drool over stupid trivia from his past.) The inspiration for bon was Martin Richards' BCPL, a stripped version of Christopher Strachey's [et al] CPL (Combined Programming Language, I think; the B in BCPL is for Bootstrap or Basic, sources differ.) It doesn't stretch the truth too far to think of B as an even-more stripped down BCPL.

      --
      -Tom Duff
  9. Re:Great... by kannibal_klown · · Score: 2, Informative

    Version 6 sucked A$$, but Vis c++ .Net is actually pretty good. And wtf are you talking about, I've used templates before with .Net (2002 and 2003) and had no problem.

  10. C++0x? by Anonymous Coward · · Score: 5, Funny

    You mean...the successor ISN'T C#?!

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

  11. Re:C++0x? by Randolpho · · Score: 2, Informative

    Already done!

    D Programming Language

    --
    "Times have not become more violent. They have just become more televised."
    -Marilyn Manson
  12. Anonymous array members by Surak · · Score: 4, Interesting

    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;
    }


    vs.


    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?

    1. Re:Anonymous array members by Abcd1234 · · Score: 4, Insightful

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

    2. Re:Anonymous array members by Q+Who · · Score: 2, Insightful

      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.

      You mean like templates, and member function templates, which allow for STL? Or operator overloading and references, which allow for *real* custom types.

      Feel free to give specific examples, Mr. Insightful.

    3. Re:Anonymous array members by statusbar · · Score: 2, Insightful

      The problem is much worst than that.

      sizeof char is defined to be 1

      1 what? 1 char.

      A char is NOT DEFINED TO BE A BYTE (8 bits) in the any standard.

      Almost always it is, though.

      Take a look at the Texas Instruments TMS320C3x family of DSP's. It can do no byte level access. In the c compiler for it, sizeof char is 1 and defines a char as 32 bits. This means sizeof long is 1 and defines 32 bits as well. and this is completely standard compliant!!

      And it also breaks tons of code!

      --jeff++

      --
      ipv6 is my vpn
  13. COBOL by mikeee · · Score: 5, Funny

    I'm still waiting for the object-oriented business programming language, "ADD 1 TO COBOL".

    1. Re:COBOL by Surak · · Score: 4, Interesting

      Actually, there *does* exist an Object-Oriented COBOL. (No, I'm NOT making this up!)

  14. How 'bout range checking like purify? by elwinc · · Score: 3, Interesting

    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.

    --
    --- Often in error; never in doubt!
    1. Re:How 'bout range checking like purify? by mystran · · Score: 2, Informative
      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.

      --
      Software should be free as in speech, but if we also get some free beer, all the better.
  15. Alan C++0X by sulli · · Score: 4, Funny

    This is what happens when he's happy to see you!

    --

    sulli
    RTFJ.
  16. learn from Java by Karma+Sucks · · Score: 3, Insightful

    I think C++ needs stuff *removed* more than it needs anything added.

    --
    (Please browse at -1 to read this comment.)
    1. Re:learn from Java by Hard_Code · · Score: 2, Insightful
      Java didn't get templates. It got generics which are implemented through erasure, not code duplication.

      Unfortunately, generics tend to have a bad reputation because of the way C++ implements them. Bracha maintains that generics as they will appear in Java attempt to fix the shortcomings of C++ templates.

      Bracha pointed out that one problem with C++ templates is code bloat. For every List of type T, C++ generates a separate class. Generics as implemented by JSR-014 will not cause similar bloat: the same class and associated bytecode will work for all Lists of T.
      --

      It's 10 PM. Do you know if you're un-American?
  17. Vaporware? by cybermint · · Score: 2, Informative

    We got the first c++ compiler to handle the whole language just a little over a year ago. (article) I wonder how many decades it will be until we get a compliant compiler for c++r0x0rz.

  18. From Merriam Webster Dictionary... by Demodian · · Score: 2, Funny

    Ox: [definition 1] a domestic bovine mammal

    Just wait until the free standard comes out: C++Gnu

  19. Boost and STL by Homology · · Score: 2, Informative
    Note that parts of Boost library is suggested as part of the new standard :

    N1450 03-0033 A Proposal to Add General Purpose Smart Pointers

    I've used parts Boost quite alot myself (www.boost.org), and found it very useful even when using Visual Studio.

  20. Lots of good papers there by Eustace+Tilley · · Score: 3, Interesting
    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
  21. c += 2 by Doomdark · · Score: 5, Funny
    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++)++)++ ).

    --
    I like paying taxes. With them I buy civilization -- Oliver Wendell Holmes
    1. Re:c += 2 by JanneM · · Score: 5, Funny

      On the other hand, maybe the ((((c++)++)++)++)... system will induce LISP-hackers to take a serious look at the language. /Janne

      --
      Trust the Computer. The Computer is your friend.
    2. Re:c += 2 by BlueWonder · · Score: 2, Informative

      The expression ++c++ is equivalent to ++(c++). Since the postfix increment operator yields an rvalue (unlike the prefix increment operator, which yields an lvalue), ++c++ is not a valid expression in C++.

    3. Re:c += 2 by ReelOddeeo · · Score: 2, Troll

      maybe the ((((c++)++)++)++)... system will induce LISP-hackers to take a serious look at the language.

      That you would say this indicates that you don't really know what Lisp is all about.

      Clue: It is not about parenthesis. It is about langauge semantics.

      Everyone gets so hung up on the surface syntax that they never see what is underneath. Very much like comparing Windows 95 to a Macintosh of the same era. Once you understand the true power of what is underneath, then the syntax has a very strong reason for being. The annoyance of using a somewhat unconventional syntax is vastly outweighed by the power it is exchanged for.

      Don't you think that any serious Lisp user would take a serious look at other languages?

      --

      Those who would give up liberty in exchange for security and DRM should switch to Microsoft Palladium!
    4. Re:c += 2 by RollingThunder · · Score: 3, Funny

      Clue: It is not about parenthesis. It is about langauge semantics.
      And that you would post that indicates that you don't really know what humor is all about.

    5. Re:c += 2 by grazzy · · Score: 3, Funny

      he did mention he knows some basic lisp syntax, that kinda implements nohumor.h

  22. Compiler Compliance by wideBlueSkies · · Score: 3, Interesting

    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.

    --
    Huh?
    1. Re:Compiler Compliance by jdennett · · Score: 2, Informative

      You'll be glad to know that the committee is aware of these issues and gives them more weight than you might believe. C++ doesn't evolve quickly; changes made in the last 6 years are nothing more than fixing defects, and the next standard is probably close to 6 years away.

      The committee is generally not interested in adding features for the sake of adding features. New proposals are expected to fix a documented problem, and to show that they are valuable enough to justify the lack of stability they cause.

      There is also clear recognition among the committee that C++98 was too inventive, and that anything significant that goes into C++0x should do so only after real-world experience with it has been obtained and reviewed. Hence the intention to publish a "technical report" on new library features -- it is likely that this TR will form the basis of much that will end up in C++0x, but its initial publication will not be in the form of an official standard.

  23. Re:C++0x? by nusuth · · Score: 2, Funny

    If there is any progress, the new language should be at least ++C. You see, C++ is better than C but all you have is the C before C++.

    --

    Gentlemen, you can't fight in here, this is the War Room!

  24. SCO by ikewillis · · Score: 4, Interesting
    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.

    1. Re:SCO by Q+Who · · Score: 2, Informative

      That's about Cfront, not ANSI C++ Standard. But I am sure you knew that, and are just karma-whoring.

  25. Re:Great... by Homology · · Score: 2, Informative
    The main difference is partial template specialization, apart from some speed optimizations.

    However, alot of code breaks when moving to VC .NET 2003 : for some reason they decided to remove classic headers, giving us _days_ of work. I've never had so much problems with a compiler as with VC .NET 2003 when trying to just build projects that have worked fine since VC 6.0.

  26. More on D by Randolpho · · Score: 4, Insightful

    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.

    --
    "Times have not become more violent. They have just become more televised."
    -Marilyn Manson
    1. Re:More on D by Homology · · Score: 2, Insightful

      If you remove the preprocessor, you'll wont be able to compile a _great_ many programs without great many changes. C++ has it's root's in C, and it show by it supporting some pretty obscure C constructs. Another use of the preprocessor, that I'm sure you use (unless you're using VC with #pragma once) is somthing like #ifndef __SOMEHEADERFILE_H__ #define __SOMEHEADERFILE_H__ ....... #endif

    2. Re:More on D by gbjbaanb · · Score: 2, Insightful

      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 that java was), ignoring the fact that people use the language to get the job done. If you want to make C++ easier - stop using it! Go get yourself a copy of Visual Basic if you don't want the features C++ offers. You *do* want those features, then learn it, just like all the other C++ programmers have done before you. Too bad that the newbies have to, *gasp* understand what they have to do to make the code work, that they can't just knock up a program in a half-hour without any thought involved. Possibly this is one of the best features of C++ - you can't have any old monkey programming it, not without being found out straight away.

    3. Re:More on D by HeghmoH · · Score: 2, Insightful

      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.

      --
      Mod down posts with a "Free Mac Mini/iPod" sig, they're spam!
    4. Re:More on D by fitten · · Score: 2, Informative

      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.

      Except that with the former, you can debug any time you need to, without using/loading a new (and different) executable. In addition, if you do it right, you can turn debugging on/off in a system without shutting it down (a feature that can be invaluable at times).

      Using #ifdef DEBUG, you, by definition, change the executable, which can change the properties of the execution of the code (things like timing). Ever had a program that worked in debug mode but not -O2 mode? Ever put a printf() into the code that caused it to work but not having it there caused the program to crash? (not talking about using variables before a value is assigned or stack corruption)

      Granted, #ifdef DEBUG can remove code that has cache destroying calls/code in it. However, just because #ifdef DEBUG can be more efficient does not mean that it is always the best approach to the problem.

    5. Re:More on D by Q+Who · · Score: 2, Insightful

      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.

      Why do I have a feeling that you never really used a preprocessor when you do claims like that? Preprocessor is most useful feature, see for example enforcer idiom by Alexandrescu and Marginean, even if it's just for __LINE__ and __FILE__.

      My only complaint for C++ preprocessor is that it's actually C preprocessor, not C++ (performed at the stage before C++ parsing), and is not flexible enough (postponing conditional compilation until macro expansion would be nice).

      There should be a rule... Everyone complaining about C++ should know it. Complain about overloading functions, be ready to cite Chapter 13 of ANSI/ISO C++98... It would really reduce S/N.

    6. Re:More on D by etymxris · · Score: 2, Informative

      Well, there are people who don't like the preprocessor and have been coding for quite a while. I've been coding C++ for 7 years and as time goes on I like the preprocessor less and less. The main reason is that it is an obstacle to tools that help development. One common example is the debugger--not even Microsoft's Visual C++ could render macros transparent.

      Another problem is tools that do automatic code-folding have a much more difficult job with macros. I was using jGRASP because it does a great job of code-folding. The only problem is that it couldn't handle macros. So a macro that expands with a semi-colon to make a complete statement would be seen instead as the first token of the next statement. Now you may fault the programmer for not figuring out how to do code-folding with macros, but I believe the difficulty is inherent in the language itself. In order to handle macros properly, it would have to have a built-in preprocessor.

      The third problem is code I'm reading or writing. It is often infuriating to try to figure out syntax problems that involve macros. The macros are supposed to make things easier, but instead they just make them opaque. One of the worst offenders is MFC, with macros like IMPLEMENT_DYNAMIC and AFX_*.

      It seems problematic that to figure out the proper syntax of the language a preprocessor must be run first. The existence of the preprocessor has many advantages, but it has many detriments too. It invites API programmers to create macro-shortcuts that hide the syntax. These attempts at abstraction introduce all the problems of abstract languages (opaque-ness) while avoiding all the benefits of abstract syntax (safety, simplicity).

  27. Re:Stroustrup's Remove Embarrassments by Eustace+Tilley · · Score: 2, Funny

    C has 15 levels of operator precedence, and you do not blush?

  28. It's great to see some metaprogramming related... by exp(pi*sqrt(163)) · · Score: 4, Interesting
    ...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.

    --
    Doesn't it make you feel good to know that our freedoms are protected by politicans, lawyers and journalists.
  29. Re:Whatever. by jkakar · · Score: 2, Insightful

    I think comments like this are often incorrectly moderated as "Flamebait". The poster makes a good point about practicality, but, at least for myself, practicality isn't enough to keep me happy and motivated. Programming is a craft; a craft involves developing and applying a collection of related and sometimes un-related skills. Craft also involves elegance. Having said all that, certainly one is able to solve many problems in C as in C++. In fact, one could probably argue that any problem solvable in C++ can also be solved in C. The difference is elegance... I think C++ makes it easier to write code that expresses the design aspect of a program without compromising the implementation; thus, well written C++ programs may be more maintainable/understable than well written C programs. Further, the biggest improvements I've made in my own programming ability has been to improve the way I do things I already know how to do; I believe that kind of behaviour has been of more benefit to me in some ways than learning how to do new things. In this sense, C++ is, as advertised, a "better C".

  30. Create a C++ platform like Java by Jack+Greenbaum · · Score: 2, Interesting

    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.

  31. Re:SCO owns nothing but C++rap by WC+as+Kato · · Score: 2, Informative

    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.

    --
    --- I'm Green Hornet's sidekick not Inspector Clouseau's!
  32. Re:how the hell do you pronouce that by Anonymous Coward · · Score: 3, Funny

    I believe it's pronounced "double-plus ungood".

  33. hehe.. sorta by Cthefuture · · Score: 5, Insightful

    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.

    --
    The ratio of people to cake is too big
    1. Re:hehe.. sorta by dusanv · · Score: 2, Interesting

      "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???

    2. Re:hehe.. sorta by Houdini91 · · Score: 2

      So the + operator function doesn't have to construct and return a temporary matrix class just to make matrix3 equal to that temporary class.

      However, as I explained in my previous post, this isn't necessary as modern compilers will optimize the temporary variable away.

      - Houdini

    3. Re:hehe.. sorta by IthnkImParanoid · · Score: 3, Informative

      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?

      --
      It's nothing but crumpled porno and Ayn Rand.
    4. Re:hehe.. sorta by stonecypher · · Score: 2, Insightful

      This sort of statement bugs me. A lot. First, all "real" programming languages are equally powerful -- they are all Turing-equivalent

      This sort of statement bugs me. It's a bit like saying that a Ferrari and a Tyco R/C are equally powerful, because they can both be used to drive a weight load from the house to the grocery store and back.

      The fact of the matter is that there's a little more to it than Turing equivalence. Sure, you could write a massively OO object exchange system in Assembly, or a language metaparser in Visual Basic, or just about anything in Befunge. They're all turing equivalent. For that matter, so is morse code to an interpreter with an abacus over tin cans and string.

      That said, in the real world we need reasonable tools to facilitate development. I have neither the time nor the patience to reinvent each and every wheel in what I make. There's a question of skill: how many of us could remake some of these mechanisms as efficiently, rigorously, or bereft of side effects (hell, even of bugs) as they currently are?

      Ahem, at least if you're not using VC. Scoping problems on for indices, indeed. If you don't know about it, google about it before flaming me, fucktards; it's a known bug with such a history that it's an option in VC.NET that actually comes shipped as default wrong. Borktastic.

      So, look, there's more to it still. Sure, writing in assembly is as turing as writing in Scheme and Haskell. But, look, let's play with C++ for a minute. Because C++ has generic programming that works in one fashion for /everyone/, then this person's template is gonna work with that other person's object. Yeah, if we were idiots, we could all each roll our own each time, but then pretty things like algorithms and iterators and so forth would be a dream.

      The fact of the matter is that if turing equivalence mattered, we'd all still be bootstrapping our mainframes with paper clips. And assembly is dead as an application writing language for a damned good reason.

      Now go back to writing VB and telling yourself that it's no different than C++. We understand.

      - Fatty, King of Contention, Arrogantest Ever (tm)

      --
      StoneCypher is Full of BS
    5. Re:hehe.. sorta by Delphiki · · Score: 2, Insightful
      Oh my god, you've got to be joking. C# and Java murder performance compared to C++. They're ok if the key is to develop quickly. They're bad if the key is to run quickly. So Intel should be pushing hard for more Java and C# since it'll help drive processor demand.

      And guess, what, YES, there are problems which are easier to program in C++ than in C#. My job is mostly programming in C# and I'd rather be programming in C++.

      There is NO one right programming language or even one right type of programming language.

      --

      Feel free to mod me "-1 - Angry Jerk".

    6. Re:hehe.. sorta by Nevyn · · Score: 2, Interesting
      but then what's the point of overloaded operators?
      Indeed, using a function is more readable; more efficent; and allows you to have more than one idea of an add for a complicated type (without doing heniously confusing things with different types on the right hand side), the C programers have been saying this for years.
      --
      ustr: Managed string API with ave. 44% overhead over strdup(), for 0-20B
  34. C++0x's biggest new feature... by Arslan+ibn+Da'ud · · Score: 2, Interesting
    Smart Pointers!!!

    If they can do this right, I'll be very happy. After all, Java's main advantage over C++ is their abstracting away pointers. Course Java is still slow, and that pointer abstraction is expensive, in terms of garbage collection, program speed, and (most important) huge memory footprint. C++ pointers are a major PITA, but they are fast 'n cheap. How fast 'n cheap are smart pointers?????

    --

    Practice Kind Randomness and Beautiful Acts of Nonsense.

    1. Re:C++0x's biggest new feature... by Tony+Hoyle · · Score: 2, Informative

      Smart pointers are relatively trivial to implement using templates, and don't slow things down much (small overhead as the pointer struct is 8 bytes + a trivial copy constructor every time you pass it). You only need a GC to cope with things like loops (a points to b which contains a pointer back to a, which means their reference counts will never be zero). If your careful you can get away without one at all.

      I don't think it impacts memory footprint much... if you remember to set pointers to null when you've finished with them they'll free at roughly the same places as if you did it manually... with the advantage they won't leak if you forget.

    2. Re:C++0x's biggest new feature... by be-fan · · Score: 3, Informative

      Smart pointers are pretty fast and cheap, because they're reference counted. Basically, there are the following costs:

      1) Creating a smart pointer involves an extra heap allocation to allocate a counter. This is necessary because boost's smart pointers (which are the basis of the standard) are non-intrusive --- they don't require giving the target object a special counter. This overhead, can be eliminated by using intersive_ptr, which allows you to put the counter inside the object itself, and provide functions to increment/decrement it.
      2) Copying a smart pointer involves an atomic increment of a counter.
      3) Having a smart pointer go out of scope involves an atomic decrement of a counter.
      4) When the last smart pointer is destructed, an extra heap free is needed to free the counter.

      --
      A deep unwavering belief is a sure sign you're missing something...
    3. Re:C++0x's biggest new feature... by be-fan · · Score: 2, Informative

      You shouldn't set smart pointers to null. That could lead to a bug if you accidentally access it afterwords. Just let the destructor do the work, and make sure you don't create a smart pointer whose scope is much larger than it needs to be. Heck, that's good advice even for regular pointers.

      --
      A deep unwavering belief is a sure sign you're missing something...
  35. How Do You Pronounce That?? by cgifool · · Score: 2, Funny

    "cee plus plus ox?"
    "cox?"
    "kooks?"

  36. Uh, no. by devphil · · Score: 4, Insightful
    Everyone knows the history of C, coming from B, which came from A.

    Everyone but you, friend.

    The language C was descended from the language B, which was descended from the language BCPL. Dennis Ritchie never decided whether C followed B because it was alphabetical (in which case C++ would have been D), or whether C followed B because it was the next letter in BCPL (in which case C++ would have been P).

    As for the C++0x thing, it's quite common to call languages by the year of their standardization, thus "FORTRAN77", "FORTRAN90", "C89", "C99", "C++98". The next cycle for C++ will be completed sometime in the next seven years, but we don't know exactly which year, so "0x".

    Either way, it doesn't look too exciting judging from these proposals. It's certainly nothing on the scale of Perl 6 compared to Perl 5, so yeah, maybe I've answered my own question. This is just a routine standards adjustment, rather than a real 'development.'

    Again, uh, no. If it doesn't look "exciting," perhaps you're simply looking at the wrong proposals. Or perhaps you simply still think of C++ as "C with more type checking, and those // comments."

    The routine standards adjustment came in the form of "TC1", which was just recently published. Basically, "C++98.0.3p4rc2", to put it in Linux terms. Just bugfixes. C++0x is a different story.

    (And I don't know that I'd call Perl 6 particularly innovative, either.)

    --
    You cannot apply a technological solution to a sociological problem. (Edwards' Law)
  37. Re:Whatever. by Austerity+Empowers · · Score: 5, Insightful

    I think C++ is quite useful, and I'm not a "2 week IT person", not that I think they are necessarily inferior beings. On another note, most IT people I know tend to make the most use of Perl/Ruby/Python since it solves most of their problems quickest.

    Straight C is my favorite tool and what I use for embedded programming, quick hacks and performance constrained work. Every time I try to do a large application with it though, I find myself thinking "you know, they already did this exact thing with C++, and I'm going to spend 2 days re-inventing this and testing it".

    I use tidbits of Assembly (80x86, MIPS, Arm, PowerPC, what have you) in embedded systems for device driver or performance critical sections. As a HW engineer I tend to use this a lot in bringup of new designs, especially "very new" designs that don't necessarily work and every instruction is important.

    I use C++ when I am building a very large, flexible application where I use many types of data structures and need it to get up and running in a short period of time. I like this language for "serious application" programming.

    I use Perl to manage my file system, do text processing and other maintenance hacks.

    I use Java for simple GUIs that often work as a front end for serious endeavors.

    I use TCL/TK for ASIC/FGPA debugging (simulator interface) and test suites.

    I use fortran less and less (often I convert to C) for purely numerical computation. Gems of knowledge exist in fortran code for optimized matrix related algorithms that are highly useful in 3D visualization.

    I have not found any practical use for Pascal or Lisp lately (the latter is useful for emacs, but I rarely mess with it).

    The point of all this is that much like you wouldn't use a screwdriver to drive a nail through wood (unless that was all that was available), you would tend to use whatever tool is best suited to a task. Us engineer types are supposed to be tool-makers and users of the highest order. It surprises me when I hear one of us suggest we should use our favorite tool to the exclusion of all others.

    I do not like C++ in terms of the performance and memory impact it infers, but when building large applications I do not have time to re-invent a linked list for the umpteenth time, nor do I want to debug every different link list in my code, there are much harder problems to solve more critical to the success of my project. That said, C++ (and C for that matter) is lacking in some very important things. Among those I think are critical are: multithreading, network stack framework (platform independent that is) and GUI framework (platform independent!). If you read the article, you'll see mention of at least two of those things (we need a standard platform independent GUI library dammit!)

  38. Fragile Base Class problem (whining follows) by mcc · · Score: 2, Interesting

    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.

  39. Useful for structs/unions by crow · · Score: 2, Interesting

    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 #define to simulate the old naming).

    1. Re:Useful for structs/unions by tc · · Score: 3, Insightful

      Until somebody adds a member called 'j' to foo, at which point your code still compiles fine, but is no longer doing what you intended.

    2. Re:Useful for structs/unions by crow · · Score: 2, Insightful

      Actually, if someone adds a member 'j' to foo, then there's no reason to assume it would compile fine. In fact, I would suggest that such a case should be specified as illegal, as it is essentially identical to having two elements of a structure with the same name.

    3. Re:Useful for structs/unions by Quietust · · Score: 2, Informative

      If you're using a Microsoft compiler, you can already do that; don't know if any other compilers have implemented that extension, though...

      --
      * Q
      P.S. If you don't get this note, let me know and I'll write you another.
    4. Re:Useful for structs/unions by SamBeckett · · Score: 2, Informative

      My C++ compiler (g++ 3.1 20020420 (prerelease)) allows this (it is called anonymous unions, structures), etc.

      Thus I can do this:

      class Foo {
      union {
      char bob;
      struct {
      unsigned frank : 4;
      unsigned jim : 4;
      }
      };
      Foo bar;
      and access bob, frank and jim via: bar.bob, bar.frank and bar.jim. :-)

  40. I like by Hard_Code · · Score: 2, Interesting

    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 help...it 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).

    --

    It's 10 PM. Do you know if you're un-American?
  41. C++0x is a Frankenstein Java by Anonymous Coward · · Score: 4, Interesting

    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?

    1. Re:C++0x is a Frankenstein Java by Jagasian · · Score: 2, Insightful

      Ok, the mods must be crazy. This guy might be a troll, but... One thing I would like to point out is that Haskell is by far an "academic" language, if there ever was such a thing. Not sure why the parent poster uses that as an insult about Java's generics.

  42. Re:C++0x? by Anonymous Coward · · Score: 2, Interesting

    From the Jargon:
    C n. [..] 3. The name of a programming language designed by Dennis Ritchie during the early 1970s and immediately used to reimplement Unix; so called because many features derived from an earlier compiler named `B' in commemoration of its parent, BCPL. (BCPL was in turn descended from an earlier Algol-derived language, CPL.) Before Bjarne Stroustrup settled the question by designing C++, there was a humorous debate over whether C's successor should be named `D' or `P'.[..]

  43. So does everyone else. by devphil · · Score: 4, Interesting


    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.

    --
    You cannot apply a technological solution to a sociological problem. (Edwards' Law)
    1. Re:So does everyone else. by zizzo · · Score: 2, Funny

      If I propose you remove operator overloading, can I get my kidney back?

    2. Re:So does everyone else. by buckinm · · Score: 2, Funny

      If I propose you remove operator overloading, can I get my kidney back?

      Actually, you get an extra colon, but you should be able to cast it to any organ you like.

      --
      This isn't any ordinary darkness. It's advanced darkness.
  44. Re:Whatever. by AssFace · · Score: 2, Funny

    everyone knows that JavaScript is where its at.

    I do all my cluster number crunching in JavaScript.

    pure speed baby

    --

    There are some odd things afoot now, in the Villa Straylight.
  45. This will help out companies by Necroman · · Score: 3, Interesting

    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.

    --
    Its not what it is, its something else.
    1. Re:This will help out companies by mstorer3772 · · Score: 2, Informative

      Boost (www.boost.org) has crossplatform libraries for both sockets and threads.

      You're welcome. ;)

      --
      Fooz Meister
    2. Re:This will help out companies by Q+Who · · Score: 2, Informative

      Sounds like you guys need to look at ACE. Multiple platform and implements all sorts of design patterns!

      du -ks /usr/local/ACE_wrappers-5.2.4
      652640 /usr/local/ACE_wrappers-5.2.4

      Just to warn the innocent... (Yes, I know that one can selectively use features, but this gives a perspective, don't you think?)

  46. NULL pointer dereference by virtigex · · Score: 2, Funny

    Obviously this is named after the long tradition in C and C++ of null pointer dereferencing. No C or C++ program is complete without it. The version after this one will be called C++BUFFEROVERFLOWWWWWWWWWWWWWWWWWWWWWWWWWWWWW...

  47. Noooooooo! by timeOday · · Score: 5, Insightful

    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?

    1. Re:Noooooooo! by be-fan · · Score: 4, Insightful

      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.

      --
      A deep unwavering belief is a sure sign you're missing something...
  48. Re:OOP by MagPulse · · Score: 2, Insightful

    If there's a fundamental design goal of C++, it is not to force anything on the programmer. C++ supports procedural (C), OOP (many C++ programs), interface/component-based (COM, XPCOM, and CORBA), and aspect-oriented programming (not widely used yet). It's flexible enough to allow all these and more that are to come.

    Java is a great example of a language that forces OOP on programmers. Most universities are starting students on Java because there are a lot fewer ways to get things done in the language. But experts know how to use the parts of the language that they need, and if C++0x took that power away from them they'd look elsewhere.

    Making small changes to C++ to do things like get it closer to merging with C and improve weaknesses in the library like smart pointers are worthwhile and will directly benefit programmers. I don't understand your logic that any changes have to be large and basically change the nature of the language.

  49. Re:Great... by be-fan · · Score: 2, Informative

    2003 is a great deal better than 2002. The version number of VC++ was only bumped to 7.1 from 7.0, but it was more of a 7.0 to 8.0 increase in compatibility. 7.1 is now on a par with GCC in terms of compatibility.

    --
    A deep unwavering belief is a sure sign you're missing something...
  50. If the differece beween C and C++ ..... by Conspiracy_Of_Doves · · Score: 2, Funny

    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?

  51. Re:Great... by Malc · · Score: 2, Insightful

    Which headers? I see IOSTREAM.H isn't there anymore. All I can say is thank goodness. I've seen so many people in the last 5 years include that file when really they should have been including IOSTREAM. Mixing the iostream libraries can be very bad. Besides, IOSTREAM is more standards compliant than IOSTREAM.H. I've seen people get confused by the documentation and use features of IOSTREAM.H that were completely unportable to other platforms. Now nobody will be confused and development costs are reduced.

    If the upgrade was so expensive, you shouldn't have done it. We're still using MSVC 5 for some products, and MSVC 6 for most of the rest. Some small *new* products are now being developed in MSVC.Net, but we have to consider the cost of having code that might not be portable to older versions of the compiler. The cost of upgrading the older products cannot be justified, so we still use what works.

  52. Re:What C++ really needs to do by slick_rick · · Score: 4, Insightful
    Delphi stomp who what? I think you mean VB an Java, not Delphi. ( I started with Delphi and remember it fondly, but you don't run across it much in the business world and never have). The reason VB succeeded is obvious, however the Java smash is more subtle. The real key in the enterprise is databases. There is no "one true way" of accessing a database through C++ (ALA JDBC or whatever model VB is using these days, it was ADO when I last had a VB contract.)


    The IDEs do also cater to the business community, probably why you don't see more Perl. The fact is "business software" is usually just glue, and Perl/Python/Java/VB/tcl will always be better glue then C++, because they were DESIGNED to be glue and C++ was designed to be the bricks and mortar.


    What I would really like to see in C++ would be compile-time exception enforcement ALA Java. I mean Jesus, when you are trying to work with a class library they can't even document what functions may throw what, how the hell are you supposed to write robust code? In Java this documentation comes for free when you write the function, and is forced to be correct by the compiler.

    --
    apt-get install redhat please god - Me (take it easy, I love Debian)
  53. Re:Lack? by Hard_Code · · Score: 2, Insightful

    Uh, just leaving it as "undefined" so that implemenations MAY (or most probably will not) define some useful behavoir...is far from useful.

    Instead of leaving it as "undefined", they should define it as "If compiled with array range checking so and so exception should be thrown with the name of the variable and line (given debugging info is one)" or something...so that at least it is USEFUL.

    --

    It's 10 PM. Do you know if you're un-American?
  54. TIME TO RETIRE C++ by Anonymous Coward · · Score: 5, Funny

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

    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

  55. A new version of language or filter-busting spam? by PDHoss · · Score: 3, Funny

    T33N 8abes ready for your h0t C++0x !!!

    --
    ======================================
    Writers get in shape by pumping irony.
  56. Just call it E. by robbo · · Score: 3, Funny

    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. ;-)

    --
    So long, and thanks for all the Phish
    1. Re:Just call it E. by mystran · · Score: 2, Funny

      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.

      --
      Software should be free as in speech, but if we also get some free beer, all the better.
  57. Cool by be-fan · · Score: 4, Interesting

    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.

    --
    A deep unwavering belief is a sure sign you're missing something...
    1. Re:Cool by stonecypher · · Score: 2, Informative

      lambdas and metafunctions: boost and spirit. However, I agree with you that they should become core langauge fetaures. Notably, that's what Boost is - a group that's working on implementing, in a rigorous and standard-friendly fashion, potential extensions. it's droolworthy; I'd say even moreso than Loki, though visible policies make other people's code far less painful. (Yay, Phoenix!)

      As far as type inference, I disagree.

      cParentClass * foo = new cChildClass();

      what's the redundancy of cFoo = new Foo(); ? You specify the type of the thing and then identify the creator and pass it information. Because you always have matched types and creators simply says that your code doesn't require some of the more complex leveraging of the language.

      Auto seems convenient at first, but consider the potential for problems. And really, what does it gain you? Five or six keystrokes, in the greater scheme of things, really just isn't that important. Predictability and specificity are, in my opinion, far more important.

      If you're so hard up for horizontal space that you can't make a single definition, stop tabbing 8 spaces, put a using or two in place, or get a bigger monitor. Jeez.

      --
      StoneCypher is Full of BS
  58. C++0x? by zephc · · Score: 2, Funny

    how about a much cuter name, like "Snugglums" or "Bwumpie-poo"?

    --
    "I would say that 99 per cent of what my father has written about his own life is false." - L. Ron Hubbard Jr.
  59. Re:Great... by macrom · · Score: 2, Insightful

    Classic headers (iostream.h, string.h, etc.) were deprecated in the 1998 Standard. You've had 5 years to remove them from your code. If you still have problems because you move to the latest compiler but don't move your code to the latest standards, then you have no one to blame but yourself. Well, maybe your manager, in which case I forgive you.

  60. What about existing proposals? by Chris+Hall · · Score: 3, Funny

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

  61. Re:C++ == Algol++++++++++ by PetWolverine · · Score: 4, Funny

    Maybe B was still short for BCPL, and C is now short for CPL because it's not Basic any more. So next, P would would be short for PL because it's not really combined (?) any more. And finally, L would be for, well, L, because it's not really for programming any more.

    --
    I found the meaning of life the other day, but I had write-only access.
  62. Re:SCO owns nothing but C++rap by catscan2000 · · Score: 2, Funny

    In related news...

    SCO announced earlier this morning that they obtained all rights to the English language from England for an undisclosed amount and plan develop a "reasonable and non-discrimatory" license plan for individuals wishing to communicate using the language. A SCO spokesperson recently told reporters: "We're not after the individual English speakers, so there's no need to worry. It has come to our attention that IBM intentionally placed some English words into the open-source Jive language and is in clear breach of our license with them, forcing us to take them to court for... (cue music and camera zoom-in) One Meelion Dollars."

    Although details are not yet finalized, SCO promises that the royalty for using the English language will be affordable, "something in the ballpark of 3 to 4 cents per word communicated." In that scenario, this news story would cost us several dollars, which is quite cheap and reasonable in this news agency's opinion. More at 11.

  63. Hmm...0x or 1x? by clary · · Score: 2, Interesting

    Can I be considered an old-timer for remembering when Fortran 90 was still the Fortran 8X proposal?

    --

    "Rub her feet." -- L.L.

  64. Why? by GnuVince · · Score: 3, Insightful
    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.

  65. Re:~bs by IWannaBeAnAC · · Score: 2, Informative
    Porting a compiler to a given platform is not just a matter of re-targetting the assembly or object format. Usually there is a ABI, supplied by the vendor, which specifies such things as calling conventions, sizes of data types, and in the Windows case, it also specifies such things as layout of virtual tables (for COM compatability) and more.

    The hard part is not in taking a compiler and getting it to construct Windows executables. The hard part is getting it to cooperate with the existing ABI well enough that you can integrate with the other compilers for the platform. This is much harder to do for Windows than it is for, say, *nix.

    In other words, if Microsoft wanted to make it easy to make 3rd party compilers for the Windows platform, then they could have done so. I am claiming that they instead did the opposite, and made it difficult to construct and maintain a 3rd party compiler. I think even Borland would agree with me on this.

    Is it Sun's fault that MS doesn't have a VB compiler for Solaris?

    No, but in this hypothetical situation, if MS had investigated making a VB compiler for Solaris but gave up because of difficulties imposed by Sun, then some of the blame must go towards Sun.

  66. Re:It's great to see some metaprogramming related. by pmz · · Score: 2, Insightful

    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 intended (structures and functions that use structures), is actually quite refreshing to program in. You know, even Motif (a C library) isn't all that bad, as long as it is used directly without resorting to compulsive-big-clever-framework-because-I'm so-smart-syndrome.

    If you haven't caught on, I don't care for programmers who are so caught up in their genius that they invent these beasts of programs just to make them feel like they are architecting a space station or something. Usually, these are people just out of college, or "experienced" folk too stubborn to see their outside of their fantasy micro-universe. People need to realize that other people have to work with that code, too!

  67. Who cares? by KalvinB · · Score: 4, Informative

    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.

    Ben

  68. Re:OOP by Atzanteol · · Score: 3, Insightful

    Personally, I'd like to see header files go the way of the dodo. Usless, annoying, and repetitive. Why do I need to define my functions twice?

    This is one aspect of Java I appreciated most...

    --
    "Ignorance more frequently begets confidence than does knowledge"

    - Charles Darwin
  69. Re:remove export by devphil · · Score: 2, Interesting


    EDG are some really smart people, but their comments have since then been disproven.

    export in itself (specifically, the idea which export is trying to implement) is a good idea. Where the committee screwed up was mandating its existence without any prior experience.

    Keep in mind that the point of an ISO standard is not to require/"legislate" new ideas, but to standardize existing practice. Everything in C++98 had already existed by the time the standard was even close to being done, except export.

    --
    You cannot apply a technological solution to a sociological problem. (Edwards' Law)
  70. Isn't it obvious? by Gorimek · · Score: 2, Insightful

    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.

  71. Re:OOP by h0ss · · Score: 2, Interesting

    Yeah, it's MUCH more efficient to slog through source code to find out the definition of a function, as opposed to looking in (much more easily read) header files. I doubt I'd be able to write code anywhere near as efficiently if I had to look up function definitions within the code modules themselves.

  72. Re:remove export by Ben+Hutchings · · Score: 2, Informative

    I think that by "EDG comments" you are referring to the paper "Why We Can't Afford Export". This was not actually written by EDG. There was a thread on comp.std.c++ recently which discussed this. You'll need to look at the whole of the first article as it refers to export only in a footnote.