From: Zeljko Vrba (zvrba_at_[hidden])
Date: 2008-08-19 06:49:03
On Tue, Aug 19, 2008 at 11:02:44AM +0300, dizzy wrote:
>
> 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
>
Hooray, we have agreed on at least something! :-)
>
> 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?
>
You're right, I want constructors. I have yet to see a case where a
user-defined constructor alters the layout of what an otherwise would be a
POD-class, but..
>
> 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.
>
Such facility can be implemented in software, if hardware does not provide a
better way. Efficiency of implementation has nothing to say about it -- not
even all CPUs support floating-point in hardware, yet FP is standardized. If
you would use a construct like overflows(a+b), you'd pay the price, however
large/small it might be, otherwise you wouldn't.
Anyway, time to bring this discussion towards the end -- it seems that we
don't have a large gap in opinions, after all.