Re: [Development] QList

On 23 March 2017 at 21:57, Thiago Macieira wrote: >> A base class that a user can name is detectable in multiple >> inheritance scenarios. >> Once you add such a base, it becomes hard to remove it, regardless of its >> size. > > True, but remember I am proposing as a

Re: [Development] RFC: Containers member functions for algorithm

On 23 March 2017 at 11:36, Marc Mutz wrote: > That said, there's a reason why there's no std::sort(Container &). It's > because you need Concepts to disambiguate the various overloads. Well, that > and because Eric Niebler doesn't manage to limit the scope of his range >

Re: [Development] QList

On 24 March 2017 at 10:34, Marc Mutz wrote: > Ville: are there any proposals for making *this passable by value? Like > >struct QLineF { >Q_CORE_EXPORT QPointF intersection(QLineF other) =; > // =: pass *this by value, mimicking & and && for (l|r)value ref

Re: [Development] QList

On 29 March 2017 at 14:26, Marc Mutz wrote: >> If I start using QArrayList today, and it's immediately >> deprecated, what >> should I use instead? vector? That doesn't >> do implicit sharing, > > Because it's you who asks: if CoW is so super-important, why did the

Re: [Development] QList

On 29 March 2017 at 11:29, Marc Mutz wrote: > On Wednesday 29 March 2017 09:37:04 Marc Mutz wrote: >> Please approve the former, or propose something else. > > I actually meant this ^^. Approve or _propose_ something else. > > Just to be clear on this: I'm ready to do the work

Re: [Development] Wishes for C++ standard or compilers

On 29 March 2017 at 12:49, Marc Mutz wrote: > This is probably one of the most important things. Ville asked on std- > proposals to show hard numbers. You don't need hard numbers. You just need to > superficially look at QVector. The compiler generally cannot proove > that the

Re: [Development] QList

On 29 March 2017 at 15:31, Marc Mutz wrote: >> All this makes me wonder why we should have QArrayList at all. If it's >> slated for immediate deprecation, > > I said _I_ would immediately deprecate it. Wether we do depends on a lot of > other things, too. E.g. what will happen

Re: [Development] QList

On 23 March 2017 at 20:27, Thiago Macieira wrote: > In the mean time: why do you care if some class derives from QStringView? > We certainly need to discuss the presence of an extra pointer inside, as that > has a cost. But derivation? A base class that a user can

Re: [Development] QList

On 18 March 2017 at 19:37, Marc Mutz wrote: >> In other words, introduce generic code where there wasn't generic code >> before - users writing >> non-generic code calling non-templates that return QLists will need to >> use deduction or a metaprogramming tool. > > No, that is

Re: [Development] QList

On 18 March 2017 at 23:51, Marc Mutz wrote: > We dug us a very deep pit here. If you compare QPair's implementation with a > typical std::pair's, you'll see that it's just totally pointless to keep > classes alive that have 1:1 std equivalents. We'll just never get to the QOI

Re: [Development] QList

On 19 March 2017 at 00:13, Marc Mutz wrote: >> > port these code lines manually come Qt 6. I do not consider auto >> > variables "generic code". >> Right. I, however, do consider them generic code. :) > You're free to call a chicken a pig for your own entertainment, but in the

Re: [Development] QList

On 18 March 2017 at 21:04, Kevin Kofler wrote: > Thiago Macieira wrote: >> A lot. I don't think we can have Qt 6 without a class called "QList". But >> we can make it be the same as QVector, which is what we want people to >> use. > > So the user code will at least compile

Re: [Development] QList

Sigh, I failed to reply to the list... On 18 March 2017 at 21:08, Ville Voutilainen <ville.voutilai...@gmail.com> wrote: > On 18 March 2017 at 20:15, Thiago Macieira <thiago.macie...@intel.com> wrote: >> During Qt 5 development, I began the process of rewriting QList so it

Re: [Development] QList

On 20 March 2017 at 20:55, Marc Mutz <marc.m...@kdab.com> wrote: > On Monday 20 March 2017 19:11:47 Ville Voutilainen wrote: >> However, I think it's still better to >> keep the name in the APIs and change >> the meaning of the name. That's far from ideal, but it

Re: [Development] QList

