EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

1994  <19951996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024  Index 1994  <19951996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
<== Date ==> <== Thread ==>

Subject: Re: A C++ API for the pcas
From: Tony Cox - (415)926-3105 <[email protected]>
To: [email protected]
Cc: [email protected]
Date: Fri, 08 Dec 1995 12:47:13 PST
Michael writes:-

>
>At an object oriented programming class, I talked to a couple of high level
>engineers from Talegent (they [soon] will be selling a C++ "environment").
>They said C++ is inappropriate for realtime uses--among other things
>garbage collection is still not solved.  They noted it has been used in
>realtime, but the examples they gave had rather slow response bounds (~1
>sec).  They said it would be a good choice for user interface work.

That sounds backwards to me. The fact that garbage collection is not part of 
the C++ language is a _good thing_ for real-time programming. The time taken to
garbage collect is essentially unbounded, and whilst in progress you can't get
at your objects (because the GC is moving them around). Better to use smart
pointers and do your own GCing, not let some language compiler decide when is a
good time to clean house.

Further C++ has compile-time binding, unlike some other languages. This means
that you can pass messages (call virtual functions) in a way which is quite
deterministic. Most other languages use some form of run-time binding, which
involves deciding at execution time who the message is for - extend your object
hierarchy, and suddenly you find the timing for your message dispatching is
completely different from what it was.

C++ certainly has its faults, but inapplicability for RT software development
isn't one of them.

Tony

--------------------------------------------------------------------------------
Dr Anthony D Cox
Computer Systems Specialist
Stanford Synchrotron Radiation Laboratory
Stanford Linear Accelerator Center
MS 69, Box 4349
Stanford CA 94305
[email protected]
--------------------------------------------------------------------------------


Navigate by Date:
Prev: Re: building vxWorks for nitro-260 Bill Brown
Next: Labview clients for EPICS Chris Timossi
Index: 1994  <19951996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
Navigate by Thread:
Prev: Re: A C++ API for the pcas watson
Next: C++ Andy Foster
Index: 1994  <19951996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
ANJ, 10 Aug 2010 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·