Hi,
(sorry for top posting)
Small note, I believe that exception safety never really worked. It was
almost not tested, so everyone depending on the feature was depending on an
undefined behavior anyway. At the beginning of Qt5 I tried to improve the
situation in our containers. I wrote a few tests, I fixed a few bugs, but it
was like going through a swamp, slow and dirty. Getting a review was difficult,
because such changes were increasing code size, binary size, were complex and
the worst almost nobody cared. The amount of bugs was scary. Even our the best
container QVector was not working correctly with exceptions. So removing
exception support is not a functionality regression it is just acknowledging of
the current state. Now, maybe in some places it works, but from a API user
perspective it is gambling. I do not think we are able to have exception safety
"back", that requires a lot of commitment that I do not see.
Personally, I used to like exceptions. It is sad that Qt is not supporting or
really use them, but I believe that people can live without such support.
std::bad_alloc, is it even possible to see it, when at least on Linux most of
distros have memory overcommit enabled?
Cheers,
Jędrek
________________________________________
Od: development-bounces+jedrzej.nowacki=digia....@qt-project.org
[development-bounces+jedrzej.nowacki=digia....@qt-project.org] w imieniu
Olivier Goffart [oliv...@woboq.com]
Wysłano: 2 października 2013 09:09
Do: development@qt-project.org
Cc: Thiago Macieira
Temat: Re: [Development] Disabling exception support in QtCore?
On Tuesday 01 October 2013 23:32:00 Thiago Macieira wrote:
> On quarta-feira, 2 de outubro de 2013 05:42:24, Knoll Lars wrote:
> > On 01.10.13 23:23, "Thiago Macieira" <thiago.macie...@intel.com> wrote:
> > >On terça-feira, 1 de outubro de 2013 20:00:56, Knoll Lars wrote:
> > >> Yes, signal/slot connections between user code should IMO still be able
> > >> to pass through exceptions. I am afraid removing that will break code
> > >>that's out there.
> > >
> > >This is already forbidden since 5.0.
> >
> > Is there any good reason why we don't support this, as we did in Qt 4? My
> > goal of still compiling Qt Core with exceptions enabled was to allow for
> > exactly this use case.
>
> Because we don't test it, so there's no guarantee that it works. In fact,
> I'd be surprised if it works at all. What's more, our types aren't
> exception-safe, even the container types. It's entirely unknown what will
> happen during a stack unwind.
>
> Personally, I don't want to maintain that functionality.
>
> And then there's the question: is it worth the 7% increase in code size?
It is working. We even got bug report for some corner case where it did not,
and I fixed those. (so they are used)
There is no test because you did not want to have one. But we could easily add
more auto tests. (It is really not that difficult)
And it is "forbidden" only because you decided so, but it is not actually
forbidden.
I personally think letting exception go from the slot to the signal is a good
feature (for the DirectConnection case).
I am willing to maintain this functionality.
Of course it is not allowed to throw an exception with QueuedConnection, or if
the caller of the signal is not exception safe (all signals in Qt).
And if a signal is connected to several slots, further slots are not going to
be called.
The only stack frame it needs to crosses are QMetaObject::activate, the moc
generated code for signals or qt_metacall, and the templated helpers in
qobject(defs)_impl.h. Could we perhaps only compile part of QtCore with
exception support?
Exceptions are not only about std::bad_alloc.
I think it is unfortunuate that we removed support for user thrown exceptions
from our container. (I agree that supporting bad_alloc is useless).
But supporting throwing constructor and copy constructor in all the containers
is a bit harder than in signals and slots. (And also less usefull)
--
Olivier
Woboq - Qt services and support - http://woboq.com - http://code.woboq.org
_______________________________________________
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
_______________________________________________
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
