Re: Ada to C++ translator?

[Ole-Hjalmar Kristensen <ohk@clustra.com>]

"Ken Garlington" <Ken.Garlington@computer.org> writes:

<interesting stuff snipped>

> "This has always been the case with Ada. I remember early X meetings
> where we were trying to get a compiler bug fixed for a large package, and
> being told that "the problem is that you're not coding it using the
> preferred Ada style." I remember A-12 being attacked because we didn't use
> tasking. The attackers didn't care about any silly compiler problems, etc.
> They just knew we "weren't Ada enough" if we didn't use tasking. After all,
> they could get tasking to work on their PC; what's the problem?....
> 
> On the projects where we used C++, I don't believe we've ever had anyone say
> we weren't "C++ enough" because we constrained the use of templates. Quite
> the contrary - there's an active effort to develop a standard C++ subset
> (EC++) for use in certain domains, without any fear of being arrested by the
> "C++ police" for subsetting the language. Why would someone want to use a
> language with a built-in Inquisition?
> 
> 

If the advantages outweigh the inquistion, I would consider switching
:-)

Seriously, what is your opinion on today's thread support in Ada?  

I'm working on a project (not written in Ada for various reasons),
running on off the shelf workstations/servers.  Our typical response
times are about 1 millisecond, and there will typically be some task
switching involved in servicing a request. 

If we were to use Ada and its tasking mechanism I would not be so
worried about the task switching time, since our system is a soft real
time system, but portability and scaling issues bother me.  We are
currently running up to several hundred tasks (homegrown very
lightweight threads, really) on each processor. My experiments with
Posix threads indicate that this would probably work on some but not
all our platforms.

Of course, we could use FSU threads, but then we risk blocking the
process while we are doing IO, and that is not acceptable.
Perhaps we risk blocking the process anyway ? Who knows? It seems that
this is entirely dependent upon the implementation.

It would be very nice if the language had support for both normal (a
la Posix or OS threads) tasks, and very lightweight tasks (presumably
running within an OS thread)

-- 
Kabelsalat ist gesund.

Ole-Hj. Kristensen