Tuesday, June 19, 2007

Can you name a C++ compiler?

C++ is arguably the best primary language available today for non web based applications that are large, complicated, and advanced. But what should one use to compile their C++ code? Can you even name a single C++ compiler?

C++ was created by Bjarne Stroustrup in 1983 at AT&T. But instead of making a compiler for it, they opted to make a C++ to C translator and dubbed it Cfront. In 1985, Bjarne Stroustrup released a book on his language, moving the language onto center stage. But still there was no compiler to be found, only a translator.

Now translators aren't so bad. After all, they give the programmer many additional features over the base language, such as new types, operators, and other goodies. These extras make it easier to breathe in the art of programming. In fact, there exist many preprocessors and language extensions today using translators to make life easier. Qt for example brings their own C++ extensions to the table such as "slot functions" which works with a preprocessor, translating code to pure C++ and adding any extra functions and data as needed. Now for minor additions, or for translators to C++ which deal with clearly defined objects, generated C++ code is pretty good. But when dealing with entirely new constructs added to a language, generated code can be very bad depending on the circumstance it's in, or not be as optimized as it could be if the compiler understood which high level constructs the code is coming from.

For these reasons, having a real compiler is better than a translator. But what was the first actual compiler for C++? It might come as a surprise to some, but the first C++ compiler was actually GCC, in 1987, 2 years after C++ was exposed to the world. However what C++ itself was - was determined by each new version of Cfront, and GCC did what it could to produce identical results (with extra features on top of course). Over time other C++ compilers came out, each bringing its own slew of extra features to the table, and some of them even acting differently than Cfront did.

In 1992, Microsoft's Visual C++ was released, and it understood code quite a bit differently than Cfront, causing many compatibility issues, and earning a new meaning to MSVC++ - Microsoft Vs. C++. Adding to these compatibility problems was many new features being proposed all the time such as templates, and Cfront development (the de facto standard) stopping in 1993, as it was deemed impossible to keep building upon a translation framework for such a complicated language. Since there was so many different implementations out there, and the "standard" one decided to throw in the towel, the International Organization for Standardization (ISO) decided to step in and standardize C++ as it did with C in 1989.

The ISO finished the standardization of C++ in 1997, and published the new specification in 1998. From this point on, the only real C++ is the one standardized in 1998 (although a second standard of C++ is being worked on to be completed in the next few years), and nothing else can be accurately labeled C++. So now we're about a decade later, guess how many C++ compilers there are?

And the correct answer to the above question is none! If you want to turn to GCC, it still doesn't support the "export" keyword, nor does it handle certain complicated classes entirely right. If you turn to MSVC, until very recently, their implementation of the Standard Template Library was quite shoddy, and was pretty bad with templates in general. More recent MSVCs still have issues though, see here for a short list from Microsoft itself. Aside from Microsoft's list, I'm told by some that they also found some other issues that aren't listed. And for some strange reason, MSVC doesn't even handle scope properly by default for variables created in headers to a block, and instead has an option to enable proper scoping separately. Whose bright idea was it to make improper scoping the default?

So if you want to write a real C++ program today, what exactly should you use? Well, lucky for us, Edison Design Group decided to do what AT&T deemed impossible, and make an up to date fully standards compliant C++ to C translator. Although EDG themselves don't distribute it to the general market. If you want to be able to build your C and C++ code properly, currently, your only choice is to find a complete setup around EDG's translator, such as Comeau C/C++.

Drawbacks with Comeau C/C++ though is that it isn't free. GCC is free, and Microsoft now also offers free versions of their C/C++ compiler, while Comeau C/C++ costs $50 per platform. Comeau C/C++ also isn't as portable as GCC, and doesn't operate properly on a fraction of the OSs that GCC does. Being a translator, it also suffers from the less optimal code generation issues, not to mention longer build times due to more memory usage and more steps involved. Comeau C/C++ also doesn't work by itself, but on install has to configure itself on top of an existing compiler already installed such as GCC or MSVC.

