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.

Comments

Re:too bad GCC is not relevant anymore thanks to L

[DeathToBill]

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.

Major *nix app using C++

[PhrostyMcByte]

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

Re:Major *nix app using C++

[Nethemas the Great]

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

Re:Major *nix app using C++

[formfeed]

Linus must be screaming inside.

Linus never allows his screaming to stay on the inside

Re:Major *nix app using C++

[hpa]

Linus doesn't scream. He obliterates with sarcasm.

This is a good thing...

[Red4man]

.. and will lead to an even more reliable compiler toolchain.

Re:too bad GCC is not relevant anymore thanks to L

[Nursie]

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

Re:Incoming Torvalds' post

[Anonymous Coward]

umbrellas? I'm getting some popcorn and a comfortable chair. this is going to be epic.

Re:too bad GCC is not relevant anymore thanks to L

[keltor]

While the GPLv3 was the reason Apple suddenly invested in clang (which just happens to ride on llvm), it has little effect on any companies that do what they should do.

Classes/Templates are not a magic bullet ...

[perpenso]

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

Re:Classes/Templates are not a magic bullet ...

[gbjbaanb]

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.

Re:Classes/Templates are not a magic bullet ...

[Marillion]

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.

Re:Classes/Templates are not a magic bullet ...

[serviscope_minor]

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.

Re:Classes/Templates are not a magic bullet ...

[ArhcAngel]

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

Re:Classes/Templates are not a magic bullet ...

[Surt]

No, it's definitely an assignment.

Re:Classes/Templates are not a magic bullet ...

[Rei]

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 determined
* Appropriate packet object is created
* Packet object processed
* Packet object deallocated

Using code one-liners like:

while (true) { auto PacketData=ReadPacket(); thread([]{ MyPacketFactory(PacketData)->RunPacket();}).detach(); }

or

while (true) { thread([](auto PacketData){ MyPacketFactory(PacketData)->RunPacket();}, ReadPacket()).detach(); }

Now, it's stylistically better to spread it out over a couple lines, and the above assumes that you're "using" std, have written your packet factory and socket reader, etc. However, it gives you an idea of how powerful the new features are. In normal code I'd probably write something like:

while (true)
{
      std::string PacketData(ReadPacket());
      std::thread([]{ MyPacketFactory(PacketData)->RunPacket();}).detach();
}

Again, to reiterate, this is just from memory; I've not tried to compile these.

Re:Classes/Templates are not a magic bullet ...

[serviscope_minor]

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.

Re:Classes/Templates are not a magic bullet ...

[serviscope_minor]

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

Re:Classes/Templates are not a magic bullet ...

[philfr]

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

Re:Classes/Templates are not a magic bullet ...

[Zan Lynx]

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.

Re:Classes/Templates are not a magic bullet ...

[Urkki]

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.

Re:too bad GCC is not relevant anymore thanks to L

[SharpFang]

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.

Re:too bad GCC is not relevant anymore thanks to L

[Bill, Shooter of Bul]

Gcc still blows the crap out of LLVM in several benchmarks. LLVM is great for many things as well. GCC needed competition to make sure it didn't get stagnent. Some of us still remeber the egcs period of time. Unless corperate entities were modifying the sources of GCC, I'm not sure why it matters.

Compiler bootstrapping?

[Ynot_82]

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:Compiler bootstrapping?

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

Re:too bad GCC is not relevant anymore thanks to L

[Carewolf]

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.

libgcc and libsupc++

[tepples]

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.

Re:libgcc and libsupc++

[Anonymous Coward]

flaminyon

Holy shit. Really?

Re:libgcc and libsupc++

[JesseMcDonald]

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.

Re:Type unsafe...

[Carewolf]

Yeah, that always freaks me out. GCC backends atleast are configured using LISP wrapped in C. I hope this is one of the things they clean-up, though, it won't be straight forward. LISP is quite powerful and fast as a machine language, it just happens to be unparsable by humans.

More like "C with Classes"

[Megane]

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.

Re:More like "C with Classes"