On 18 March 2017 at 11:51, Marc Mutz <marc.m...@kdab.com> wrote: > On Saturday 18 March 2017 09:06:09 Ville Voutilainen wrote: >> There's been a fair amount of talk about QList's future, so I'm curious: >> >> 1) What are the problems with QList? > > See Konstantin

[Development] QList

There's been a fair amount of talk about QList's future, so I'm curious: 1) What are the problems with QList? 2) What do we plan to do about those problems? 3) How do we expect to migrate code that uses it? Pardons all around for not being up to date if there's some material on the points above;

Re: [Development] QList

On 20 March 2017 at 14:13, Robin Burchell wrote: >> And when size matters, have this in mind: >> >> sizeof(std::vector) == 32 >> sizeof(QVector) == 8 >> sizeof(QList) == 8 > > To provide a more helpful response than Marc's: I assume that you are > aware that the Qt

Re: [Development] QList

On 20 March 2017 at 19:51, Marc Mutz wrote: >> Perhaps we shouldn't get on that side track, but *I* didn't do it, I'm >> not entirely convinced >> it broke "an awful lot of lines of code", and it indeed specifically >> did not and does not break very >> vast swaths of existing

Re: [Development] QList

On 20 March 2017 at 15:52, Marc Mutz wrote: > So, e.g.: Pay twice the fees to use a compatibility QList until Qt 7 or pay > the normal price and port, possibly with an automated tool a la clang- > modermize. And if I want to run the same code with Qt 5 and Qt 6? I don't want

Re: [Development] QList

On 22 March 2017 at 13:14, Philippe wrote: > by user, I meant "application programmer using Qt" :) So did I. :) The question for a free utility function and a base class is the same: are they exposed in any way? If not, neither of them is something the application programmer

Re: [Development] Focusing bug fixes to 5.9 branch and patch releases during H1/17

On 11 April 2017 at 11:47, Tuukka Turunen wrote: > > Hi Marc, > > I can understand your viewpoint, but unfortunately keeping 5.8 open does > cause additional load to the systems as well as people. It would be great if > you would rather focus into improving Qt 5.9 and

Re: [Development] Focusing bug fixes to 5.9 branch and patch releases during H1/17

On 11 April 2017 at 15:16, Marc Mutz <marc.m...@kdab.com> wrote: > On Tuesday 11 April 2017 13:49:01 Ville Voutilainen wrote: >> You say we discourage cherry-picking. Why? Is that not a fairly >> natural way to backport >> bugfixes from a bleeding-edge branch to a stabl

Re: [Development] Focusing bug fixes to 5.9 branch and patch releases during H1/17

On 11 April 2017 at 12:14, Marc Mutz <marc.m...@kdab.com> wrote: > On Tuesday 11 April 2017 10:34:20 Ville Voutilainen wrote: >> To elaborate: I run a bleeding-edge compiler. It feels odd to me that >> the best branch to run it on >> is a non-bleeding-edge branch, it'

Re: [Development] Focusing bug fixes to 5.9 branch and patch releases during H1/17

On 11 April 2017 at 11:22, Ville Voutilainen <ville.voutilai...@gmail.com> wrote: > On 11 April 2017 at 10:30, Marc Mutz <marc.m...@kdab.com> wrote: >> On Tuesday 11 April 2017 07:49:28 Tuukka Turunen wrote: >>> There has been a lot of discussion about this

Re: [Development] Focusing bug fixes to 5.9 branch and patch releases during H1/17

On 11 April 2017 at 10:30, Marc Mutz wrote: > On Tuesday 11 April 2017 07:49:28 Tuukka Turunen wrote: >> There has been a lot of discussion about this in the mailing lists, I think >> the two ones below sum it up quite well. > > They sum up *your* POV well. But up to a few

Re: [Development] How to include Standard Library headers from Qt ones?

On 16 April 2017 at 20:51, Giuseppe D'Angelo wrote: > Il 16/04/2017 18:32, Corentin ha scritto: >> >> More on point: >>* You don't actually need to include anything from the STL to >> implement std::hash. > > You actually do: you need to see the primary template

Re: [Development] Deleter that calls deleteLater() for use with std::unique_ptr<> and other smart pointers

