In article <35tv0c$88c@tethys.otol.fi> tohoyn@janus.otol.fi (Tommi H|yn{l{nmaa) writes:
>
>* Currently C++ allows only a single indexing operator to be defined.
>This complicates the design of multiple-indexed arrays. These could be
>programmed more easily if the multiple-indexing operator could be
>defined directly.

Yea.  So?

Accessing ISAM files could `be programmed more easily' if support for
ISAM files were built right into the language.  Does that imply that
C++ should become COBOL?  I think not.

(Uh oh!  Maybe I should keep these thoughts to myself.  Why do I all of
a sudden get the feeling that at the next C++ standardization committee
meeting, someone will be there with a proposal for adding ISAM support
to the standard C++ library? :-(

--

-- Ron Guilmette, Sunnyvale, CA ---------- RG Consulting -------------------
---- domain addr: rfg@netcom.com ----------- Purveyors of Compiler Test ----
---- uucp addr: ...!uunet!netcom!rfg ------- Suites and Bullet-Proof Shoes -

* Currently C++ allows only a single indexing operator to be defined.
This complicates the design of multiple-indexed arrays. These could be
programmed more easily if the multiple-indexing operator could be
defined directly.

e.g.
class Array2d
{
public:
..
  OwnType operator[][] (int y, int x)
    {
    if( y >= ysize || x >= xsize ) Error();
    return data[y][x];
    }
private:
  OwnType data[ysize][xsize];
};

class Array3d
{
..
OwnType operator[][][] (int, int, int);
..
};

* Template argument constraining (as in Eiffel). That is, the type of the
template class argument could be restricted to a given class and its
subclasses. The programmer can then control better the use of the template
class.

class SortableObject
{
public:
  int Compare(const SortableObject&);
};

template <class T: SortableObject>
class SortedArray
private:
  T* data[size];
  ...
public:
  const T& operator [] (int i) const  { return *data[i]; }
  ...
};

* A way to declare "true" functions. That is, functions that only calculate
their result using their arguments and perhaps some global data. These
functions would not be allowed to change the values of their arguments
(that is, they would all be 'const') or to change the values of global
variables. Changing the system state (printing to the screen, memory
allocation, etc.) should also be prevented inside these functions.
You can declare all arguments 'const' in current C++, but this is not
enough.
This kind of function can e.g. change the values of global variables or
draw something on the screen.

* Assertions (preconditions, checks,...) could be part of the language.

By the way, where can I find the latest C++ standards?

{

>>>>> Tommi H|yn{l{nmaa <tohoyn@janus.otol.fi> writes:

> * Template argument constraining (as in Eiffel). That is, the type of the
> template class argument could be restricted to a given class and its
> subclasses. The programmer can then control better the use of the template
> class.

There is no need for an extension to supply this; if you only want to
accept classes that provide a certain method, just use it in the template.
An instantiation using a class that doesn't will produce an error.

> * A way to declare "true" functions. That is, functions that only calculate
> their result using their arguments and perhaps some global data. These
> functions would not be allowed to change the values of their arguments
> (that is, they would all be 'const') or to change the values of global
> variables. Changing the system state (printing to the screen, memory
> allocation, etc.) should also be prevented inside these functions.
> You can declare all arguments 'const' in current C++, but this is not
> enough.
> This kind of function can e.g. change the values of global variables or
> draw something on the screen.

I assume you mean "cannot" in this last sentence.  Many vendors already
provide this functionality as an extension.  For example, GNU C/C++ provide

double cos (double) __attribute__ ((const));

HP's compilers allow you to say

#pragma NO_SIDE_EFFECTS cos

OSF/1 uses

#pragma _KAP no side effects (cos)

etc, etc.  It *would* be nice to standardize this.

> * Assertions (preconditions, checks,...) could be part of the language.

You can use assert() for these.  There has been discussion of an
exception-based assert(), but I'm not sure whether anything has come of it.

Jason