Corrected spelling.

fixed typo

accept

Please note that we'll do this iff we don't hear screams of pain (followed by 
injections of funding) from users of TAO!

Ooooooooooooooowwwwwwwwwwwwwwwwwwwwwwwwwwwwwww!
Emulated exceptions result in a substantially smaller footprint (factor of 4)
for our embedded systems running VxWorks using gcc-2.96 and egcs. I'm not sure
if the exception handling scheme has changed in newer versions of gcc to reduce
the footprint, and perhaps other compilers including newer ones have a big
footprint with native exceptions.

Our footprint stats show that with newer compilers there is also some increase
but not as major as you say.

Hi Thomas - we've been discussing these issues for some time now on the 
ACE+TAO mailing lists and have reached the conclusion that maintaining the 
exception macros is something above and beyond what the DOC group and other 
commercial support providers can do without sponsorship or having someone else 
takeover the responsibilities for keeping this stuff updated.  If you and/or 
other groups would like to get involved in taking over this responsibility 
that would be great, but we don't have the resources to keep this going with 
our current sponsors/helpers.  Probably the best thing to do would be to see 
if the latest/greatest G++ 4.x compilers can work well enough for what you're 
doing!

An important thing do add, the active maintenance of the emulated exception
macros ended somewhere half october. At that moment our fuzz scripts detected at
least 600 places where macros where not used correctly or where missing. Because
of these errors and the fact that we don't maintain it anymore we put a check in
place which results in an error if you try to build TAO with emulated
exceptions. From x.4.8 the macros in the code are still there but not really
safe to use anymore.

After x.4.7 was release we found errors in the fuzz script checking for the
macros. The scripts have been fixed and improved, resulting in finding a lot of
errors in emulated exception usage through TAO. A lot has been fixed but more
had to be done which started the real discussion whether we would do such an
action or not. The results was to drop support until someone stands up and
sponsors this.

we could then also zap the TAO_RAISE macro

added 1301 as blocks, when this is handled we don't have to solve 1301

*** Bug 2624 has been marked as a duplicate of this bug. ***

I have changes for TAO_IDL pending

We are doing this at this moment, x.5.5 does have a lot of macros in it that are
not usable, x.5.6 will be macro free!!!!!!!!!!!!!!

ready