Re: System calls - GNAT library vs. direct bindings

[Markus E Leypold <development-2006-8ecbb5cc8aREMOVETHIS@ANDTHATm-e-leypold.de>]

> In <1180623520.303981.191090@q75g2000hsh.googlegroups.com>, Maciej Sobczak <see.my.homepage@gmail.com> writes:
>>Hi,
>>
>>I would like to now your opinion about the two options in the subject.
>>
>>Let's suppose that the problem is a network-aware application on the
>>POSIX system. Ada doesn't know about network per RM, so we have to
>>look around for libraries.
>>One option is to use the GNAT library that has some package for
>>sockets.
>>Another is to write thin wrappers that bind directly to relevant
>>system calls (socket, connect, read, write, close, bind, listen,
>>accept, select - that's it for the basic stuff).
>>
>>1. The advantage of using GNAT library is portability across various
>>systems that are targeted by GNAT. (I assume that the GNAT library is
>>available outside of POSIX - if not, please correct me.)
>>
>>2. The advantage of writing custom thin wrappers is portability across
>>various compilers that target POSIX platforms.
>>
>>The first is not really important for me, I will probably use only
>>POSIX systems.
>


> One factor is that Ada was designed for portability there if you do not care 
> about portability then do not use Ada!

What nonsense, Mr anon@anon.org. 

Since there is no portable library for reading any sensors, then your
kind of portability is gone as soon as there is a hardware specific
driver for sensors anywhere. By your definition, almost all real world
code is unportable.

The right way to achieve portability is, of course, to encapsule the
environment / target specific parts of your system into an abstract
layer (say, abstract over sockets towards a send_message_to_my_server
and recieve_message_from_my_server module). Then one has only port the
layer(s) that interface to the outside world, if the target changes.


<snipped>

> But portability gives an average stable performance with a reduced 
> maintainability cost. Which means that development cost may be high but 
> installation and maintains cost afterwards for the software team is very 
> low. Especially in this age of upgrading the hardware every 6 to 18 months.
> So unless one wants to spend the rest on the days updating and rewritting 
> code to maintain that package, portability should be the highest priority.

Astonishin argument. You know that you don't need to port software to
a higher cpu clock speed?


Regards -- Markus