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.