Il 10/06/19 23:45, Kevin Kofler ha scritto:
Perhaps you forgot to read the part where I said:
I, for one, don't give a darn about all those new C++11/14/whatever STL
features.
That's a straw man. Since YOU don't care, then NOBODY cares.
Sorry, plonking you.
--
Giuseppe D'Angelo | giuseppe.d
Giuseppe D'Angelo via Development wrote:
> Perhaps you forgot to read the part where I said:
>
>> Then, it comes a moment when "upstream" stuff has more and more
>> advantages -- more speed (algorithms), more flexibility (e.g. mutex
>> classes and utilities; shared_ptr; etc.), more static analysis
Giuseppe D'Angelo via Development wrote:
> There are some practical problems with this:
>
> 1) It creates technological debt into QtCore, where we have to keep this
> stuff around forever (and working and supported on *all* platforms, and
> compatible with the latest compilers, etc.).
You call th
(Changing the subject to be on topic)
On 10/06/2019 13:27, Konstantin Tokarev wrote:
At the cost of saying for the 100th time, before this stuff ends up
indexed by Google: you can port away from Q_FOREACH in an automated way
only in trivial cases.*NOT* in the general case.
How is one supposed
10.06.2019, 13:10, "Giuseppe D'Angelo" :
> On 08/06/2019 21:39, Konstantin Tokarev wrote:
>>> What abouthttps://valdyas.org/fading/hacking/happy-porting/
>>>
>>> "[...] none, not a single one of all of the reasons you want to
>>> deprecate
>>> Q_FOREACH is a reason I care even a littl
Hi,
On 08/06/2019 19:17, Boudewijn Rempt via Development wrote:
I kept out of this for the longest time, especially because people have been
quoting my blog post, but I give up now.
On zaterdag 8 juni 2019 18:14:36 CEST Giuseppe D'Angelo via Development wrote:
Then, it comes a moment when "
On 09/06/2019 00:09, Kevin Kofler wrote:
André Pönitz wrote:
I see that pattern, too. But now, instead putting the break between 3) and
4), the whole thing is killed, and everybody downstream has to do 1)-3)
again, or put up with what the standard offers.
And could prevent overextension by -x'i
On 09/06/2019 13:38, André Pönitz wrote:
So effectively, application developers need to support multiple versions
of Qt as they cannot really be sure which of their version the
distributors will combine with which version of Qt which is
conveniently ignored by our deprecators when they deprecate
On 08/06/2019 20:31, André Pönitz wrote:
On Sat, Jun 08, 2019 at 06:14:36PM +0200, Giuseppe D'Angelo via Development
wrote:
On 05/06/2019 23:01, André Pönitz wrote:
As a matter of fact, some of the previous deprecations, e.g. the removal
of qalgorithm, triggered re-implementing the deprecated
On 09/06/2019 00:00, Kevin Kofler wrote:
There is one option missing:
* We could just keep the Qt equivalent as is, without adding the features
of the STL equivalent if there is no manpower to port them to the Qt
equivalent. Developers using the Qt version are happy with the Qt version
On 08/06/2019 21:39, Konstantin Tokarev wrote:
What abouthttps://valdyas.org/fading/hacking/happy-porting/
"[...] none, not a single one of all of the reasons you want to deprecate
Q_FOREACH is a reason I care even a little bit about. It’s going to
be deprecated? Well, that’s a deci
11 matches
Mail list logo
