On Monday 09 March 2015 07:57:18 Knoll Lars wrote:
> The problem is that a non throwing new can’t reliably detect OOM issues.
> Even if we did check the return value of every 'operator new’ call in Qt,
> this would leave us with one big problem that’s more or less impossible to
> solve. The main problem is that we call new inside other constructors (ie.
> Inside another call to operator new).
>
> The fundamental issue that can’t be solved without exceptions is that this
> should cause the outer operator new to fail (as the inner object didn’t
> get constructed, thus the outer object is not fully constructed and
> usable). But without exceptions there’s no way we can report this back
> through the outer constructor call.
You will be glad to know that the compiler is required to add a null check
before calling the constructor in case of a noexpect or non-throwing operator
new.
[C++11 5.3.4 13]
Other than that, if an user of Qt wants a different behavior for malloc and
new, it is easy enough to use the facilities C++ provides, such as providing a
global operator new, or overriding malloc.
If the application provides its own symbol 'malloc', that one will be used.
So Qt does not need to do anything.
--
Olivier
Woboq - Qt services and support - http://woboq.com - http://code.woboq.org
#include <QtCore/QtCore>
extern "C" void *__libc_malloc(size_t s);
extern "C" void __libc_free(void *s);
extern "C" {
void *malloc(size_t s) {
printf("malloc: %d\n", int(s));
return __libc_malloc(s);
}
}
void *operator new(size_t s) {
printf("new: %d\n", int(s));
return __libc_malloc(s);
}
void operator delete(void *v) {
__libc_free(v);
}
struct Test { double a,b; };
int main() {
printf("main\n");
Test t;
QList<Test>() << t << t << t;
QVector<char> v(88);
}
_______________________________________________
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
