Problems:
1. The only way I can think of to rename a member function using an
inline function is if that inline function is global. I'm not sure I
like this.
2. If I rename a class using typedef, that will only be effective for
the files I myself am compiling. This is likely to result in surprises
at link time and during symbolic debugging.
On the other hand, if I am obtuse enough to insist on substituting my
own names for an existing interface, I probably deserve whatever I
get. Unless the provocation is extremely great, as when a developer
insists on naming the conjugation operation on a complex number
"operator*". In which case I'm stupid to trust the developer.
Otherwise, I really don't care how the interface is spelled. I care
whether the interface provides adequate functionality and can be
implemented efficiently.
>
> I propose class names which are composed of three parts:
>
> <Type><System><Class>
...
What's wrong with
template class Class<class Type, class System>
instead of your vaguely Hungarian notation?
>
> The library developer provides definitions
> for integral types Offset, Stride and Length.
> An Offset or Length could be an unsigned type
> since they can never have negative values
> but a Stride must be a signed integral type.
Harmless but unnecessary, at least for serial or shared-memory parallel
computations. After all,
ptrdiff_t
*must* have sufficient range for all possible offsets or strides, while
size_t
*must* have sufficient range for all possible sizes of objects.
On distributed-memory parallel machines, one might want a
pseudo-integral type capable of spanning very large distributed
containers. But this would be a class rather than a renamed integral
type. Also, I have grave doubts about the viability of distributed
containers. (I think it will be hard to ever match explicit message
passing for efficiency.)
>
>
> It is probably best to begin with the names of member functions
> which access the attributes of scalar, vector, matrix and tensor objects:
>
> SubScalar SubVector SubMatrix SubTensor | return type
> -----------------------------------------------------------|------------
> handle() handle() handle() handle() | Handle
> offset() offset() offset() offset() | Offset
> stride() stride1() stride1() | Stride
> length() length1() length1() | Length
> stride2() stride2() | Stride
> length2() length2() | Length
> stride3() | Stride
> length3() | Length
> ------------------------------------------------------------------------
>
> After the declaration
>
> doubleMatrix A(m, n);
>
> A.handle() references a 1D array with length m*n
> of double precision floating-point numbers.
> The actual representation of the 1D array
> is determined by the library developer.
> A.handle() may contain a pointer to an ordinary 1D C array,
> a valarray, or some other representation.
If A.handle() really has the semantics of a reference to a 1D array,
then it's indispensible. I want it. I want to be able to hand it to
legacy code, include code written in FORTRAN-77. This requires that
the representation be something I can convert to a pointer to double.
In which case, why not just give me a pointer to double in the first
place? If the answer is that the underlying data layout need not be
a contiguous chunk of memory containing m*n doubles in either row-major
or column-major order, then I'm not interested in using your library.
>
> A.offset() returns the location of element A[0][0] within the 1D array
> and A.offset() == 0 in this case.
So the array bounds are variable? I don't want that added expense, which
can be sizeable. IMO variable array bounds are gold paint.
>
> A.stride1() == 1, A.length1() == n, A.stride2() == n and A.length2() == m
> so A is stored in "row major order"
> if you think m is the number of rows and n is the number of columns.
>
> After the declaration
>
> doubleSubMatrix B = A.t();
>
> where member function t(void) is the "transpose" operator,
> B references the same 1D array as A but
> B.stride2() == A.stride1(), B.stride1() == A.stride2(),
> B.length2() == A.length1() and B.length1() == A.length2()
> so B appears to be stored in "column major order". Bob Tisdale
>
How will this achieved efficiently?
Kent G. Budge
Sandia National Laboratories