[Ed Avis]

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 language concepts which are quite normal and accepted in the rest of the world.

Re:More like "C with Classes"

[Aidtopia]

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:More like "C with Classes"

[VortexCortex]

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, I love C++, but they have rules that are conflicting when you get "deep" into the language. Try using multiple inheritance and polymorphism... It almost works, but not if you have two base classes with the same virtual function names -- That's just one of many edge cases I ran into... Theres several corners we're forbidden to go where templates, type safety, and inheritance don't play well with each other...

After a while I just scratched my head, "Really C++? Really?!" Why would you have features that are incompatible? So long as I only use some of C++'s features some of the time, then everything is fine, but when I needed to use MOST of the language in the implementation of my scripting language, then shit hit the fan. Many experience people I look up to have told me if I need to use the WHOLE C++ language then I'm doing it wrong. To them I say: If you can't use the entire language at once then the Language is "doing it wrong".

C++ is great if you're only using C++, and C++ constructs. That you have to use extern "C" { ... } to make shared libs that will actually work with other compilers or languages is a serious show-stopper for me. Protip: method names are munged into unique C function names so you can actually compile "C++", ergo they need to standardize name munging rules but to do that would be to admit that C++ is mostly implemented as a fancy pre-processor for C...

Most of my C++ code was contained in extern "C" blocks, and I had abandoned most of the C++ features for my own language's simpler implementations, so one day I woke up and realized I should stop fighting C++ and just use C.

My problem was that I needed a language that let me closely express the construct of another language within it -- embedability was a prime factor. Sure I could write the VM in C++, and have a ton of interfaces and abstraction and overloaded operators, etc, but with C I didn't need to do that.

Some of the reasons I left C++ for are being fixed / added in C++2012, but it's too late for me. I'm not going back. I'll use C++ for my C++ only projects, but for anything that needs to work with other languages (most of my code), then I'll use C. Bonus: Instead of 15 minutes to compile the C++ implementation, it takes just seconds as C.

C has many pitfalls, but at least they're out in plain sight; Unlike the C++ pitfalls, which are hidden in corners, shrouded in "advanced feature" mystery, and blanketed by the fog of denialism -- When things that should work according to spec don't (because of the implementation details), then you do you really have a language, or is it just part of a language?

