Re: Returning a template depending on arguments
On Aug 28, 5:21 pm, daniele lugli <daniele.lu...@gmail.com> wrote:
On 29 Ago, 01:15, Noah Roberts <roberts.n...@gmail.com> wrote:
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.
Of course yes; and it's precisely what I don't want to do. I don't
like copying and pasting the same code many times.
Who said anything about copy/pasting code? You can write templates
that operate on arrays you know.
With the risk of pasting the wrong lines and looping beyond the size
of the matrix, what is impossible with my class.
Clearly not. Not even close. Your matrix class provides ZERO bounds
protection of any kind, which was my point.
StupidMtx<1,1> digit;
double x = digit[99][4032]; // will happily compile.
In
fact, I'd be better off doing so since I'm not relying on silent
conversion operators to break encapsulation.
your opinion.
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?
Why should I write .M[][] when I can simply write [][] ?
Why write anything at all? At this point I'm beginning to think we'd
all be better off if you didn't.
an obviously misjudged
attempt to force [][] syntax into the equation.
Why 'attempt'? It works.
Does it?
Yes it does.
You mean it apparently does what you think you want it to to the best
of your understanding. You've not thought things through very well
though.
Quite the contrary in
fact, your class provides for some interesting avenues for unexpect=
ed
behavior.
Examples please.
As with all classes that offer implicit conversion operators, your
conversion sequence will be used silently when perhaps it should not.
Are you able to show an example of this? Code, I mean, not words.
template <size_t n>
void fun(double [][n]);
fun(StupidMatrix());
Reconsider your conversion operator and attempt to gain [][] syntax=
..
Maybe through an operator[] returning a row selector object, having i=
n
turn an operator[] ?
Or, I don't know, a function?
Give your example code please.
template < typename T, size_t M, size_t N >
struct slightly_better_matrix
{
T elem(size_t m, size_t n); // no unnecessary exposure of privates,
no complicated reference temps.
slightly_better_matrix() : mtx_() {} // no crazy for loop crap
either.
private:
T mtx_[M][N]; // doesn't have to be this.
};
I'd show you how to use expression templates to make * but It'd blow
your mind too much, especially since "use a function" required example
code.
and here are the results on my machine:
Time in seconds for 1000000 accesses to a SmallMatrix element: 0.004
Time in seconds for 1000000 accesses to an OtherSmallMatrix element:
0.008
Doubling the time could really be a problem.
Try turning off the -g switch and turning on some optimizations.
Examine the assembler output. G++ is actually quite good at inlining
things like this.
Furthermore you're missing a whole class of simpler solutions that
don't exhibit either issue and are prone to easier use and more reuse
of algorithms to a wider array of problems.