On Wednesday 16 December 2015 15:01:23 Marc Mutz wrote:
> // assume the following are friends of QContainerWrapper,
> resp.: template
> QContainerWrapper qAsConst(const T &t) // lvalue
> Q_DECL_NOTHROW
> { return {t}; } // stores reference
> template
> QCon
On Friday 20 February 2015 02:26:25 Thiago Macieira wrote:
> Do NOT do this. This will crash:
>
> for (auto const &item : std::cref(somefunction()) { ... }
Sorry for warming up an old thread, but since there was talk about the QtC
coding style recommending this...
It's safe for lvalues.
On Friday 15 May 2015 10:42:54 Matthew Woehlke wrote:
> > for (auto x : function(function2()))
> >
> >
> >
> > If function returns a temporary and function passes through a reference,
> > [...]
> Er... wait. My bad. Does it resolve the issue if 'Container const& c;'
> in qtEnumerator is changed to
On 2015-05-14 16:37, Thiago Macieira wrote:
> On Thursday 14 May 2015 11:34:25 Matthew Woehlke wrote:
>> On 2015-05-14 10:58, Thiago Macieira wrote:
>>> On Thursday 14 May 2015 14:36:43 Olivier Goffart wrote:
I'm afraid your solution is not working with temporaries containers.
>>>
>>> That sho
On Thursday 14 May 2015 11:34:25 Matthew Woehlke wrote:
> On 2015-05-14 10:58, Thiago Macieira wrote:
> > On Thursday 14 May 2015 14:36:43 Olivier Goffart wrote:
> >> I'm afraid your solution is not working with temporaries containers.
> >
> > That should be submitted as a change request to the st
On 2015-05-14 10:58, Thiago Macieira wrote:
> On Thursday 14 May 2015 14:36:43 Olivier Goffart wrote:
>> I'm afraid your solution is not working with temporaries containers.
>
> That should be submitted as a change request to the standard. There are a
> couple of other cases where this bites peop
On Thursday 14 May 2015 14:36:43 Olivier Goffart wrote:
> I'm afraid your solution is not working with temporaries containers.
That should be submitted as a change request to the standard. There are a
couple of other cases where this bites people.
It needs a new paper.
--
Thiago Macieira - thia
On Wednesday 13. May 2015 09:45:30 Matthew Woehlke wrote:
> On 2015-04-30 16:04, Matthew Woehlke wrote:
> > On 2015-02-20 14:42, Thiago Macieira wrote:
> >> On Friday 20 February 2015 12:53:24 Matthew Woehlke wrote:
> >>> for (auto const i : qtEnumerate(map))
> >>>
> >>> Maybe it would be nice f
On 2015-04-30 16:04, Matthew Woehlke wrote:
> On 2015-02-20 14:42, Thiago Macieira wrote:
>> On Friday 20 February 2015 12:53:24 Matthew Woehlke wrote:
>>> for (auto const i : qtEnumerate(map))
>>>
>>> Maybe it would be nice for Qt to provide one or both of these?
>>
>> Sounds easy enough. Want t
On 2015-02-20 14:42, Thiago Macieira wrote:
> On Friday 20 February 2015 12:53:24 Matthew Woehlke wrote:
>> for (auto const i : qtEnumerate(map))
>>
>> Maybe it would be nice for Qt to provide one or both of these?
>
> Sounds easy enough. Want to give it a try?
I *finally* got permission to sha
On 2015-02-20 04:04, André Somers wrote:
> Bo Thorsen schreef op 20-2-2015 om 09:03:
>> Andrés question about how this would change the API is a lot more
>> interesting. I so far haven't seen a single case where someone has
>> described how access to lambdas might improve the API. If they are
>>
> On Feb 20, 2015, at 10:04 AM, André Somers wrote:
>
> Bo Thorsen schreef op 20-2-2015 om 09:03:
>> Andrés question about how this would change the API is a lot more
>> interesting. I so far haven't seen a single case where someone has
>> described how access to lambdas might improve the API.
I think Kai's approach is probably what would work best for now. As much
as I'd like to, we can't yet use C++11 features unconditionally inside the
core of Qt itself as we'd loose a few platforms that we still need to
support.
But we can (and should) certainly use C++11 in our examples and
documen
On 20 February 2015 at 16:28, Koehne Kai wrote:
>> -Original Message-
>> From: development-bounces+kai.koehne=theqtcompany.com@qt-
>> [...]
>> But this is an implementation convenience only. You can't convince me to
>> drop VS2010 to be able to use them internally inside Qt. Or 2008 for Wi
On Sunday 22 February 2015 05:47:41 Kevin Kofler wrote:
> Rafael Roquetto wrote:
> > That would mean you would also deprecate QNX 6.5.0, 6.6.0 (which is a
> > relatively new release), and BlackBerries. I personally would have loved
> > to remove support for 6.5.0, since it is based on an old gcc ve
Rafael Roquetto wrote:
> That would mean you would also deprecate QNX 6.5.0, 6.6.0 (which is a
> relatively new release), and BlackBerries. I personally would have loved
> to remove support for 6.5.0, since it is based on an old gcc version that
> can barely keep up with latest C++ developments (an
On Saturday 21 February 2015 09:06:13 Sean Harmer wrote:
> On Friday 20 February 2015 08:02:50 Thiago Macieira wrote:
> > On Friday 20 February 2015 09:49:57 Olivier Goffart wrote:
> > > I already have added Q_DECL_OVERRIDE to all the examples in
> > > qtbase/examples. The examples are currently co
On Saturday 21 February 2015 09:11:57 Sean Harmer wrote:
> The best approach is likely to be for us to work with QNX to point out
> where their dinkumware libcpp has problems with specific examples, as we
> are doing regarding the recent constexpr support issue. I'm sure QNX will
> be happy to get
On Saturday 21 February 2015 10:46:41 Sebastian Lehmann wrote:
> Its implementation follows straight out of how Q_FOREACH is implemented,
> just adding another for-loop. I only implemented the GCC version back
> then, though.
Hi Sebastian
I "upgraded" Q_FOREACH for 5.4 to make it more readable
Just want to throw in my "foreach key/value" loop implementation, as an
extension of "foreach", which I did years ago just as a proof of
concept.
http://codereview.stackexchange.com/questions/11681/
It allows you to do:
foreachkv(auto key, auto value, map) {
// do sth with key /
On Friday 20 February 2015 14:09:09 Rafael Roquetto wrote:
> On Fri, Feb 20, 2015 at 08:00:17AM -0800, Thiago Macieira wrote:
> > On Friday 20 February 2015 16:44:28 Cristian Adam wrote:
> > > There is another option for QNX, use libstdc++ from GCC and not libcpp
> > > from
> > > Dinkumware.
> > >
On Friday 20 February 2015 08:02:50 Thiago Macieira wrote:
> On Friday 20 February 2015 09:49:57 Olivier Goffart wrote:
> > I already have added Q_DECL_OVERRIDE to all the examples in
> > qtbase/examples. The examples are currently compiled as part of CI, but
> > maybe we should start using lambda
On 2015-02-20 14:42, Thiago Macieira wrote:
> On Friday 20 February 2015 12:53:24 Matthew Woehlke wrote:
>> for (auto const i : qtEnumerate(map))
>>
>> Maybe it would be nice for Qt to provide one or both of these?
>
> Sounds easy enough. Want to give it a try?
I'm happy to give you my headers;
On Friday 20 February 2015 12:33:56 Matthew Woehlke wrote:
> That said... QThread. Taking a functor that can be a lambda for
> something like QtConcurrent::run (which I think may already do this) or
> to replace the run() of a QThread seems useful.
https://codereview.qt-project.org/89063
--
Thiag
On Friday 20 February 2015 13:37:16 Matthew Woehlke wrote:
> On 2015-02-19 20:26, Thiago Macieira wrote:
> > Do NOT do this. This will crash:
> > for (auto const &item : std::cref(somefunction()) { ... }
>
> Does it crash without the std::cref?
No, due to lifetime extension of the temporary.
On Friday 20 February 2015 12:53:24 Matthew Woehlke wrote:
> for (auto const i : qtEnumerate(map))
>
> Maybe it would be nice for Qt to provide one or both of these?
Sounds easy enough. Want to give it a try?
Note that this should also work for foreach:
foreach (const auto i, qtEnumer
On 2015-02-19 20:26, Thiago Macieira wrote:
> Do NOT do this. This will crash:
>
> for (auto const &item : std::cref(somefunction()) { ... }
Does it crash without the std::cref? If not... seems like a good
argument to support a free 'const'...
> And another reason is that std::cref is a C+
On 2015-02-20 07:10, Иван Комиссаров wrote:
> Sorry for interupting the discussion, but i saw mentioning of a
> range-based-for, so i have a question. std::map/unordered_map uses
> std::pair as a value type, and map::iterator::operator* returns reference
> to a pair, while Qt doesn't have an underl
On 2015-02-20 04:04, André Somers wrote:
> One example I could come up with as a potential new API is
> QSortFilterProxyModel. Currently, it requires subclassing to change the
> sort or the filter functions: it supplies protected filterAcceptsRow,
> filterAcceptsColumn and lessThan functions. I
On Friday 20 February 2015 12:52:31 André Somers wrote:
> > If you wanted to support, implement, say,
> > QSortFilterProxyModel::setFilter(
> > cont std::function &filter)
> >
> > You would need a generic general purpose QFunction. For which you can
> > specify the arguments as
On Friday 20 February 2015 09:51:59 Marc Mutz wrote:
> Just make sure - and that's a big part of what I was trying to refer to -
> that you don't use that statment in more than one function. Because
> identical lambdas in different functions have different types, and thus
> templates they are pass
On Fri, Feb 20, 2015 at 08:00:17AM -0800, Thiago Macieira wrote:
> On Friday 20 February 2015 16:44:28 Cristian Adam wrote:
> > There is another option for QNX, use libstdc++ from GCC and not libcpp from
> > Dinkumware.
> >
> > But then again Rafael knows more about this:
> > http://www.foundry27.
On Friday 20 February 2015 09:49:57 Olivier Goffart wrote:
> I already have added Q_DECL_OVERRIDE to all the examples in qtbase/examples.
> The examples are currently compiled as part of CI, but maybe we should
> start using lambda and auto in the examples and disabling the compilation
> of them on
On Friday 20 February 2015 16:44:28 Cristian Adam wrote:
> There is another option for QNX, use libstdc++ from GCC and not libcpp from
> Dinkumware.
>
> But then again Rafael knows more about this:
> http://www.foundry27.com/sf/go/projects.qt/discussion.general.topc21981
>
> Is it not possible to
On Friday 20 February 2015 15:24:04 Mark Gaiser wrote:
> I've read about this range-based-for stuff before and there was this paper
> [1] that apparently wants to introduce the next generation of it. It would
> introduce the syntax (WITHOUT auto!):
> for (elem : range)
>
> Which would be exactly t
On Fri, Feb 20, 2015 at 3:56 PM, Rafael Roquetto
wrote:
>
> Now, having said that, QNX 6.6.0 is gcc 4.7 based. Compiler-wise, that
> should
> be enough for lambdas, but correct me if I am wrong.
> The problem with 6.6.0 starts to arise when we
> decide to use features that their libcpp does not s
On Fri, Feb 20, 2015 at 03:01:01PM +0100, Olivier Goffart wrote:
> On Friday 20 February 2015 11:52:32 Rafael Roquetto wrote:
> > On Fri, Feb 20, 2015 at 02:37:09PM +0100, Olivier Goffart wrote:
> > > On Friday 20 February 2015 11:17:51 Rafael Roquetto wrote:
> > > > On Fri, Feb 20, 2015 at 12:32:4
On Fri, Feb 20, 2015 at 2:26 AM, Thiago Macieira
wrote:
> On Friday 20 February 2015 00:17:00 Mathias Hasselmann wrote:
> > Use std::cref() if not sure about your container's constness.
> >
> > for (auto const& item : std::cref(c)) { ... }
>
> Do NOT do this. This will crash:
>
> for
On Friday 20 February 2015 11:52:32 Rafael Roquetto wrote:
> On Fri, Feb 20, 2015 at 02:37:09PM +0100, Olivier Goffart wrote:
> > On Friday 20 February 2015 11:17:51 Rafael Roquetto wrote:
> > > On Fri, Feb 20, 2015 at 12:32:45PM +0100, Olivier Goffart wrote:
> > > > On Friday 20 February 2015 11:1
Regarding the bloat,
why not add the new functions and mark the old ones as deprecated. Of course
it bloats the default. But it would also mean we know which functions will
vanish encourage people not to use deprecated functions for old code and
have a compile option that doesn't compile deprecat
On Fri, Feb 20, 2015 at 02:37:09PM +0100, Olivier Goffart wrote:
> On Friday 20 February 2015 11:17:51 Rafael Roquetto wrote:
> > On Fri, Feb 20, 2015 at 12:32:45PM +0100, Olivier Goffart wrote:
> > > On Friday 20 February 2015 11:15:32 BogDan wrote:
> > > > I fully agree with you, but, sadly, I th
On Friday 20 February 2015 11:17:51 Rafael Roquetto wrote:
> On Fri, Feb 20, 2015 at 12:32:45PM +0100, Olivier Goffart wrote:
> > On Friday 20 February 2015 11:15:32 BogDan wrote:
> > > I fully agree with you, but, sadly, I think it will not be possible in
> > > 5.x.
> >
> > We started supporting
El Friday 20 February 2015, Tomasz Siekierda escribió:
> On 20 February 2015 at 12:52, Alejandro Exojo wrote:
> > El Thursday 19 February 2015, Tomasz Siekierda escribió:
> >> So those companies/ users of QNX are not willing to upgrade their OS,
> >> compiler, but they are willing to upgrade Qt?
>
On Fri, Feb 20, 2015 at 12:32:45PM +0100, Olivier Goffart wrote:
> On Friday 20 February 2015 11:15:32 BogDan wrote:
> > I fully agree with you, but, sadly, I think it will not be possible in 5.x.
>
> We started supporting C++98 during the course of Qt 4.x.
> We dropped MSVC 6, in Qt 4.5 (despite
Sorry for interupting the discussion, but i saw mentioning of a
range-based-for, so i have a question. std::map/unordered_map uses
std::pair as a value type, and map::iterator::operator* returns reference
to a pair, while Qt doesn't have an underlying struct and operator* returns
ref to T (without
On 20 February 2015 at 12:52, Alejandro Exojo wrote:
> El Thursday 19 February 2015, Tomasz Siekierda escribió:
>> So those companies/ users of QNX are not willing to upgrade their OS,
>> compiler, but they are willing to upgrade Qt?
>
> I think the main problem with requiring a very up to date Qt
On Friday 20 February 2015 12:43:18 Bo Thorsen wrote:
> Den 20-02-2015 kl. 12:32 skrev Olivier Goffart:
> > At some point we are going to drop MSVC 2008 and GCC 4.4
[...]
> Since we're talking about lambdas, it's MSVC 2010 as well. I don't know
> what the status of lambdas is in MSVC 2012, since al
Olivier Goffart schreef op 20-2-2015 om 12:22:
> On Friday 20 February 2015 11:38:21 André Somers wrote:
>> Olivier Goffart schreef op 20-2-2015 om 11:38:
>>> On Friday 20 February 2015 11:26:31 Daniel Teske wrote:
>>> [...]
>>>
That's one area. The others are too replace trivial interfaces wi
El Thursday 19 February 2015, Tomasz Siekierda escribió:
> So those companies/ users of QNX are not willing to upgrade their OS,
> compiler, but they are willing to upgrade Qt?
I think the main problem with requiring a very up to date Qt is that sometimes
only newer versions of Qt have bugfixes.
El Friday 20 February 2015, André Somers escribió:
> Olivier Goffart schreef op 20-2-2015 om 11:38:
> > On Friday 20 February 2015 11:26:31 Daniel Teske wrote:
> > [...]
> >
> >> That's one area. The others are too replace trivial interfaces with a
> >> low amount of virtual functions by a std::fu
Den 20-02-2015 kl. 12:32 skrev Olivier Goffart:
> On Friday 20 February 2015 11:15:32 BogDan wrote:
>> I fully agree with you, but, sadly, I think it will not be possible in 5.x.
> We started supporting C++98 during the course of Qt 4.x.
> We dropped MSVC 6, in Qt 4.5 (despite there was still peopl
Olivier Goffart schreef op 20-2-2015 om 12:32:
> On Friday 20 February 2015 11:15:32 BogDan wrote:
>> I fully agree with you, but, sadly, I think it will not be possible in 5.x.
> We started supporting C++98 during the course of Qt 4.x.
> We dropped MSVC 6, in Qt 4.5 (despite there was still people
On Friday 20 February 2015 11:15:32 BogDan wrote:
> I fully agree with you, but, sadly, I think it will not be possible in 5.x.
We started supporting C++98 during the course of Qt 4.x.
We dropped MSVC 6, in Qt 4.5 (despite there was still people using it) and
were able to finally use member templ
On Friday 20 February 2015 11:38:21 André Somers wrote:
> Olivier Goffart schreef op 20-2-2015 om 11:38:
> > On Friday 20 February 2015 11:26:31 Daniel Teske wrote:
> > [...]
> >
> >> That's one area. The others are too replace trivial interfaces with a low
> >> amount of virtual functions by a st
I fully agree with you, but, sadly, I think it will not be possible in 5.x.
IMHO for the start we should use C++11/14 in the QPA plugins when we know for
sure that the compiler supports these features.E.g. I already used (stashed)
some C++11 features in the Android QPA, but sometime I got -1s be
On Friday 20 Feb 2015 00:17:00 Mathias Hasselmann wrote:
> >>> [...]
> >> [...]
> > [...]
> [...]
I guess my point that the ranged based for loop and qt containers don't mix
too well is now very much proven by the depth of this particular discussion.
The upcoming Ranges TS has also uses std::b
Olivier Goffart schreef op 20-2-2015 om 11:38:
> On Friday 20 February 2015 11:26:31 Daniel Teske wrote:
> [...]
>> That's one area. The others are too replace trivial interfaces with a low
>> amount of virtual functions by a std::function properties. This can simplify
>> code if e.g. the different
On Friday 20 February 2015 11:26:31 Daniel Teske wrote:
[...]
> That's one area. The others are too replace trivial interfaces with a low
> amount of virtual functions by a std::function properties. This can simplify
> code if e.g. the different implementations don't fit into a nice hierarchy.
Not
On Thursday 19 Feb 2015 15:41:42 Matthew Woehlke wrote:
> On 2015-02-19 15:21, Marc Mutz wrote:
> > On Thursday 19 February 2015 13:29:48 Daniel Teske wrote:
> >> more than 400 lambdas in Creator's source
> >
> > Sounds like lambdas are overused (as any new language feature is overused
> > before
Bo Thorsen schreef op 20-2-2015 om 09:03:
> Andrés question about how this would change the API is a lot more
> interesting. I so far haven't seen a single case where someone has
> described how access to lambdas might improve the API. If they are
> there, I'd love to see them, because maybe thi
On Friday 20 February 2015 00:17:21 Mathias Hasselmann wrote:
> NO, please. Just use std::cref(). The feature is there already in the STL.
Sadly, attempts to do so are punished with error message not under 100 lines.
--
Marc Mutz | Senior Software Engineer
KDAB (Deutschland) GmbH & Co.KG, a KDA
On Friday 20 February 2015 08:28:24 Koehne Kai wrote:
> > -Original Message-
> > From: development-bounces+kai.koehne=theqtcompany.com@qt-
> > [...]
> > But this is an implementation convenience only. You can't convince me to
> > drop VS2010 to be able to use them internally inside Qt. Or 2
On Thursday 19 February 2015 21:41:42 Matthew Woehlke wrote:
> connect(d->UI.scrollBar, &QAbstractSlider::valueChanged,
> [d](int value){ d->scrollTo(value); });
Indeed, I hadn't thought of private slots. Thanks for the reeducation.
Just make sure - and that's a big part of what I was
> -Original Message-
> From: development-bounces+kai.koehne=theqtcompany.com@qt-
> [...]
> But this is an implementation convenience only. You can't convince me to
> drop VS2010 to be able to use them internally inside Qt. Or 2008 for Win CE or
> old gcc for blackberry or one of all the oth
On 02/19/2015 09:41 PM, Matthew Woehlke wrote:
> On 2015-02-19 15:21, Marc Mutz wrote:
>> On Thursday 19 February 2015 13:29:48 Daniel Teske wrote:
>>> more than 400 lambdas in Creator's source
>>
>> Sounds like lambdas are overused (as any new language feature is overused
>> before it's fully unde
On Friday 20 February 2015 00:17:00 Mathias Hasselmann wrote:
> Use std::cref() if not sure about your container's constness.
>
> for (auto const& item : std::cref(c)) { ... }
Do NOT do this. This will crash:
for (auto const &item : std::cref(somefunction()) { ... }
See my other em
On 2015-02-19 16:27, Kevin Funk wrote:
> On Thursday 19 February 2015 15:41:42 Matthew Woehlke wrote:
>> p.s. It would be cool if these restrictions could be relaxed by adding
>> an overload that takes a QObject that "owns" the slot.
>
> http://doc.qt.io/qt-5/qobject.html#connect-6 (since Qt 5.2)
Am 19.02.2015 um 20:47 schrieb Matthew Woehlke:
> On 2015-02-19 14:28, Thiago Macieira wrote:
>> On Thursday 19 February 2015 17:46:01 Giuseppe D'Angelo wrote:
>>> That on a non-const shared container
>>>
>>> for (auto i : container)
>>>
>>> will detach it. That's why having rules instead of sayi
NO, please. Just use std::cref(). The feature is there already in the STL.
Am 19.02.2015 um 20:36 schrieb Thiago Macieira:
> On Thursday 19 February 2015 12:07:04 Matthew Woehlke wrote:
>> On 2015-02-19 07:29, Daniel Teske wrote:
>>> Qt's container classes and C++11 range based for loop do not mix
On Thu, Feb 19, 2015 at 03:41:42PM -0500, Matthew Woehlke wrote:
> On 2015-02-19 15:21, Marc Mutz wrote:
> > On Thursday 19 February 2015 13:29:48 Daniel Teske wrote:
> >> more than 400 lambdas in Creator's source
> >
> > Sounds like lambdas are overused (as any new language feature is overused
>
On Thursday 19 February 2015 15:41:42 Matthew Woehlke wrote:
> On 2015-02-19 15:21, Marc Mutz wrote:
> > On Thursday 19 February 2015 13:29:48 Daniel Teske wrote:
> >> more than 400 lambdas in Creator's source
> >
> > Sounds like lambdas are overused (as any new language feature is overused
> > be
On 2015-02-19 15:21, Marc Mutz wrote:
> On Thursday 19 February 2015 13:29:48 Daniel Teske wrote:
>> more than 400 lambdas in Creator's source
>
> Sounds like lambdas are overused (as any new language feature is overused
> before it's fully understood by the resp. language community).
Maybe, may
On Thursday 19 February 2015 13:29:48 Daniel Teske wrote:
> more than 400 lambdas in Creator's source
Sounds like lambdas are overused (as any new language feature is overused
before it's fully understood by the resp. language community).
> and have several interfaces
> that take a std::functio
On 2015-02-19 14:36, Thiago Macieira wrote:
> On Thursday 19 February 2015 12:07:04 Matthew Woehlke wrote:
>> On 2015-02-19 07:29, Daniel Teske wrote:
>>> Qt's container classes and C++11 range based for loop do not mix very
>>> well.
>>> Ranged based for uses std::begin(container), which if not ov
On 2015-02-19 14:28, Thiago Macieira wrote:
> On Thursday 19 February 2015 17:46:01 Giuseppe D'Angelo wrote:
>> That on a non-const shared container
>>
>> for (auto i : container)
>>
>> will detach it. That's why having rules instead of saying "just use
>> it", I guess...
>
> And who says it's not
On Thursday 19 February 2015 12:07:04 Matthew Woehlke wrote:
> On 2015-02-19 07:29, Daniel Teske wrote:
> > Qt's container classes and C++11 range based for loop do not mix very
> > well.
> > Ranged based for uses std::begin(container), which if not overloaded calls
> > container.begin(), which det
On Thursday 19 February 2015 17:46:01 Giuseppe D'Angelo wrote:
> On 19 February 2015 at 17:26, Thiago Macieira
wrote:
> > Sounds like the intended behaviour to me. What's wrong with this picture?
>
> That on a non-const shared container
>
> for (auto i : container)
>
> will detach it. That's w
On 2015-02-19 07:29, Daniel Teske wrote:
> Qt's container classes and C++11 range based for loop do not mix very well.
> Ranged based for uses std::begin(container), which if not overloaded calls
> container.begin(), which detaches.
As an aside, the "correct" fix for this IMHO is for range-based
On 19 February 2015 at 17:26, Thiago Macieira wrote:
> Sounds like the intended behaviour to me. What's wrong with this picture?
That on a non-const shared container
for (auto i : container)
will detach it. That's why having rules instead of saying "just use
it", I guess...
--
Giuseppe D'Ange
On Thursday 19 February 2015 17:32:11 Daniel Teske wrote:
> On Thursday 19 Feb 2015 08:26:29 Thiago Macieira wrote:
> > On Thursday 19 February 2015 13:29:48 Daniel Teske wrote:
> > > [1] ranged based for uses std::begin(container), which if not overloaded
> > > calls container.begin(), which deta
On Thursday 19 Feb 2015 08:26:29 Thiago Macieira wrote:
> On Thursday 19 February 2015 13:29:48 Daniel Teske wrote:
> > [1] ranged based for uses std::begin(container), which if not overloaded
> > calls container.begin(), which detaches.
> >
> > So using range-based can be used:
> > - If the cont
On Thursday 19 February 2015 13:29:48 Daniel Teske wrote:
> [1] ranged based for uses std::begin(container), which if not overloaded
> calls container.begin(), which detaches.
>
> So using range-based can be used:
> - If the container is const or
> - If the container is unshared or
> - To actuall
roject.org
> Aihe: Re: [Development] Proposal: Deprecating platforms in Qt 5.6 that don't
> support lambda
>
> On Thu, Feb 19, 2015 at 03:11:05PM +0100, Björn Breitmeyer wrote:
>
> > So long point short, i would like to dicuss this for a move to Qt6 because
> > of
>
On Thu, Feb 19, 2015 at 03:11:05PM +0100, Björn Breitmeyer wrote:
> So long point short, i would like to dicuss this for a move to Qt6 because of
> this and the points Andre mentioned already.
+1
--
Rafael Roquetto | rafael.roque...@kdab.com | Software Engineer
Klarälvdalens Datakonsult AB, a
I agree that it would be nice to have this, but we can do quite a bit of
things with the Qt abstraction of most new features. And for std::function
you can add new interfaces for compilers that do support it without breaking
old code, its done for move constructors and co already.
Sure it would
> On 19 Feb 2015, at 14:27, Tomasz Siekierda wrote:
>
> On 19 February 2015 at 14:17, Rafael Roquetto
> wrote:
>> One of the many reasons for that is that many of those systems running QNX
>> are homologated and
>> changing/upgrading involves lots of different process apart from the
>> techn
On Thu, Feb 19, 2015 at 2:36 PM, Rafael Roquetto
wrote:
> >
> > QNX 6.6 comes with GCC 4.7.3, which has lambda support:
> > https://gcc.gnu.org/gcc-4.7/cxx0x_status.html
>
> Indeed, but it builds against Dinkumware's libcpp, which has half-baked
> C++11
> support (see https://codereview.qt-projec
On Thu, Feb 19, 2015 at 02:27:32PM +0100, Tomasz Siekierda wrote:
> On 19 February 2015 at 14:17, Rafael Roquetto
> wrote:
> > One of the many reasons for that is that many of those systems running QNX
> > are homologated and
> > changing/upgrading involves lots of different process apart from t
On Thu, Feb 19, 2015 at 02:25:27PM +0100, Cristian Adam wrote:
> On Thu, Feb 19, 2015 at 2:17 PM, Rafael Roquetto
> wrote:
>
> > > We need to start now and deprecate old compilers that do not support any
> > C++11
> > > features at all. I I suggest requiring support for lambda as
> > > supported
On 19 February 2015 at 14:17, Rafael Roquetto wrote:
> One of the many reasons for that is that many of those systems running QNX
> are homologated and
> changing/upgrading involves lots of different process apart from the technical
> stuff.
So those companies/ users of QNX are not willing to up
On Thu, Feb 19, 2015 at 2:17 PM, Rafael Roquetto
wrote:
> > We need to start now and deprecate old compilers that do not support any
> C++11
> > features at all. I I suggest requiring support for lambda as
> > supported by MSVC 2010, g++ 4.5 and clang 3.1 in Qt 5.7 and deprecating
> all
> > platf
Daniel Teske schreef op 19-2-2015 om 13:29:
> Hi,
>
> Standard C++ is evolving in a unprecedented pace at the moment. Both C++11 and
> C++14 added a lot of new good features. C++17 is planned to be a big step
> again.
>
> Qt needs to evolve together with C++ or it will be a outdated toolkit stuck i
Hi Daniel,
On Thu, Feb 19, 2015 at 01:29:48PM +0100, Daniel Teske wrote:
> Hi,
>
> Standard C++ is evolving in a unprecedented pace at the moment. Both C++11
> and
> C++14 added a lot of new good features. C++17 is planned to be a big step
> again.
>
> Qt needs to evolve together with C++ or
Hi,
Standard C++ is evolving in a unprecedented pace at the moment. Both C++11 and
C++14 added a lot of new good features. C++17 is planned to be a big step
again.
Qt needs to evolve together with C++ or it will be a outdated toolkit stuck in
a C++98 world.
As an example, Qt's container clas
94 matches
Mail list logo
