Hi everyone

Is Template Argument Deduction going to implemented in near future? This is a VERY important feature for me. I need it especially for some of my math classes. In C++ i had a operator * for matrices:

template<int AROWS, int ACOLS, int BCOLS>
matrix<AROWS,BCOLS> operator * (matrix<AROWS, ACOLS>& a, matrix<ACOLS, BCOLS>&
b);

I can do this i D too. But:
- I can't use operator overloading, because operators have to be member
functions. No member function templates.

- I have to write the arguments of the mult operation every time I use it, a C++ compiler deduces the arguments for me.

Is there a chance to get these features in the next months? Or does anyone know a solution for my problems?

Cheers Tobias

PS: Sorry for my bad english

"Tobias Neukom" <Tobias_member@pathlink.com> wrote in message news:bv398f$os9$1@digitaldaemon.com...
> Hi everyone
>
> Is Template Argument Deduction going to implemented in near future? This
is a
> VERY important feature for me. I need it especially for some of my math
classes.
> In C++ i had a operator * for matrices:
>
> template<int AROWS, int ACOLS, int BCOLS>
> matrix<AROWS,BCOLS> operator * (matrix<AROWS, ACOLS>& a, matrix<ACOLS,
BCOLS>&
> b);
>
> I can do this i D too. But:
> - I can't use operator overloading, because operators have to be member
> functions. No member function templates.
>
> - I have to write the arguments of the mult operation every time I use it,
a C++
> compiler deduces the arguments for me.
>
> Is there a chance to get these features in the next months? Or does anyone
know
> a solution for my problems?
>
> Cheers Tobias
>
> PS: Sorry for my bad english

What I'd do for now is make a matrix class that is not parameterized by the row and column sizes:

    class Matrix
    {    int rows;
         int cols;
         real data[][];

        Matrix opMul(Matrix a, Matrix b) { ... }
    }

Yes, it'll be theoretically slightly slower than if the array sizes were fixed at compile time, but for one thing it'll also be a far smaller app.

>What I'd do for now is make a matrix class that is not parameterized by the row and column sizes:
>
>    class Matrix
>    {    int rows;
>         int cols;
>         real data[][];
>
>        Matrix opMul(Matrix a, Matrix b) { ... }
>    }
>
>Yes, it'll be theoretically slightly slower than if the array sizes were fixed at compile time, but for one thing it'll also be a far smaller app.
>
>

Yeah, maybe your rigth, shouldn't be much slower + I can set matrix size at runtime. One question: Is there a way to get the size of a rectangular array? What will array.length return for a rectangular array?

Thanks & Cheers Tobias

That's a decent temporary workaround, but it won't be a good longterm solution.  I'm not so sure about the "far smaller app" part either, since the compiler has to code several nested loops, none of which is known at compile time.  Not to mention jagged arrays and pointer walking add overhead, in the form of extra instructions.

Do you have any thoughts on how to enable this feature?  Everyone seems to think loose operators and implicit template instantiation are necessary.

Sean

"Walter" <walter@digitalmars.com> wrote in message news:bv4qqj$9de$2@digitaldaemon.com...
> What I'd do for now is make a matrix class that is not parameterized by
the
> row and column sizes:
>
>     class Matrix
>     {    int rows;
>          int cols;
>          real data[][];
>
>         Matrix opMul(Matrix a, Matrix b) { ... }
>     }
>
> Yes, it'll be theoretically slightly slower than if the array sizes were fixed at compile time, but for one thing it'll also be a far smaller app.

"Tobias Neukom" <Tobias_member@pathlink.com> wrote in message news:bv52g4$ml6$1@digitaldaemon.com...
> Yeah, maybe your rigth, shouldn't be much slower + I can set matrix size
at
> runtime. One question: Is there a way to get the size of a rectangular
array?
> What will array.length return for a rectangular array?

int array[3][4];

array.length * array[0].length;

