D - Template argument deduction, template member functions
- Tobias Neukom (16/16) Jan 26 2004 Hi everyone
- Walter (17/33) Jan 26 2004 is a
- Tobias Neukom (4/14) Jan 26 2004 Yeah, maybe your rigth, shouldn't be much slower + I can set matrix size...
- Walter (6/9) Jan 28 2004 at
- Sean L. Palmer (11/21) Jan 27 2004 That's a decent temporary workaround, but it won't be a good longterm
- Walter (11/19) Jan 28 2004 The loops only have to be coded once for all, not once for each array
- Sean L. Palmer (14/33) Jan 29 2004 since
- Lars Ivar Igesund (5/10) Jan 29 2004 I've no real arguments to add here, but I totally agree with Sean.
- Matthew (5/11) Jan 29 2004 I am in no way a fan of the IOStreams, or the general abuse of operators...
- Ilya Minkov (6/9) Jan 29 2004 It would mean significant changes in the language. I would vote it stays...
- Sean L. Palmer (15/20) Jan 29 2004 The current system is too complicated, because it's being abused to do
- Matthew (3/24) Jan 29 2004 Agree totally
- davepermen (5/7) Jan 29 2004 if you really want philosophical arguments, you simply know you're wrong...
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
"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? Thisis aVERY important feature for me. I need it especially for some of my mathclasses.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 anyoneknowa solution for my problems? Cheers Tobias PS: Sorry for my bad englishWhat 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
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
"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 sizeatruntime. One question: Is there a way to get the size of a rectangulararray?What will array.length return for a rectangular array?int array[3][4]; array.length * array[0].length;
Jan 28 2004
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 bytherow 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
"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
"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...sinceThat'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,Sure. But this line of argument is similar to: "I need a hammer" "We don't have one, but here's this nice screwdriver!"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.toDo you have any thoughts on how to enable this feature? Everyone seemsNo, 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. Seanthink 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 29 2004
Sean L. Palmer wrote: > No, the primary reason for free operator overloads is because they nevershould 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
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.Justbecause something *could* be used for a purpose doesn't mean it will be,andhell, 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
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
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
"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 totallySean "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
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