Hello,
On Monday 01 July 2013 07:05:03 Kevin Ottens wrote:
> On Sunday 30 June 2013 22:48:50 Ivan Čukić wrote:
> > > > +1 ABI should be the same in both versions (unlike gcc's std::list
> > > > iirc)
> > >
> > > Just wondering, was this email as "OK, I see where you come from", or
> > > was
> > >
On Sunday 30 June 2013 22:48:50 Ivan Čukić wrote:
> > > +1 ABI should be the same in both versions (unlike gcc's std::list iirc)
> >
> > Just wondering, was this email as "OK, I see where you come from", or was
> > it
> I think we should discuss this at Akademy (with Aaron, Martin and Marco as a
>
> > +1 ABI should be the same in both versions (unlike gcc's std::list iirc)
>
> Just wondering, was this email as "OK, I see where you come from", or was it
I think we should discuss this at Akademy (with Aaron, Martin and Marco as a
minimal WG).
I'd separate the discussion in three parts tha
Hello,
On Saturday 29 June 2013 18:51:38 Ivan Čukić wrote:
> > > I don't agree that these /additional/ features are about the api.
> > > is an (IMO) immensely useful, especially with lambdas and
> > > std::bind for actual non exposed parts.
> >
> > Well, yes that's all useful. That's the type of
> > I don't agree that these /additional/ features are about the api.
> > is an (IMO) immensely useful, especially with lambdas and
> > std::bind for actual non exposed parts.
>
> Well, yes that's all useful. That's the type of things I'd like to use
> everywhere too. I badly worded that above t
On Friday 28 June 2013 23:58:21 Ivan Čukić wrote:
> > OK, then we got a misunderstanding somewhere...
> >
> > Using those Q_* macros is perfectly fine (and even encouraged, we already
> > use Q_DECL_OVERRIDE and I'd like to see more Q_NULLPTR for instance). They
> > enable exactly what I was descr
> OK, then we got a misunderstanding somewhere...
>
> Using those Q_* macros is perfectly fine (and even encouraged, we already
> use Q_DECL_OVERRIDE and I'd like to see more Q_NULLPTR for instance). They
> enable exactly what I was describing earlier: works without C++11 support,
> you get extra
On Friday 28 June 2013 23:13:34 Ivan Čukić wrote:
> > such a premise VS2012 has a very partial C++11 support, Android NDK uses
> > gcc 4.6 by default (apparently you can upgrade that to 4.7 but we can't
> > expect third parties to do it by default, means partial support in both
> > cases), BB10 cro
> such a premise VS2012 has a very partial C++11 support, Android NDK uses
> gcc 4.6 by default (apparently you can upgrade that to 4.7 but we can't
> expect third parties to do it by default, means partial support in both
> cases), BB10 cross- compiler doesn't properly support C++11. We're not
T
On Friday 28 June 2013 20:52:59 Aaron J. Seigo wrote:
> On Friday, June 28, 2013 13:08:49 Kevin Ottens wrote:
> > Just to clarify: It's not a "no-no" to using C++11, it's to make sure
> > we're able to build without them.
>
> We have no interest in trying to maintain a build that does not require
On Fri, Jun 28, 2013 at 2:52 PM, Aaron J. Seigo wrote:
> On Friday, June 28, 2013 13:08:49 Kevin Ottens wrote:
>> Just to clarify: It's not a "no-no" to using C++11, it's to make sure we're
>> able to build without them.
>
> We have no interest in trying to maintain a build that does not require C
On Friday, June 28, 2013 13:08:49 Kevin Ottens wrote:
> Just to clarify: It's not a "no-no" to using C++11, it's to make sure we're
> able to build without them.
We have no interest in trying to maintain a build that does not require C++11.
There are too many useful features that we can take adva
> > Isn't the point of a dependency (on C++11) to make it required?
>
> Well, we have required and optional dependencies. C++11 is not special in
> that regard, we can make it either required or optional.
So, essentially, the issue is that Plasma keeps both the framework and the
shells in the s
On Friday 28 June 2013 07:33:43 Shaun Reich wrote:
> On Fri, Jun 28, 2013 at 7:08 AM, Kevin Ottens wrote:
> > On Friday 28 June 2013 11:02:25 Ivan Čukić wrote:
> >> On Friday 28 June 2013 08:13:32 Kevin Ottens wrote:
> >> > Git commit 597397b41f5450f24ddc784e0faa13133fed6bd5 by Kevin Ottens.
> >>
On Fri, Jun 28, 2013 at 7:08 AM, Kevin Ottens wrote:
> On Friday 28 June 2013 11:02:25 Ivan Čukić wrote:
>> On Friday 28 June 2013 08:13:32 Kevin Ottens wrote:
>> > Git commit 597397b41f5450f24ddc784e0faa13133fed6bd5 by Kevin Ottens.
>> > Committed on 28/06/2013 at 08:07.
>> > Pushed by ervin into
On Friday 28 June 2013 11:02:25 Ivan Čukić wrote:
> On Friday 28 June 2013 08:13:32 Kevin Ottens wrote:
> > Git commit 597397b41f5450f24ddc784e0faa13133fed6bd5 by Kevin Ottens.
> > Committed on 28/06/2013 at 08:07.
> > Pushed by ervin into branch 'master'.
> >
> > Revert "Enabling C++11 flags for
On Friday 28 June 2013 08:13:32 Kevin Ottens wrote:
> Git commit 597397b41f5450f24ddc784e0faa13133fed6bd5 by Kevin Ottens.
> Committed on 28/06/2013 at 08:07.
> Pushed by ervin into branch 'master'.
>
> Revert "Enabling C++11 flags for clang and gcc"
This request [1] got a green light by Aaron [2
17 matches
Mail list logo
