Hi,
Please remember to update this to documentation. Both the supported platforms
page and QNX platform notes.
Yours,
--
Tuukka
> Rafael Roquetto kirjoitti 11.6.2015 kello 12.54:
>
> Hello,
>
> It was agreed during this year's Qt Contributors Summit that, as of Qt 5.6,
> QNX 6.5.0 will no
On 6/11/15, 2:47 PM, "Alan Alpert" <4163654...@gmail.com> wrote:
...
>They have their own modules on their side. One of the sessions you
>missed included a demo with Meteor.js talking to QML applications
>using a somewhat similar approach. It had custom logic that mapped
>Meteor's wire protocol int
On Friday 12 June 2015 10:49:38 Matthew Woehlke wrote:
> On 2015-06-12 04:17, Marc Mutz wrote:
> > On Friday 12 June 2015 08:08:51 André Somers wrote:
> >> Available for use then:
> > range-for?
> > variadic macros (these we already use in tests/ and no-one complained so
> > far).
> André, you ment
On Friday 12 June 2015 18:58:59 Marc Mutz wrote:
> On Friday 12 June 2015 16:37:15 Thiago Macieira wrote:
> > On Friday 12 June 2015 12:12:17 Olivier Goffart wrote:
> > > Which mean using things like std::function, std::unique_ptr, in our ABI.
> > > Should we allow that?
> >
> > The problem is dec
On Fri, Jun 12, 2015 at 12:58:42AM +0200, Marc Mutz wrote:
> On Thursday 11 June 2015 23:15:20 André Pönitz wrote:
> > That's exactly the kind of situation I was referring to in my previous
> > mail: This is intentionally introducing API inconsistency. It does not
> > really matter to me whether "p
On 2015-06-12 13:02, Marc Mutz wrote:
> On Friday 12 June 2015 16:49:38 Matthew Woehlke wrote:
>> On 2015-06-12 04:17, Marc Mutz wrote:
>>> On Friday 12 June 2015 08:08:51 André Somers wrote:
For now, don’t put std lib ABI into Qt ABI, except for nulltpr_t.
>>>
>>> Too late: QException inherit
On Friday 12. June 2015 07:37:15 Thiago Macieira wrote:
> On Friday 12 June 2015 12:12:17 Olivier Goffart wrote:
> > Which mean using things like std::function, std::unique_ptr, in our ABI.
> > Should we allow that?
>
> The problem is deciding between std::function and std::__1::function.
That's
On Friday 12 June 2015 16:49:38 Matthew Woehlke wrote:
> >> For now, don’t put std lib ABI into Qt ABI, except for nulltpr_t.
> >
> >
> >
> > Too late: QException inherits std::exception (for a looong time already),
> > and by virtue of various exported subclasses of QVector and QList, we
> > exp
On Friday 12 June 2015 16:37:15 Thiago Macieira wrote:
> On Friday 12 June 2015 12:12:17 Olivier Goffart wrote:
> > Which mean using things like std::function, std::unique_ptr, in our ABI.
> > Should we allow that?
>
> The problem is deciding between std::function and std::__1::function.
Is __1 n
Thanks for structuring this! Much appreciated.
On Friday 12 June 2015 22:23:09 Sze Howe Koh wrote:
> First, a big thanks to Stephen for bringing the
> I propose the following, with the hope that we formalise our decisions
> at http://wiki.qt.io/Coding_Conventions for future reference.
Agreed.
>
On 2015-06-12 04:17, Marc Mutz wrote:
> On Friday 12 June 2015 08:08:51 André Somers wrote:
>> Available for use then:
>
> range-for?
> variadic macros (these we already use in tests/ and no-one complained so far).
André, you mentioned 'auto'... does that include return type deduction?
What about
On Friday 12 June 2015 10:17:21 Marc Mutz wrote:
> Hi Andre,
>
> thanks for the write-up!
>
> On Friday 12 June 2015 08:08:51 André Somers wrote:
> > Available for use then:
> range-for?
Nope and they are the ones that are bad for our containers until extended
lifetime references show up, proba
On Friday 12 June 2015 12:12:17 Olivier Goffart wrote:
> Which mean using things like std::function, std::unique_ptr, in our ABI.
> Should we allow that?
The problem is deciding between std::function and std::__1::function.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect
First, a big thanks to Stephen for bringing these issues to the ML's attention.
The topic of namespacing has been raised a few times before, but
discussions faded without us reaching any solid conclusions:
http://comments.gmane.org/gmane.comp.lib.qt.devel/13176
I think the disagreements we have o
On Friday 12. June 2015 10:17:21 Marc Mutz wrote:
> Hi Andre,
>
> thanks for the write-up!
>
> On Friday 12 June 2015 08:08:51 André Somers wrote:
> > Available for use then:
> range-for?
> variadic macros (these we already use in tests/ and no-one complained so
> far).
> > No for now: std::for_e
Hi,
On Thursday 11 June 2015 23:15:20 André Pönitz wrote:
> Specifically, for item #6:
>
> [Stephen]
>
> > Qt3DParamter might be better *and* more consistent.
> > Similar applies to other classes.
>
> [Sean]
> It's precisely because of these kinds of issues that we decided t
On Thu, Jun 11, 2015 at 08:30:37PM +, Gladhorn Frederik wrote:
> On Thursday 11. June 2015 18.47.40 Oswald Buddenhagen wrote:
> > you won't get rid of the redundant dependency specifications anyway,
> > because qt.pro (and the sync.profile's) are about repository deps,
> > while the module's re
Hi Andre,
thanks for the write-up!
On Friday 12 June 2015 08:08:51 André Somers wrote:
> Available for use then:
range-for?
variadic macros (these we already use in tests/ and no-one complained so far).
> No for now: std::for_each (issues with leaks)
Which leaks?
> For now, don’t put std lib
On 11-Jun-15 18:47, Oswald Buddenhagen wrote:
> you won't get rid of the redundant dependency specifications anyway,
> because qt.pro (and the sync.profile's) are about repository deps, while
> the module's requires() (and whatever other methods they use to exclude
> themselves) are about module (
19 matches
Mail list logo
