Re: Using representation clauses in networking software

["Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>]

On Sun, 15 Aug 2010 18:40:15 +0200, Yannick Duch�ne (Hibou57) wrote:

> Le Sun, 15 Aug 2010 18:10:08 +0200, Dmitry A. Kazakov  
> <mailbox@dmitry-kazakov.de> a �crit:
>>> Would it make sense to deprecate them?
>>
>> Maybe, especially because they do not allow writing portable programs
>> anyway.
> How do you handle this then ?

Dynamically:

   Value :=  Unsigned_16 (Buffer (Index)) * 256 +
      Unsigned_16 (Buffer (Index + 1));
   Index := Index + 2;
   ...
exception
   when Constraint_Error =>
      Raise_Exception (Protocol_Error'Identity, "Malformed telegram at ...

BTW, an ability to handle protocol errors is another good argument against
representation clauses.

> How would interface API as an example ?  
> Formated memory blocks ?

It is usually layered, at least: raw I/O, telegrams, application layer. In
reality it can be more, because modern time protocols themselves are
layered. Many of them are dynamic. You just cannot statically describe all
queries and responses. You ask the device capacities, build query lists,
configure events, start measures, stop measures. It is far too complex for
representation clauses.

> Can you give an example case where this shows to be contradictory with  
> portability ?

When using representation clauses? In order to use them you have two
parameters in the equation: the internal endianness and external
endianness. How can it be statically independent on the former (=portable)?
Well, with conditional expressions of Ada 201X, maybe, it could be possible
to describe. But I don't want to be one to maintain that mess. I'd better
stick to good old means.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de