Re: [Boost-users] size_type doubts / integer library..

From: dizzy (dizzy_at_[hidden])
Date: 2008-08-19 04:02:44

On Monday 18 August 2008 18:29:27 Zeljko Vrba wrote:
> 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.

Then I'm out of my arguments (for the case of comparison alone, there are 
other cases where such conversions are also performed where more problems need 
to be solved than the additional compare operation). If I were to decide how 
to do it I would have decided as you suggested since it seems the least error 
prone for the user. I'm sure however that there were other reasons that made 
it be this way and I don't think they are arbitrary. Maybe someone more 
knowledgeable can comment. I also do not consider this little feature 
something so important that because it doesn't do as we see it best then we 
can say the language integer types are broken.

> It's not about trust - it's about being unable to detect invalid input.

And how does current C++ makes it impossible 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

By that URL:
The term POD class types collectively refers to aggregate classes (POD-struct 
types)...

And then it says: The term aggregate refers to an array or class that has none 
of the following characteristics [§8.5.1, ¶1]:  user-declared constructors,

And since a ctor used for conversion is such a user declared ctor then you 
can't have it POD anymore. Either if you don't want implicit conversion with a 
ctor you still need your own ctors taking integer values or other integer 
types (with other ranges) and that makes it not a POD anymore right?

> > 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.

Yes it would have been nice to know portably an arithmetic operation has 
overflowed that results in fast CPU code checking for some flag. But I am not 
sure if this is possible for all CPUs that C++ is supposed to run on or how 
useful would be.

-- 
Dizzy
			"Linux is obsolete" -- AST