Thread: Though implementation problem

Yes, the code compiles, but it is far from correct.
In the first case, -1 is converted to unsigned and 255 is added.
In the second case, the number is truncated and 255 is added.

What's "correct"? Given that you're dealing with an unsigned 8-bit value which uses modulo math, adding -1 and adding 255 are mathematically identical. So are adding 2^64 - 1 and adding 255.
If you don't actually want modulo-256 ring math, why are you using a CInt<uint8_t>?

CInt<uint8_t> is just a way of saying "I want this integer to be 8 bits."
But it doesn't stop me from adding 64-bit integers. Yes, it will overflow, but in some instances, you might want to or ignore that.
And besides, the point is that it's misleading. The result is pretty undefined and that's wrong. You would expect to be able to add something without truncating it. The behavior is just... too wrong.

For example:

Code:

	uint8_t i = 0;
	i += 0xFFFFFFFFFFFFFFFF;

This code will perform the addition in full 64-bit addition operation on i, and then truncate it when moving it back into i.
However, the class would truncate the number to 0xFF and then add it, which wouldn't produce the same operation, though I'm unsure if it would produce the same result.

I don't know the impact of this but it's certainly not a good thing, because it destroys warnings (especially unsigned/signed warnings).

phantomotap:
However, I still see no reason as to not use templates. They are a generic way of doing the same thing for an infinite range of types, right?
Since all types would be handled the same, I see it as a means to remove code duplication and maintenance for the class. The real beauty lies in that I can specialize a template if I need a specific type to behave differently.

And besides, the point is that it's misleading. The result is pretty undefined and that's wrong. You would expect to be able to add something without truncating it. The behavior is just... too wrong.

Not, it's perfectly defined and correct. You just have to understand the mathematics of modulo rings.
http://en.wikipedia.org/wiki/Modular_arithmetic

However, the class would truncate the number to 0xFF and then add it, which wouldn't produce the same operation, though I'm unsure if it would produce the same result.

It would. That's why your concern is unfounded.

because it destroys warnings (especially unsigned/signed warnings).

None that I know of. Shouldn't it already warn you upon creating the implicit CInt<uint8_t> because of the truncation?

Originally Posted by CornedBee

None that I know of. Shouldn't it already warn you upon creating the implicit CInt<uint8_t> because of the truncation?

It doesn't.
This produces a warning:

Code:

	uint8_t i = 0;
	i += -1;
	i += 0xFFFFFFFFFFFFFFFF;

This doesn't:

Code:

	CInt<uint8_t> i;
	i += -1;
	i += 0xFFFFFFFFFFFFFFFF;

How about this?

Code:

	CInt<uint8_t> i;
	int i = rand() - (RAND_MAX / 2);
	i += i;

No warning. Change to uint8_t, I do get a warning.
Wait. It might be because of something implementation. I'll run a test.
EDIT: Now I get a warning for both.

I see now. It's basically the same behavior as if doing with native types.

Code:

	uint8_t i = 0;
	i += 0xFFFF; // Truncation
	i += -1; // Signed/unsigned

My fears are unfounded. Good.

I've already changed it to:

Code:

	CInt& operator %= (const CInt& Data);

And it seems to behave just as with normal integers, so I'm all happy now with less complexity


Ah yes, quick question:
I'm trying to check for overflow/underflow, but instead of taking into account everything (including the possibility of negative numbers) and using templates/traits for max/min range of numbers, isn't there some assembly equalient that can check for overflow/underflow?
I'm not sure if there are some other functions that may check or if it's possible to check in assembly after the operation has been done (ie check flags)?

Suggestions?

Why is this thread nearly 300 replies long?
Haven't you fixed the original problem yet, or is this just a meandering "Elysia" support thread?

Just a suggestion, but if these are new questions, they should be new threads, with links if you think it's relevant.

Oh, I could fit in a 100 questions to this generic topic title, but if you insist, I can make new threads.
But I found it exciting to enlarge the thread and see how many replies could get crammed into it.

Originally Posted by phantomotap

It depends on the architecture and operation, but I think 'x86' has a flag that it sets after an operation is performed if any overflow/underflow occurs.
Soma

Yes, it's x86. I don't do much other than Windows™ programming.
I'd rather do it in assembly than a fat code and additional complications to check for under/overflow.
I'll try looking in an assembly manual.