Follow Slashdot stories on Twitter

 


Forgot your password?
Close
typodupeerror
×
Programming IT Technology

Standard C++ Moves Beyond Vapor 415

Posted by Hemos from the crying-and-squalling-into-the-world dept.
An Anonymous Coward++ writes "This google thread announces the first C++ compiler that can actually handle the whole language (we'd been waiting for half a decade here). The company that did it is EDG. They're a tiny outfit, but they're apparently also behind the Intel compiler (both on Windows with Visual C++ extensions, and on Linux with GCC extensions). There are rumors they can compile the Linux kernel too."
This discussion has been archived. No new comments can be posted.

Standard C++ Moves Beyond Vapor More

Standard C++ Moves Beyond Vapor

Comments Filter:

  • 10? (Score:3, Funny)

    by sean23007 ( 143364 ) on Saturday May 11, 2002 @02:21PM (#3503000) Homepage Journal
    This includes the first C++ compiler that fully implements the 1998 ISO/ANSI C++ standard (including "export")

    1998. Ten years, eh? Oh wait- what year is it again?
    • ignore that. the guy at the computer next to me read it to me and either i misinterpreted him or he misspoke. damn it.

  • C+_ (Score:3, Funny)

    by Second_Derivative ( 257815 ) on Saturday May 11, 2002 @02:22PM (#3503001)
    We have here to my knowledge the first known /. misspelling of a story TITLE

    Yeah, well done, 'editors' ;)

    - S_D
    Has Karma to blow

  • linux kernel (Score:3, Funny)

    by Anonymous Coward on Saturday May 11, 2002 @02:22PM (#3503002)
    "There are rumors they can compile the Linux kernel too"

    Finally!! Someone pulled it off!

  • GCC is missing stuff? (Score:4, Interesting)

    by stonecypher ( 118140 ) <`moc.liamg' `ta' `rehpycenots'> on Saturday May 11, 2002 @02:23PM (#3503004) Homepage Journal
    If so, where can I go to find out what GCC is missing?

    (I had to write this three times because of that damn 20 second after reply widget. Thanks, trolls.)
    • GCC code is slow.

      I code computationally intensive number crunching code and I had to buy Intel's compiler for Intel and Compaq's compiler for Alpha just to get some performance. And I'm talking about 10-20% difference.

      • GCC code is slow.

        I code computationally intensive number crunching code and I had to buy Intel's compiler for Intel and Compaq's compiler for Alpha just to get some performance. And I'm talking about 10-20% difference.

        Then you should like GCC 3.1. Here is a snippet from the changelog (you can see the entire list of changes at http://gcc.gnu.org/gcc-3.1/changes.html [gnu.org]):

        • According to the SPECInt2000 results on an AMD Athlon CPU, the code generated by GCC 3.1 is 6% faster on the average (8.2% faster with profile feedback) compared to GCC 3.0. The code produced by GCC 3.0 is about 2.1% faster compared to 2.95.3. Tests were done using the -O2 -march=athlon command-line options.
        • The compiler now supports MMX, 3DNow!, SSE, and SSE2 instructions. Options -mmmx, -m3dnow, -msse, and -msse2 will enable the respective instruction sets. Intel C++ compatible MMX/3DNow!/SSE intrics are implemented. SSE2 intrics will be added in next major release.
        • Following those improvements, targets for Pentium MMX, K6-2, K6-3, Pentium III, Pentium 4, and Athlon 4 Mobile/XP/MP were added. Refer to the documentation on -march= and -mcpu= options for details.
        • For those targets that support it, -mfpmath=sse will cause the compiler to generate SSE/SSE2 instructions for floating point math instead of x87 instructions. Usually, this will lead to quicker code -- especially on the Pentium 4. Note that only scalar floating point instructions are used and GCC does not exploit SIMD features yet.
        • Prefetch support has been added to the Pentium III, Pentium 4, K6-2, K6-3, and Athlon series.
        • Code generated for floating point to integer converisons has been improved leading to better performance of many 3D applications.
        There is also AltiVec support for the PowerPC now. You can also trying using -fprofile-arcs, run your program once, then recompile with -fbranch-probabilities to help GCC predict branches (but then again if all your code does is crunch large numbers, there might not be too many branches in the first place).
      • I believe the alpha version of gcc has had some optimization problems for some time. I remember reading here back in 99 about a %40-50 performance hit for standard c code. This created headaches for alphalinux. If you compilied the code with gcc the kernel would be as slow as mollasis. The problem is that most hackers who write gcc have intel based machines. The rest use a few sparcs and powerpc's from apple since they can compile the code more optimally for their platforms. This is why many risc linux users still avoid using alpha's. I know there was a similiar problem for powerpc linux a couple of years ago until enough programers bought some macs and fixed it.

    • Re:GCC is missing stuff? (Score:5, Informative)

      by norwoodites ( 226775 ) <pinskia.gmail@com> on Saturday May 11, 2002 @02:33PM (#3503051) Journal
      gcc is missing export and some other stuff see http://gcc.gnu.org/bugs.html for more examples of what is missing, scroll down.

    • Re:GCC is missing stuff? (Score:5, Informative)

      by RealityThreek ( 534082 ) on Saturday May 11, 2002 @02:37PM (#3503069)
      Go buy the newest version of Bjarne Strostrup's book, and try out his example programs in the majority of C++ compilers.

      You'd be amazed at how much has been missing. Mainly the STL stuff, but there's some bugs in templating in some compilers too.

      It sucks when you try to write portable code in C++ and you end up not being able to use some cool stuff because not all compilers support it. A friend of mine switched to Java specificly because of this.

      • Re:GCC is missing stuff? (Score:3, Informative)

        by stripes ( 3681 )
        You'd be amazed at how much has been missing. Mainly the STL stuff, but there's some bugs in templating in some compilers too.

        I don't think gcc is missing any of the STL stuff anymore (or rather the includes and libg++). GCC does have trouble with some of the "new" namespace stuff, and some edge cases in the type system can do the wrong thing (however they are far enough on the edge that maybe I was wrong about them, not gcc).

        It sucks when you try to write portable code in C++ and you end up not being able to use some cool stuff because not all compilers support it. A friend of mine switched to Java specificly because of this.

        Well that is the nice thing about pushing all the complexity into the libraries (yes Java is a more complex language the C...but less then C++ or Perl). Hmmm, speaking of Perl (or even Intercal...) it is also an advantage of really only having one implementation too...

    • where can I go to find out what GCC is missing?

      "Testing C++ Compilers for ISO Language Conformance" (Dr. Dobb's Journal, May 2002). This article introduces a Python framework that uses example code from the standard. Article and partial code available [clemson.edu]. Compilers include: GCC 3.0, 2.96, 2.95; Borland 5.5; VC++ 6.0.

      "C++ Conformance Roundup" (C/C++ User's Journal, April 2001). This article, referenced by the previous article, analyzed results from Dinkumware [dinkumware.com], Perennial [peren.com], and Plum Hall [plumhall.com]. Compilers include: IBM, Sun, Metrowerks, Intel and KAI, MS, GNU, Borland, and Comeau.

    • Exported templates, universal character names in identifiers, and a few less important things. As of 3.1, gcc has a pretty complete standard library.

  • You mean usenet (Score:2, Insightful)

    by Anonymous Coward
    It's a usenet thread, not a google thread.

    • Re:You mean usenet (Score:4, Funny)

      by Anonymous Coward on Saturday May 11, 2002 @03:00PM (#3503160)
      There was a time when it was called usenet. Unless you have been living in a cave you will know that Google bought the usenet and renamed it to google groups.
      • Blockquoth the poster:

        There was a time when it was called usenet. Unless you have been living in a cave you will know that Google bought the usenet and renamed it to google groups.


        Uhm. Here, I must disagree with you. They didn't "Buy the USENET" in the same way that it is impossible to "Buy the web" or "Buy Email."

        They did, however, successfully purchase an archive of the last twenty years of USENET posts, and currently archive all USENET posts made today. Their copy/mirror of USENET is called "Google Groups."
  • So up until now all compilers have been incomplete? What insanely great features have had to be left out because of this? I'm not a developer, so I'm more than a little ignorant. Mainly I'm just wondering if this will allow fewer lines in the same code, shorter compile times, etc...
    • so far, c++ code hasnt been very portable among different compilers (even different versions of the same compiler... i've got plenty of textbook code around that compiles under the g++ 2.x series, but not g++ 3)

      They all don't properly implement different parts of the standard, which leads to all sorts of cross platform issues.

      It's about time someone has done something about it. EDG is no small name in the compiler world either..

      • compiles under the g++ 2.x series, but not g++ 3)

        Then:

        a) It's not ISO C++ compliant code: you should sell them, or throw them out, or burn them, or something.

        or

        b) It's a regression in GCC. In which case you should report it to the GCC team. They are very concerned with regressions, and work hard to make them go away (the release of 3.1 is currently blocked on a small handful of regressions)

        Given that it's a textbook, and textbook code is usually pretty trivial, I'm leaning highly towards (a) as the correct answer.

        ISO C++ broke a lot of old (pre-Standard) C++ code. Them's the breaks. But I've written a ~18K line C++ program (using modern features like the STL, dynamic_cast, etc) that runs on egcs 1.1.2 up to gcc 3.0.4, and over half a dozen commercial compilers, including VC7. Portability is entirely possible, it just needs some care, just like it does with C or Perl.

    • Not much (Score:4, Interesting)

      by Bastian ( 66383 ) on Saturday May 11, 2002 @02:43PM (#3503094)
      Unless a few of the unimplemented language features have uses that nobody has thought of (not entirely unlikely since this is the first compiler I know of that supports all of them), I doubt it will make a huge difference for most coders. C++ programmers have gotten along fine without them thus far.

      However, it is nice to see that they have made it in. Maybe now other groups will start imlementing the full language, too.

    • Missing Features List As Of Last Year (Score:5, Informative)

      by Carnage4Life ( 106069 ) on Saturday May 11, 2002 @03:32PM (#3503270) Homepage Journal
      Read the test results [cuj.com] of the C/C++ User Journal's compiler roundup [cuj.com].
    • You should take a look a the Mozilla C++ Portability Guide [mozilla.org]. It's quite depressing.

      • Re:Mozilla C++ Portability Guide (Score:2, Informative)

        by Anonymous Coward
        yes that IS depressing. Most of the things I do to help me keep bugs down are "dont's" and the things I dont do to keep bugs down are "do's". My favorite out of that list HAS to be #if 0. I never never never never ever use that. Why? Im lazy. It will never get put back in correctly. I would ask a better question when you use #if 0. Why in THE HELL are you checking in code that does not work? You obviously KNOW it doesn't work. Why are you checking it in? Open another file plop the code in there. Take it out of the other file and do not be so sloppy. Had one programmer that did the #if 0 'trick' quite a bit. He left the project (then the company). But we were stuck with LARGE chunks of code we were not quite sure how they hell it even compiled. Im talking 20 pages of commented out stuff. When we found those little gems we were ready to kill. If it doesn't work take it out... Extra junk laying around in a file makes a already tough job even harder!
      • While I agree that the state of C++ compilers could be a lot better (more power to EDG!), the Mozilla C++ Portability Guide is seriously outdated. It is by now 4 years old, and it shows. The claims about the HP compiler, for instance, apply to the previous compiler. No, not just the previous version, the previous compiler, for which HP has discontinued all support some time ago already. Actually, even back in April 98, HP's CC compiler was already being phased out and replaced by the much much better aCC one. Actually, we made the switch some time (I don't recall exactly) before the start of my current project in September of 1997.

      • I really dislike portability guides like that.

        We're using C++, but we're not supposed to use templates, exceptions, RTTI? Am I allowed to use a class, or do I have to write pure C with a .cpp extension, FFS?

        That sort of limitation was relevant five years ago. Today, the vast majority of compilers on all major platforms handle the vast majority of such functionality quite happily. Most rules banning templates, exceptions, etc. are out of date and inappropriate for the target readership. Don't use particularly devious template tricks, sure; it'll be another couple of years before it's safe to use Alexandrescu-esque techniques in code that must be portable across several compilers. But banning templates altogether (and presumably the whole STL and IOStreams libraries with them)? That's just silly.

    • Re:what am I missing? (Score:2, Informative)

      by Josh ( 2625 )
      The implementation of the 'export' feature for templates has been missing from most compilers. Having it enables projects to possibly compile faster and with less code bloat in the binaries. Using templates often leads to faster executables than other strategies for doing the same thing.
  • Thats surely not written in C++, or is it?
    OMG, i have been programming the device drivers in C !! 8-o
    • C, at least the C code in the kernel, is a subset of C++ (with some gcc specific stuff), so it should compile if they implemented all of the gcc extensions. C99 is not a proper subset of C++, but I'm not aware of any C99 code in the kernel.

  • Ahhh (Score:2, Funny)

    by PhoenxHwk ( 254106 )
    Wow! A compiler! Now all we need is a language whose syntax makes sense! I have an easier time coding in Perl than trying to use the bloody C++ STL.

    • Re:Ahhh (Score:3, Interesting)

      by ZxCv ( 6138 )
      .... Now all we need is a language whose syntax makes sense! ....

      Which is the exact reason I've moved pretty much completely to Objective-C. After cursing C++ for years, I've finally found peace with a C-like, object-oriented language that makes sense. I learned Obj-C when I was getting familiar with OS X development, and I haven't used C++ on anything since, on any platform. Obviously, I still have to maintain plenty of C++ code, but as time goes on, that amount will become less and less and eventually, I'll be rid of C++ forever!
      • Objective C is even worse.
        It is a compelete hack around C, its the slowness of Smalltalk, with a syntax as ugly as C++ and even worse.
        Move to Python, Smalltalk or Lisp instead.
    • Like scheme?
    • Because it lets you do complicated things. Part of the problem is I don't think anyone (including Stroustrup) have any idea of all the complicated things you can do with it. I'd be surprised to find a university course on the topic that even scratches the surface of what is possible with it. A major part of the problem has been what this story's about; no compiler implemented all the language features and the features there were implemented were not implemented correctly.

      If you want to see some of the really weird thigns you can do with the language, check out Andre Alexandrescu's "Modern C++ Design." You might also want to look at the signal system that gtk-- uses. Yes, it can lead to a twisty maze of templates, but it also affords some very powerful type checking, which I miss when moving to languages like Scheme or Java.

      • Because it lets you do complicated things. Part of the problem is I don't think anyone (including Stroustrup) have any idea of all the complicated things you can do with it.

        That at least use to be true. In interviews the guy that designed the STL (Steponov?) shocked Stroustrop -- he didn't think anything like the STL could be implemented in C++ (and it turns out he was partly right, there were some minor language changes to make the STL work, and some bigger changes to make it work better/be simpler to implement).

        If you want to see some of the really weird things you can do with the language, check out Andre Alexandrescu's "Modern C++ Design." You might also want to look at the signal system that gtk-- uses.

        I'm just forced to add "Me too!" here. I miss gtk--'s signal system when using ObjC or pretty much anything else...and Modern C++ design is just chock full of interesting ideas that will totally drive maintance programmers apeshit.

      • Part of the problem is I don't think anyone (including Stroustrup) have any idea of all the complicated things you can do with it.

        Quite true... if memory serves me right in The C++ Programming Language Stroustrup actually says he does not consider himself an expert at C++. It's pretty much humanly impossible (IMHO) to know the entire language and make proper use of it 100% of the time. I smile to myself everytime I see young programmers fresh out of college calling themselves C++ experts.
      • I think you're missing the point. "Doing complex things" is not the gaol of a good language -- "doing complex things simply" is. And those of us who have waded through "powerful" C++ code can all attest to how refreshing it is to see normal structured C code. :)
    • slow on the uptake I'm only now realizing that C++ is a topic of some fea^H^H^H^H controversy on slashdot.

      C++ syntax makes perfect sense. There are no arbitrary relationships. As a multi-paradigm language it allows you to choose a subset of features for a given product, depending on what you need.

      You do not need the STL to write C++ code. However, you are crazy not to use it, becuase they are generally excellently implemented collections useable in any program... and the STL is an elegant flexible system. Like most great feats of software engineering you have to think it's way to get it to work, and then it is your friend.

      I'm starting to get a big laugh forming for all the complaints of C++ just being too darn hard. Why do I not find it hard? Do I know restraint? Do I just get it? Bad taste? Infinite wisdom?

      I can but wonder, will I lose or gain karma for speaking well of noble C++!
      • C++ syntax makes perfect sense. There are no arbitrary relationships. As a multi-paradigm language it allows you to choose a subset of features for a given product, depending on what you need.

        Bless you. As far as I am concerned, C++ is still the greatest open standard we have. There will always be "best of breed" languages which are stronger in their own field of affairs: its hard to beat Perl for text, or Haskell for maths. But as a resolutely general-purpose language, which is owned by nobody except its users, C++ remains the first and best of its kind.

        I still don't think we have explored even half its potential: it'll be interesting to see what contribution a truly standard-compliant compiler makes to this.

  • C+_ (Score:2, Funny)

    by CptNoSkill ( 528594 )
    It is good to see the conspiracy of silence finally ended. I have been using this program language since it was started, and finally to see C+_ to get the respect it deserves.I'd say it is the greatest... wait a minute, C++ where the hell did that come from??? Damn, slashdot, covering up the real "C+_" with the fake C++ language,can you say
    C-O-N-spiracy

  • From Later in the Thread (Score:5, Informative)

    by Ieshan ( 409693 ) <ieshan@gmai[ ]om ['l.c' in gap]> on Saturday May 11, 2002 @02:47PM (#3503114) Homepage Journal
    "The product Edison sells is basically just the front end. Someone needs
    to add a code generator, libraries, support tools, etc. to produce
    a complete compiler package. (We use the Edison front end for our
    compiler product at Concurrent, so hopefully we'll have all these
    nifty features someday - but everyone should be sure they don't
    interpret this casual comment as an official promise - I don't even
    work on the compiler :-)."

    I dont know how right this guy is, and I have no expertise in the area myself... but isn't this exactly what we're doing with this slash story? Interpretting this comment as an official promise?

    • More information: what this really means (Score:4, Informative)

      by Anonymous Brave Guy ( 457657 ) on Saturday May 11, 2002 @05:31PM (#3503646)

      <sigh>Once again my story gets rejected when it contains more info than the one that gets posted. :-(

      To set the record straight, EDG [edg.com] do indeed produce C++ front end compiler tools, and it is these that have just been released.

      However, major C++ vendors including Comeau Computing [comeaucomputing.com] use that in their compilers. Comeau already have a beta of their 4.3.0 compiler available at their on-line compiler [comeaucomputing.com]. The full version is due later this month.

      Dinkumware [dinkumware.com] have also announced a version of their standard library implementation to work with Comeau, which should be available shortly after the Comeau compiler is released. Apparently, it makes extensive use of export, but for little change in performance at compile-time.

      That makes their new library implementation a bit academic as far as Joe Developer goes. However, it's excellent news in general, because it shows that using export isn't going to entail a performance hit. We can finally write template code with interface and implementation properly separated out.

  • Sun and Java vs. C++ (Score:3, Interesting)

    by sterno ( 16320 ) on Saturday May 11, 2002 @03:07PM (#3503183) Homepage
    Sun is constantly talking about protecting the Java language for the sake of humanity. I find it rather amusing, by comparison, that C++ is so out there in the open that it took 5 years to actually get a complete implementation of it. Evidence that such tight controls aren't necessary to make a language stable and long lasting?

  • Great. (Score:2, Funny)

    by MadFarmAnimalz ( 460972 )
    Wonder how long the man page is.

    The man page for gcc is bad enough... They could write something like "I love VB" somewhere in the midst of the thing and no one would ever get that far...

    Hmm.

  • Uh, ze linux kernel isn't written in C++, it is written in C.

    Also, linux (kernel) uses a bunch of (proprietary to GCC :) extensions to C that no other compiler has, so this compiler hasn't a hope in hell of compiling the kernel.

    You need to realize that most low-level stuff isn't written in C++ (ie kernels, device drivers, TCP/IP stack, Apache, Perl, Python etc). C++ simply does not have the efficiency. I'm not saying C++ is slow, just that it isn't suitable for that kind of programming.


    • You need to realize that most low-level stuff isn't written in C++ (ie kernels, device drivers, TCP/IP stack, Apache, Perl, Python etc). C++ simply does not have the efficiency. I'm not saying C++ is slow, just that it isn't suitable for that kind of programming.
      Uh.. I don't really agree with that. There is no inherent slowness in C++. Consider that many of the larger C projects use C in a kind of OO way (ie. structs with function pointers can be thought of as objects). There is no speed advantage in executing a function via a pointer in a struct compared to executing a non virtual method in a C++ object. The difference is that in C++ the compiler does a lot of the work for you behind the scenes, thus saving your time. The reason C is used lies mainly in the fact that many programmers are more used to it than C++. And for the projects you mention, they were all started quite a long time ago, when the GNU C++ really was nothing to cheer about. And also that C compilers exist for more platforms than C++ compilers, so if maximum portability is your priority number 1, plain C may be a better choice.

      In fact, I remember there were some discussion on the python mailing lists that a future version of python should perhaps be implemented in C++. Apparently it turned out that Jython (the implementation of python in Java) is a lot cleaner than the classical Cpython, largely because the OO features in Java made a much cleaner design possible.

  • A replacement for C++ (Score:3, Funny)

    by Anonymous Coward on Saturday May 11, 2002 @03:31PM (#3503264)
    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 "classes" out of his code, and then manipulates these "classes". Since I'm assuming that you, dear reader, are as skilled at programming as I am, I'll skip further explanation of these "classes".

    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 existance, 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 aquainted 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 klunky double-pluses.) Its biggest strength is that it abandons an OOPS-style of programming. No more awkward "objects" or "classes". Instead C uses what are called structs. Vaguely similiar to a C++ "class", a struct does away with anachonisms like inheiritance, 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 stablity rivalling 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 langauage.

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

    • Re:A replacement for C++ (Score:2, Interesting)

      by Anonymous Coward
      Dude! You totally ripped that off from an earlier comment attached to this story!

      Wow, good use of plagarism!

  • Info available on EDG's website (Score:4, Informative)

    by xphase ( 56482 ) on Saturday May 11, 2002 @04:23PM (#3503476)
    For those who don't trust a google discussion(like me), EDG's website has info here:
    Supported C++ and C Language Features [edg.com]

    This page also says:

    There is also a GNU C compatibility mode, which provides the extensions supported by GCC (version 3.0.1), along with various undocumented features and bugs. The compatibility is good enough that the front end can compile the Linux kernel and utilities. At present, there is no g++ mode, i.e., no way to enable GNU extensions and C++ mode at the same time.

    --xPhase

  • It's a pity that the standard is broken. (Score:4, Insightful)

    by Ungrounded Lightning ( 62228 ) on Saturday May 11, 2002 @06:20PM (#3503811) Journal
    Congratulations to the Edison Design Group. An awesome job.

    It's too bad that the standard itself is broken...

    In case you're interested: The issue is a deceptively fine point in constructor/destructor semantics. The current standard allows behavior that massively breaks a bunch of stuff you'd have been able to do if it had required behavior that conformed with the rest of the philosophy of the language. It is this:

    You have a class base class with,

    a virtual member function and,

    a constructor that,

    exports a copy of the pointer to the instance under construction (which is stored externally), and

    a derived class with,

    a member variable of a class-with-construction type, and

    an overriding of the virtual function, and

    the constructor of the derived class's member variable (or something it calls, or some other member-variable initialization) gets hold of the pointer and,

    calls the virtual member function.
    Does it get the base class version, derived class version, or go wonky?

    Similarly during DEstruction of the member variables (i.e. after the derived class destructor but before the base class destructor).

    My claim is that the standard SHOULD explicitly specify the behavior as follows:

    The result of a virtual member function call is defined from the execution of the first line of any constructor of the class through the execution of the last line of the destructor, at the most-baseward class where the virtual member function has a defined behavior (unless a more derived class overrides the function to again be pure virtual, and this is allowed).

    The result of a virtual member function call to a virtual member function that is overridden in a derived class is the derived class behavior if the function is called during or after the execution of the first line of any constructor and before or during the execution of the last line of the destructor (unless a more derived class overrides the function again), the base class behavior if called before the first line of a derived class constructor or after the last line of the derived class destructor.

    In other words: Member variable constructors/destructors (and everything else executing at that time) "see" the base class.

    Instead we have this: With respect to calling virtual member functions during construction the early language definition and first ANSI standard said the behavior was undefined. The "final" standard essentially says "don't do that". I'm not sure what current compilers do. But when I checked about ten years ago, of the four binary combinations of whether constructors and destructors got it "right" or "wrong":

    cfront (and cfront-derived compilers at Sun and SGI) got it "wrong" one way.

    three compilers for PCs got it "wrong" a second way.

    g++ got it "wrong" the third way.

    Now the semantics I've described are very powerful and create a consistent object model.

    Up to the beginning of the user-written code of the constructor through the end of the user-written code of the destructor the instance is a collection of components - base classes, member variables - which have their own internally-consistent behaviors. It is wrong to execute the derived-class member function, because the derived class instance doesn't exist yet. But it is right to execute the base-class member function, because the base class DOES exist and IS initialized.

    After the execution of the constructor and before the execution of the destructor the derived-class instance is a fully-constructed and initialized member of the derived class. It might later be hammered into a new shape by serving as a component of a more-derived class, but for now it's consistent.

    During the constructors the components are pulled together into a whole, and during the destructor they're disassembled into their components. But the constructors and destructor are aware of the state of the assembly, and can use care not to let a derived-class virtual member function be executed until everything it depends on is ready, or co-operate with it by passing it flags to inform it of construction progress.

    I won't go into all the things this enables. But I will note that it would make C++ more consistent and more powerful for object-oriented programming than other contenders, which also do this "wrong". (For instance: Smalltalk has the derived-class ("subclass") behavior during the base-class ("superclass") construction. This risks breaking the consistency of already-debugged construction code whenever a method is overridden and requiring those coding to constantly recheck code outside their new class' modularity boundary.)

    Since the behavior I want is a legal option within the standard, perhaps the Edison Design Group might be willing to give me a compiler switch or pragma ("object_construction_semantics"?) to cause their compiler to generate it?

    Pretty please?

  • >harsh restrictions of the BSD license. It also lacks >the GPLs requirement that anything coded with its >tools becomes property of the FSF. You have this totally backwards. The GPL only says that if you modify the source code of a GPL program amd redistribute it - you must make the orginal code available to the end user. What you use a GPL'd piece of software for is up to you. Furthermore GPL'd software is NOT property of FSF unless you decide to give them those rights. otherwise the copyright is held by the orginal author.
  • I cannot even begin to count how many times I have wanted to do something along these lines. Keeping everything nice and separated. Instead, the only way to make this work is to include Foo.cpp in main.cpp, which is well, retarded. C++ needs some serious work with templates... so is something like this fixed? Or does it contain some abiguity that I am not aware of?

    /* Foo.h */
    template<class T>
    class Foo {
    public:
    Foo(void);
    void doSomething(void);
    T bar;
    };

    /* Foo.cpp */
    #include"Foo.h"
    template<class T>
    Foo<T>::Foo(void) { /* Do magic here. */ }
    template<class T>
    void Foo<T>::doSomething(void) { /* Do magic here. */ }

    /* main.cpp */
    #include"Foo.h"
    int main(int argc, char *argv[]) {
    Foo<int> *foo;
    foo=new Foo<int>();
    foo->doSomething();
    }

  • EDG's role (Score:4, Informative)

    by Animats ( 122034 ) on Saturday May 11, 2002 @07:46PM (#3504088) Homepage
    As others have mentioned, Edison only does the front end. The output is an intermediate form, not object code. There aren't very many C++ parsers. GCC has one, Microsoft has one, and most of the other compilers use the EDG front end.

    It says something about how complex C++ syntax has become that this is the case. It's very hard to parse C++, because you have to do extensive declaration handling to find out what's a type name, and you have to know what's a type name just to parse. C++ is thus context-dependent.

    One major implication of that context-dependency is that you can't parse a C++ text file without processing the include files. This is why tools like "indent" are hard to find for C++. "Little" tools for C++ are rare. And that hurts the language.

    I'd like to see a cleanup of C++, but it's not going to happen. Most of the action in the C++ standards effort is going into adding obscure features for fancy templates. As a result, C# and Java are gaining market share.

  • ObjC (Score:3, Interesting)

    by theolein ( 316044 ) on Saturday May 11, 2002 @08:42PM (#3504242) Journal
    I am not in any way a C++ programmer. The only thing I've ever read my way through is the Bruce Eckel's book. That was enough for me. I know some Java and C and was starting to learn how to go further on Mac OSX (which uses GCC) and was wondering whether to go with C++ or ObjC. One little trial programme in both and I went with ObjC. It *is* a lot easier, especially if you know some Java and has similar dynamic features. I don't know enough to comment on whther C++ is faster or not but it defintely has a very difficult syntax for beginners.

    Although I agree with the OSS crowd that Java should also be opensourced, it is at least a standard and this is a godsend for someone learning the language. In C++ the problem with learning it is whose version do you learn? Microsoft's? GCC? What are the fine points of symantic differences inbetween the differing versions? ObjC has this problem as well but since it's only heavily used on OSx at the moment it is not so critical, but if GNUStep were to more successful for instance there might arise differnces there as well (infighting over GCC ObjC compilation with Apple etc). I personally wish for more standards in these heavily used languages although I don't suppose it'll happen anytime soon.
  • June's DDJ (#337) has a pretty good article in it about C++ conformance and actually goes on to test a series of compilers for standards compliance. Pick up the magazine and read the article which was pretty interesting because they used Python to write a test framework that could be used with different compilers and different operating systems. They tested compilers on Solaris, Linux, and Windows2000. GCC 3.04 ended up with the highest passing percentage while VC++ ended up with the worst. They didn't include either the DDJ compiler or Intel's which was one I was especially curious about considering I just got a demo of it.

  • Yawn! (Score:3, Interesting)

    by McDoobie ( 409584 ) on Sunday May 12, 2002 @03:15AM (#3505089)
    Ada95 has had fully compliant compilers(plural) since at least 1995.(When it was Internationally standardized.)

    Java has at least a coherent standard. And Common Lisp has been there for almost 20 years now.

    It's funny to watch the members of the C/C++ Gestapo wet thier pants over this. I bet Bjorne is doing a double-take right about now.

Slashdot Top Deals

6.023 x 10 to the 23rd power alligator pears = Avocado's number

Close