Why dont RealTime Embedded programmers use Exception Handling?

The concept is fine.

The way it's implemented in C++ makes it difficult to avoid pitfalls like memory leaks and just plain being a memory hog.

--
Grant Edwards                   grante             Yow!  - if it GLISTENS,
                                  at               gobble it!!
                               visi.com

Exception handling in C++ is often implemented with table searches and stack-frame walking. The time taken to process an exception can be large even for user initiated exceptions (throw), while exceptions driven by hardware (access violation, FPU) have additional overheads. So, if the exception only occurs in non-RT part of the application then all is well but otherwise...

Peter

Peter:

How does the implementation with table searches and stack-frame walking decrease the performance?

How do we catch the exceptions driven by the hardware? the C++ exception are caught if exceptions are thown.. right?

Thanks.

Peter Dickers> > I have seen at several places that C++ programmers writing for RealTime

Compared to _not_doing_ table searches and stack-frame walking, _doing_ them takes a lot of time.

You mean interrupts? The hardware causes an ISR to be called.

I suppose so, unless your compiler and runtime library are broken.

I've also been told by C++ experts that exceptions, when combined with some other features you get almost unavoidable memory leaks. I don't remember the exact combinations, and the "experts" may have been wrong, but IMO C++ is sufficiently opaque that usage of anything other than a carefully screened subset of it's features is just too dangerous.

[Yes, I think that's true for general purpose applications programming as well.]

--
Grant Edwards                   grante             Yow!  If elected, Zippy
                                  at               pledges to each and every
                               visi.com            American a 55-year-old
                                                   houseboy...