Ioannis Vranos said:
Since I have had enough with this signed value range of Ada, here is a
quick implementation of mine and some uses of it.
Are you under the illusion that the code [your code included below] is
actually expressive?
About forty years ago, when I was working in a Fortran shop, we were awarded
a contract for an inventory management system. At that time, we were mostly
focused on missile defense software, but our DoD customer was persuaded by
our marketing people that we could do the job.
An argument ensued in our programming group about what language to use. I
was trying to convince my colleagues that we should use COBOL since, at that
time, it was the dominant language for business applications. In my view, COBOL
best expressed the kind of solutions we needed for the problem at hand.
Many of my colleagues were adamant about Fortran. Each example I gave of how
something would be done in COBOL, they countered with an example of how it
"could" be done in Fortran. As this debate continued, some of the Fortran
solutions
began to look more and more bizzare. Our manager finally concluded, correctly,
that the problem could best be solved in COBOL.
From this experience, I concluded that there were two important considerations
in
language selection: 1) how well does this language express the kind of
solutions
required for the problem to be solved, and 2) is it possible to solve the
problem
using a given language, even it the solution is a little ugly?
The first I called expressiveness. The second I called expressibility. In
the years
since then, others have come to similar views and that is why new languages are
designed from time to time.
A solution to almost any programming problem can be expressed in almost any
language. This is expressibility. When a language allows one to express that
solution with concisely and with ease, that is expressiveness. Expressible?
Expressive? Which is more appropriate for solving problems?
While you solution demonstrates expressibility, it fails to meet the test of
expressiveness.
I admit that one must be a little careful when using the expressiveness test in
evaluating a language design. Some expressive syntax might be expressive,
but fail other tests. For example, the popular,
+=
*=
and other operator=
constructs of the C family of language are wonderfully expressive of a simple
idea, but their use fails the test of compile-time confirmability. That is,
they
are highly expressive but some of them are also error-prone. The example
from Ada,
type Index is range -42 .. 453;
is confirmable every place it is used. It is expressive of a simple idea. It
does
not involve any unusual behavior at any point in the program where it is used.
It can be checked by the compiler for validity. It can raise run-time errors
without the programmer inserting specialized code. It is expressive of the
idea of a static range of values for a named type.
No doubt that, when you evaluate your solution in the context of expressiveness
versus expressibility, you will see the difference.
------------------------------------------------------------------------------
I am sure one can create a better one or a container directly that
supports ranges, if he devotes some time, so the question again arises,
since it is possible and nothing exists, probably it is not considered
useful to have such a feature in C++:
#include <vector>
#include <algorithm>
#include <cstdlib>
template <class T>
class range
{
std::vector<T> array;
T min, max;
public:
range(const T &mi, const T &ma):array(ma-mi+1), min(mi), max(ma)
{
using namespace std;
if(max-min<=0)
;//throw some exception
for(typename vector<T>::size_type i=0; i<array.size(); ++i)
array
=min+i;
}
const T &operator[](const T &index)
{
// Add range checking max>=index>=min if desirable
return array[index-min+1];
}
operator T() { return array.size(); }
};
int main()
{
using namespace std;
range<int> r(-100, -20);
vector<int> vec(r);
vec[r[-65]]=3;
}
) I do not think there is any