On Mon, Aug 18, 2008 at 06:03:11PM +0300, dizzy wrote:
It can work perfectly, there are only two cases: - a < 0 : true, done, no need for conversion - a >= 0 : ordinary unsigned comparison
Well that still is a too much cost for some people. You just transformed a single CPU comparison of a < b to 2 comparison instructions. People who made sure that "a" is always positive in their program do not want to pay for the price of doing one more comparison for those who didn't.
Well, then they get to cast their signed number to unsigned: (unsigned)a < b, problem solved.
Depends how do you define security, when you receive a reference are you
Being able to detect invalid input. malloc(-12) is certainly meaningless, malloc(something_large), might be, might be not - where's the border?
references? I hope not! And if not, then why do you trust references but do not trust other syntactic sugar like "unsigned"? Because I meant of using it
It's not about trust - it's about being unable to detect invalid input.
So you make your new Integer class a POD. But then how do you enable implicit conversions (for most of the operator overloads sure you can overload them non-member).
PODs can have member functions, at least if I interpret this correctly: http://www.fnal.gov/docs/working-groups/fpcltf/Pkg/ISOcxx/doc/POD.html
That's how CPUs were made, they don't make much sense in strict mathematical arithmetic but they make a lot of sense in binary mode arithmetic.
CPUs provide various simple means to detect anomalous conditions. C++ does not.
Sure it can, the new Integer type you are doing is such an option. Where should the line be drawn between whatever other high level language features some users need and what the standard library provides?
If there's place for locale...