Java 1.5

[Skywing]

In Java, I would do this:

Code Select Expand

import java.util.BigInteger;
...
BigInteger a = new BigInteger(4);
BigInteger b = new BigInteger(1);
c = a.multiply(b);


I personally prefer that over your operator overloading.

If you really like things being extra-verbose, you could always do c.operator=(a.operator*(b));

[Banana fanna fo fanna]

I hate typing for no reason.

[iago]

In Java, I would do this:

Code Select Expand

import java.util.BigInteger;
...
BigInteger a = new BigInteger(4);
BigInteger b = new BigInteger(1);
c = a.multiply(b);


I personally prefer that over your operator overloading.

If you really like things being extra-verbose, you could always do c.operator=(a.operator*(b));

That just looks ugly..

[Adron]

In Java, I would do this:

Code Select Expand

import java.util.BigInteger;
...
BigInteger a = new BigInteger(4);
BigInteger b = new BigInteger(1);
c = a.multiply(b);


I personally prefer that over your operator overloading.

If you really like things being extra-verbose, you could always do c.operator=(a.operator*(b));

That just looks ugly..

Well, you could settle for c = a.operator*(b); which looks rather close to your java version.

Is the = operator overloaded in java? Or does it always do some particular thing? (i.e. member-wise assignment, pointer assignment, something like that)

And I still don't understand why you prefer function names over operators. It seems a little strange that you'd want to know exactly what happens, but at the same time you're programming in a language that is farther away from the hardware than C++ is. Is this based on bad experiences with someone using the operators to do non-intuitive things?

[iago]

I was beaten with overloaded operators as a child

But seriously, it's because I like code clarity, and I don't htink operators provide that.  

And = in Java is always the same -- assignment.  If it's a primitive type, it assigns the value to the variable, and if it's a pointer (ie, an object) it assigns the pointer to the variable.  

One of the reasons I like Java is simply for code clarity -- unless you're a crappy programmer, code in Java is very clean and readable.  For example, compare this C++ code:

Code Select Expand

ebp = *(DWORD *)((BYTE *)(Copy+3) - ((esi >> 5) << 2));
To the equivolant Java code (as best as I could write it):

int location = 12 - ((esi >>> 5) << 2);
ebp = IntFromByteArray.LITTLEENDIAN.getInteger(Copy, location);

I rather prefer the more verbose, but clearer code in Java.  

[Adron]

I was beaten with overloaded operators as a child

But seriously, it's because I like code clarity, and I don't htink operators provide that.  

And = in Java is always the same -- assignment.  If it's a primitive type, it assigns the value to the variable, and if it's a pointer (ie, an object) it assigns the pointer to the variable.  

One of the reasons I like Java is simply for code clarity -- unless you're a crappy programmer, code in Java is very clean and readable.  For example, compare this C++ code:

Code Select Expand

ebp = *(DWORD *)((BYTE *)(Copy+3) - ((esi >> 5) << 2));
To the equivolant Java code (as best as I could write it):

int location = 12 - ((esi >>> 5) << 2);
ebp = IntFromByteArray.LITTLEENDIAN.getInteger(Copy, location);

I rather prefer the more verbose, but clearer code in Java.  

I prefer the less verbose but clearer C++ code:

ebp = Copy[3 - esi / 32];

(assuming Copy has been properly declared as a pointer to DWORD or int or whatever you're pointing at)

I suppose it really does become a matter of opinion. I find it much easier to abstract away as much detail as possible, and only keep the important things. The less code I have to look at, the better.

[Banana fanna fo fanna]

Code Select Expand


int location = 12 - ((esi >>> 5) << 2);
ebp = Copy[location];


[iago]

Code Select Expand


int location = 12 - ((esi >>> 5) << 2);
ebp = Copy[location];


That won't work because of different pointer sizes.