C++ has the same problem with C that I experienced with C++ -- When you try to implement a language in a way that's really close to another language, so you can use its underlying tool-chain, you run into a point where you must be shackled by the base language's implementation details... You can either build around the limitations (what C++ does), or you can embrace them (what I've done). Unfortunately I couldn't embrace the C++ implementation -- a complete one doesn't exist.

Re:More like "C with Classes"

[swillden]

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

Re:More like "C with Classes"

[swillden]

+1

The only downside to C++ vs C, IMO, is the C++ learning curve. You have to learn all of both language, and how their respective constructs get translated to machine code and when to use what. However, once you've done that, and internalized it all, you can write highly efficient code at a much higher level of abstraction, making you much more productive. And you can also drop down to low-level bit-twiddling when you need to, wrapping it in a higher-level abstraction or not, as appropriate.

If you have staff with the capability and education to use C++ effectively, it's a far better choice than C. If you're struggling to find good people... stick to Java or C#.

Re:More like "C with Classes"

[shutdown -p now]

Forbidding exception is de-facto standard for C++ programmers

This is plainly false. In 7 years of writing C++, I've yet to work on a project where exceptions were forbidden. And the sky hasn't fallen, quite the opposite. Specifically:

exceptions are an unsafe feature that integrates extremely poorly with most programming paradigms C++ is used for

The primary programming paradigm that C++ enables is RAII. And RAII integrates extremely well with exceptions - in fact, it's pretty hard without them.

Re:oh nooos

[Samantha Wright]

RTFS—GCC itself is becoming a C++ program. It'll still compile stuff the same way. (Optimizing your compiler is for Gentoo users and communists.)

Awesome

[Carewolf]

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!

Re:too bad GCC is not relevant anymore thanks to L

[Lemming Mark]

I think there are a few non-ARM embedded platforms that use gcc. AVR (even the 8-bit variants) has a good gcc port.

Re:too bad GCC is not relevant anymore thanks to L

[petermgreen]

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.

Will keep compiling C properly?

[Windwraith]

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

Re:too bad GCC is not relevant anymore thanks to L

[keltor]

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

OOM inside STL

[tepples]

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.

Re:OOM inside STL

[maxwell demon]

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

Re:GCC should remain small and fast

[serviscope_minor]

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.

C++ is Dead, Long Live Java

[Anonymous Coward]

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!

Re:too bad GCC is not relevant anymore thanks to L

[VortexCortex]

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.

Re:too bad GCC is not relevant anymore thanks to L

[DeathToBill]

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.

Re:bad_alloc

[squizzar]

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

Re:oh nooos

[petermgreen]

Which is a complier more likely to be able to optimise? polymorphism that is explicit in the language or polymorphism that is hacked together by creating vtables (which are basically structures full of function pointers) manually? Which is more likely to have mistakes made that associate the wrong vtable with an object?

C++ has it's problems but it's the only widely supported language that both provides OOP features and yet still allows the writing of tight code where needed.

Re:Next steps

[xTantrum]

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

Re:bad_alloc

[VortexCortex]

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.

Re:Type unsafe...

[Anonymous Coward]

(not (quite_like (works LISP) you_say))

C++?

[Anonymous Coward]

C++? seriously?

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

Re:C++?

[willodotcom]

C++? seriously?

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

which is also written in C++

Re: progress

[presidenteloco]

I too would have seen a move from C to C++ as progress...

in 1989.

It took me til about 1990 to realize that C++ was a fundamentally broken and overcomplicated attempt at an object oriented programming language. By attempting too much (OO + C backward compatibility) it achieved, to be kind, something other than safety and elegance.

C++ seems to me like the space shuttle of programming languages; includes a kitchen sink, a tool on board for every purpose, lightning fast, and dangerous as hell.

So tell me, has 22 years more development managed to fix it?

Re:too bad GCC is not relevant anymore thanks to L

[Anonymous Coward]

LLVM was created by freeBSD due to the continual dropping of support for older hardware by the GCC team.

Wrong!

The LLVM project started in 2000 at the University of Illinois at Urbana–Champaign, under the direction of Vikram Adve and Chris Lattner. LLVM was originally developed as a research infrastructure to investigate dynamic compilation techniques for static and dynamic programming languages.

Re:too bad GCC is not relevant anymore thanks to L

[schaiba]

LLVM was created by freeBSD due to the continual dropping of support for older hardware by the GCC team. Another issue they had was the optimizations of the software increased the difficulty of debugging things as the optimizations varied every time they compiled the software. Thus LLVM was created with the goal of binary stability that could be easily debugged and that supported the many older peices of kit that freeBSD runs on instead of being forced to use GCC 1.2/1.5/2.1/2.2/2.3 and such.

Since when was LLVM created by FreeBSD? o.O

Re: progress

[DeathToBill]

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.

Re:my fridge thermostat is digital

[aztracker1]

Which should bring us back to a point... how do *you* know the fridge isn't using logic compiled by GCC?

Re: progress

[smittyoneeach]

http://www.boost.org/

Re:RTFA

[MichaelJ]

Maybe not a big deal on a Linux system with an older G++ already installed, but this could be a serious issue for bootstrapping GCC on non-Linux platforms. Where you might have only needed the native C compiler before, now you will need the native C++ compiler, which may be an expensive product.

Unless they're going to make it a multi-step bootstrap where the first pass is only C code. I highly doubt that.

Re: progress

[maxwell demon]

Without C compatibility, there would have been no chance that GCC was ever rewritten in C++. It would have been too much of a task. As is, the C could gradually be amended to be C++ compatible (because C++ is not completely compatible to C) while at the same time continuing normal development, with the only restriction that all new C code must also compile as C++. And now the switch to C++ just means that from now on code that doesn't compile with C will be accepted.

Re:RTFA

[nebosuke]

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.

...different type combinations

[tepples]

I have incorporated your correction about templates into my article. Thank you.

Programmers can lose track of for how many different type combinations they have instantiated a template, causing code size to balloon. There is a common extension called extern template allowing for explicit instantiation, but it's not in C++98, and not all compilers support it.

[This] is extremely misleading. Your point of contention is in no way specific to C++ nor templates. It equally applies to any langauge which supports structures and/or classes. That's not C++ nor templates specific issue.

I still don't understand what you're trying to say about my point about "different type combinations" being wrong. I was referring to the fact that a lot of compilers instantiate templates by duplicating the object code one for each specialization, and you get one specialization for each combination of types, not just for each type.

Re:too bad GCC is not relevant anymore thanks to L

[jeremyp]

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.

Re: progress

[21mhz]

I too would have seen a move from C to C++ as progress...

in 1989.

It took me til about 1990 to realize that C++ was a fundamentally broken and overcomplicated attempt at an object oriented programming language. By attempting too much (OO + C backward compatibility) it achieved, to be kind, something other than safety and elegance.

Actually if it only had near-compatibility with C and OO, it would have been a very nice and useful language. But then things went south and they added too many overloadable operators, a nightmarish jumble of rules for typecasting/overload resolution, exceptions that can't be implemented properly in modern application software, but add a whole new dimension of concerns that the programmer should always be aware of... Then they topped it all off with hideously overcomplicated templates. The standard libraries mostly have crappy and/or misguided design: practically non-extensible, bloat-inducing iostream, the bloatware generation templates that used to be called STL, and so on.

So now, real-world projects that use C++ for the useful things it does provide have to maintain coding guidelines to avoid shooting themselves in the foot too often.

Re: progress

[smittyoneeach]

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

Re:Define properly

[21mhz]

What, did you think the swap file made [ if ( ! (a = malloc(sizeof[int] * 1024))) return ENOMEM; ] unnecessary?

Swap itself didn't; virtual memory allocation techniques allowing overcommit did.
It's practically useless to check the result of a malloc on a modern VM-equipped OS, except for very large buffers (where you typically also have an obvious failure path e.g. "screw it, this image is too big"). You program can get OOM-killed after all allocations have succeeded.

Even in environments with honest-to-god memory allocation, implementing proper OOM safety requires prohibitively thorough testing, where you need to simulate the failure of practically every memory allocation your program might have, and then have a way to ascertain that the failure handling is done correctly. If you want to bring up C++ exceptions as an easy solution, please be aware that each potential throw path also has to be tested individually; look for words "undefined behavior" in the C++ standard to understand why. And please, let's not discuss a hypothetical infallible C++ genius able to wrap everything into 100% correct RAII code; these do not exist in real life.

Re:RTFA

[Joce640k]

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.

An observation of "procedural" coders

[GodfatherofSoul]

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.

Re: progress

[Greyfox]

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.

Re:Type unsafe...

[jonadab]

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

Re:too bad GCC is not relevant anymore thanks to L

[Darinbob]

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.

Re:Type unsafe...

[Darinbob]

What, who can't parse Lisp? It's incredibly simple. People don't like it because they're not used to it is all.

Re:RTFA

[Darinbob]

If they use the Smarter-C-than-C parts of C++ it's fine. Just don't start going overboard with modern C++ style, bloatware with templates and generics, autopointers, overloaded operators and functions, etc, then it's great. Use it as C with better type checking and easier modularization and the C diehards will approve.

Re: progress

[luis_a_espinal]

"So now, real-world projects that use C++ for the useful things it does provide have to maintain coding guidelines to avoid shooting themselves in the foot too often."

How is that not the case for _any_ modern language? Anyone write terrible code in any language. I've seen some Python that made me want to rip my eyeballs out (used tons of esoteric functionality... coupled with a design that made me question the person's sanity).

