looking for compilers and/or platforms **without** C++ exception support

Sort of a vague question for this group. As this group works with several processors including DSPs and RISC chips. Do you want to include compilers that run on a PDP-11? Do you want compilers that compile to different operating systems?

....just wish to point out there are a lot of possibilities here, and you may want to narrow your question to a certain range of possibilities.

Convince gcc porters to stop work dead, and you'll have quite a few OSes...

-Dhruv :-)

Hello

Microsoft embedded C++ 3.0 (eVC 3)

-- GISTEK software Gis consultant. snipped-for-privacy@gistek.net

Many C++ compilers for 16 bit DOS do not support exception handling, templates or RTTI (but Digital Mars C++ does).

On 30 Oct 2003 11:07:45 -0500, snipped-for-privacy@yahoo.ca (Bill Davidson) wrote in comp.realtime:

Since you posted to comp.arch.embedded with such a hopelessly vague question, there are quite a few architectures with no C++ compilers at all, so they certainly do not support native, or foreign, C++ exceptions.

It seems a strange question - what for?

The C++ language is now defined by an ISO standard. The language specified in that standard /does/ support exceptions, and the runtime library described in the standard /does/ use exceptions. Any compiler that doesn't support them isn't C++ (not standard C++, anyway).

Maybe that's the answer you're looking for? Non-C++ compilers don't support native C++ exceptions. Fortran compilers, for example.

If, on the other hand, your question is really "how widespread are C++-subset compilers that don't support exceptions" or "if I use exceptions in my code will my code be significantly less portable than if I don't use them" then the answer is that all modern compilers on desktop platforms do support exceptions, as do the better embedded ones. I would expect this situation to improve as compilers continue to be updated to include more of the provisions of the standard.

- I believe that the Microsoft compilers targetting Windows CE currently don't support exceptions (is that still true? It seems a strange omission), - Visual C++ for 16-bit platforms didn't support excpetions (but had an exception-like system without stack unwinding kludged with longjump). - C++ on the Symbian platform does not use exceptions (because it depends upon an old version of the gcc cross-compiler which is deficient in exception support) and so has its own error-handling mechanism. Porting code to/from Symbian is a fairly major undertaking because Symbian provides a large runtime library that is peculiar to the Symbian platform, support for exceptions will be the least of your worries. All the C++ compilers I'm aware of for Windows and/or linux do support exceptions.

Unless you have a particular compiler or platform in mind that you know does not support exceptions I would go ahead and use them. In my experience the use of exceptions leads to clearer code and more robust error handling than the alternatives.

Daniel James | djng Sonadata Limited, UK | at sonadata | dot co dot uk

ARM - ARM Developer Suite (ADS) 1.2 ARM - RealView Compilation Tools (RVCT) 2.0

Davids>> I am looking for a list of popular compilers and/or platforms that

The wording looks quite strange, but considering that the realtime and embedded newsgroups are included, I would guess that the original poster is considering situations in which exception handling is not desirable.

A compiler that does not support exceptions will not generate exceptions at run time :-).

I think that the more relevant question in the embedded and/or realtime environment is that, can a compiler that supports exception handling be configured in such a way that it does not generate exceptions ? This is especially important regarding the run time libraries, such as "new".

The exceptions can not be disabled, then the use of C++ in some situations is out of the question.

Paul

Davids> >> I am looking for a list of popular compilers and/or platforms that

Right. Some compilers, particularly in the embedded world, do indeed permit exceptions to be disabled. That can lead to code that is smaller or faster (or both). Or it can simply permit the use of C++ in a project that outlaws exceptions for safety reasons (whether justified or not). If you want to use a compiler that can disable exceptions, then you also need a library that can work that way. We provide such a creature, which is one of the reasons why so many embedded compilers ship with our library. I believe one or two other libraries do too. But if the library that comes with your compiler doesn't work properly in the absence of exception handling, your only choice is not to use the library.

P.J. Plauger Dinkumware, Ltd.

The notion of 'native' is not clear to me, however, it might mean three things IMHO, either

1. the compiler does not know the concept of exceptions (it is not native to the compiler implementation) and therefore does not support try/catch
2. the compiler does not know that the platform it generates code for has a particular exception mechanism as for example the structured exception mechanism of Windows NT or a similar architecture in VMS (one of the signs showing heritage)
3. the platform on which the code runs does not know an exception mechanism, most if not all UNIXen.

In case #1, that would be a pretty old compiler I would say. Case #2, I would say could be versions of the Borland C++ compilers, that indeed make use of the structured exception handling mechanism but only in a limited way, meaning that they /do/ use structured exception handling for propagating exceptions by using a structured exception with the 0x0EEFFACE number (or 0x0EEDFACE for Delphi), and in case #3, the exception handling mechanism is almost always 'emulated' in some sense.

What is very instructive in the last case is what code a compiler inserts at the start of a try/catch block. I think I am not far from reality if in most cases a register is reserved for pointing to the current exception handler while outer exception handlers are kept in a stack, much like structured exception handling in Windows NT.