From: Zeljko Vrba (zvrba_at_[hidden])
Date: 2008-08-18 11:29:27
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...