Coding guidelines are a good idea no matter the language. Keep everything consistent and make sure that the code remains maintainable into the future...

You are missing the point. Most languages, if not all, have coding guidelines, but compare guidelines for, say, Java, Python, or even C, with existing coding guidelines in C++. You'll see the difference in how much the later cuts through what is available in C++.

Pretty much most C++ coding guidelines (in particular for systems and mission-critical development) cut away templates, STL, i/o streams and exceptions. Boost and RTTI are certainly the most banned of things.

So you end up with a C-like language with native support for object-orientation, which is really not a bad thing. If you are lucky, you might get some limited usage of templates (limited in the sense that you have to demonstrate, but really demonstrate your usage will not *explode* into code bloat via template hoisting or what not). A few of the most used STL template classes, string, auto_ptr, map and list are typically permitted. In many cases, the later three are restricted to instances parameterized to void* or to references to a very restricted, audited set of subclasses.

The lack of exceptions forces a design based on error codes. The later is really not a great choice, but the semantics are clear, far clearer than exceptions as implemented in C++. And that's why sometimes people, out of painful experience, end up choosing C with simulated inheritance as a safer, more cost effective alternative.

One typical counter-argument is that people aren't intelligent enough to use C++ safe. Maybe so, but mental effort should be saved to harness a language most effectively in solving problems in a particular domain, not on knowing how not to blow your toes to pieces.

