Re: Standard Ada Preprocessor (Was: why ada is so unpopular ?)

["Robert I. Eachus" <rieachus@comcast.net>]

Warren W. Gay VE3WWG wrote:

> Ah, but when you are writing code that must interface with
> 3rd party software, where at one version it uses a 16-bit
> value, and on other versions 32-bits etc., then you must
> make your Ada code match _it_.

Hmmm.  I won't say that this is not a potentially killer problem.  Just 
that the issue has nothing to do with configuration clauses.

First let me deal with the different size issue.  I have code that 
interfaces to the two different versions of the subprogram, and code 
that checks a (local static variable) defining which interface is used. 
  My code is written with an if or case statement and multiple calls:

procedure Thick_Binding (I: in out Integer) is
begin
   if OS.Name = Solaris then
     declare
       Local: Int_16;
     begin
       Local := Int_16(I);
       C_Routine(Local);
     exception
       when Constraint_Error => ...
     end;
   elsif OS.Name = Windows then
     Different_C_Routine(I);
   end if;
end Thick_Binding;

The code is all legal Ada except that I have left out the thin C binding 
part) and the fact that there may be all sorts of trouble if C_Routine 
is called with a 16-bit value on Windows (or maybe not).

As I said, the thin bindings part may compile on the "wrong" system or 
may not.  But I deal with that problem in the thin bindings themselves.

Why all the dire words up above?  We used to call it "version skew."  If 
your project depends on components and tools from more than three 
vendors or from the same vendor with different update schedules, you can 
have the problem that there may never be a consistant set of all three 
that works together.  That is a problem outside the ability of anyone 
here to fix.  All you can do is to choose the components that your 
project DEPENDs on, and keep that list small.

In fact, you can partition the code into two separately compiled and 
mantained subsystems to mitigate the version skew effects.  One thing 
that almost jumps out at you from this is something that is almost 
normal practice in the industry.  If you have a system that depends on 
web protocols AND a database, you need to partition the two as well as 
you can.  You may or may not have separate front ends for IE and 
Netscape/Mozilla, you may use ASPs or generate HTML, etc.  But if you 
want to avoid headaches, the portion of the application that is database 
dependent (schemas, data integrity, etc.) is separate from the 
webserving front end.

> And what is even worse, you can configure your interface
> with the pragma Import(), and it will compile and link
> successfully. However, at _run_ time, you'll get undefined
> behavior if things don't agree. This is the impedance
> mismatch that you get between Ada and C (for example),
> and obviously something you try to minimize.

Exactly, I use Ada to choose the right version of the interface for the 
actual system.  But more important, as I said above, I try to partition 
the system as much as possible so that different 
subsystems/partitions/whatever can be updated separately, with only Ada 
interfaces maintained as part of the project in common.


-- 
                                           Robert I. Eachus

"The war on terror is a different kind of war, waged capture by capture, 
cell by cell, and victory by victory. Our security is assured by our 
perseverance and by our sure belief in the success of liberty." -- 
George W. Bush