Slashdot Mirror


GCC 4.0 Preview

Reducer2001 writes "News.com is running a story previewing GCC 4.0. A quote from the article says, '(included will be) technology to compile programs written in Fortran 95, an updated version of a decades-old programming language still popular for scientific and technical tasks, Henderson said. And software written in the C++ programming language should run faster--"shockingly better" in a few cases.'"

5 of 684 comments (clear)

  1. This is a troll, right? by devphil · · Score: 5, Interesting


    The gcc team seem to have no respect for legacy code.

    You've got to be fucking kidding me.

    Have a look at the mailing list anytime somebody reports a bug, and the choice is between fixing the bug and changing the ABI. Watch the flamefests erupt.

    (Watch them die down a few days later as one of the brilliant core maintainers manages to do both, with a command-line option to toggle between the default fixed version and the buggy old version.)

    Wait a few months. See a new corner-case weird bug some in. Lather, rinse, repeat.

    Incompatible syntax changes

    Such as...?

    All the ones I can think of were GCC extensions long before they were officially added to the languages. In fact, their presence in GCC actually influences their presence in an official language standard, because that's what the standards bodies do: standardize existing practice.

    The troublesome part is when the syntax as added to the language standard differs from the extension that was originally put in GCC. Then we have to choose which once to support -- because supporting both is often not feasible -- knowing that whatever choice we make, slashdot is going to whinge about it. :-)

    --
    You cannot apply a technological solution to a sociological problem. (Edwards' Law)
  2. Re:Nitpicking by Mad+Merlin · · Score: 5, Interesting
    From what I've seen, ICC is still ahead of GCC, but Intel has actually been putting a fair bit of work into GCC, and this is showing in the newer releases of GCC (mostly with Intel processors however, who would have guessed?), mostly compile time related, but also some optimizations for runtime speed. I'd provide hard numbers, but I don't have ICC or the articles that mentioned such handy.

    No idea about MSVC, it doesn't build very good Linux binaries though anyways.

  3. Re:I just want C++ programs to COMPILE faster by Anonymous Coward · · Score: 5, Interesting

    templates are invaluable, destructors are invaluable, classed arrays (things like vectors instead of pointers) are invaluable, maps are invaluable, etc.

    I'll add a couple things that have been _very_ useful in my experience:

    - the const keyword: if you want to make your codebase a whole lot safer, and compile AND run faster, const is great. (Yes I know it finally became part of the C language with the C99 standard...)

    - the STL. Some love it, some hate it. For my old job (game programmer), it was invaluable. We made extensive use of certain containers, and the algorithms are great. Sure I learned how to write various sort routines in college but I don't even have to think about it when the STL already has an optimal version.

    - operator overloading. Once again, some love it, some hate it. Game programmers deal with vector math and quaternions all the time, so this feature of C++ is put to good use. It makes the code read more like a math equation, instead of stuff like:

    result = vector1.add(vector2);

    There are probably more things that have slipped my mind but those are the ones that jumped out at me right away.

  4. Re:I just want C++ programs to COMPILE faster by captaineo · · Score: 5, Interesting

    This has more to do with the habits of C++ programmers rather than the language itself. If you take a random piece of C code and compile it as C++, it will probably take no more than 2-3x more time (the slowdown being due to a larger compiler binary, more sophisticated type-checking, etc). However what is often considered "good C++ programming style" involves inlining far more code than is the norm for C. (e.g. some STL implementations are entirely inline, whereas it would take a pretty crazy C programmer to implement hash tables and heaps inline). That's what blows up the compile time (and binary size).

    The extra compile time buys you more inlining (which can be either good or bad for performance, depending on cache behavior) and also type-safe templates which are not acheivable in C (without ugly hacks).

  5. Re:Can anyone elaborate on this LLVM v. RMS issue? by Anonymous Coward · · Score: 5, Interesting

    Over time, many companies have tried to make money off of portions of gcc without giving anything back to the community. For example, one of the Edison Group's C++ front-ends can be patched onto gcc, giving a "free" compiler for many platforms without giving a better C++ front-end to gcc. Currently, only an end user can patch gcc to work with that front-end. That restriction makes the product less attractive.

    Because of this history, RMS does not want to make it easier for companies to take from gcc without giving back. LLVM would provide a clean interface between portions of gcc, and that clean interface could be so abused.

    Remember that gcc has Objective-C support only because NeXT was forced to abide by the GNU GPL. Large portions of gcc were contributed by volunteers under the terms of the GNU GPL; their work was donated with the expectation that others' work would be made available. Many would see LLVM as a betrayal of that expectation. The next version of the GPL may address this issue...