Re:bad_alloc

[shutdown -p now]

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.

Re:too bad GCC is not relevant anymore thanks to L

[Anonymous Coward]

apparently the gcc code base is a complete mess as far as integration with other tools is concerned

Lots of that was self-inflicted. GCC maintainers did not permit attempts to refactor GCC into smaller reusable component libraries, or import / export abstract syntax tree (AST) data. Granted, these things were difficult due to GCC's legacy codebase problems, but you couldn't even try. Your patches would be rejected.

It was pure Richard Stallman tinfoil hat paranoia. RMS believes that if you make GCC too modular, especially with interfaces that can't propagate GPL virality, it will inevitably become a wedge used to destroy GCC. You see, people could then write non-free programs to extend GCC in useful ways. And under RMS-ism, you can't have that. It's better for holy free software purists to live in hair shirts than to permit changes which might theoretically allow outsiders to tempt them with evil. So RMS used his influence with the FSF and GCC to block attempts to move GCC in that direction.

There was also a lot of provincialism. I believe C++ used to be unthinkable, but that tune may have changed due to the success of clang / LLVM, which use C++ features to good effect. GCC's ancient crufty internals have become a huge barrier to progress, and this sounds a bit like belated recognition of it. (They have to be worried about contributor mindshare going to LLVM family projects merely because they're so much easier to work on.)

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.

Apple was very frustrated with the state of affairs I described above. They (and many other non-purist GCC contributors from the commercial sector) wanted to modernize GCC to make it more competitive with closed source compilers, but the FSF literally wouldn't let them. See also: the egcs fork, which also had its origins in FSF small-mindedness. However, after egcs effectively won that battle, the FSF was able to bring GCC back under its control. If Apple ever considered a serious attempt to fork GCC, no doubt that outcome played a role in deciding against it.

Ironically, the result is that now we have a complete, high quality alternative to GCC, it's not burdened by a horrible internal design preserved in amber by misguided distrust of outsiders, it's licensed more permissively, it's structured exactly the way RMS feared, it's not rigidly controlled by the FSF (which requires that everything contributed to GCC have copyright assigned to the FSF), deep-pocketed commercial GCC contributors are migrating to it because it's run by sane people, and nobody is using it to force proprietary software on the free software community.

Re:GCC should remain small and fast

[shutdown -p now]

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.

Re:too bad GCC is not relevant anymore thanks to L

[cheesybagel]

Actually the exceptions that allow you to build non-GPL programs aren't necessary. Otherwise all art you produce with GIMP or text you write with Emacs would be GPLed as well. Stallman just added them to stop the FUD against GCC.

Re:RTFA

[bluefoxlucid]

The problem with mangling is C gives you a symbol like "strcpy", which you might compare for the 50,000 links that have to be made during program load, and have to perform 300,000 character comparisons.

