Re: OO languages

Hi Vladimir,

Vladimir Vassilevsky wrote:

Are there any folks who have successfully deployed larger
applications in an OO language? No, I'm not talking about
desktop apps where the user can reboot when the system
gets munged. I'm working in a 365/24/7 environment so
things "just HAVE to work".

We have a relatively big embedded system (several M of the source code, filesystem, TCP/IP, RTOS, etc.) developed by a team of five programmers. This system works in the field, 24/7, unattended.

With a filesystem, I am assuming (not a "given") that you have
lots of resources available (?).

Not a lot. Only 600MHz, 64M. In our days, that's nothing. :-)

Ah, I had assumed you also had magnetic media (for the file
system and, by extension, VM). My bad.

Actually, the OS, filesystem and TCP/IP is not very resource consuming: depending on the number of threads, files, sockets, etc., the system needs are practically in the ~100K range. At minimum, we can run from the BlackFin CPU L1 memory.

I'm considerably over that limit. The OS provides lots of
services -- and supports several "critical" services for
applications. So, its got a pretty heavy footprint.
(e.g., HRT guarantees, VM support, tight and loosely
coupled multiprocessing, etc.)

E.g., does the OS support VM?

Unfortunately, BlackFin only has the rudimentary MMU. The full featured MMU would be very useful; I will certainly consider a CPU with the MMU for the next project like that.

Yes. I am a firm believer in this as it probably does more to
"help" the developer than most language features! Of course, there
are costs associated with its use but they are easily (IMO)
outweighed by the extra tricks you can play...

Or, are all of the tasks (processes) running on it known to have
bounded resource requirements?

You feel my pain...

Was the OS written in C++ or just the applications?

The RTOS was written in C++. The multitasking and the hardware abstraction concepts fit nicely with the C++ paradigm; this was one of

*Exactly*! This is the "draw" (for me) to using C++ (or
similar OO). It is just *so* much more elegant to be able
to deal with OS constructs as tangible objects than as
just "handles", etc. And, being able to augment their
definitions with extra cruft to facilitate debugging
(e.g., have a CString in the DEBUG version of each object
that lets you tag the object's instantiation with something
descriptive that you can later use the debugger to inspect.)

The OS itself is object oriented but not implemented in an
OO language. :(

the arguments for using C++. I was very frustrated with the C call nuisance of mucos-II and ADI VDK before.

Does the OS have provisions to detect (and recover from)
crashed applications? Or, does a crashed application
bring the system to its knees?

A crashed application can very well screw up everything. However, if this happens, we fall into the bootloader, so we can recover.

But there is nothing that *detects* that something has gone awry?
I.e., you rely on the errant application to clobber "something"
that *eventually* causes the system to crash? (perhaps a watchdog
brings you back to sanity?)

At the very beginning, there was the usual trivial argument about C vs C++, and it was decided to use C++. Now I can say that was a wise choice; it would be difficult to tackle the complexity in C.

Agreed. But, the problem (IMO) with C++ (or other 4G languages)
is that it is often hard to find folks who *really* know what's
happening "under the hood".

That's the whole point: making the application programming available for dummies. The OO system is supposed to protect them from themselves.

At one level, it *does* (e.g., uninitialized variables, walking
off the end of arrays, etc. -- assuming a well defined set of
classes). But, on other levels, it can bring with it all sorts
of invisible overhead that might be hard for someone not
intimately familiar with the language to pick up on. (e.g.,
I am *constantly* startled by the presence of anonymous
objects that materialize in my code -- albeit of transitory
nature. As objects get "heavier" (e.g., adding debug support),
each one of these that the compiler creates starts to hammer
on memory...

Any tips you can share that can help me get C-like
behavior from a C++-like implementation? (besides the
obvious: "use only the C subset of C++" :> )

"There is no and there can't be any substitute for the intelligence, experience, common sense and good taste" (Stroustrup).

(sigh) But said by someone working for a firm with lots of
re$ource$ to devote to staff, etc. Things seem to be considerably
different in the "real world" (I am continually disappointed
with the caliber of the "programmers" I meet... "just get it
done" seems to be their mantra -- note that "right" is not
part of that! :< )

From the other hand, the bulk of the programmer's work is nothing more then a legwork; it doesn't have to be done brilliantly; it is just has to work somehow.

I think that is true of work in a desktop environment.
There are no *typical* time constraints nor resource
constraints. If the application crashes, the user can
"try again". You (or the OS) can provide feedback to
the user in the form of dialog boxes, log messages, etc.

But, in an embedded system, the application often *must*
work. It may be unattended (no one there to push the
reset button) or perform some critical role, etc. Your
user I/O may be seriously constrained so conversing with
the user may be difficult or impractical (especially if
the user isn't *there*!).

It is exactly this problem that has me vacillating about whether
a "highly structured C approach" would be better or worse than
doing it in C++ (or other 4G HLL). I.e., which are "average Joes"
least likely to screw up? :-/

Just recently I had to fix the project in C developed by "average Joes". There were the usual C problems with not initializing something, providing not enough of memory for something, and running out of the array size. So I think C++ is the better way to do the things.

Again, I think you trade one set of problems for another.
I'm just trying to figure out where the "least pain" lies :<
.

Quantcast