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

[Georg Bauhaus <sb463ba@user1.uni-duisburg.de>]

Ioannis Vranos wrote:
> Georg Bauhaus wrote:
> 
>  > We want a vector type indexed by values between M and N only *and* we
>  > want the compiler + tools to help us make data structures in accord
>  > with these ranges. We want it to take advantage of what it can learn
>  > from the type system which allows index range checking _at compile 
> time_.
> 
> 
> At first, it is easy to write

Not the point.

> a container in C++ that accepts a 
> specified range for indexes.

A vector has an index range built into the language C++.
It was stated that type based indexing together with
attributes helps both the writer and the compiler.
No programmer effort needed.

> The only reason that there is not one, is 
> because it does not make sense in C++

Interesting claim. I Don't buy it. It is just not available
in the language.

> The [0, +] style maps closely what is 
> happening in the machine.

Another Off Topic.

> Also it is possible to define range-checked at run-time, operations. 
> vector::at() is an example.

Why are you repeating this? Not the point.

> vector is also a dynamic-type array, so placing compile-time bounds 
> checking isn't possible/doesn't make sense.

Elsewhere you say that it is possible and does make sense
to work around this lack using compile time assertions,
carfully placing them close to the object to which they are somehow
related. (Effectively creating an ad-hoc meta-language written in
templates. Only shows that the thing is indeed missing in C++.)

It makes sense to know the bounds of a container,
possibly in advance. Are you declaring that std::vector and
not knowing the bounds is the only reasonable thing to do in
programming?

Type attributes are a mode of expression, available with
types in Ada. You can build algorithms around language provided
attributes, for example bounds, without having to resort to
mere conventions and the hope that the compiler will do something
useful with the conventional items.

> For fixed size arrays and containers it is true, the compiler does not 
> catch at compile time any out of boundaries access. However we can do 
> this explicitly, by using compile-time checked assertions.

In other words, C++ array like types don't have these properties.
I'm not saying this is catastrophic. It's just not available
unless you roll your own. This has consequences for how you write
your software. It has consequences for what your compiler can do.
Some of them are interesing, because of template computing.


>  > No. I mean a double subtype whose values range from N.M to N'.M'.
> 
> 
> May you give an example for a container along with such a subtype?

It was given, starting this "sub"thread.

>  > Here you can see one point that you might want to demonstrate:
>  > The compiler won't tell you that there is something wrong
>  > with
>  >
>  >   doors[10].SetOpen().SetNoVan();
>  >
>  > Worse, the program won't tell you either. This shows the missing
>  > link between vector indexing and the base type system in your
>  > approach. You could use
>  >
>  >   doors.at(10).SetOpen().SetNoVan();
>  >
>  > and handle the exception _at run time_.
>  > In Ada, the compiler will tell you: "index value 10 is no good!"
>  > because the array "doors" can only be indexed by values effectively
>  > between 0 .. 9. These and only these are the values of the type
>  > enumerating the ten doors, and only these are allowed as index
>  > values x in expressios doors(x).
>  > No exception handling, no .at() needed when you listen to your
>  > compiler and fix the indexing error before you deliver a program.
>  > You get this for free as a result of the language's type handling
>  > at compile time.
> 
> 
> Will the Ada compiler tell you this, for user-defined types too?

An enum is a user defined type.
Any unconstrained type (including more than array types)
entails constrained objects, and the compiler may have a word
in this.
Maybe, if one gets used to template programming, the basis of the
language is deliberately ignored?
Ada just doesn't need templates for many things that are tried
using templates in C++, because the things are already in the
language.


> Or is 
> this restricted to built-in arrays? If the latest is true, then its 
> value isn't that much.

Every bug that is found at compile time is worth a lot
to me.

Try telling someone that useful array attributes, and type attributes
and object attributes in general, aren't of much value.
What else are .begin() and .end() other than roll-my-own replacements
for something that C style arrays lack, *language-wise*?
   Those working for an insurance company, in a stocks related business,
in math related computing, statistics, etc. use *Array Programming
Languages*. Why would they be doing this if good array support
isn't worth something? What is the value of good array support in
all those valuable Fortran computing libraries?

Are you saying that a robust base type system isn't worth it because
of the STL?
Consider the effort is takes to get a useful STL made of
basically, at-least-so-many-bits integers, pointers, and malloc().

Please answer this question:
Why is vector not implemented using vector? (I'm serious.)

 > I think that the value of defined subranges in the style
> -1000, -400 has not any practical use.

Any evidence?

>  > - Given an enum, and
>  > - given a language that allows the enum as a basis for the construction
>  > of an array type in the type system 
  ...
>  > (a) useful names for objects in your problem domain, checked at
>  > compile-time
> 
> 
> What do you mean by names?

I mean object names (enumerated identifiers), not strings. Like in

   typedef std::map<Some_Enum, int>  Slow_Array;

This is not the same as

   typedef std::vector<int>  Faster_Array:


>  > (b) a conceptual link between the enum (naming the single items) and
>  >   a container _type_ (containing these items); you cannot use anything
>  >   but these named numbers for indexing
> 
> 
> Which has no value in the world of C++, but I guess many things in Ada 
> depend on this.

You just gave an example of an assertion working around
the indexing issue...  So apparently proper indexing has
a value in the world of C++, contradicting your claim.


>  > (c) the fastest possible access, for both reading and writing, possibly
>  >   checked at compile time
> 
> 
> Fastest possible access in C++.

The fastest possible element access in C++ is dereferencing a pointer.
The fastest possible element access in STL/C++ is varying with container
and method.

Compare

    type Floor_Number is -2 .. 52;
      --  sky scraper

    type Door_Count is array(Floor_Number) of Natural;

versus

     typedef char Floor_Number;
     typedef std::map<Floor_Number, unsigned int> Door_Count;

We are discussing fastest access, and type based indexing.

So my question again, what does it take, in C++, to replace
Floor_Number as typedefed above with something that matches
the given building's floors exactly? What is the price to pay?


> is the Ada compile-time boundaries checking available 
> to user-defined containers? 

We are discussing the value of a container that doesn't *need*
to be defined because it is built into the language's type system,
with all bells and whistles and compiler help. No user definition
is *needed*, it's already there.

If you insist on leading us astray and on constructing your own
containers: The presence of bounds checking in programmer defined
ADTs depends on how they are defined.

 > can compile-time assertions be used?

The compiler will warn you when it can evaluate the expression
in a pragma assert at compile time. More importantly, the
compiler will use the compile-time checking required by Ada
array types. No need for programmer assertions expressed
using add-on templates.

> Of course
> one can always program improperly. :-)

I did say that this is not the point, didn't I?

The point is, how does a language help you writing
correct and efficient programs. C++ the language doesn't
have fixed size built in arrays. In some problem domains,
fixed size arrays are very useful, if not essential.

This is why many programming languages have them.

Georg