Scary how we don't even have a compiler for the first standardization of C++ and they're already working on a second standardization. C also had a second standardization done in 1999, but is mostly supported by GCC, and will probably be fully supported soon enough. C99 of course is also supported by Comeau C/C++ and works by translating C99 to C89 as needed.

Although the important question we have to ask is not "where are the C++ compilers?", but will we ever see a C++ compiler? GCC for example has their own propaganda written up over how much they support the in progress second C++ standard, without even worrying about the first standard, or even showing a page of how far that is completed yet. Even Microsoft has a page describing some of their caveats. The only little snippet GCC has is this.

Even more disconcerting is that RMS, the idiotic hypocritical redefinitional head of the FSF says he prefers not to have support for "export" in GCC, and prefers it if GCC doesn't follow the standard. His chutzpa is so bad, that he even asked the standards committee if they can change the standard to reflect what he's implemented in GCC, and remove the export keyword altogether, since he doesn't want it to be there.

Of course someone may wonder what is the big fuss about the export keyword anyway. Good C/C++ programmers know that when breaking up functions into different files, it's best to put sizable functions in the C/C++ file, and prototypes for them in the header files for other functions elsewhere to use. The export keyword is supposed to tell the C++ compiler that the current function uses templates, and it needs to have a special uncompiled (but perhaps middle representation) version of the function saved separately to be able to link with other code that calls that function properly.

The problem with export here is that some of the code won't be compiled until link time, meaning a more annoying link process, and the possibility of compile errors at link time. So we have to decide which is the lesser of two evils, either start sticking code in headers files (as people are now forced to do), or have code compile at link time (which people like RMS don't even want to give us the freedom to do). Or do we? Is there perhaps another implementation option?

For MSVC, where Visual Studio itself, annoyingly, won't let you compile a file without having a whole project for it can in fact use this to its advantage. Since it has a full file list, and also keeps class lists and other things such as function prototypes handy for auto completion and tool tip hints, it already knows where it has to grab actual code from. An IDE like Visual Studio just has to pass its compiler the actual file to compile, and a list of other files to pull templates from, and it's all transparent to the programmer. Any compiler could do this, although it would probably get quite annoying if you have to specify all the locations by hand. Of course a sane default might be to try to find '.cpp' files to match any template function prototype in a header file included by the current C++ file that is being compiled.

Post your thoughts on this subject, and any other ideas you might have to sanely implement the export keyword in C++ without running into some of the cons listed above.

19 comments:

Saying that there are no C++ compiler is like saying that Firefox and Internet Explorer 7 aren't really browsers because they don't fully support all the standards. Having a program follow all standards completely is very hard. Viewing standard compliance as a minimum, instead of a goal, skews ones outlook on program assessment. There are things other than standards such as stability security, interoperability, user friendliness, and features.

If you notice the side of my blog, it says: "Get Firefox, a real web browser", I don't consider IE6 a real web browser because of how many standards it breaks.Regarding IE7 and other browsers though, if they suppoer HTML 4, and CSS 1, I'd consider them a web browser. Would you really consider something a web browser if it still didn't finish implementing a decade old standard? I'll get more judgmental about web browser support of CSS 2 and 3 in the future, as they should have had enough time to support it by then.

Now while you have a point that user friendliness, features, and other things are very important, after all we'd rather use an application that has these instead of its competition, if it doesn't really reach its primary goal, why should we use it?

If a program isn't stable, then it isn't a program, and whatever else it does is worthless. Once it is stable, if it doesn't do what it's supposed to do, it's also worthless, unless it manages to do something, and for that little something it's okay. At that point, we look to see what else it offers.

You do have a point though that following every last standard isn't always that important. True, I use GCC despite the fact it doesn't support export. But should I use a so called C++ compiler that doesn't handle basic loops properly? Or one that somehow miscompiles static integers? Can we really call such a program a C++ compiler?

