home *** CD-ROM | disk | FTP | other *** search
- Path: sparky!uunet!haven.umd.edu!darwin.sura.net!mips!sdd.hp.com!hp-cv!ogicse!reed!henson!news.u.washington.edu!uw-beaver!micro-heart-of-gold.mit.edu!xn.ll.mit.edu!xn!jvp
- From: jvp@juliet.ll.mit.edu ( Jim Pieronek )
- Newsgroups: comp.realtime
- Subject: Re: Realtime Object Oriented Programming
- Message-ID: <JVP.92Jul22160308@curan.juliet.ll.mit.edu>
- Date: 22 Jul 92 23:03:08 GMT
- Article-I.D.: curan.JVP.92Jul22160308
- References: <3435@eastman.UUCP>
- Sender: usenet@xn.ll.mit.edu
- Organization: M.I.T. Lincoln Lab - Group 43
- Lines: 23
- In-Reply-To: spoelhof@kodak.com's message of 22 Jul 92 11:20:46 GMT
-
- In article <3435@eastman.UUCP> spoelhof@kodak.com (Gordon C. Spoelhof) writes:
-
- Does anyone have any experience with object oriented programming in embedded
- realtime systems? We are considerng C++ in some of our product futures, but
- have concerns regarding the heavy use of dynamic memory allocation used in
- most object oriented implementations. Is this a real concern? Or do the
- benefits outweigh this?
-
- I have wrestled with the same concern. We do radar DSP and the
- processor has to run for months without a restart. I chickened out on
- relying on the built-in memory management and allocated space
- "manually" and had the constructors/destructors manage free lists to
- keep from getting fragmented. This has not been extensively tested,
- but I've had no problems with it yet. Someday I'll have the time and
- resources to try it both ways over a long period.
-
- -Jim
-
- --
- -----------------------------------------------------------------------
- J.V. Pieronek Internet: jvp@ll.mit.edu
- M.I.T. Lincoln Laboratory (617) 981-3468
- Disclaimer: The Laboratory disavows any knowledge of me.
-