Catch up on stories from the past week (and beyond) at the Slashdot story archive

 



Forgot your password?
typodupeerror
×
GNU is Not Unix Programming

GCC Switches From C to C++ 406

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.
This discussion has been archived. No new comments can be posted.

GCC Switches From C to C++

Comments Filter:
  • by PhrostyMcByte ( 589271 ) <phrosty@gmail.com> on Wednesday August 15, 2012 @09:43AM (#40996725) Homepage

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

  • .. and will lead to an even more reliable compiler toolchain.
  • by perpenso ( 1613749 ) on Wednesday August 15, 2012 @09:52AM (#40996849)
    Given a collection of developers that write difficult to understand, difficult to maintain and sloppy type unsafe code, going to C++ may not help. The previous problems are problems with the developers not the language. C++ just enables such developers to write even worse code. Hopefully they are also introducing new coding style guidelines, and are willing to enforce such guidelines. If so I'd be more optimistic.

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

    Or maybe they just want to use C++ style comments and won't really use classes and templates much. :-)
    • by gbjbaanb ( 229885 ) on Wednesday August 15, 2012 @09:58AM (#40996929)

      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.

      • bad_alloc (Score:2, Interesting)

        by tepples ( 727027 )

        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)

        On a platform with no swap file, such as a handheld or set-top device, one of the more common "very specific performance issues" is the ability to handle allocator failures. A program in such an environment is supposed to free cached or otherwise purgeable resources instead of just letting main() catch std::bad_alloc and abort. What are best practices for using the C++ containers if virtual memory is not available?

        • Is he referring to using containers as part of the target application or as part of the compiler itself? The compiler internals might be much cleaner or there may be less redundant code for the compiler if it used STL rather than alternative or custom containers etc. Your target application would still only be using STL if you wrote code to use it...

        • You write a damn exception handler block every time you have a "new". If you're using Linux and you run out of VRAM, it just starts killing processes until it has the memory. Its "optimistic" allocator doesn't throw std::bad_alloc -- is some really scary shit.
      • by Rei ( 128717 )

        There are some cases where lambda-d functions improve clarity. For example, lambdas make for very clear, concise threading of simple tasks using the new C++11 threading operations.

        Really, many of the new features play so beautifully together. For example, you can write a simple packet reader/parser which:

        * Loops indefinitely
        * Waits until data can be read
        * Spawns the processing of that data in its own thread and resumes holding and processing packets, while in the spawned thread:
        * Proper type of packet is

    • by Marillion ( 33728 ) <ericbardes@NospAM.gmail.com> on Wednesday August 15, 2012 @10:05AM (#40997001)
      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.
      • by philfr ( 89798 )
        I could be wrong, but I doubt the Linux kernel ever used anything C++ related, given the strong opinion Linus has about the language [cat-v.org]
        • by Zan Lynx ( 87672 )

          If you look at the way the Linux kernel uses macros combined with GCC extensions like typeof(x), it is obvious that they are actually writing templates. And many of their struct definitions reproduce inheritance and virtual method calls.

          You could look at it as writing C++ code disguised as C.

    • by serviscope_minor ( 664417 ) on Wednesday August 15, 2012 @10:06AM (#40997015) Journal

      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.

      • by cras ( 91254 )

        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.

        You can do all kinds of nifty stuff with macros and gcc/clang extensions to provide type safety to C. Yeah, if you don't already have a library for that it can be a bit difficult to write one (or find one you like). But once you have the library it's very easy to write (mostly) type safe code with C. For example I have a type safe array_sort() in C.

        • by serviscope_minor ( 664417 ) on Wednesday August 15, 2012 @11:23AM (#40998049) Journal

          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.

    • going to C++ may not help.

      I dunno. I don't see what business non-C++ programmers have working on a C++ compiler. One of the problems might be that they're still using malloc() and strdup().

  • by Ynot_82 ( 1023749 ) on Wednesday August 15, 2012 @09:55AM (#40996901)

    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.

    • Re: (Score:2, Insightful)

      by Anonymous Coward

      Not much.

      You can cross-compile all you like.

      If that fails, and you find yourself on a system with only a K&R C compiler, you bootstrap to
      an ANSI C compiler by going to gcc 2.95.n or something like that. Then you use that to get
      to a fairly recent C-based gcc and finally use the resulting C++ compiler to compile the
      final version of gcc.

  • by Megane ( 129182 ) on Wednesday August 15, 2012 @10:00AM (#40996949)

    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 [mbed.org] libraries. Doing this has really helped improve encapsulation in my own code.

    • In particular, exceptions and RTTI are absolutely verboten. [...] Any templates outside of STL are also forbidden

      What implementation of STL do you recommend for low-memory systems that have a heap, albeit not a very big one, where you don't want to crash upon running out of memory?

      Even iostreams are being frowned on

      In my experience (quarter megabyte static hello world), <iostream> would be the first to go, in favor of <cstdio>. See what else I've written about the pitfalls of C++ on small systems [pineight.com].

    • They're even planning a compiler switch that turns off the features that will be outlawed in the compiler source.

      That is an interesting avenue. As languages like C++ and perl can attest, languages can evolve by adding features but it's almost impossible to take them back. Having a compiler flag to enforce a coding standard is a way to do that less coercively.

      Maybe this will result in a popular new dialect of C/C++.

    • by Ed Avis ( 5917 )
      It's a strange mindset to see run-time type information, available by standard in widespread languages such as Java and C#, as 'really crazy shit that you can do in C++'. It carries a runtime cost and the only unusual thing about C++ is that you don't have to pay that cost if you don't use it. There is indeed crazy shit like compile-time Turing-complete template metaprogramming (the 'Vogon liver' that has grown way beyond its original intended purpose) but it's important to distinguish between that and la
    • by Aidtopia ( 667351 ) on Wednesday August 15, 2012 @11:08AM (#40997827) Homepage Journal

      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.

    • Re: (Score:3, Insightful)

      I've gone the opposite direction. Moving more of my C++ code into C by using my own OOP system. Before you say "That's crazy talk", consider that it makes inter-operating with my game's scripting language so much more buttery smooth than in C++ -- It's so nice to just create a new object in either script or C and have them talk to each other without going through a few layers of APIs, passing off dynamically allocated instances and having C free it, or the script GC it automatically.

      Don't get me wrong,

    • This could work well. Indeed, there is something to be said for having C with a few extensions being a lot better for application programming than plain C.

      On the other hand, a lot of real-world C++ code is as crappy as it is exactly because people write it as if it were C with a few extensions, rather than taking advantage of other C++ features that would make it actually nice to read.

      As an example of this, it helped me a lot when I finally realized that, in C++, you can use almost any well-implemented type

  • Awesome (Score:5, Insightful)

    by Carewolf ( 581105 ) on Wednesday August 15, 2012 @10:02AM (#40996969) Homepage

    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!

  • by Windwraith ( 932426 ) on Wednesday August 15, 2012 @10:07AM (#40997031)

    That's all I really care about, to be honest. As long as I can keep coding in C, they can do whatever.

  • by Anonymous Coward on Wednesday August 15, 2012 @10:16AM (#40997155)

    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!

    • by BobNET ( 119675 )

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

      It's Java interpreters all the way down!

  • C++? (Score:4, Funny)

    by Anonymous Coward on Wednesday August 15, 2012 @11:06AM (#40997795)

    C++? seriously?

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

  • by GodfatherofSoul ( 174979 ) on Wednesday August 15, 2012 @02:33PM (#41000377)

    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() [oracle.com] 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.

Things are not as simple as they seems at first. - Edward Thorp

Working...