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 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 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 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 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 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 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 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 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 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 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 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
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.
Cheers,
Lars
On 10/1/13 9:31 PM, "Hausmann Simon" wrote:
>
>Hmm question - certainly worth it for sjlj platforms like 32-bit ios.
>
>
>
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
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)
Simon
Fra: Thiago Macieira
Sendt: 21:20 tirsdag 1. oktober 2013
Til: development@qt-p
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
-- Forwarded message --
Subject: [graphics] Nov meeting and "2D Lite" scope
Date: segunda-feira, 30 de setembro de 2013, 09:47:08
From: Herb Sutter
Para: graph...@isocpp.org
(updating subject)
November meeting: The Seattle-area face-to-face meeting date is not yet set
in ston
On Tue, Oct 1, 2013 at 2:54 PM, Blasche Alexander
wrote:
>
>>From: development-bounces+alexander.blasche=digia@qt-project.org
>>[mailto:development-bounces+alexander.blasche=digia@qt-project.org] On
>>Behalf Of Kate Alhola
>
>>How about getting list of Bound ( and known) Devices from
>>
Hi all,
It seems to me this code from qglobal.h is not correct:
#if !(defined(Q_WS_WIN) && !defined(Q_WS_WINCE)) \
&& !(defined(Q_WS_MAC) && defined(QT_MAC_USE_COCOA)) \
&& !(defined(Q_WS_X11) && !defined(QT_NO_FREETYPE)) \
&& !(defined(Q_WS_QPA))
# define QT_NO_RAWFONT
#endif
It en
>From: development-bounces+alexander.blasche=digia@qt-project.org
>[mailto:development-bounces+alexander.blasche=digia@qt-project.org] On
>Behalf Of Kate Alhola
>How about getting list of Bound ( and known) Devices from
>QBluetoothLocalDevice ( or from somewhere else) ?
>Normal use cas
Manual page says that it returns all local devices QBluetoothHostInfo .
In bluez it uses listAdapters to query list of local bluetooth Adapters.
To get list of remote devices you should use GetProperties to certain
localAdapter and then property named Devices.
Kate
On Tue, Oct 1, 2013 at 1:42 P
On Tuesday 01 October 2013 12:25:37 Kate Alhola wrote:
> On Tue, Oct 1, 2013 at 11:23 AM, Michael Zanetti <
>
> michael.zane...@canonical.com> wrote:
> > On Monday 30 September 2013 13:09:53 Thiago Macieira wrote:
> > > On segunda-feira, 30 de setembro de 2013 19:39:53, Knoll Lars wrote:
> > > > >
On Tue, Oct 1, 2013 at 11:23 AM, Michael Zanetti <
michael.zane...@canonical.com> wrote:
> On Monday 30 September 2013 13:09:53 Thiago Macieira wrote:
> > On segunda-feira, 30 de setembro de 2013 19:39:53, Knoll Lars wrote:
> > > >As far as I know from my colleague, it misses some necessary API --
On Monday 30 September 2013 13:09:53 Thiago Macieira wrote:
> On segunda-feira, 30 de setembro de 2013 19:39:53, Knoll Lars wrote:
> > >As far as I know from my colleague, it misses some necessary API -- at
> > >least the connection state changes notification and device disappearing
> > >notificati
> -Original Message-
> From: development-bounces+alexander.blasche=digia@qt-project.org
> [mailto:development-bounces+alexander.blasche=digia@qt-project.org]
> On Behalf Of Thiago Macieira
> However, if there are major defects in the API, they need to be voiced now.
> Like Lars s
26 matches
Mail list logo
