Re: Returning a template depending on arguments
On Aug 28, 2:26 pm, daniele lugli <daniele.lu...@gmail.com> wrote:
On 28 Ago, 19:49, Noah Roberts <roberts.n...@gmail.com> wrote:
On Aug 28, 7:38 am, daniele lugli <daniele.lu...@gmail.com> wrote:
Dear all,
this class:
template<int m, int n>
class SmallMatrix
{
typedef double myData [m] [n];
myData M;
public:
SmallMatrix () {
for (int i = 0; i < m; i++) {
for (int j = 0; j <=
n; j++) {
j] = 0.;
}
}
}
virtual ~SmallMatrix () {}
operator myData & () {
return M;
}
operator const myData & () const {
return M;
}
};
This entire class of yours can be replaced by this single line of
code:
;
That's right, a noop.
Now I'll use it:
double matrix0[10][5] = {};
Your class offers nothing over this implementation.
Not true.
My minimal example offers matrix multiplication; matrix-vector
multiplication (over a similar SmallVector template class) and other
similar operations can be added.
The compiler checks that such operations are made with the correctly
sized types.
And none of that adds anything. I can do all that with the array. In
fact, I'd be better off doing so since I'm not relying on silent
conversion operators to break encapsulation.
The encapsulation
benefit you'd normally get from implementing a matrix class is
entirely destroyed by your conversion operator,
I have no reason to completely hide the data: accessing directly via []
[] is a simple and overhead-free way to fill or read the entries.
Then why not just leave the variable public?
an obviously misjudged
attempt to force [][] syntax into the equation.
Why 'attempt'? It works.
Does it?
Quite the contrary in
fact, your class provides for some interesting avenues for unexpected
behavior.
Examples please.
As with all classes that offer implicit conversion operators, your
conversion sequence will be used silently when perhaps it should not.
Reconsider your conversion operator and attempt to gain [][] syntax.
Maybe through an operator[] returning a row selector object, having in
turn an operator[] ?
Or, I don't know, a function?
This could leave place to add some bound-checking code.
But I don't need bound-checking here and I don't want the overhead of
this mechanism.
Because you've measured it and know that it's a problem, right?
What I want is just to avoid rewriting the loops for matrix
operations.
And...?