Since we decided to roll back support for exceptions in our container classes,
the only thing that currently needs exception support is the mainloop allowing
std::bad_alloc through.
Is it worth it?
Should we disable exceptions in QtCore?
--
Thiago Macieira - thiago.macieira (AT) intel.com
S
nt@qt-project.org
Emne: [Development] Disabling exception support in QtCore?
Since we decided to roll back support for exceptions in our container classes,
the only thing that currently needs exception support is the mainloop allowing
std::bad_alloc through.
Is it worth it?
Should we di
Thiago wrote:
> Since we decided to roll back support for exceptions in our container
> classes,
> the only thing that currently needs exception support is the mainloop
> allowing
> std::bad_alloc through.
>
> Is it worth it?
>
> Should we disable exceptions in QtCore?
>
No, and yes. ;-))
I vot
forms like 32-bit ios.
>
>
>One thing I'd love to see is the ability to throw exceptions through
>meta-call invocations (would be useful for qml, which uses exceptions)
>
>
>Simon
>
>
>
>Fra: Thiago Macieira
>Sendt: 21:20 tirsdag 1. oktober 2013
>Til: de
On Tue, Oct 01, 2013 at 12:20:29PM -0700, Thiago Macieira wrote:
> Since we decided to roll back support for exceptions in our container
> classes,
> the only thing that currently needs exception support is the mainloop
> allowing
> std::bad_alloc through.
>
> Is it worth it?
Given that hopin
On terça-feira, 1 de outubro de 2013 19:31:05, Hausmann Simon wrote:
> Hmm question - certainly worth it for sjlj platforms like 32-bit ios.
>
> One thing I'd love to see is the ability to throw exceptions through
> meta-call invocations (would be useful for qml, which uses exceptions)
The rule i
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.
You can throw from your slots
On terça-feira, 1 de outubro de 2013 22:28:53, André Pönitz wrote:
> Perhaps... do we have numbers how much the gain would actually be, say,
> for code size?
Give me an hour.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center
signatur
On Tuesday 01 October 2013 21:20:29 Thiago Macieira wrote:
> Since we decided to roll back support for exceptions in our
> container classes, the only thing that currently needs exception
> support is the mainloop allowing std::bad_alloc through.
>
> Is it worth it?
>
> Should we disable exceptio
On terça-feira, 1 de outubro de 2013 22:28:53, André Pönitz wrote:
> Perhaps... do we have numbers how much the gain would actually be, say,
> for code size?
All numbers are based on my own QtCore tree, which contains a lot of patches
on top of current stable, including protected visibility. I wi
On quarta-feira, 2 de outubro de 2013 00:04:58, Christoph Feck wrote:
> On Tuesday 01 October 2013 21:20:29 Thiago Macieira wrote:
> > Since we decided to roll back support for exceptions in our
> > container classes, the only thing that currently needs exception
> > support is the mainloop allowin
On Wednesday 02 October 2013 00:41:56 Thiago Macieira wrote:
> On quarta-feira, 2 de outubro de 2013 00:04:58, Christoph Feck
wrote:
> > On Tuesday 01 October 2013 21:20:29 Thiago Macieira wrote:
> > > Should we disable exceptions in QtCore?
> >
> > If it allows us to get a backtrace actually sho
On quarta-feira, 2 de outubro de 2013 01:03:19, Christoph Feck wrote:
> > In order to properly do that, we should remove all try/catch blocks
> > in QtCore and replace with scoped pointers and scoped values. We
> > should let the destructors handle the cleanup.
>
> Sounds "a bit" more work than si
On 2013-10-01 21:20, Thiago Macieira wrote:
> Since we decided to roll back support for exceptions in our container classes,
> the only thing that currently needs exception support is the mainloop allowing
> std::bad_alloc through.
>
> Is it worth it?
>
> Should we disable exceptions in QtCore?
>
On 01.10.13 23:23, "Thiago Macieira" 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 alr
On quarta-feira, 2 de outubro de 2013 05:42:24, Knoll Lars wrote:
> On 01.10.13 23:23, "Thiago Macieira" 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
On quarta-feira, 2 de outubro de 2013 06:57:01, Thomas Sondergaard wrote:
> On 2013-10-01 21:20, Thiago Macieira wrote:
> > Since we decided to roll back support for exceptions in our container
> > classes, the only thing that currently needs exception support is the
> > mainloop allowing std::bad_
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" wrote:
> > >On terça-feira, 1 de outubro de 2013 20:00:56, Knoll Lars wrote:
> > >> Yes, signal/slot connections between user code
On 02.10.13 09:09, "Olivier Goffart" wrote:
>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"
>>wrote:
>> > >On terça-feira, 1 de outubro de 2013 20:00:56, Knoll Lars wrote:
>
On Wed, 2 Oct 2013, Knoll Lars wrote:
> +1. It's our decision not to use exceptions in Qt code, but I see quite a
> bit of value in being able to throw exceptions from a slot if that's the
> pattern a developer chooses to use. We've been doing quite a bit of work
> to allow this in Qt 4, and it's
On quarta-feira, 2 de outubro de 2013 07:13:11, Knoll Lars wrote:
> +1. It's our decision not to use exceptions in Qt code, but I see quite a
> bit of value in being able to throw exceptions from a slot if that's the
> pattern a developer chooses to use. We've been doing quite a bit of work
> to al
On quarta-feira, 2 de outubro de 2013 09:09:16, Olivier Goffart wrote:
> 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
On Wed, Oct 02, 2013 at 06:57:01AM +0200, Thomas Sondergaard wrote:
> On 2013-10-01 21:20, Thiago Macieira wrote:
> > Since we decided to roll back support for exceptions in our container
> > classes, the only thing that currently needs exception support is the
> > mainloop allowing std::bad_alloc
On Wed, Oct 2, 2013 at 12:39 PM, André Pönitz <
andre.poen...@mathematik.tu-chemnitz.de> wrote:
> On Wed, Oct 02, 2013 at 06:57:01AM +0200, Thomas Sondergaard wrote:
> > On 2013-10-01 21:20, Thiago Macieira wrote:
> > > Since we decided to roll back support for exceptions in our container
> > > cl
On quarta-feira, 2 de outubro de 2013 20:39:25, André Pönitz wrote:
> Size overhead for "just enabling exceptions" is (of course depending on
> actual model/implementation) typically cited as 5-10%, which incidentally
> matches Thiago's findings for Qt Core rather well. That's a pretty high
> price
On 2013-10-02 20:39, André Pönitz wrote:
[...]
>
>
> tp://google-styleguide.googlecode.com/svn/trunk/cppguide.xml#Exceptions
> is for instance pretty concise: "We don't use C++ exceptions". They
> later
> give detailed reasoning and a conclusion including "Our advice against
> using exceptions
On Wednesday 02 October 2013 09:30:58 Thiago Macieira wrote:
> On quarta-feira, 2 de outubro de 2013 07:13:11, Knoll Lars wrote:
> > +1. It's our decision not to use exceptions in Qt code, but I see quite a
> > bit of value in being able to throw exceptions from a slot if that's the
> > pattern a d
Le 03/10/2013 10:36, Olivier Goffart a écrit :
> On Wednesday 02 October 2013 09:30:58 Thiago Macieira wrote:
>
>> That would mean any signal could throw ANY exception. It would also preempt
>> the execution of further slots, which might be important.
>>
>> Usually the person who connects a signal
(sorry for jumping in the middle of the discussion)
>Quoting style guides that apply for applications can by definition not
>contain reasoning for library writers. Apps live in their own little
>dream world and can play with the compiler flags anyway they wish. They
>only target one App, after
:
> From: Julien Blanc
> Subject: Re: [Development] Disabling exception support in QtCore?
> Date: 3 Oct 2013 11:10:21 GMT+02:00
> To: development@qt-project.org
>
>
> Le 03/10/2013 10:36, Olivier Goffart a écrit :
>> On Wednesday 02 October 2013 09:30:58 Thiago Macieira wro
On quinta-feira, 3 de outubro de 2013 10:36:44, Olivier Goffart wrote:
> > I dislike allowing this via the signal-slot mechanism because I see
> > throwing from a slot as incompatible with the connection semantics.
> >
> > That would mean any signal could throw ANY exception. It would also
> > pre
On quinta-feira, 3 de outubro de 2013 09:43:18, Marc Mutz wrote:
> Qt is a general-purpose framework library. As a library, its *only*
> purpose is to serve its users; as a framework, it mandates a certain
> structure on programs using it. As a general-purpose library, it can
> only assume very lit
Assuming exceptions are enabled for signal/slots what is going to happen
with Qt::QueuedConnection?
As far as I understand at this point you can't catch exception in the
signal.
That means you will have to do it in the event loop. What is going to
happen next? Re-throw it and an uncaught exception
On quinta-feira, 3 de outubro de 2013 17:11:54, Alex Malyushytskyy wrote:
> Assuming exceptions are enabled for signal/slots what is going to happen
> with Qt::QueuedConnection?
> As far as I understand at this point you can't catch exception in the
> signal.
If we choose to standardise that exce
On Fri, Oct 4, 2013 at 7:08 AM, Thiago Macieira
wrote:
> On quinta-feira, 3 de outubro de 2013 17:11:54, Alex Malyushytskyy wrote:
> > Assuming exceptions are enabled for signal/slots what is going to happen
> > with Qt::QueuedConnection?
> > As far as I understand at this point you can't catch e
In some markets like Avionics and Defense, it is simply forbidden for us to use
exceptions.
So, at least I think it should be possible to disable them in Qt if it was
decided to allow them, otherwise we would be forced to use another framework.
Aside from that, and that is personal, I really like
2013/10/4 Kurt Pattyn :
> In some markets like Avionics and Defense, it is simply forbidden for us to
> use exceptions.
> So, at least I think it should be possible to disable them in Qt if it was
> decided to allow them, otherwise we would be forced to use another
> framework.
There's no way we w
On 2013-10-04 07:34, Kurt Pattyn wrote:
> In some markets like Avionics and Defense, it is simply forbidden for
> us to use exceptions.
The only reason to forbid exceptions on technical (as opposed to
uneducated or -worse- political) grounds is in hard real-time systems,
because throwing an exce
On Thursday 03 October 2013 18:38:44 Thiago Macieira wrote:
> On quinta-feira, 3 de outubro de 2013 17:11:54, Alex Malyushytskyy wrote:
> > Assuming exceptions are enabled for signal/slots what is going to happen
> > with Qt::QueuedConnection?
> > As far as I understand at this point you can't cat
On Thursday 03 October 2013 10:38:59 Thiago Macieira wrote:
> On quinta-feira, 3 de outubro de 2013 10:36:44, Olivier Goffart wrote:
> > > I dislike allowing this via the signal-slot mechanism because I see
> > > throwing from a slot as incompatible with the connection semantics.
> > >
> > > That
Op 10-10-2013 14:53, Olivier Goffart schreef:
> On Thursday 03 October 2013 10:38:59 Thiago Macieira wrote:
>> On quinta-feira, 3 de outubro de 2013 10:36:44, Olivier Goffart wrote:
I dislike allowing this via the signal-slot mechanism because I see
throwing from a slot as incompatible wi
On Thursday 10 October 2013 15:14:02 André Somers wrote:
> Op 10-10-2013 14:53, Olivier Goffart schreef:
> > On Thursday 03 October 2013 10:38:59 Thiago Macieira wrote:
> >> On quinta-feira, 3 de outubro de 2013 10:36:44, Olivier Goffart wrote:
> I dislike allowing this via the signal-slot mec
On Thursday, October 10, 2013 9:26 AM, Olivier Goffart
wrote:
> On Thursday 10 October 2013 15:14:02 André Somers wrote:
> > Op 10-10-2013 14:53, Olivier Goffart schreef:
> > > On Thursday 03 October 2013 10:38:59 Thiago Macieira wrote:
> > >> On quinta-feira, 3 de outubro de 2013 10:36:44, Oli
On quinta-feira, 10 de outubro de 2013 14:53:50, Olivier Goffart wrote:
> The only places where exceptions are allowed are:
> - Exceptions thrown by a slot are propagated to the signal connected with
> direct connection
> - Exceptions propagated through a call to invokeMethod are propagated from
On Thursday 10 October 2013 08:22:44 BRM wrote:
> I have personnally maintained a 400k+ SLOC codebase based on QT.
> It made extensive use of Signals/Slots between objects. Even though I was
> pretty much the only developer working on it, I still had to quite often
> track through signals/slots to
On 10/10/13 6:02 PM, "Olivier Goffart" wrote:
>On Thursday 10 October 2013 08:22:44 BRM wrote:
>
>> I have personnally maintained a 400k+ SLOC codebase based on QT.
>> It made extensive use of Signals/Slots between objects. Even though I
>>was
>> pretty much the only developer working on it, I st
>> However, someone who is using currently exceptions, they will have to
change
their code for more complicated code because we decided to forbid it ("for
their own good")
>> May I recall that exceptions through signals and slots always worked,
and was
used.
It never worked.with other than direct
On quinta-feira, 10 de outubro de 2013 13:54:09, Alex Malyushytskyy wrote:
> It never worked.with other than direct connections.
> As I see it there is a simple choice either to provide indirect connections
> or propagate exceptions to signal. Otherwise you always have to assume that
> every slot i
48 matches
Mail list logo
