I thought of this vaguely hackish (okay, very hackish) C++ pattern today. It looks far too succint to be original, but I don't know what it's called ("this thing that acts sort of like lazy evaluation").

class Factorial {
public: 
	unsigned int base;
	Factorial(unsigned int _base) : base(_base) {};
	operator unsigned int() {unsigned int b=1; for (int i = 1; i <= base; i++) b *= i; return b;}
	unsigned int operator/(Factorial f){unsigned int bma=base, bmi=f.base,b=1; for (bmi++;bmi<=bma;bmi++) b*=bmi; return b;}
};

unsigned int hello(Factorial a, Factorial b)
{
	unsigned int c=a,d=b;
	return c/d;
}

unsigned int goodbye(Factorial a,Factorial b)
{
	return a/b;
}

This is a dumb example since a compiler could figure it out, but the second function does a shortcut.

thunks? (didn't read the code, sorry)

Very cool, and very evil.

A prime example of why operator overloading is a bad idea. ^^;

Evil? Because it lets you write more efficient code without sacrificing readability?

I think this is why it's a good idea. A bad one would be if I overloaded a typecast to have side effects. Or maybe cout.

> Because it lets you write more efficient code without sacrificing readability?

You have to be kidding. That is readable? You've been in Perl-land far too long.

I'm familiar with C++, yet that still took me a few moments to decipher. Are you telling me that is more readable that the straight-forward non-overloaded implementation? Maybe I'm just rusty, but I really doubt it.

I don't like overloading simply because it makes code less transparent. What does this do in C:

a = b + c;

Pretty obvious, right? It adds two things. The only other detail is data type.

Now, what does it do in C++? Uh... well, let me check the definition. Hmm, not a standard type. Is that an object or not? Let me check the headers. Oh, it's a class? Well, shit, I'll need to look in the class declaration. Oh, no, the class inherits from elsewhere, etc.

Perhaps overloading is a useful tool that is just too easily abused.

Uh, switch "definition" and "declaration" where appropriate.

> well, let me check the definition. Hmm, not a standard type. Is that an object or not? Let me [..]

well, that's pretty much standard fare in oop

>>6

You're looking at lines out of context, though, which you'd never do in a real program. The "operator overloading makes code harder to read" argument is a strawman based on assuming bad implementations and a lack of real-world insight. In a real program, you'd know what classes are involved, and with good operator overloading the operators would do the thing you expect to happen with whatever classes you want, and your code would be much readable.

I find it much easier to read this:

matrix m;
vector v1,v2;
vector v3=3*m*v1+2*v2;

Than this:

matrix m;
vector v1,v2;
vector v3=m.transform(v1).multiply(3).add(v2.multiply(2));

You could attempt to ditch OO entirely and go with this, but it doesn't help much:

matrix m;
vector v1,v2;
vector v3=add(multiply(transform(m,v1),3),multiply(v2,2));

I don't even know if I translated those right, because they're so painfully unredable. Now try to implement 3D graphics where you have page after page of vector/matrix maths in that kind of syntax, and see how painful it is to read, compared to the neat and clean operator-overloaded code.

PS: I could make up my own strawman about how hard it is to read my third example in C because I don't know what the functions "transform()", "multiply()" and "add()" do without looking at their source code or something. Also, C code is hard to read because I have no idea what machine code is generated so I don't know what my program actually does, so the only truly readable code is assembly, except I don't know what byte values are generated by the assembler so the only truly readable programming language is machine code.

Arguments about "transparency of code" are bullshit. Every language hides stuff from you - that's the point of using a programming language instead of flicking switches on a front panel.

> In a real program, you'd know what classes are involved

Really?

And what if you're in the middle of a page of code? With lots of variables? And what if you're also worried about exceptions?

I hardly think this concern is a strawman, unless the whole goto-is-bad argument is build on strawmen too. What's wrong with asking about something as simple as a = b + c;? If that silly thing already causes problems, why shouldn't I be concerned?

> Arguments about "transparency of code" are bullshit.

This isn't black and white.

Then again, that can be said for overloading.

Chill.

> assuming bad implementations

After half an hour, and rereading this, I announce that I have been enlightened.

I probably only notice overloading when it's done poorly.

> This isn't black and white.

Exactly, which is the reason I think arguments against operator overloading are stupid, because they are blanket condemnations. But you seem to have caught on to my line of thought here.

Operator overloading is great unless you're the new guy on the project trying to figure out wtf the last guy was writing. Moral of the story: cycle to work.

If you start making language design decisions based on business cod emonkeys who barely know the language, you end up with Java. Or VB.