Re: Why use C++?

["Jed" <jehdiah@orbitway.net>]

Georg Bauhaus wrote:
> On 12.08.11 21:51, Jed wrote:
>
>>> The general idea is that you start from the problem
>>> without giving thought to representation.  Typically,
>>> without loss of efficiency.  Compiler makers know a fair
>>> bit about good choice of representation.  This means:
>>> Describe precisely what matters to your program, on
>>> any machine, without reference to any representation.
>>> Then, and only then, and only if necessary, throw in your
>>> knowledge of representation.
>>
>> That doesn't work when you do IO.
>
>
> Specifying representation when needed, and separate  from
> the type declaration, works perfectly well for I/O.
> For I/O in particular!

Maybe true, but maybe I'd agree, and maybe I'd maybe I'd "bail out" at 
the last step before boarding the airplane, which of course I could maybe 
never ever do, for being so afraid of being in the sky under someone(s) 
else's control... I mean, like Rain Man.

>
> Short summary:
>
> Declaring a type for computation does *not* require specification
> of representation.

That goes without saying. But maybe I LIKE it that way.

> However, should it become necessary

It's not a question of necessity.

> to
> specify a representation of objects of a type, the programmer
> should be able to do so, but *not* by forcing the representation
> into every existing type.

Maybe, but maybe that is too "pie in the sky" academia/wishful-thinking, 
etc. Who are the beneficiaries of such and it is a benefit at all?

>
>
> (Incidentally, bit-oriented, abstracting types (bit fields
> in C, std::bitset in C++, bit arrays in D, or packed arrays of
> Booleans in a host of Pascalish languages) don't make a
> language 4GL.)

I know what a 4GL is, do you? ;)

>
> Examples of how omitting (implied) representation from type
> declaration works well with I/O.
>
> 1. (I/O As-is) Suppose I/O means writing to a particular address.
> There is an output port to write to.  It has CHAR_BIT bits,
> and CHAR_BIT == 8.  You want to write an object of type long
> which happens to consists of four octets.  One approach is to
> write a function that shifts bits into a char object and then
> pushes this object out the port.
>
> Using the fundamental type system of C++, you need some size
> computations, at compile time, or by the programmer, so that
> the program will perform the right number of shifts, for a
> given implementation.  With C++ and long, long[], etc, there
> are idioms. They typically use the sizeof operator, and division.
>
> The very same technique is available for objects declared of a
> type 1e0 .. 1e5 that does not mention any other type's name!
> The programmer may leave it to the compiler to choose a
> representation for objects of type 1e0 .. 1e5 that is
> best on the target hardware for computation.  For I/O, the
> programmer again uses the type system and inquires of the type
> how many octets there are in the type.  But!  He does not have
> to name a type for the "computational objects", such as
> declaring them to be "long", he just lists the values that
> should be stored in objects of the type, and exactly these, no
> more, no less.

Pfft. There is no "int", "long", "short"... but there is int32, uint8, 
etc. Don't bother me with past mistakes. Given that, then move on. All 
else is banter/irrelevant (to progress).

>
> In pseudo code,
>
>    type T is exactly 1e0 .. 1e5.
>    T obj.   // representation left to the compiler
>
>    // compute, compute, compute, ...  then,
>
>    for k in [0, octet_size(T)) do
>      x <- shift_octet_from (obj@k),
>      write_octet(x, port_address)
>    done.

Ech, I have to skip past example code mostly. Until the higher level is 
worked out. "Design in code" is a fantasy (for the most part, it is just 
wailing on the guitar, which is, of course, masturbation).

>
> 2. (Conversion) Suppose I/O means writing a number of structured
> objects to a stream.

Suppose? Suppose this: there is no "stream". :P