In C++ you get _NSstd__IOSTREAM__55STRING_OPEREQ__STRING__STRING__CHARX__ or some crazy thing. You wind up with 100, 150, 250 character long function names for class foo member 'int bar(int, &int)'. To make matters worse, the above hypothetical was ridiculous: you won't do 300,000 character comparisons because there are only about 20 str* functions, you'll do 60 comparisons (20x3) plus around 50,000 more because of all these functions that don't start with 's' (though there will be a couple thousand that do, but don't start with 'st', adding a few thousand more comparisons). In C++, though, things aren't so friendly...

In C++, you actually wind up comparing, as per our approximated example, _NSstd__ for EVERYTHING in the std namespace. That's 8 character comparisons per symbol (function, overloaded operator, variable, class, class member, etc) in the std namespace--everything in the STL. That once for EVERY symbol in the STL. EVERYTHING under the IOSTREAM class has to compare _NSstd__IOSTREAM__, so each one of those totals 18 character comparisons per member of the IOSTREAM class. That means just to load IOSTREAM you definitely have to do (members_of_iostream^2 * 18 / 2) character comparisons. In the real world, you can do hundreds of thousands or even millions of character comparisons just to load one C++ class member.

It used to take about 14 seconds to load OpenOffice.org on a given piece of hardware. Michael Meeks made that about 1.7 seconds by direct binary linking (i.e. telling the linker that a given symbol was in a given library), avoiding 95% of the character comparisons. It got down to somewhere between 2.5 and 3.5 seconds with just Meeks' PT_GNU_HASH non-standard ELF extension, which adds sorted bucket hashes to the symbol tables to bypass most of the work--it worked so well, in fact, that after publicly discussing the patch on the glibc mailing list as Meeks repeatedly submitted new versions, Ulrich Drepper waited a month and then put his name at the top of the patch and claimed he wrote it (on the same mailing list!).

Meeks had white papers written about this shit. He showed how long it takes C programs to link versus similar C++ programs, explained why, then set out to mitigate the stupidity caused simply by using C++. Current gcc toolchains produce PT_GNU_HASH headers (precomputed ELF hashes) and sort the symbol tables to match the ordering of the hash tables, allowing glibc to basically walk through the binary in a straight line. This eliminates the CPU overhead of computing hash values (never mind character comparisons, we're doing a ton of math) and puts everything in a straight line so PREFETCH instructions and just built-in automated CPU prefetching can reasonably eliminate CPU cache misses--which makes things REALLY fucking fast. Loading a C++ program on Linux is now roughly half as fast as loading an architecturally equivalent C program, which is an improvement over the 10x longer it used to take to load C++ programs.

You can see a bunch of shit at http://lwn.net/Articles/192624/ for the executive summary. Sorry the writing's so poor; I need to not write technical column articles like I write slashdot posts.

Re: progress

[DuckDodgers]

C++ is awesomely powerful, incredibly fast and resource efficient, and between new high performance applications and existing codebases it will continue to be used for decades.

However, it also has a beastly learning curve and lots of corner cases, and while its execution speed is wonderful it's so complex that compilation times for non-trivial applications are slower than equivalent feature (but slower execution) applications written in most other languages. If you really need performance that only C++ can provide, use C++. If you have a team of brilliant C++ developers, use C++.

If you don't have either of those needs, you owe it to yourself to investigate alternatives.

I'm sure the people working on GCC are C++ experts, so I think that's a place where C++ is an optimal or nearly optimal choice.

Re: progress

[DuckDodgers]

The Java community is working around some of the design flaws in the language related to exceptions. As you probably know, RuntimeExceptions don't have to be declared or explicitly caught with try/catch, unless the developer wants to catch them. So I've seen tons of code in different open source libraries that wraps the core Java libraries with code that does try { doSomethingWithCoreJavaLibrary(); } catch (Exception ex) { throw new RuntimeException(ex); }

Java keeps evolving, they keep adding new features and offering simpler syntax for common tasks. Maybe by version 11 or 12 it will be a language that won't make experienced Python, Ruby, Perl, and Lisp developers get sick to their stomach just reading it. ;)