2011/10/16 Christoph Hertzberg <chtz@xxxxxxxxxxxxxxxxxxxxxxxx>:
> On 16.10.2011 22:21, Benoit Jacob wrote:
>>
>> Note that there is a small performance overhead associated with that.
>> I tried to minimize it, but there is still 1 integer division in the
>> size=rows*cols overflow check. I hope that's still negligible compared
>> to the cost of malloc.
>
> I have not looked into your patch yet, but wouldn't a multiplication in
> int64/int128 also do the job?
I don't know that all platforms have an integer type twice bigger than size_t?
On x86-64 are there 128 bit integers? I didn't know that.
Also I'm afraid there might exist 32bit platforms without 64bit integers.
> I guess that would be much cheaper than a
> division. Anyways I would agree that the overhead should be negligible.. If
> someone really cares for that overhead, we might introduce a flag such as
> EIGEN_DONT_CHECK_INTEGER_OVERFLOW.
>
>> Like the standard behavior of operator new and of our own aligned_new
>> routines, these checks throw std::bad_alloc on error and don't do
>> anything else. In particular, we still don't guarantee that
>> aligned_new returns null on error. It feels weird to me to rely
>> entirely on exceptions to report these errors, but this is how c++
>> works (as long as one doesn't use nothrow-new) and what we've been
>> doing. Is this OK?
>
> I don't want to start a philosophical discussion about exceptions vs
> return-type checking, but honestly I guess that the C++ way is much more
> reliable, since about 99% of malloc users hardly ever check for NULL
> pointers ("Come on, how likely is it that I can't get ** MB?").
> Furthermore, I guess hardly anyone disables exceptions in C++, unless he
> really knows what he's doing.
Both Mozilla and KDE are examples of large projects building with
-fno-exceptions. That's the kind of fact that makes me uncomfortable
about C++ exceptions.
Benoit