Re: Fun with C

[Georg Bauhaus <rm.dash-bauhaus@futureapps.de>]

On 4/20/11 9:04 PM, Vinzent Hoefler wrote:

> <http://www.open-std.org/jtc1/sc22/wg14/www/charter>:
>
> |Some of the facets of the spirit of C can be summarized in phrases like
> |(a) Trust the programmer.
> |(b) Don't prevent the programmer from doing what needs to be done.
> |(c) Keep the language small and simple.
> |(d) Provide only one way to do an operation.
> |(e) Make it fast, even if it is not guaranteed to be portable.

Not much different from what is true about Ada.

(a) (Like Haskell,) Ada trusts the programmer to be explicit,
e.g. instantiating Unchecked_Conversion.
Normally, though, Ada doesn't trust us when we want to pass
addresses of local objects up the call chain. But it is possible.

(b) Ada seems to make it a little difficult to get pointer arithmetic
from Interfaces.C.Pointers to omit null tests.  But otherwise...

(c) The C standard is about the same size as Ada's, isn't it?
C is simple?

(d) Are there two ways to do an operation in Ada?

(e) Some Ada programs are fast and still guaranteed to be portable.
That's true of some C programs as well.  Ada programs might need unchecked
conversions and representation clauses to make a program non-portable.

Although, an Ada program need not be non-portable even though we let
the *compiler* choose efficient the representation on a target
machine:

     type Roman is ('M', 'D', 'C', 'L', 'V', 'I', 'X');
     for Roman'Size use Integer'Size;

     function To_Integer is new Unchecked_Conversion(Roman, Integer);

Now

     To_Integer(X) + N;

will produce the "byte operation [that] is more efficient on the
target machine" iff the compiler uses efficient byte operations
for Integer.  Or this,

     type S is new String;
     for S'Component_Size use Integer'Size;

So I guess C's (e) is working around the fact that C's choices
would not allow the programmer to say what needs to be done?