On 19 April 2017 at 20:48, Konstantin Tokarev wrote: > > > 19.04.2017, 20:43, "Thiago Macieira" : >> On quarta-feira, 19 de abril de 2017 06:44:24 PDT Konstantin Tokarev wrote: >>> Hello, >>> >>> I think it will be a good idea to provide

Re: [Development] Use of std::function in Qt API

On 14 March 2017 at 17:54, Thiago Macieira wrote: >> I understand that there are limitations (to put it mildly) regarding the use >> of API from the C++ standard library in Qt API itself due to the inability >> to extend our binary compatibility promise. I'm curious

Re: [Development] QList

On 6 April 2017 at 09:26, Lars Knoll <lars.kn...@qt.io> wrote: > >> On 05 Apr 2017, at 17:51, Oswald Buddenhagen <oswald.buddenha...@qt.io> >> wrote: >> >> On Sat, Mar 18, 2017 at 10:06:09AM +0200, Ville Voutilainen wrote: >>> There's been a

Re: [Development] QList

On 24 April 2017 at 21:15, Marc Mutz <marc.m...@kdab.com> wrote: > On 2017-04-06 09:20, Ville Voutilainen wrote: > [...] >> >> Okay, I will do it. :) > > [...] > > Interested to see the result, as I'm considering abandoning the QArrayList > changes.

Re: [Development] How to make a fancy QMap c++17 initializer_list

