Experimental Physics and
Industrial Control System

Benjamin Franksen <[email protected]> · Thu, 16 Aug 2001 21:32:13 +0200

Jeff Hill wrote:
> 
> I suspect that most of the effort required to interface EPICS R3.14 with HPUX
> is going to be related to the implementation of threads on HPUX. My understanding
> is that there is a very complete (better than Tornado II) implementation of the
> C++ standard on HPUX.

Maybe. Thank gods, I don't have to do that work myself. My judgement
comes mostly from the observation of how much of other people's time and
effort is constantly required to port code to different C++ compilers on
different plattforms. I am not talking about individual systems or
compilers but about the general situation.

> Today, as in the past, it is a good idea to consolidate on a common
> programming language. For OO system programming projects that require optimized
> object code C++ is the industry standard.

This is the standard argument in favor of C/C++. It reminds me of
Microsoft claiming their software must be superior since so many more
people use it. Sure, lots of people use it - and get bad results, and
accept it because they don't see an alternative and this is because they
are too frightened to look around and try out something new. It's more a
matter of tradition and fear than of standardization and quality. And
BTW, the standardization of C++ exists only on paper but not in the real
world.

> So for us, the issue is not to search
> for the ultimate OO programming language syntax, but instead whether we should
> continue to use only procedural programming techniques in C or move on to OO
> techniques.

That is not the issue. Large parts of the EPICS core are object oriented
in spirit and design while being implemented in plain C.

I am not arguing that this is the perfect way to do object oriented
programming. A language that better supports OO techniques would be
preferable. Only C++ is not such a language. And this is more than a
matter of syntax, as you probably know very well. Please read or at
least take a look at the "Critique of C++" (the article I recommended in
my original message). The deficiencies of C++ are *not* a question of
style or more or less beautiful syntax or similar superficial aspects.

I will give you a real-life example: When Ralph hacked the support for
alarm acknowledging into the 3-13 portable cas (about a year ago) it
took us hours of discussion to work out the probable internal workings
of the compiler's implementation of multiple inheritance, in order to
understand why a certain C++ construct did not do what any sane person
would expect it to do. This is a general feature of C++: it continually
forces you to base semantical analysis of a piece of code from your
(supposed) knowledge of what the compiler will transform it to at the
assembler or C level. This is worse in C++ than in C, because the
mapping between C code and assembler code is plain and mostly obvious.
In C++ it is no longer obvious, making the reasoning about what a piece
of code actually does, often a matter of guess-work.

Back to the EPICS code: Implementing an OO design in C has resulted in
very nice and clean code that is quite easy to understand and maintain.
I doubt very much that it will improve when re-implemented in C++. But
it could probably be improved using an OO language (like Eiffel) that
really gives you all the advantages of the OO paradigm.

Note that I am *not* in favour of re-implementing *anything*, no matter
what language it is written in, as long as there are no definite
advantages in doing so.

> Use of other languages beside C++ would not allow us to integrate
> efficiently with our original C source code base.

This is plainly wrong. See http://www.elj.com/eiffel/bm/hp-project and
there especially the link to the HP project where Eiffel was used for
embedded systems (printers). They even used VxWorks as their OS. The
most difficult part for them was to get their existing C-code in order,
so that it wouldn't violate assertions made in the Eiffel code. Mind
that these were errors in their old C-code, only these errors became
apparent simply by adding the Eiffel code to the system.

Most existing Eiffel compilers produce Ansi-C code and so are absolutely
portable to any existing plattform. There are straight forward and
efficient ways to interface to existing C code as well as calling Eiffel
code from C. I agree with Mayer (see above link) that

"This is in fact the best way to combine O-O and C: 

- don't mix the paradigms at the language level (which is the best way
to get much confusion and lose the principal benefits of object
technology);

- instead, keep a clean, simple, consistent O-O language; and rely on
the ubiquity, portability and efficiency of C compilers to build on a
solid technology base and take advantage of the mass of C and C++ code
available."

Also note that the EPICS community has already invested a lot of effort
to insulate the EPICS code from the native OS interfaces (see the osi
layer, present in 3.14), thereby making it a lot easier to write
wrappers for other languages.

There is a lot of litarature out there in the www about how and why and
with what results high-level OO languages like Eiffel have been used for
real-time and embedded systems. Read it. It's a revelation.

Ben

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System