www.digitalmars.com         C & C++   DMDScript  

D - Template argument deduction, template member functions

reply Tobias Neukom <Tobias_member pathlink.com> writes:
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
Jan 26 2004
parent reply "Walter" <walter digitalmars.com> writes:
"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.
Jan 26 2004
next sibling parent reply Tobias Neukom <Tobias_member pathlink.com> writes:
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
Jan 26 2004
parent "Walter" <walter digitalmars.com> writes:
"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;
Jan 28 2004
prev sibling parent reply "Sean L. Palmer" <palmer.sean verizon.net> writes:
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.
Jan 27 2004
parent reply "Walter" <walter digitalmars.com> writes:
"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.
Jan 28 2004
next sibling parent reply "Sean L. Palmer" <palmer.sean verizon.net> writes:
"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
Jan 29 2004
next sibling parent Lars Ivar Igesund <larsivar igesund.net> writes:
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
Jan 29 2004
prev sibling parent reply "Matthew" <matthew.hat stlsoft.dot.org> writes:
 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.
Jan 29 2004
parent reply Ilya Minkov <minkov cs.tum.edu> writes:
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
Jan 29 2004
parent reply "Sean L. Palmer" <palmer.sean verizon.net> writes:
The current system is too complicated, because it's being abused to do
things it's not designed to do.  If all operators were global (not class)
scope, all these problems would go away.  Added would be:

We would have to make our own reverse operators.  No big deal.  Usually
almost the same as the normal one.

Operators could not be virtual.  No big deal, just forward to a virtual
class member function if that's what you need.

Can anyone think of any other drawbacks to making operators be
non-class-members?  Other than it is effort which keeps Walter from doing
other things?

If we get to D 1.0 with it like it is now, it will never be changed and
we'll all be perpetually unhappy about it.

Sean

"Ilya Minkov" <minkov cs.tum.edu> wrote in message
news:bvbgpb$2e2p$1 digitaldaemon.com...

 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
Jan 29 2004
parent "Matthew" <matthew.hat stlsoft.dot.org> writes:
"Sean L. Palmer" <palmer.sean verizon.net> wrote in message
news:bvbk18$2j9e$1 digitaldaemon.com...

 The current system is too complicated, because it's being abused to do
 things it's not designed to do.  If all operators were global (not class)
 scope, all these problems would go away.  Added would be:

 We would have to make our own reverse operators.  No big deal.  Usually
 almost the same as the normal one.

 Operators could not be virtual.  No big deal, just forward to a virtual
 class member function if that's what you need.

 Can anyone think of any other drawbacks to making operators be
 non-class-members?  Other than it is effort which keeps Walter from doing
 other things?

 If we get to D 1.0 with it like it is now, it will never be changed and
 we'll all be perpetually unhappy about it.


Agree totally


 Sean

 "Ilya Minkov" <minkov cs.tum.edu> wrote in message
 news:bvbgpb$2e2p$1 digitaldaemon.com...

 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
Jan 29 2004
prev sibling parent "davepermen" <davepermen hotmail.com> writes:
 Philosophically, I don't believe that this is what arithmetic operator
 overloads should be used for.



if you really want philosophical arguments, you simply know you're wrong.
they don't belong to a type. they belong to two types. so you should not
force them to be bound to one type. thats just plain wrong.

philosophically, that is.

:D
Jan 29 2004