On 26 July 2017 at 01:33, Thiago Macieira wrote: > On terça-feira, 25 de julho de 2017 15:03:17 PDT Marc Mutz wrote: >> A nested brace initializer does not have a type, if the types used in >> the inner braces are distinct, so >> >> std::map m = {{k1, v1}, {k2,

Re: [Development] Proposal for Qt 5.10 platforms and configurations changes

On 27 April 2017 at 14:58, Shawn Rutledge wrote: > Giuseppe was asking on IRC for GCC 7 and Clang 4. Which are quite bleeding > edge for almost all distros at this point, I suppose; Arch recently got Clang > 4 but not GCC 7 yet. That's because GCC 7 hasn't been released

Re: [Development] Use of std::function in Qt API

On 25 April 2017 at 17:34, Lars Knoll wrote: > >> On 25 Apr 2017, at 15:51, Thiago Macieira wrote: >> >> Em terça-feira, 25 de abril de 2017, às 07:59:03 -03, Marc Mutz escreveu: >>> What's holding us back? >> >> At this point, inertia. >> >> I've

Re: [Development] QList

On 27 April 2017 at 17:57, Thiago Macieira wrote: > On Thursday, 27 April 2017 01:19:16 -03 Marc Mutz wrote: >> On 2017-04-26 23:38, Konstantin Tokarev wrote: >> > 26.04.2017, 08:04, "Marc Mutz" : >> >> Users >> >> that need a queue can use

Re: [Development] [Releasing] Qt 5.10 pre-built bunaries

On 8 June 2017 at 09:45, Lars Knoll wrote: >>> And dropping GCC 4.7 would imply dropping support for QNX 6. >> >> I'll make the observation that we just released an LTS release that >> will support QNX 6 >> until the next LTS comes out. > > > Sure, it's still important that we

Re: [Development] [Releasing] Qt 5.10 pre-built bunaries

On 8 June 2017 at 09:23, Lars Knoll wrote: >> I'd like to propose raising the minimum version for GCC to 4.8.1, which is >> the >> first C++11 complete version, or higher. The reason for this is actually to >> drop GCC 4.7 and earlier, which have a few bugs with their C++11

Re: [Development] Dropping older compilers for Qt 5.10 (was: Qt 5.10 pre-built bunaries)

On 9 June 2017 at 23:31, Thiago Macieira wrote: > On Wednesday, 7 June 2017 15:10:57 PDT Thiago Macieira wrote: >> * Unicode strings >> * unrestricted unions >> >> Another benefit is that MSVC 2017 and 2015 are supposedly binary compatible >> with each other. With

Re: [Development] QUIP 6: removing top-level const from return types

On 23 May 2017 at 11:39, Marc Mutz wrote: > On Tuesday 23 May 2017 08:36:00 Lars Knoll wrote: >> (a detach happening on Linux, but not on MSVC) > > Don't fall for FUD. > > QPixmap does not have functions that are overloaded on const/non-const. > Neither does QRegion. Well,

Re: [Development] QList

On 24 May 2017 at 22:25, Marc Mutz wrote: > On 2017-05-24 15:12, Konstantin Tokarev wrote: >> >> 24.05.2017, 15:49, "NIkolai Marchenko" : >>> >>> A semi-sane idea that I think no one has suggested yet: >>> >>> What if, starting from Qt6, QList becomes

Re: [Development] QUIP 6: removing top-level const from return types

On 23 May 2017 at 12:00, Marc Mutz wrote: >> Maybe, but I have some questions: the review for removing top-level consts >> from QRegion says "It has no effect and inhibits move semantics." How does >> it inhibit move semantics? How is this even a SiC? What _positive_ impact >>

Re: [Development] Dropping older compilers for Qt 5.10 (was: Qt 5.10 pre-built bunaries)

On 8 June 2017 at 19:09, Konstantin Tokarev wrote: >> So I'm guessing we should require GCC 4.8.5 (all the latest fixes). This will >> give us full C++11 support in GCC. > > I'd like to insist that GCC 4.8 does not provide full C++11 support (see my > previous mail), > i.e.

Re: [Development] DBus signals for (dlclose'd) style plugin causing crash during application exit?

On 6 May 2017 at 22:48, Thiago Macieira wrote: > Second, compiling to ARM requires cross-compilation. Since the problem happens > because of cross-compilation, it happens for all ARM builds. Perhaps we should get ARM hardware so that we can do ARM builds without

Re: [Development] DBus signals for (dlclose'd) style plugin causing crash during application exit?

On 7 May 2017 at 18:36, René J. V. Bertin <rjvber...@gmail.com> wrote: > Ville Voutilainen wrote: > >> Perhaps we should get ARM hardware so that we can do ARM builds >> without cross-compilation. :) > > Not a single Qt dev who'd be willing to donate

Re: [Development] Qt Coding style and C++11

On 18 September 2017 at 10:02, Lorn Potter wrote: >>> The section "Conventions for C++11 usage" in [1] states: >>> >>> "Note: This section is not an accepted convention yet. >>> This section serves as baseline for further discussions." >>> >>> I'd like to push this

Re: [Development] Qt Coding style and C++11

On 18 September 2017 at 10:36, Lars Knoll wrote: >>> But for new plugins that target a known platform that supports c++11, they >>> can most likely use new conventions. >>> Unless someone can come up with technical reasons the new c++11 member >>> initialization is better than

Re: [Development] Qt and IoT infographic

On 28 August 2017 at 18:38, Thiago Macieira wrote: > Timur began working on an simple HTTP server. This is a controversial > decision, since we've long said that Qt should not be the tool for server-side > programs. That might be worth reconsidering as a guideline

Re: [Development] Dropping of MSVC 2013

On 18 October 2017 at 07:51, Thiago Macieira wrote: > This came up again in QtCS and we decided that dropping it soon is probably a > good idea, especially after Qt 5.9 became LTS. > > Did we decide on 5.10 or 5.11? > > Because one of my changes for 5.10 is currently

Re: [Development] Urgent: Qt 5.9.3 binaries built with too NEW Linux distribution

On 30 November 2017 at 19:47, Thiago Macieira wrote: > See https://bugreports.qt.io/browse/QTBUG-64820 and > http://lists.qt-project.org/pipermail/interest/2017-November/028766.html > > The Qt 5.9.3 binaries were compiled by GCC 6, which is too new for the latest >

Re: [Development] QtCS 2017 QtCore sessions

On 4 December 2017 at 21:29, Allan Sandfeld Jensen wrote: >> > I believe the name "optional" comes from Haskell and Java where it >> > appeared >> > first. The standard library only imports things that are already industry >> > standard, and once there were several

Re: [Development] Urgent: Qt 5.9.3 binaries built with too NEW Linux distribution

On 1 December 2017 at 10:02, Jani Heikkinen wrote: >> > 2) recompile the 5.9.3 binaries and post them. No changes to the >> > source code, just rebuild. > > I understand that but still I think we shouldn't do this. Qt 5.9.4 is coming > on January and I hope we can wait to

Re: [Development] QtCS 2017 QtCore sessions

On 1 November 2017 at 17:46, Thiago Macieira wrote: > On quarta-feira, 1 de novembro de 2017 08:25:01 PDT Konstantin Tokarev wrote: >> > No, not really, since it's already limited to half the full VM space. No >> > object can be larger than that. Using unsigned is

Re: [Development] QtCS 2017 QtCore sessions

On 2 December 2017 at 18:48, Marc Mutz wrote: > If that analyis were true, you'd need to explain why it is, then, that the > Qt containers now have more or less the same API as std ones, when in Qt 1 > they were very different. And why I keep needing to fight off QOptional. ..

Re: [Development] QtCS 2017 QtCore sessions

On 4 December 2017 at 16:20, Allan Sandfeld Jensen wrote: > On Montag, 4. Dezember 2017 15:00:53 CET Marc Mutz wrote: >> >> Ah, well, yes. Nothing truly originates in C++, true. But, IIRC, the >> Haskell name is maybe. So why is it QOptional and not QMaybe? Because >> the C++

Re: [Development] QtCS 2017 QtCore sessions

On 1 December 2017 at 22:35, Thiago Macieira wrote: > In theory, it's possible to use GCC 6 against an old set of libstdc++ headers. > > I don't know if the GCC devs officially support this (Ville, can you chime > in?). There's no attempt by GCC maintainers to make a

Re: [Development] Dropping of MSVC 2013

On 20 December 2017 at 16:17, Lars Knoll wrote: > Hi all, > > here are the promised numbers: > *Version* > *Compiler* > *Commercial* > > *Version* > *Compiler* > *Opensource* > 5.10.0 > MinGW530 > 22 % > > 5.10.0 > MinGW530 > 25 % > 5.10.0 > MSVC2013_64 > 14 % > > 5.10.0 >

Re: [Development] QTBUG-43096 - QML instantiation performance decadence

On 26 May 2018 at 12:20, Uwe Rathmann wrote: > Hi Robin, > >> Why does it need to be? I have never needed to subclass QQuickControl, >> personally, so I have never brought this topic up. > > For the same reason all other controls from QC2 do subclass it. If you > want to

Re: [Development] clang-format

On 19 June 2018 at 19:13, Philippe wrote: >> For the above reasons I'd lean towards not running it globally and just >> using it >> on new changes. > > +1, based on my clang-format experience on a big application. > > BTW, keep in mind that you can disable clang-format on code sections with: > >

Re: [Development] unique_ptr and Qt

On 5 June 2018 at 15:40, Daniel Teske wrote: > Hi, > > I've done some research into how supporting unique_ptr in Qt might look > like. > > I have a patch which adds apis using unique_ptr for ownership transfer to > almost all of QtBase and a patch for Qt Creator to show how using those apis >

Re: [Development] qqc2-desktop-style for qt6?

On 2 June 2018 at 22:23, Lars Knoll wrote: >> On 2 Jun 2018, at 19:33, Thiago Macieira wrote: >> >> On Saturday, 2 June 2018 10:27:28 PDT Jason H wrote: >>> I heard that after 5.11 the focus will start on Qt6? >> >> That information is outdated. There are no plans for Qt 6. > > Not yet, but

Re: [Development] clang-format

On 22 June 2018 at 19:39, Scott Bloom wrote: > I cant even get my developers to agree the emacs takes to many fingers, and > VI(m) is the only editor they need > > Let alone, where the brackets and spaces belong > > Let alone, if statements on the same line as the conditional > > The

Re: [Development] Any supported platforms not tested in CI?

On 20 October 2017 at 16:59, Konstantin Tokarev wrote: > > > 20.10.2017, 16:55, "Dmitry Shachnev" : >> On Wed, Oct 11, 2017 at 01:23:58PM +0200, Thiago Macieira wrote: >>> Are there any supported platforms that we do not test in the CI? Probably >>>

Re: [Development] QtCoap: QNAM-like API or not

On 14 January 2018 at 19:49, Adrien LERAVAT wrote: > With the clear drawback of explicit memory management needed by users. We > made > > some tests with a container/RAII object for the reply, and it seems fine, > but before > > moving forward in this limited timeframe, we

Re: [Development] #pragma once

On 25 January 2018 at 12:31, Konstantin Tokarev wrote: > > > 25.01.2018, 13:27, "Mathias Hasselmann" : >> Let's see what people who know much more about compiler features than >> any of us think about "#pragma once". Let's check what GCC and Clang do

Re: [Development] #pragma once

On 24 January 2018 at 16:30, Oswald Buddenhagen wrote: > but that's only tangentially related to the issue at hand, because the > compiler would still pick only one of the files under normal > circumstances. a problem would arise if different include styles in >

Re: [Development] Qt branches & proposal how to continue with those

On 29 January 2018 at 08:59, Jani Heikkinen wrote: > - '5.6' will move in 'very strict' mode > - '5.9' will move in 'strict' mode. So no direct submissions anymore, just > cherry picks from stable > - '5.10' will be closed and Qt 5.10.1 will be the final release from Qt

Re: [Development] Qt branches & proposal how to continue with those

On 29 January 2018 at 10:06, Jani Heikkinen wrote: >> On 29 January 2018 at 08:59, Jani Heikkinen wrote: >> > - '5.6' will move in 'very strict' mode >> > - '5.9' will move in 'strict' mode. So no direct submissions anymore, >> > just cherry picks from

Re: [Development] Qt branches & proposal how to continue with those

On 9 February 2018 at 18:17, Thiago Macieira wrote: > We do have BLACKLISTs this time and I complain every time I see one being > added without even an attempt at figuring out what's wrong with the test, or > when the match is overly aggressive ("it fails on Ubuntu in

Re: [Development] Qt branches & proposal how to continue with those

On 9 February 2018 at 20:39, Thiago Macieira <thiago.macie...@intel.com> wrote: > On Friday, 9 February 2018 08:32:20 PST Ville Voutilainen wrote: >> On 9 February 2018 at 18:17, Thiago Macieira <thiago.macie...@intel.com> > wrote: >> > We do have BLACKLISTs this

Re: [Development] Qt branches & proposal how to continue with those

On 9 February 2018 at 20:46, Ville Voutilainen <ville.voutilai...@gmail.com> wrote: >> But I am asking to do a minimal investigation. In most cases of blacklisting, >> the test has been failing for days, if not months. Spending an hour or two to >> understand why it's

Re: [Development] Qt branches & proposal how to continue with those

On 9 February 2018 at 13:07, Olivier Goffart wrote: > Anyway, here is some example of models which works: > > In LLVM, devs commit directly. buildbots build the trunk continuously. In case > of failure, the buildbot maintainer quickly find out which commit likely broke > the

Re: [Development] clang-format

On 22 June 2018 at 02:36, Olivier Goffart wrote: > On 2018-06-21 16:02, Thiago Macieira wrote: >> >> On Thursday, 21 June 2018 04:51:38 PDT Frederik Gladhorn wrote: >>> >>> checkout the change before we run clang-format >>> run clang-format on the changed files >>> push on top of the formatting

Re: [Development] Qt 6 buildsystem support requirements

On 1 August 2018 at 11:24, Jason Newton wrote: >> And... seriously, *Java*?! Talk about bloat-ware... As dependencies for >> *a build tool* go, that's pretty insane. Especially if you're not >> planning to use it to build Java code. > > As I said, ~300-400 megabytes for a JRE (~90MiB DL), in

Re: [Development] Qt 6 buildsystem support requirements

On 31 July 2018 at 22:33, Thiago Macieira wrote: > On Tuesday, 31 July 2018 11:43:49 PDT Scott Bloom wrote: >> Just a note.. for CMake, I find the -debug-output -trace and -trace-expand >> as useful as the -d and -d -d . >> >> One other thing I use all the time for dependency analysis, is the

Re: [Development] Qt 6 buildsystem support requirements

On 31 July 2018 at 20:49, Thiago Macieira wrote: > I know CMake meets these requirements, but it has other problems and the fact > that it currently does not build Qt. On that front, qbs is ahead. But qbs has > a shorter track record. Since we're not switching buildsystems in the next 2 > years,

Re: [Development] override keyword on destructors

On 20 August 2018 at 16:58, Kevin Funk via Development wrote: > On Monday, 20 August 2018 14:08:36 CEST Sérgio Martins via Development wrote: >> Hi, >> >> >> Looks like some 'override' keywords crept into a few destructors. This >> is probably because clang-tidy warns about it (and now

Re: [Development] Strange behavior on 5.12 branch and moc genrated file ( KDE application )

On 5 September 2018 at 14:42, Helio Chissini de Castro wrote: > Unfortunately not. > > Just compiled again reverting this commit and the issue still there. > > No ideas for now :-/ Any volunteers to bisect the problem? ___ Development mailing list

Re: [Development] #pragma once

On 24 January 2018 at 12:22, Alexander Nassian wrote: > Maybe because it’s not part of the C++ standard? #pragma once is not a replacement for include guards. It's not part of the C++ standard because it doesn't always work, and modules are a superior solution

Re: [Development] #pragma once

On 24 January 2018 at 14:19, Mitch Curtis wrote: >> > https://en.wikipedia.org/wiki/Pragma_once#Caveats >> >> That wikipedia link seems to describe the problems fairly accurately. > > Do we have that issue in Qt? I do not anticipate to like to debug it if we hit that issue in

Re: [Development] #pragma once

On 24 January 2018 at 12:34, Mitch Curtis <mitch.cur...@qt.io> wrote: > > >> -Original Message----- >> From: Ville Voutilainen [mailto:ville.voutilai...@gmail.com] >> Sent: Wednesday, 24 January 2018 11:25 AM >> To: Alexander Nassian <nass...@bit

Re: [Development] #pragma once

On 24 January 2018 at 14:24, Ville Voutilainen <ville.voutilai...@gmail.com> wrote: > On 24 January 2018 at 14:19, Mitch Curtis <mitch.cur...@qt.io> wrote: >>> > https://en.wikipedia.org/wiki/Pragma_once#Caveats >>> >>> That wikipedia link seems to desc

Re: [Development] Qt 5.12 schedule proposal & proposal for release process change

On 16 April 2018 at 09:43, Simon Hausmann wrote: > Hi, > > Same here. At first this seemed like a good idea, but it becomes awkward when > you look at it from the dev workflow point of view: After fixing a bug, what > is the fix version? Reported in snapshot-24062918 and

[Development] Maintainer action requested on tests

As many of you know, we've been operating a task force to reduce autotest flakiness and improve the stability of COIN and related CI infra. This has resulted in fair amounts of newly-blacklisted tests. What we need maintainers of various modules to do is as follows: 1) look at the blacklisted

Re: [Development] Resolving coding style contentions

On Mon, 19 Nov 2018 at 18:37, Thiago Macieira wrote: > > On Monday, 19 November 2018 02:34:09 PST Edward Welbourne wrote: > > I note a glaring exception to that: after the opening parenthesis of > > a parameter list, if the line would otherwise be too long: > > > > auto variable = > >

Re: [Development] Resolving coding style contentions

On Mon, 19 Nov 2018 at 22:41, Thiago Macieira wrote: > > On Monday, 19 November 2018 12:03:06 PST Ville Voutilainen wrote: > > I personally tend to split such things after an opening parenthesis. > > Getting back to allowing ctor-initializers to be written > > with a

Re: [Development] Proposal: New branch model

On Thu, 24 Jan 2019 at 20:26, Simon Hausmann wrote: > > > I would see the biggest long term impact with the massive amount of cherry > picks from dev to qt6 over a long period of time. > > Git rerere works locally, so it doesn’t help in this setup I think. Completely seriously, without any

[Development] Nominating Brett Stottlemeyer for Approver status

Brett is the maintainer of Qt Remote Objects. Thus he should be documented as a maintainer, and should also be an approver. Brett has been effectively maintaining QRO since 2014, so it seems like a slam dunk to give him the rights. ___ Development

Re: [Development] Nominating Kimmo Ollila for Approver

On Fri, 25 Jan 2019 at 10:22, Teemu Holappa wrote: > > Hello All, > > I'd like to nominate Kimmo Ollila for Approver. He has joined The Qt Company > more than five years ago. Lately he has been working on INTEGRITY RTOS > support and maintenance. +1.

Re: [Development] Nominating Sami Nurmenniemi for Approver status

On Fri, 25 Jan 2019 at 10:31, Simon Hausmann wrote: > > > +1 without any hesitation. (I thought he was an approver already :) +1. ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development

Re: [Development] Proposal: New branch model

On Wed, 23 Jan 2019 at 17:53, Jedrzej Nowacki wrote: > Proposal in short: let's use cherry-pick mode everywhere. > > All(**) changes would go to dev. From which they would be automatically > cherry-picked by a bot to other branches. The decision to which branch cherry- > pick, would be taken

Re: [Development] Proposal: New branch model

On Thu, 24 Jan 2019 at 15:47, Edward Welbourne wrote: > > Allan Sandfeld Jensen (24 January 2019 14:35) > > We can't integrate multiple changes to the same branch in parellel. > > I was under the impression that was exactly what we do. > > When I press Stage, my change gets cherry-picked to a

Re: [Development] Proposal: New branch model

On Thu, 24 Jan 2019 at 15:39, Shawn Rutledge wrote: > > > > > On 24 Jan 2019, at 14:15, Jedrzej Nowacki wrote: > > > > Typical use case I have with bug fixing in dev is when I develop a feature > > and > > I see let's say a memory leak in the code that I'm modifying or somewhere > > around.

Re: [Development] Proposal: New branch model (part: new contributors)

On Thu, 24 Jan 2019 at 16:14, Konstantin Tokarev wrote: > > > > 24.01.2019, 17:09, "Ville Voutilainen" : > > With the proposed model I push into trunk like in every other project. > > Why every other? Quite a few projects have different policies, e.g. in >

Re: [Development] Proposal: New branch model (part: new contributors)

On Thu, 24 Jan 2019 at 15:56, Jedrzej Nowacki wrote: > > Dnia środa, 23 stycznia 2019 18:09:31 CET Alex Blasche pisze: > > > - simpler for new contributors, always push to dev > > > > Really? Me being the new guy wanting to fix a bug in 5.12 need to magically > > know that I have to push to dev

Re: [Development] unique_ptr and Qt, Take 2

On Fri, 14 Jun 2019 at 00:36, Matthew Woehlke wrote: > > On 13/06/2019 16.09, Ville Voutilainen wrote: > > The minor problem being that to not so small audiences, > > new Whoosh(something); > > just looks like a bug, and then you need to look three times to > > real

Re: [Development] unique_ptr and Qt, Take 2

On Sat, 15 Jun 2019 at 02:30, Matthew Woehlke wrote: > >> OTOH, I just realized a problem with that... when the new child needs to > >> take its parent in the ctor for other reasons. I don't know if there is > >> an easy solution to that. (Of course, you can still pass the parent with > >>

Re: [Development] unique_ptr and Qt, Take 2

On Thu, 13 Jun 2019 at 22:54, Matthew Woehlke wrote: > > On 13/06/2019 14.13, Daniel Teske wrote: > > On June 12, 2019 23:13:14 Matthew Woehlke wrote:>> Generally, if you follow > > three rules: - If you create an object > on the stack, either don't parent it or ensure>> its parent

Re: [Development] Oslo, we have a problem [char8_t]

On Sat, 6 Jul 2019 at 19:24, Mutz, Marc via Development wrote: > > Though, if the compilers are implementing the behaviour correctly, > > maybe the right course of action is to actually complain to the > > committee that their change breaks code… > > AFAIU, this is a conscious break. See

Re: [Development] HTML5/CSS vs Qt QML and QtCreator / Assistant

On Sat, 29 Jun 2019 at 14:34, Konstantin Tokarev wrote: > > > > 29.06.2019, 14:27, "Konstantin Tokarev" : > > 29.06.2019, 14:00, "Giuseppe D'Angelo" : > >> Il 29/06/19 12:59, Konstantin Tokarev ha scritto: > This makes the exercise an couple of orders of magnitude harder, not >

Re: [Development] Supported compilers for Qt 6

On Mon, 12 Aug 2019 at 15:10, Allan Sandfeld Jensen wrote: > explicit(bool): We use some ugly patterns in places to simulate this. Can you point me to those? I do know what such patterns are in general, std::optional and std::tuple are full of it. :) > Integrating feature-test macros: Could

Re: [Development] Supported compilers for Qt 6

On Mon, 12 Aug 2019 at 11:00, Lars Knoll wrote: > Here’s the baseline I would like to propose: > > VC++ 2019 > GCC 8 > Clang 6 > Apple Clang 10.0 > > Why not the latest for all the compilers, like gcc 9 and clang 8? I assumed we > would use the 5.15 LTS to justify requiring the latest available

  1   2   3   >