Slashdot Mirror


GCC Switches From C to C++

According to a post on the GNU Compiler Collection list, GCC is now built as a C++ program by default. This is the fruition of much effort, and the goal now is to clean up the GCC internals that are reportedly pretty type-unsafe by rewriting them using C++ classes and templates.

45 of 406 comments (clear)

  1. Re:too bad GCC is not relevant anymore thanks to L by DeathToBill · · Score: 5, Informative

    Irrelevant? Not quite. For your particular use, maybe. But most Linux distros are still built using GCC, and most embedded platforms provide a GCC-based toolchain. So if, by 'irrelevant', you actually mean, 'the compiler with the most-often executed output code on earth', then yes, I guess you're right.

    --
    Slashdot - News for Nerds, Stuff that Matters, in ISO-8859-1 Has just realised that beta makes this signature redundant
  2. Major *nix app using C++ by PhrostyMcByte · · Score: 3, Funny

    I'll go get my cats-and-dogs umbrella.

    1. Re:Major *nix app using C++ by Nethemas+the+Great · · Score: 3, Funny

      I don't know. He's been doing some pretty crazy things lately like versioning the kernel as something other than v2.6.x..

      --
      Two of my imaginary friends reproduced once ... with negative results.
    2. Re:Major *nix app using C++ by formfeed · · Score: 5, Funny

      Linus must be screaming inside.

      Linus never allows his screaming to stay on the inside

  3. Re:too bad GCC is not relevant anymore thanks to L by Nursie · · Score: 4, Informative

    No, no it does not mean anything of the sort.

  4. Re:too bad GCC is not relevant anymore thanks to L by SharpFang · · Score: 3, Insightful

    Don't be so bold in claiming most embedded platforms are something.

    Most embedded platforms use Keil, Assembler and all kinds of various odd proprietary compiler suites that suit their 8-bit and 16-bit nature better. The elitist, narrow though visible of 32-bit ARM is using GCC.

    I assure you your refrigerator temperature thermostat was not programmed in GCC.

    --
    45 5F E1 04 22 CA 29 C4 93 3F 95 05 2B 79 2A B2
  5. Compiler bootstrapping? by Ynot_82 · · Score: 5, Interesting

    How will this affect bootstrapping the GCC on bare systems?

    Been a while since I've delved into LFS or the like, but I'd think GCC being C++ based would seriously complicate things as it's now got more dependencies.

  6. Re:too bad GCC is not relevant anymore thanks to L by Carewolf · · Score: 4, Informative

    This is the first I've heard of anything like this. Did I miss something? Is GCC now GPLv3, and does that mean you can't use it to build non-GPL programs?

    No, it means when you go in and add extra functions to GCC that those would have to be GPLv3 as well, at least if you want to distribute them.

    It has NO effect on what the use of the application. In fact that is has no effect on the end user is one of the topmost clause of the GPLs.

  7. Re:Classes/Templates are not a magic bullet ... by gbjbaanb · · Score: 4, Insightful

    Bad code is bad code, and you can write it in any language, yes, even visual basic.net.

    So the point is not so much "how useless are those lousy GCC devs who will write crappy code", but "how good are those GCC devs now they have a more powerful tool in their hands".

    I'd hope they start to discover the STL too, and use the standard containers at the very least - no need to use custom ones unless you either continue to use the existing C-based ones, or you have some very specific performance issues that you absolutely cannot fix any other way (and generally, you don't have this problem with the STL)

    Now, sure, I hope they don't discover cool new features like STL algorithms and start to litter the code with lamba-d functors.

  8. libgcc and libsupc++ by tepples · · Score: 3, Interesting

    What does a distribution license have to do with a compiler?

    Division support in C on some platforms (such as ARM) and exception support in C++ rely on libraries called libgcc and libsupc++. These libraries are GPLv3 with an exception. Were it not for the exception, anything compiled with the would either be GPL (because of libgcc and libsupc++) or produce a linker error (because the libraries are called and not present). The exception applies only if the compiler has not been modified to introduce non-free optimization passes performed in an independent process. See GCC Exception FAQ.

    Who does believes in GPL cuties? Apple, FreeBSD, 6 year olds, anybody else?

    You can add Nintendo. See the case of Pajama Sam for Wii, where Atari was willing to distribute the source code to a GPL interpreter used for the game but Nintendo didn't want GPL software on its platform.

    1. Re:libgcc and libsupc++ by JesseMcDonald · · Score: 3, Informative

      Were it not for the exception, anything compiled with the [gcc compiler?] would either be GPL (because of libgcc and libsupc++) or produce a linker error (because the libraries are called and not present).

      I think you mean "linked with libgcc/libsupc++". One can compile code with gcc/g++ without linking against the bundled libgcc. For example, the BSD-licensed libcompiler-rt library produced for the LLVM project is said to be a drop-in replacement for libgcc, and as a bonus, it's even a bit more efficient. If the same is not already true for libsupc++, I'm sure it's only a matter of time.

      --
      "The state is that great fiction by which everyone tries to live at the expense of everyone else." - Bastiat
  9. More like "C with Classes" by Megane · · Score: 5, Informative

    I've read their guidelines, and they're doing much like I've been doing recently with moving from C to C++ for embedded systems programming, which is to avoid the really crazy shit that you can do in C++. In particular, exceptions and RTTI are absolutely verboten. They're even planning a compiler switch that turns off the features that will be outlawed in the compiler source. Any templates outside of STL are also forbidden ("template hell" sucks), and I won't even use STL myself because I can't count on having a heap. Even iostreams are being frowned on except maybe possibly in debug dump code where no text language translations are needed.

    C++ can really tidy up C code that uses any sort of function pointer hooks or object dispatch style switch statements with virtual methods. A class can become a mini-API, and even used as a sort of device-driver, as in the mbed libraries. Doing this has really helped improve encapsulation in my own code.

    --
    #naabhaprzrag, #sverubfr-000, #agi-fcbafberq, negvpyr[pynff*=' negvpyr-ary-'] { qvfcynl: abar !vzcbegnag; }
    1. Re:More like "C with Classes" by Aidtopia · · Score: 5, Informative

      In particular, exceptions and RTTI are absolutely verboten.

      Ignoring RTTI is fine, but forbidding exceptions requires a dangerous sort of doublethink. The language itself, as well as the STL, is defined to generate and use exceptions. By ignoring their existence, you banish yourself to a nonstandard purgatory.

      For example, every new now must become new(std::nothrow). For every STL container type, you have to provide a custom allocator that doesn't throw. That's a bit unwieldy.

      By denying exceptions, you force everyone to use error-prone idioms. For example, the only way a constructor can signal a failure is to throw an exception. If you forbid exceptions, then all constructors must always be failure-proof. And then you have to provide an extra initializer method to do the real initialization that can fail. Every user of the class must reliably call the init method after construction, which gets cumbersome when classes are nested or when you're putting instances into an STL container. It also means that objects can have a zombie state--that period of time between construction and initialization. Zombie states add complexity and create an explosion in the number of test cases. Separate initialization means you can't always use const when you should.

      Exceptions are necessary to the C++ promise that your object will be fully constructed and later destructed, or it will not be constructed at all. This is the basis of the RAII pattern, which just happens to be the best pattern yet devised for resource management. Without RAII, you will almost certainly have leaks. Worse, you won't be able to write exception-safe code, so you are essentially closing the door to ever using exceptions.

    2. Re:More like "C with Classes" by swillden · · Score: 3, Insightful

      When I realized that my array of Boolean objects in C++ was an order of magnitude more memory intensive than the bit-arrays I could create in C

      Dude, std::vector<bool>. All of the iterable, dynamically-resizable, type-safe goodness of a real array type with very nearly all the efficiency (time and space) of hand management of packed bit arrays. The only downside is that you do have a little extra bookkeeping info (an int) to support the dynamic resizing. If you need to avoid even that, there's also std::bitset, which has a length fixed at compile time. Odds are that code using std::bitset will be more efficient than what you'd write, and you don't have to waste brain cycles on "keeping track of the fact that it's a pointer to a bunch of bits".

      There are some reasons to prefer C over C++, but your example is decidedly not one of them. In fact, it strongly favors C++.

      --
      Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.
  10. Awesome by Carewolf · · Score: 4, Insightful

    GCC as a compiler and a community seems to really be moving, it is probably due to the competition from LLVM, but atleast for now, GCC is still the better compiler, and I wish them the best of luck.

    Good compilers benefits everybody!

  11. Re:too bad GCC is not relevant anymore thanks to L by petermgreen · · Score: 4, Interesting

    AIUI GCC is now GPLv3, the libraries it ships with are GPLv3 with exceptions that allow using them to build non-GPL programs. However they were paranoid about the idea that people would try and save gcc's internal state to disk and then run it through a propietry backend. So they crafted a complex exception that tries to forbid that while allowing most other combinations of gcc with propietry tools.

    --
    note: i'm known as plugwash most places but i screwd up registering that here somehow in the past and now can't register
  12. Re:Classes/Templates are not a magic bullet ... by Marillion · · Score: 3, Informative

    The Linux Kernel used the C++ compiler for a while. I believe it was during the 0.99.x era. The goal was to improve the code quality by leveraging C++ compiler features like function name mangling while only using C language features. This, however, looks like they want to use a limited set of C++ language features that would be very handy for experienced C programmers.

    --
    This is a boring sig
  13. Re:Classes/Templates are not a magic bullet ... by serviscope_minor · · Score: 5, Informative

    Given a collection of developers that write difficult to understand, difficult to maintain and sloppy type unsafe code, going to C++ may not help.

    It is very difficult to write easy to understand, type-safe, code in C.

    The reason being that C requires so much micro-management that you end up with the code for that mixed in with the actual interesting algorithms. C++ basically makes the compiler do an awful lot of what you have to do in C anyway and does it for you automatically while keeping the details neatly out of the way.

    It's also very hard to write type safe code properly in C. Just look at the classic example of the unsafe qsort versus the safer and faster std::sort.

    I'd also be more optimistic if by using classes and templates they were really referring to using STL, not writing their own.

    What on earth is wrong with writing your own classes and templates? They almost certainly already have a healthy collection of structs with function pointers and macros (linux certainly does have poor reimplementations of half of C++ using macros). These are best replaced with classes and templates on the whole.

    That's the point. C++ formalises what everyone was doing in C anyway, making it much more uniform, easier to read, shorter and therefore much less prone to bugs.

    --
    SJW n. One who posts facts.
  14. Re:too bad GCC is not relevant anymore thanks to L by keltor · · Score: 3, Informative

    Actually a number of the older embedded platforms I've programmed for DID in fact use gcc+patches, usually with proprietary stuff added all around. I believe for most of the microcontrollers supported by Keil, the compiler is based on GCC (often the older 2.x series.)

  15. Re:GCC should remain small and fast by serviscope_minor · · Score: 5, Insightful

    I used to be more polite to ignorant C++ haters. But I've lost patience.

    A program written in C++ is going to be slower than an equivalent program written in C, no way around it.

    There is a way around it: by not being an astonishingly incompetent developer.

    And that's without even getting into features like templates, which only five people in the world understand.

    Don't assume everyone is as dim as you.

    --
    SJW n. One who posts facts.
  16. C++ is Dead, Long Live Java by Anonymous Coward · · Score: 5, Funny

    C++ is as good as dead.

    Everything should be written in java, since this would give a huge speed increase.

    For even more speed, programs could be run on a java interpreter, running on a java interpreter written in java.

    Think of the raw speed!

  17. Re:too bad GCC is not relevant anymore thanks to L by VortexCortex · · Score: 4, Funny

    I assure you your refrigerator temperature thermostat was not programmed in GCC.

    That's because its CPU is a bi-metallic strip wound into a coil, and it's RAM is only one bit. The equivalent of running .configure and make is rotating a dial and tightening a screw.

  18. Re:too bad GCC is not relevant anymore thanks to L by DeathToBill · · Score: 4, Interesting

    Well, let's see. I personally work with control systems using x86, MIPS, PowerPC and ARM architectures, running Linux, VxWorks, QNX and WinCE (various combinations). They all have GCC toolchains, although we admittedly don't use it for CE.

    If you're thinking microcontrollers, then GCC supports AVR, 68000-series, MicroBlaze, MSP430, ARM again...

    Now, personally, my refrigerator has an analog thermostat, so, technically, you are right. If it had a thermostat implemented on a CPU, then I'd think there's a very good chance it was compiled with GCC.

    What exactly "programmed in GCC" might mean is left for the reader to speculate on.

    --
    Slashdot - News for Nerds, Stuff that Matters, in ISO-8859-1 Has just realised that beta makes this signature redundant
  19. Re:Next steps by xTantrum · · Score: 3

    I'm a hot chick at college studying computer science using Python. insensitive clod!

    --
    $action = empty(PHP) ? backToC() : unset(PHP) ; "when the concrete cases are understood, the abstractions are readily
  20. Re:Classes/Templates are not a magic bullet ... by ArhcAngel · · Score: 4, Funny

    I find that jerks who bitch the most are often the worst at writing code, sorry just sayin. Big ego = ass hat to work with and awful at writing code. C# might work out better for ya.

    Shouldn't that be:
    Big ego == ass hat

    --
    "A person is smart. People are dumb, panicky dangerous animals and you know it." - K
  21. Re:Classes/Templates are not a magic bullet ... by Surt · · Score: 4, Funny

    No, it's definitely an assignment.

    --
    "Who is the Journal of Quantum Physics going to believe?" --Stephen Hawking
  22. C++? by Anonymous Coward · · Score: 4, Funny

    C++? seriously?

    That's it, I'm switching to LLVM!

    1. Re:C++? by willodotcom · · Score: 4, Informative

      C++? seriously?

      That's it, I'm switching to LLVM!

      which is also written in C++

  23. Re:Classes/Templates are not a magic bullet ... by serviscope_minor · · Score: 5, Insightful

    You can do all kinds of nifty stuff with macros and gcc/clang extensions to provide type safety to C

    Yes, I know.

    You can write a GENERATE_SORT(Type, Comparator) macro which generates a sort function to work on an array of Type, using the specified comparator, and has no name collisions and is type safe using liberal amounts of ## and so on.

    The point is not that you can't do them in C (you can), but the methods for doing it are ad-hoc. By moving the functionality into the compiler, C++ provides a regularity of syntax for such things that C lacks.

    --
    SJW n. One who posts facts.
  24. Re: progress by DeathToBill · · Score: 4, Insightful

    No. 22 more years has seen Challenger and Columbia blow up, and we've learnt some lessons about things we should do and things we shouldn't do. Just as the Challenger investigation didn't conclude, "Ban O-rings," nobody has decided to ban parts of C++, either.

    C++ is in some ways like a human language: It has an enormous range of things you can say in it. Some of them are only appropriate in certain situations. Some of them are never appropriate if you want people to take you seriously. Some of them just plain don't make sense.

    So quite a lot of the development over those 22 years has been in the community learning idioms that let you use the power of C++ without hurting yourself.

    --
    Slashdot - News for Nerds, Stuff that Matters, in ISO-8859-1 Has just realised that beta makes this signature redundant
  25. Re:Classes/Templates are not a magic bullet ... by serviscope_minor · · Score: 5, Insightful

    I don't write 'university code' though; and I'm not out to impress a professor or win 'elegance awards'.

    I think the enormous chip on your shoulder might be obscuring your view of C++.

    --
    SJW n. One who posts facts.
  26. Re: progress by smittyoneeach · · Score: 4, Informative
    --
    Get thee glass eyes, and, like a scurvy politician, seem to see things thou dost not.--King Lear
  27. Re:RTFA by nebosuke · · Score: 3, Informative

    Bootstrapping on another platform is done as follows:

    1. Write gcc backend to output code for target platform.
    2. Cross-compile gcc for target platform using an already-supported-platform and the newly written backend.
    3. Transfer resulting binaries to target platform
    4. profit!

    Note that at no point does the target platform need some other way to compile gcc independently in order for the port to happen.

  28. Re:OOM inside STL by maxwell+demon · · Score: 4, Insightful

    Actually the correct comparison is to not only disable exceptions in the compiler, but in addition adding hand-crafted error handling to the code. Because manual error handling also costs performance. And without error handling, your application is broken, period (and yes, I have been bitten by applications doing improper error handling. And yes, that included data loss. Loss of data stored on the hard disk, because the application didn't do any error checking when replacing the file with a new version. Fortunately I could get back most of it from the nightly backup).

    --
    The Tao of math: The numbers you can count are not the real numbers.
  29. Re:too bad GCC is not relevant anymore thanks to L by jeremyp · · Score: 4, Informative

    The GPL doesn't force you to give back. You need to have a read of it, it only forces you to "give forward".

    Apple has now fully embraced clang/llvm for a couple of reasons: it was legally very difficult to for them to integrate gcc tightly with their IDE (by which I mean they would have to GPL Xcode if they linked directly to gcc); it is technically very difficult to integrate with an IDE - apparently the gcc code base is a complete mess as far as integration with other tools is concerned.

    Clang/LLVM is financed by Apple and it is released under an Open Source licence. Call that parasitic if you like but because of Apple (in part) you now have a clean modern compiler toolchain that's a credible open source alternative to gcc. If nothing else, it means that the gcc dev team now have an incentive to improve their product because they have competition.

    --
    All I want is a secure system where it's easy to do anything I want. Is that too much to ask ~~ Randall Munroe
  30. Re: progress by smittyoneeach · · Score: 3, Insightful

    Which thesis clearly explains why no one uses Boost and it has zero developers, not to mention a dearth of creative ideas.

    --
    Get thee glass eyes, and, like a scurvy politician, seem to see things thou dost not.--King Lear
  31. Re:RTFA by Joce640k · · Score: 3, Interesting

    Yeah. I'm not a fan of C++, though the compiler spends so little time running that this shouldn't pose much of a problem with bloat and clunk. On the other hand, loading C++ stuff is an abomination that takes eternity due to massive mangling (a problem Michael Meeks has spent a lot of time trying to marginalize with Bdirect linking, faster hash algorithms, etc), and the compiler gets run repeatedly.

    I'm not sure mangling is really as much of a problem people make it out to be. It *did* cause problems trying to mix binaries from different compilers but I don't think it was ever really a performance problem. If linking is slower it's because the programs are larger.

    OTOH name mangling is a massive benefit to programmers. Writing big programs is a huge pain in the butt if every single function/variable has to have a unique name. Namespaces are one of the reasons C++ programs scale so much better then C programs.

    --
    No sig today...
  32. An observation of "procedural" coders by GodfatherofSoul · · Score: 3, Interesting

    I've never understood the hostility towards OOP. I've always seen it as nothing more than another great tool to use, but so many posters act as if OOP is some false god brainwashing the masses. My theory is they're taking the act of embracing OOP as synonymous with insulting C.

    Look at the added java.io.PrintStream.printf() method that uses a variable argument list. Someone had to be a special kind of asshole to adulterate a strongly-typed OO-language with that bullshit when the obvious OO solution is an array for a second argument. That's the kind of modification made when someone is making a political point, not a design improvement.

    --
    I swear to God...I swear to God! That is NOT how you treat your human!
  33. Re:Classes/Templates are not a magic bullet ... by philfr · · Score: 3

    I could be wrong, but I doubt the Linux kernel ever used anything C++ related, given the strong opinion Linus has about the language

  34. Re: progress by Greyfox · · Score: 3, Interesting
    I hadn't really looked at it much through the course of my career -- most of my employers wanted C or Java, not C++. Having only recently started with it, I'm finding it to be about as sharp a weapon as C, but with the ability to be far more type safe. It really isn't that difficult to get a grasp on it. You just need to understand its pass-by rules, which are moderately more complex than Java's. You also need to be able to understand the STL and use it effectively. You also need some object oriented design experience if you're doing your own design work.

    The third party libraries for it are pretty nice these days, too. I'd rather do threading in C++ with boost::thread than in Java. I've found boost::regex and boost::program_options to be a joy to work with as well. Eigen is also very nice if you need a math library.

    Overall I've been quite enjoying working with it. It's not nearly as intimidating as it first appears, and the stuff you really need to know about it is pretty simple and easy to learn.

    --

    I'm trying to teach myself to set people on fire with my mind... Is it hot in here?

  35. Re:Type unsafe... by jonadab · · Score: 3, Insightful

    > LISP is quite powerful and fast as a machine
    > language, it just happens to be unparsable by humans.

    What on earth are you talking about? Lisp is extremely trivial to parse. Lisp barely even has syntax.

    Now, keeping track of Lisp program flow in your head, that can be a bit tricky and can lead to some substantial maintainability issues, especially when some hotshot programmer starts throwing lambda functions around like there's no tomorrow (or, worse, continuations).

    But parsing? Parsing Lisp is dead simple. You could train an elementary education major to do it.

    --
    Cut that out, or I will ship you to Norilsk in a box.
  36. Re:too bad GCC is not relevant anymore thanks to L by Darinbob · · Score: 3, Informative

    And the AVR I have used used a mix of GCC and GNU assembler. I think someone somewhere had an official commercial compiler for it but that doesn't help if it's not licensed for anyone in the company to use.

    I have actually seen cases where companies license one commercial compiler for use in production builds while all the developers use GCC, out of concerns that the commercial compiler is more efficient while being too expensive to license more broadly. Over time there's pressure to dump the commercial compiler because it tends to be difficult to debug when the devs don't have access to the production compoiler, and because it turns out the expensive compiler doesn't really generate more efficient code.

  37. Re:bad_alloc by shutdown+-p+now · · Score: 3, Informative

    It could be worse though, in .NET if you run out of stack, you don't even get the exception - it just exits.

    You do get a StackOverflowException, actually. The catch - pardon the pun - is that it's a "magic" exception type that cannot be caught by user code, since .NET 2.0. So in practice it's only there for debuggers.

  38. Re:GCC should remain small and fast by shutdown+-p+now · · Score: 3, Informative

    Doesn't help. STL arrays are allocated on the heap, and that's a quite slower and more wasteful allocation form than on the stack.

    What is an "STL array"? If you mean std::array, then no, it's allocated on the stack. If you mean std::vector, then that's a dynamically resizable array, and an analogous data structure written in C would still be heap-allocated - you'd just have to do malloc/realloc/free yourself.

    Sure, you can use C arrays, but guess what: out go type safety and STL algorithms and C++ idioms.

    Again, wrong. Since raw pointers are iterators, you can perfectly well use STL algorithms and other C++ idioms with C arrays. In C++11 it's even easier now that std::begin and std::end are defined as global functions, and overloaded for arrays, so you don't need to much around with pointers at all. Type safety is still there as well, since C arrays are typed.

  39. Re:Classes/Templates are not a magic bullet ... by Urkki · · Score: 3, Insightful

    For you, I suggest two-pronged approach to C++. First of all you have libraries and frameworks. They take full advantage of C++ features, but hide them. Then you have the actual application code that uses these libraries, and is much simpler, ideally readable by somebody who only knows Java or C#.

    The difference to doing the same in C is, in C you'll use macros and have poor type safety, ugly-looking code and get obscure macro related errors when when you put bad stuff as macro arguments.

    In short, the trick with C++ is, you don't use most of the features, unless you really have to. Note that you can write your current C code as C++ code, except use whatever subset of C++ features you think will make your C-like code better, and only when it actually makes it better. Limiting yourself to pure C is, IMNSHO, just stupid, unless you're coding for a small embedded system and don't want to include C++ runtime in it.