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

["Warren W. Gay VE3WWG" <warren@ve3wwg.tk>]

Robert I. Eachus wrote:

> 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.

That statement is rather strong. This kind of thing is
handled in the C/C++ world all the time as a configuration
item. Now we could argue whether it should or not, but
I don't want to beat on that dead horse here.

> 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).

This does work I suppose, if you add the different pragma Imports
to do the mappings between C_Routine and Different_C_Routine to
the same C function xyz().

But this type of a solution can explode
if the variations to the different versions of OS kernels is
added. Linux for example has gone through many revisions, and
so IMO, it is much simpler to define pid_t as a particular type,
once and for all, once you know what it should be. If you
had to code for these variances everywhere a pid_t was
involved, it would be much more ugly than the
conditional compiled solution.

But, that is _opinion_, and I expect that we'll disagree
about that.

...
> 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.

But this was my original point: if this is done successfully in C/C++
every day, then why can we not provide the same capability
(albiet in a better way) to compete at this same level?
Because of the conditional compilation bias, people want
to explain away the need for it.

Right now, it is _difficult_ to write Open Sourced projects
that compete with C/C++ ones. You might not care about that,
but it is close to my heart. So while I am running short
of energy for further discussion of this apparently futile
idea, it was my hope to spark some good ideas for some
solution(s).

> In fact, you can partition the code into two separately compiled 

Partitioning works good for smaller "works". Once the
number of variables rise, this becomes impractical.

Remember, you are trying to write something that will
compile on the most "user hosted platforms" as possible.
You cannot dictate the version of their kernel, the
version of the other software non-Ada libraries they
are using. You might dictate that your project is only
supportable with certain version restrictions, but you
want to reduce the number of those limitations to the
minimum practicable.

You will _never_ be able to compile all variations
yourself either, nor will you be able to test them
yourself. Some source code "alternatives" are safer
in the "untested" realm.

You cannot every hope to code for all of the possibilities.
As ugly as it is, C/C++ has managed to deal with this
problem sucessfully. And I am not suggesting for a
minute that we copy their approach, but they are doing
_something_ right.

Anyway, I have said my piece on this subject. I have
no energy to flog this dead horse even more. I already
know what I have to do ;-)

-- 
Warren W. Gay VE3WWG
http://ve3wwg.tk