Slashdot Mirror

That's not entirely true - one of the most well-respected C++ compilers, Comeau compiles to C.

C and C++ is not the same. And actually as I see it Microsoft has officially "abandoned" their C compiler, they will not add C99 support and not do much development at all for all I know (unless they changed their mind recently).

True, but there's only one MSVC compiler .exe to do both and I expect the backend code generation path is virtually the same for both (if not actually the same). In the context of this thread I meant "native code compiler" as opposed to .NET compiler anyway.

Microsoft say they haven't done full C99 because of lack of user interest, although they note that much of C99 is required for compatibility with the next C++ standard. Mind you if you want C99 with an MSVC backend you can always use Comeau C.

At least the Comeau C++ compiler still generates C code, and is known as one of the most portable and standard-compliant C++ compilers (including support for exported templates!). So compiling C++ to C is definitely a viable strategy (although I can understand compiler vendors that want to offer a complete toolchain take a different approach).

I think you're missing the point, C++ is a language, (nearly) everything you are talking about here is related to IDE's. Thats not to say what you have said is not valid, but IDE's are frilly text editors and its compilers that use the C++ language (or any other language) to generate machine code (FYI most compilers have a 'generate list' switch that will give you the same disassmbly output as you're used to with PIC compilers - I guess because they tend to be huge they are off by default.) Thats where the problem comes, the compilers very rarely adhere to the language standard, for example the first 100% compliant C++ compiler Comeau/Dinkum(http://www.comeaucomputing.com/tryit out/) was released as recently as August 2002. C++ has its faults, the same as any other mature language but I prefer it as my weapon of choice for the parts of large applications where I need to get close to the HW, and C if I've got to get really close. As much as I use the same old languages I do find myself changing editor far more often trying to find something that does everything, still mostly jumping between MSDEV and Emacs.

Well, I am not a Fortran advocate but even I know that modern Fortran is not spelled all UPPER CASE.

Which leads me to belive that your informations are not up to date - a Fortran advocate can tell you when the move from FORTRAN to Fortran was done but it must be more then 10 years ago.

But what strikes me more: You as a C/C++ advocate should know that there is only one fully compiant C99 compiler available. Apart from that:

Maybe C/C++ could have evolved differently, if it wasn't so much a "commercial" software. All companies did incompatible improvements to C/C++ so their marketing people could say "ours is the best C/C++ in the market".

Only of corse they arn't - MS-C does not evern know about the keyword "restrict" which is an optimzing hint and the minimum implementation requironment is to ignore the keyword.

Fully working implementation of C99's VA arrays - no where to see - appart from just one compiler (http://www.comeaucomputing.com./

In Germany we have a saying: "Don't throw stones if you sit in glass house".

Martin

Who said there are only 2 compilers? He only tested 2, that's all. Here's a bit of a list - and notice that some of these are targeted specifically to scientific computing:

1. GCC
2. Intel compiler (Intel only)
3. Comeau
4. PathScale (Opteron only)
5. Portland Group (PGI)
6. Borland

• Maturity
• Speed
• Correctness
• Standards Compliance
• Inexpensive and affordable
• for Linux and other platforms

I believe that Comeau has historically had the most compliant C++ compilers. I'm not sure if they fully implement the standard, but if anybody does, it's them.

here are some C/C++ references. The chip documentation is not public AFAIK, although google picks up occasional hints.

Actually, all of the most popular C++ compilers are getting pretty close to standards compliance (even g++ ;-). This is largely thanks to the work of The Edison Design Group, who license compiler front ends, and are very focused on standards compliance.

If you don't want to spend a lot of money, and you don't want to stop using the compiler that you have, I highly recommend The Comeau Compiler. It is a compiler front end derived from the EDG codebase, and only costs you $50. The big downside is that your compile times will be much longer than usual, but at least you can use the export keyword to help with that a bit.

As far as I know, Comeau's compiler is the most standards conformant on the market. It even supports export!

Only US$50 for per copy.

The people who use Comeau's compiler are generally concerned with portability, because, as any C++ programmer knows, most compilers completely blow when it comes to standards conformance at the moment.

> Every bit of the code that is in Qt to
> implement signals/slots is standard ISO C++
> code. No different than with Boost::Signals

But Qt code uses non-standard keywords such as "public slots" and "signals". Code which uses these keywords need to be fed into a preprocessor which then converts that code into legal C++. The Comeau C++ compiler is a C++-to-C translator. Your argument is like saying any C++ code is perfectly legal ANSI C code; you just have to feed the C++ code into a "preprocessor" (such as Comeau's compiler) first before you actually compile it.

A signal/slot implementation like boost::signals, on the other hand, is ANSI C++ code.

Comeau C++ is standards compliant. Most compilers based off of the EDG front-end are very compliant. This includes Intel, Comeau's and SGI's C++ compilers. It does not include MS C++ 6 or Sun's C++ compiler, and look at how standards-compliant those are (on the other hand, Borland's compiler is quite good and it's not EDG-based).

If you need total standards compliant though, Comeau C++ is the tool for you.

class foo {
void operator=( int a ) {
}
} ;

There are a great variety of cross-platform libraries and frameworks that you would find useful. For example, for a humble JPEG coded, the Independent JPEG Group's JPEG library works really well and runs on everything from DOS to a Cray. It is portable beyond belief. For a lossless graphics format there is libtiff. (I don't know what's available for cross-platform video format software, but I'm sure there is some.)

If you're going to write in in C++, my favorite framework for GUI, file API's, TCP networking, multithreading and database is ZooLib. (But note that presently the best code to use is what's in CVS because it hasn't had a release in a long time (Real Soon Now, really!).

I've started writing a book about ZooLib that is released under the GNU Free Documentation License.

But if you don't like ZooLib, it's important to use some cross-platform framework. There are many to choose from.

Another important framework is the Simple DirectMedia Layer. You will want this for your rendered scenes and for sound (ZooLib does 2-D graphics, it's not a 3-D API).

If you write in C++, do as much as you can with the Standard Template Library. There are some excellent books that teach how to use it.

For a long time, the STL has got a bad rap, in part because the template definitions in the header files are hard to read, and in part because of poor compiler implementations of the C++ ISO standard, or poor implementations of the library itself. But by now there are excellent implementations for every OS that is in common use. For example, on Windows, don't bother with Visual C++ - use Metrowerks CodeWarrior or Comeau C/C++.

Even if you choose to work with a broken compiler, the STLPort library provides a compliant standard library that will work almost anywhere.

I was rather intimidated by the STL when I first encountered it but once I got a good book and learned how to use it, I thought it was the best thing since sliced bread.

Boost has many portable C++ libraries that are of excellent quality.

Finally, I am (slowly) building a website devoted to educating developers in cross-platform and portable programming called ByteSwap.net. Read my first article there Writing Cross-Platform Software - Getting Started. More articles will appear when I get more free time!

g++ is missing various things: the export keyword, the two-phase name lookup principle (which changes the meaning of a program; so that could be bad), universal character names and a number of other things.

However, being fully compliant doesn't only mean you can put a checkmark next to every feature. The feature must be implemented correctly and invalid programs should get errors. That last part g++ does pretty poorly on. It swallows tons of things the online Comeau compiler (an EDG derivative) correctly gives errors on.

<sigh>Once again my story gets rejected when it contains more info than the one that gets posted. :-(

To set the record straight, EDG do indeed produce C++ front end compiler tools, and it is these that have just been released.

However, major C++ vendors including Comeau Computing use that in their compilers. Comeau already have a beta of their 4.3.0 compiler available at their on-line compiler. The full version is due later this month.

Dinkumware have also announced a version of their standard library implementation to work with Comeau, which should be available shortly after the Comeau compiler is released. Apparently, it makes extensive use of export, but for little change in performance at compile-time.

That makes their new library implementation a bit academic as far as Joe Developer goes. However, it's excellent news in general, because it shows that using export isn't going to entail a performance hit. We can finally write template code with interface and implementation properly separated out.

<sigh>Once again my story gets rejected when it contains more info than the one that gets posted. :-(

To set the record straight, EDG do indeed produce C++ front end compiler tools, and it is these that have just been released.

However, major C++ vendors including Comeau Computing use that in their compilers. Comeau already have a beta of their 4.3.0 compiler available at their on-line compiler. The full version is due later this month.

Dinkumware have also announced a version of their standard library implementation to work with Comeau, which should be available shortly after the Comeau compiler is released. Apparently, it makes extensive use of export, but for little change in performance at compile-time.

That makes their new library implementation a bit academic as far as Joe Developer goes. However, it's excellent news in general, because it shows that using export isn't going to entail a performance hit. We can finally write template code with interface and implementation properly separated out.

In particular, I know that KAI C++ and Compaq's C++ compiler are both based on EGD.

Yes, KAI and Compaq use the Edison front end. So do Comeau, SGI, Intel, and a number of other compilers. See EDG's site for a more complete list.

Some of EDG's customers will release a compiler based on the new front end sooner than others, partly for business reasons (every company has different tradeoffs) and partly for technical reasons (for some companies, a new front end means an awful lot of integration work).

I expect Comeau to be the first company to sell a compiler based on the new EDG front end: Greg Comeau has been very excited at being able to support export. I'll be surprised if it takes longer than a few weeks for the new Comeau compiler to come out.

To me, the export keyword is a "nice to have", and not a "must have". Personally, I'll consider export a viable alternative to defining templates in the header when a broad range of compilers support it. Unfortunately, it seems that most implementations will be lacking it for a while longer. The compiler that is closest to supporting it, AFAIK, is Comeau.

That number being, of course, zero.

Although Comeau Computing's C++ compiler is due to include support imminently, according to their web site. Their compiler is far ahead of most others in standards compliance, however.

• Tech Talk About C++ and C
  
• PGI Workstation User's Guide
  
• Fortran and C/C++ Mixed Programming
  

No-one seems to have mentioned Comeau C++ yet.

Greg Comeau is a regular contributor to C++ newsgroups, and I've had some personal communication with him in the past. He obviously takes some pride in his product. From what I hear, it's justified; the output it produces is good, and its compliance with standard C++ is, and always has been, at the head of the field. For example, it gets a credit in Alexandrescu's "Modern C++ Design" for being sufficiently up to speed that it can use the Loki library's template tricks, and they're predicting the all-important "export" support by the end of this year. Perhaps most important, Greg seems open to comments, and willing to proactively improve the product.

The big problem used to be lack of a standard library implementation, but I believe it now ships with the latest Dinkumware libraries (as used in VC++, but a much more recent version without the irritating flaws). It should also be noted that this is a commercial product, although Comeau Computing provide a free "try it out" facility on their web site.

I have no association with Greg Comeau or Comeau Computing other than having spoken to Greg in the past and found him to be a good guy.

Nitpick: Actually, it won't compile on every system. C99 forbids "implicit int", i.e. you can't declare main without an explicit return value of int anymore; and calling undeclared functions is illegal, too. Sniff around www.comeaucomputing.com for an online C99 compiler.