Re: Teaching new tricks to an old dog (C++ -->Ada)

[Ioannis Vranos <ivr@remove.this.grad.com>]

fabio de francesco wrote:

> Ciao,
> 
> I think we don't have to care about the presence of a high-level
> construct like whatever container. When C++ hadn't yet standardised
> containers, everyone could actually build these higher-level structures
> by himself. The only problem is standardisation. If you have languages
> that are sufficienly low-level like C++ and Ada you can manufacture
> every type of algorithm and containers you need.
> 
> You build higher-level components by using lower-level built-in
> language features. Every compile-time or run-type check that you can
> have for built-in types you "inherit" for user created structures. This
> is said to answer your past question about Ada having or not same
> checks for built-in types and user defined types.


OK.


> I suppose std::vector is a simple array which must be copied to a
> larger one in order to insert a new element while it is full. You know
> it can be done in Ada too.


It is not that expensive. An implementer reserves some more space so as 
to avoid frequent reallocations, and vector provides reserve() method to 
allocate unitialised space for objects since the beginning by yourself, 
if you are going to insert many objects later, so as to avoid 
reallocation. For example:


// Contains 10 ints initialised to 0.
vector<int> vec(10);

// Reserves unitialised memory space for 1000 ints in total
vec.reserve(1000);



> What's more in Ada is that you can, in a standardised way, directly
> create low-level representation of user defined types with a lot of
> attributes that C++ doesn't provide. Ada programmers prefer to build
> their own types rather than using built-in Integer, Float, Long_Float
> (int, float, double) and so on in order to gain a much finer control.
> 
> In Ada you can decide representation attributes like range, digit,
> delta, mod, address, alignment, size, byte-order (little or big endian)
> in record component, and many other things like these. As an example
> you can write:
> 
> type Counter is new Integer;
> for Counter'Size use 48;
> for Counter'Alignment use 16;
> 
> What's more, you get a compiler error if your machine can't use some
> sort of representation you need in order to free you from knowing how
> much space a type can provide.
> 
> You said that real C++ code hardly need to specify ranges, because you
> should be careful not to assign a value that can't be held by a
> variable of some specific type. Imagine you have know a variable is to
> hold numbers not larger than 99_999 and you choose to store them in an
> "int" knowing that you have enough space. When later you port your
> program to a machine where "int" is 16 bits you don't have any warning
> from a C++ compiler and program run for years until for some reason
> that variable is assigned with say 86_000. I think you know what
> happens..


The standard guarantees the minimum ranges, for int can hold at least 
16-bit values and long at least 32-bit values.


> If you had that type declared as "type Var_T is range 0 .. 99_999;", at
> the very moment you port your program to this new machine the compiler
> would choose the correct size to hold values of that type so program is
> no more restricted to this 16 bits C++ "int" and consequently won't
> raise this bug.
> 
> Do you still think you don't need ranges?


Ranges are a nice thing to have, however if you are provided with 
minimum range guarantees, this also does the job.


I would prefer compiler error messages for out of range assignments 
though. And I wonder what backwards compatibility (apart from -1 
assignment to unsigned integral types) this would break.



-- 
Ioannis Vranos

http://www23.brinkster.com/noicys