Re: Why use C++?

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

On Tue, 16 Aug 2011 15:51:29 +0100, Bill Findlay wrote:

> On 16/08/2011 11:58, in article 17sfxzivd6ba0.1lpjrmelcfuoa$.dlg@40tude.net,
> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote:
> 
>> On Tue, 16 Aug 2011 12:23:48 +0200, Georg Bauhaus wrote:
>> 
>>> Is changing only the representation of types, not the types,
>>> necessarily premature optimization?
>> 
>> The answer depends on the time the change is made. "Premature" in its
>> original meaning (Knuth) means: during design, before functional
>> requirements are met.
> 
> There are important cases in which the representation of types is an
> essential part of the functional requirement.

I addressed this in my earlier post.

> For example, writing a
> bit-accurate emulator for an existing computer architecture;

Actually not. You can represent an array of bits in any desired way. The
order of bits and their actual layout in the memory (if observable), are
unrelated:

   type Word is array (1..16) of Boolean;
   type Word is mod 2**16;
   type Word is range 0..2**16-1;
   type Word is new Wide_Character;

You are free to choose any of them and yet remain "bit-accurate". Bit
accuracy is defined by the implementation of Get_Bit, Get_Byte etc
operations.

> or processing data generated by a legacy non-Ada system.

You need only one type for an octet or other atomic type used as the I/O
unit. Note that this type is predefined by the I/O library, so normally
there is no need not to define it. You cannot use anything more complex
than that because there is no any guaranty on I/O semantics of composite
type.

> These cases are not the most common, but they are also not the ignorable
> trivia you claim them to be.

They are. The second case is communication to alien hardware/software
protocols, it is my daily job. You don't need any representation clauses
there.

It is amazing how many people think otherwise. It seems that conflation of
the encoding issues with type representations is very deep rooted.

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