But when dealing with entirely new constructs added to a language, generated code can be very bad depending on the circumstance it's in, or not be as optimized as it could be if the compiler understood which high level constructs the code is coming from.

No, it means better optimisation.

Because the translator for the language (e.g. GHC for Haskell) can focus on optimising the high level constructs of that language into efficient C, and then the C compiler can focus on lower level optimisations - for all of the languages that are translated to it.

It also means all these languages can more easily interoperate and use each others data types.

Microsoft are taking a similar route to this, but with dot net bytecode instead of C.

Even more disconcerting is that RMS, the idiotic hypocritical redefinitional head of the FSF says he prefers not to have support for "export" in GCC, and prefers it if GCC doesn't follow the standard. His chutzpa is so bad, that he even asked the standards committee if they can change the standard to reflect what he's implemented in GCC, and remove the export keyword altogether, since he doesn't want it to be there.

Yes what chutzpa, to think the author of the original c++ compiler would try to give some input towards the c++ standard. No, instead only people who've never heard of c++ should offer suggestions to the c++ standards committee and RMS has no right to express his opinion that code should all compile at COMPILE TIME.

So we have to decide which is the lesser of two evils, either start sticking code in headers files (as people are now forced to do), or have code compile at link time (which people like RMS don't even want to give us the freedom to do).

RMS has given so much so that you can make GCC do whatever you damn well like. I may not like or agree with everything he says, but saying he's against you having the freedom to make GCC do whatever you like is pure, unadulterated, bullshit.

Yes what chutzpa, to think the author of the original c++ compiler would try to give some input towards the c++ standard.

He may have started the first ever C++ compiler, but how dare he suggest to remove a feature because he doesn't like it? People even wanted to implement support for it into g++, and he said no.

code should all compile at COMPILE TIME

If you read what I said, you'd see I offered a way to implement export that it would compile at compile time.

RMS has given so much so that you can make GCC do whatever you damn well like. I may not like or agree with everything he says, but saying he's against you having the freedom to make GCC do whatever you like is pure, unadulterated, bullshit.

He has posted on the GCC mailing lists that when people wanted to implement support for export, he told them not in his compiler and vetoed it. If we were going to implement export like the standard says, we'd have to fork GCC, since he doesn't like it for some reason.

He may have started the first ever C++ compiler, but how dare he suggest to remove a feature because he doesn't like it? People even wanted to implement support for it into g++, and he said no.

So should nothing ever be removed from standards, or should Richard Stallman be allowed no opinion on what should be removed?

It seems you're arguing for the latter - but you still haven't told me who isallowed to make suggestions.

"only people who've never heard of c++ should offer suggestions to the c++ standards committee"?

If you read what I said, you'd see I offered a way to implement export that it would compile at compile time.

I see, I'd misunderstood that paragraph.

If we were going to implement export like the standard says, we'd have to fork GCC, since he doesn't like it for some reason.

GCC already is a fork (http://en.wikipedia.org/wiki/EGCS).

"EGCS development proved considerably more vital than GCC development, so much so that the FSF officially halted development on their GCC 2.x compiler, "blessed" EGCS as the official version of GCC and appointed the EGCS project as the GCC maintainers in April 1999."

There's no reason it couldn't be forked again.Unless people don't give a crap about the export keyword.In which case Stallman maybe has a point?

So should nothing ever be removed from standards, or should Richard Stallman be allowed no opinion on what should be removed?

I have nothing against voting against removing something from a standard.

However I do have a problem with someone demanding that something be removed from a standard just because they can't figure out how to implement it and would rather not have to deal with it in any way shape or form.

>If we were going to implement export like the standard says, we'd have to fork GCC, since he doesn't like it for some reason.

GCC already is a fork

Which is relevant how?

It was forked because of a bad optimizer, and most patches being thrown out the window, so most developers moved to the fork, which then replaced the original.

You can't create a fork over one feature or matter of compliance and somehow shift the whole development team to your fork.

A fork by itself also dies out if not kept up to date with the original, which is a problem when the fork is just one patch which basically has to rewritten for every other new version.

There's no reason it couldn't be forked again.

But forking over one feature ain't gonna happen. If GCC is going to be forked again any time soon, it's going to be because 4.2 is complete trash, the optimization is broken to heck and back. The amount of test cases that don't compile properly is astounding.

A fight regarding licensing could also ensue.

In which case Stallman maybe has a point?

I don't see how "oh I can't figure out how to do it" is a valid point.

However judging from your comments, I guess I wasn't clear enough in my article about how compiler developers have had a very hard time implementing export which is where the problem comes in from, and why RMS dislikes it, not any actual language reason for not having it.

> However I do have a problem with someone demanding that something be removed from a standard just because they can't figure out how to implement it and would rather not have to deal with it in any way shape or form."

Is that really RMS's reason?I doubt it - especially since other people want to implement it for him.

This is a more likely reason:

* The more complex code is, the harder it is to change.* 'export' would add a lot to the code complexity, but comparatively little to the quality of gcc.* It's therefore best not to implement 'export' until all the more simple/urgent changes are made to gcc* This means probably never

And as for his 'demanding' it be removed from the standard - up until now you've claimed he was only 'asking' for it to be removed.

Is that really RMS's reason?I doubt it - especially since other people want to implement it for him.

I'll try to dig up his mailing list messages on it, yes he specifically stated it was too hard to implement and must be removed from the standard.And as for his 'demanding' it be removed from the standard - up until now you've claimed he was only 'asking' for it to be removed.

In Context of Windows:What is the name of C compiler? Yes, this is very strange statement but this is fact, very less number of people knows about the name of c compiler instead mostly using cpp compiler to resolve the problem of c. Most of the companies launched their c compiler with thier editor. No one seperatly issue c compiler which can be compile and execute program directly on MS DOS.

Michael Tiemann developed g++, not Stallman. Quoting from Tiemann in http://gcc.gnu.org/wiki/History :

I wrote GNU C++ in the fall of 1987, making it the first native-code C++ compiler in the world. C++ was a much more complex language than C, and it was still evolving when we started Cygnus. In 1990, several new, even more complex features became "standard," and with all the distractions of Cygnus, I had no time to keep GNU C++ current.

Cast of characters:"dgregor" = Doug Gregor, an Apple employee, Clang hacker, and a member of the C++ committee."_sabre_" = Chris Lattner, another Apple employee, and the chief architect and creator of the LLVM project"jyasskin" = Jeffrey Yasskin, a Google employee and LLVM hacker"ddunbar_" = Daniel Dunbar, another Apple employee and LLVM hacker.

[11:44am] dgregor: export is dead[11:44am] ddunbar_: oh?[11:44am] jyasskin: Yay!...[12:03pm] _sabre_: dgregor: export is dead?[12:03pm] dgregor: yup[12:03pm] _sabre_: what does that mean?[12:03pm] dgregor: removed from the FCD[12:03pm] _sabre_: out of the standard?[12:03pm] _sabre_: whoa.[12:03pm] _sabre_: shocking.[12:03pm] dgregor: no deprecation[12:03pm] _sabre_: ridiculously sensible![12:03pm] dgregor: so we'll never conform to the C++98 or C++03 standards [12:03pm] _sabre_: like most c++ compilers...[12:04pm] ddunbar_: I assumed you wanted to implement it "just for fun"? [12:04pm] dgregor: weekend project

the major problem with "export", as I see it, was in libraries. Say i make a library from codeexport template<int x> int foo();...template<int x> int foo() { return x; }

what shall be in my library file? As you see, there is _no_ easy way of compiling this at link-time. And that's quite bad. Only EDG guys implemented the "export" keyword and they spent on it more time than on writing the rest of c++ compiler :)