Am Don, 15 M�r 2001 schrieben Sie:
> On Thursday 15 March 2001 16:14, jmartins wrote:
> > Hi
> >
> > We have to perform a hard real time project for ~2000 work hours.
> > For this project we have ~20 objects written in C++.
> > Approximately rewriting cost of these objects into plain C is ~200 work
> > hours.
> >
> > We have not make choice between RTLinux and RTAI yet
> > and hope to develop easy portable system from RTLinux to RTAI and vice
> > versa.
> >
> > Interesting - what is a more reasonable decision:
> > 1) to port our C++ objects into plain C
> > 2) acquire C++ for kernel programming
> >
> > We have some difficulties to make decision.
>
> It depends on a few things, such as which C++ features the existing code is
> relying on, what kind of real time programming model it's designed around,
> whether or not it does dynamic memory allocation, whether on not it
> instantiates objects in real time etc.
I agree.
> I've done some kernel space C++ programing with RTL, and didn't run into any
> serious problems - but then I wrote the code directly for RTL, to run in a
> hard real time system, and considering determinism when designing the
> objects, avoiding excessive complexity. All you have to do is to implement
> new/delete (don't forget the array versions!), and keep in mind that you must
> call the global ctor/dtor hooks explicitly if you're using global instances
> of some classes.
See threads in the mailing list archive as well.
> The most useful (IMHO) features of C++, such as virtual methods, class name
> spaces, inheritance and so on work just fine with RTL, provided you know what
> kind of code is generated. However, dynamic memory allocation - although
> possible to implement (done in RTAI, IIRC) - doesn't mix well with complex
> code and hard real time; actually not with hard real time at all in anything
> by the simplest programs. If you instantiate or destroy objects when
> responding to RT events, you're even deeper init, and have to keep track of
> which ctor/dtor functions are actually called, especially if there are heavy
> ones. Large inheritance trees can make that messy, but OTOH, there are tools
> that make that kind of work a lot easier. (After all, it's all in the code;
> you just have to make sure you don't miss the details.)
If I right remeber you are not able to allocate memory inside a realtime thread
(nevertheless C/C++). There was an allocator for RTAI which can do that. Should
be to find in the mailing archive.
> In short, if the C++ code is properly designed for a hard real time system,
> you'd probably be wasting time converting it into C, but if it's
> "traditional" C++ code, you may actually save time that way.
Biggest Problem is imo the eh. Rtti you can implement with a code rip from the
gcc sources.
> Then again, if the only real problem is too much dynamic (de)allocations,
> that can still be fixed without rewriting to C code - C++ is exactly what you
> make it, rather than inherently dynamic and indeterministic. Inheritance and
> object pools don't mix well, though. If objects are of reasonable and/or
> similar sizes, you can get away with a very simple LIFO stack memory manager
> with one or a few block sizes.
Suggestions:
- I use CTor/DTor as well as auto_ptr excessive for resources.
- Problems using STL (redefiningg POSIX_INITIALIZER from rtl causes problems in
the STL) - I had to rip the auto_ptr from memory (which does include a lot
of config headers which are never used inside ....)
- Keep it simple: Kernel is never be thought to be C++ compliant.
Regards
Olaf
-- [rtl] ---
To unsubscribe:
echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR
echo "unsubscribe rtl <Your_email>" | mail [EMAIL PROTECTED]
--
For more information on Real-Time Linux see:
http://www.rtlinux.org/rtlinux/