"Sean L. Palmer" <palmer.sean@verizon.net> wrote in message news:bv5d0l$17vs$1@digitaldaemon.com...
> That's a decent temporary workaround, but it won't be a good longterm solution.  I'm not so sure about the "far smaller app" part either, since the compiler has to code several nested loops, none of which is known at compile time.

The loops only have to be coded once for all, not once for each array dimension value.

>  Not to mention jagged arrays and pointer walking add
> overhead, in the form of extra instructions.

You don't really have to use jagged arrays, you can write the array internally as a one dimensional array, and do the r*rows+c calculation explicitly.

> Do you have any thoughts on how to enable this feature?  Everyone seems to think loose operators and implicit template instantiation are necessary.

I'm less convinced. The primary reason for free operator overloads appears to be to implement non-mathematical ops like C++ stream I/O. Philosophically, I don't believe that this is what arithmetic operator overloads should be used for.

"Walter" <walter@digitalmars.com> wrote in message news:bv9l1t$2bdo$1@digitaldaemon.com...
>
> "Sean L. Palmer" <palmer.sean@verizon.net> wrote in message news:bv5d0l$17vs$1@digitaldaemon.com...
> > That's a decent temporary workaround, but it won't be a good longterm solution.  I'm not so sure about the "far smaller app" part either,
since
> > the compiler has to code several nested loops, none of which is known at compile time.
>
> The loops only have to be coded once for all, not once for each array dimension value.
>
> >  Not to mention jagged arrays and pointer walking add
> > overhead, in the form of extra instructions.
>
> You don't really have to use jagged arrays, you can write the array internally as a one dimensional array, and do the r*rows+c calculation explicitly.

Sure.  But this line of argument is similar to:

"I need a hammer"

"We don't have one, but here's this nice screwdriver!"

> > Do you have any thoughts on how to enable this feature?  Everyone seems
to
> > think loose operators and implicit template instantiation are necessary.
>
> I'm less convinced. The primary reason for free operator overloads appears to be to implement non-mathematical ops like C++ stream I/O. Philosophically, I don't believe that this is what arithmetic operator overloads should be used for.

No, the primary reason for free operator overloads is because they never should have been tied to one side or the other to begin with.  Don't let your all-consuming fear of iostreams cloud your judgment on this one.  Just because something *could* be used for a purpose doesn't mean it will be, and hell, Walter, even if it is, why do you care?  That's the end-users' problem.  If they want to make such a beast, let them.

Sean

Sean L. Palmer wrote:

 > No, the primary reason for free operator overloads is because they never
> should have been tied to one side or the other to begin with.  Don't let
> your all-consuming fear of iostreams cloud your judgment on this one.  Just
> because something *could* be used for a purpose doesn't mean it will be, and
> hell, Walter, even if it is, why do you care?  That's the end-users'
> problem.  If they want to make such a beast, let them.

I've no real arguments to add here, but I totally agree with Sean.
Operators tied to a class seems, well, wrong.

Lars Ivar Igesund

> No, the primary reason for free operator overloads is because they never should have been tied to one side or the other to begin with.  Don't let your all-consuming fear of iostreams cloud your judgment on this one.
Just
> because something *could* be used for a purpose doesn't mean it will be,
and
> hell, Walter, even if it is, why do you care?  That's the end-users' problem.  If they want to make such a beast, let them.

I am in no way a fan of the IOStreams, or the general abuse of operators, but I absolutely agree that operators do not belong being tied to class instances. It's just plain wrong.

Matthew wrote:

> I am in no way a fan of the IOStreams, or the general abuse of operators,
> but I absolutely agree that operators do not belong being tied to class
> instances. It's just plain wrong.

It would mean significant changes in the language. I would vote it stays as it currently is. Just that bug has to be fixed, which doesn't search for a reverse (right operand) operator overload if a non-matching direct (left operand) overload exists.

-eye