Re: [Development] Qt Coding style and C++11
> On 15 Sep 2017, at 6:47 pm, Kevin Funk wrote: > > (2) And maybe your request: > - Use C++11 member initialization where possible > (IOW: Run clang-tidy cppcoreguidelines-pro-type-member-init checker > on code base and apply all fixes) But then files will begin to have a mixture of the two conventions, which is not necessarily a good thing. Wide scale changing of this is probably not a good idea. > > > I personally think that (1) would be useful (despite it costing us a lot of > code churn when doing the transition) because it's much easier to read > `nullptr` than `Q_NULLPTR`, or `override` instead of `Q_DECL_OVERRIDE` in > code. Other opinions may vary, but it's definitely more comfortable for > newcomers to read familiar C++ keywords than custom macros. > > I'd be willing to provide the patches for (1) and maybe even (2) if there's a > clear sentiment towards the change(s). > >> 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 discussion, because if code is converted to a new >> base, it should be clear to everyone HOW to do so. > > For new code the this should be a no-brainer, IMO. So +1 from my side. It really depends on the code, and where it is. Not all platforms/systems will support c++11 I suppose, and we might want to still target these. I am not up to date with all the platforms/targets, etc. 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 what is there now, I’d rather keep it the same as it is now. - Lorn Potter Developer, Maintainer QtSensors/QtSystemInfo ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
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 discussion, because if code is converted to a new >>> base, it should be clear to everyone HOW to do so. >> >> For new code the this should be a no-brainer, IMO. So +1 from my side. > > > It really depends on the code, and where it is. Not all platforms/systems > will support c++11 I suppose, and we might want to still target these. I am > not up to date with all the platforms/targets, etc. Do we still really support targets that don't support C++11? > 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 what is there now, I’d rather keep it the same > as it is now. If you have more than one constructor that set a member to the same value, it's arguably simpler and less error-prone to use a member initializer. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QRandomGenerator and boot times
On 15.09.2017 18:21, Thiago Macieira wrote: On Friday, 15 September 2017 00:31:36 PDT Sami Nurmenniemi wrote: I think we'll just have to accept blocking for the devices without hwrng. I don't know if we really support any such devices. If we do and boot time is essential for those, we'll have to figure out some way (probably saving entropy over reboot). And that would be a non-Qt job. I wasn't worried about Qt on real devices because I don't expect it to be run early enough to matter. On VMs, that's another story, and if you don't trust your undercloud-provided /dev/hwrng, why are you using that cloud? (Though I'll say there's an Intel team working on figuring out how a VM can get trust from the actual hardware, skipping the hypervisor trust) We have made some safety critical customer demos where fast boot time of Qt framework is essential. It was demoing boot time of 1.2s for a Qt application to start after powering on the device. I suppose that demo (and real safety critical use cases) is going to have problems with the QRandomGenerator even with hwrng in use. Anyway, I've read the entire Python thread to figure out what their conclusion was. Turns out, after spending hours reading everything, the bug ends without a conclusion. It must have been concluded, but it's not recorded in the bug report! ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt Coding style and C++11
> On 18 Sep 2017, at 09:25, Ville Voutilainen > wrote: > > 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 discussion, because if code is converted to a new base, it should be clear to everyone HOW to do so. >>> >>> For new code the this should be a no-brainer, IMO. So +1 from my side. >> >> >> It really depends on the code, and where it is. Not all platforms/systems >> will support c++11 I suppose, and we might want to still target these. I am >> not up to date with all the platforms/targets, etc. > > Do we still really support targets that don't support C++11? No, we don't. We still support some compilers that have incomplete C++11 support (VS2013 comes to my mind). But at least override and nullptr are now supported everywhere. I am in favour of doing a global search and replace of Q_DECL_OVERRIDE with override etc, as it does improve readability of our code base a lot. > >> 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 what is there now, I’d rather keep it the same >> as it is now. > > If you have more than one constructor that set a member to the same > value, it's arguably simpler and less error-prone > to use a member initializer. I also think that we should be using member initialisers when writing new code (or when refactoring existing code). But doing a global search/replace of existing code might lead to subtle errors as it's easy to miss the rare case when different constructors initialise members differently. Cheers, Lars ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt Coding style and C++11
Op 18/09/2017 om 09:02 schreef Lorn Potter: >> On 15 Sep 2017, at 6:47 pm, Kevin Funk wrote: >> >> (2) And maybe your request: >> - Use C++11 member initialization where possible >> (IOW: Run clang-tidy cppcoreguidelines-pro-type-member-init checker >> on code base and apply all fixes) > But then files will begin to have a mixture of the two conventions, which is > not necessarily a good thing. Wide scale changing of this is probably not a > good idea. I don't get this. Wouldn't doing this do as much cleanup as is reasonably possible across the whole code base? How do you end up with a mixture then? > >> >> I personally think that (1) would be useful (despite it costing us a lot of >> code churn when doing the transition) because it's much easier to read >> `nullptr` than `Q_NULLPTR`, or `override` instead of `Q_DECL_OVERRIDE` in >> code. Other opinions may vary, but it's definitely more comfortable for >> newcomers to read familiar C++ keywords than custom macros. >> >> I'd be willing to provide the patches for (1) and maybe even (2) if there's >> a >> clear sentiment towards the change(s). >> >>> 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 discussion, because if code is converted to a new >>> base, it should be clear to everyone HOW to do so. >> For new code the this should be a no-brainer, IMO. So +1 from my side. > > It really depends on the code, and where it is. Not all platforms/systems > will support c++11 I suppose, and we might want to still target these. I am > not up to date with all the platforms/targets, etc. Qt already requires C++11. So no, we do not still want to target platforms that don't support C++11. > > 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 what is there now, I’d rather keep it the same > as it is now. It is less error-phrone to initialize at the place of declaration, instead of in a different file. This gets worse if you have multiple constructors. So, naturally, we end up with uninitialized member variables, with all the mahem that may cause. André ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
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 what is there now, I’d rather keep it the >>> same as it is now. >> >> If you have more than one constructor that set a member to the same >> value, it's arguably simpler and less error-prone >> to use a member initializer. > > I also think that we should be using member initialisers when writing new > code (or when refactoring existing code). But doing a global search/replace > of existing code might lead to subtle errors as it's easy to miss the rare > case when different constructors initialise members differently. Note that if you have both a member initializer and a ctor-initializer (the colon-list after the constructor signature, X() : foo(a), bar(b)), the ctor-initializer is used. It is non-trivial to remove ctor-initializers and replace them with member-initializers, I don't know whether the clang-tools can do that. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt Coding style and C++11
> On 18 Sep 2017, at 09:37, André Somers wrote: > > Op 18/09/2017 om 09:02 schreef Lorn Potter: >>> On 15 Sep 2017, at 6:47 pm, Kevin Funk wrote: >>> >>> (2) And maybe your request: >>> - Use C++11 member initialization where possible >>> (IOW: Run clang-tidy cppcoreguidelines-pro-type-member-init checker >>> on code base and apply all fixes) >> But then files will begin to have a mixture of the two conventions, which is >> not necessarily a good thing. Wide scale changing of this is probably not a >> good idea. > I don't get this. Wouldn't doing this do as much cleanup as is > reasonably possible across the whole code base? How do you end up with a > mixture then? I’m not sure what Lorn meant, but there are cases where you can’t do the initialization along with the declaration: for example bitfields. Or when the initialization needs to be different in different constructors. So as long as we accept that it will never be 100%, I think it doesn’t hurt to use it where we can. >>> I personally think that (1) would be useful (despite it costing us a lot of >>> code churn when doing the transition) because it's much easier to read >>> `nullptr` than `Q_NULLPTR`, or `override` instead of `Q_DECL_OVERRIDE` in >>> code. Other opinions may vary, but it's definitely more comfortable for >>> newcomers to read familiar C++ keywords than custom macros. >>> >>> I'd be willing to provide the patches for (1) and maybe even (2) if there's >>> a >>> clear sentiment towards the change(s). +1 yes please… I always do (1) in new code and strongly encourage it in code reviews, for a long time already. > It is less error-phrone to initialize at the place of declaration, > instead of in a different file. This gets worse if you have multiple > constructors. So, naturally, we end up with uninitialized member > variables, with all the mahem that may cause. Yep; and the lazy reason to like it is that you don’t have to worry about keeping initialization in the same order as declaration, with all the $#@% warnings if you don’t. (If this pedantry is so important, why can’t it be automated? And now it finally is.) Slight downside: it’s going to make merges harder for a while. I guess we will do such wholesale changes only on dev branch? ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt Coding style and C++11
On Monday, 18 September 2017 09:38:53 CEST Ville Voutilainen wrote: > 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 what is there now, I’d rather keep it the same as it is now.>> > >> If you have more than one constructor that set a member to the same > >> value, it's arguably simpler and less error-prone > >> to use a member initializer. > > > > I also think that we should be using member initialisers when writing new > > code (or when refactoring existing code). But doing a global > > search/replace of existing code might lead to subtle errors as it's easy > > to miss the rare case when different constructors initialise members > > differently. > Note that if you have both a member initializer and a ctor-initializer > (the colon-list after the constructor signature, X() : foo(a), > bar(b)), the ctor-initializer > is used. It is non-trivial to remove ctor-initializers and replace > them with member-initializers, I don't know whether the clang-tools > can do that. I have to take back my claim that clang-tidy can automatically transform initialization via initializer list to initialization via in-class field initializers. I just remembered that this cppcoreguidelines-pro-type-member-init checker just *adds* in-class field initializers for fields which haven't been initialized altogether *before*. It does nothing if the initializer list initializes all fields already. So in order to actually port all uses of initializer lists to something more modern, clang-tidy would need to be extended. So I guess the discussion whether to a global search/replace for this particular C++11 feature is moot for now, since doing this port on all of Qt is infeasible without proper tooling. Regards, Kevin ___ > Development mailing list > Development@qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- Kevin Funk | kevin.f...@kdab.com | Senior Software Engineer KDAB (Deutschland) GmbH&Co KG, a KDAB Group company Tel. Germany +49-30-521325470, Sweden (HQ) +46-563-540090 KDAB - The Qt, C++ and OpenGL Experts smime.p7s Description: S/MIME cryptographic signature ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt Coding style and C++11
On 09/15/2017 06:42 AM, André Hartmann wrote: I'd like to push this discussion, because if code is converted to a new base, it should be clear to everyone HOW to do so. Great initiative! It would be great if the guidelines could be updated to reflect the new standard. What I like to add, is to encourage the use of C++11 member initialisation. They are already used in QtSerialBus (from the beginning) and QtCreator (ongoing changes to existing codebase). +1 What do you think? I was right now wondering if `typedef` or `using` is preferred in new code. And if `using` is preferred, what to do when there are existing typedefs in nearby code? Personally, I think we should prefer `using`, and update nearby typedefs accordingly, but it should also be safe to do a search-replace in the entire codebase if we are already doing that for other things. Is there a way we could formalize this discussion a bit? Perhaps a wiki-page where we could list the suggested changes and we could have some kind of voting mechanism? It could make it easier to separate the things everybody agrees on from the more interesting discussions. Best regards, Svenn-Arne ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt Coding style and C++11
> I'd like to push this discussion, because if code is converted to a new > base, it should be clear to everyone HOW to do so. I agree regarding consistency. If we are spending time on this, then it should be done properly. I think Qt Coding Conventions wiki should be moved to somewhere where changes can be reviewed via Gerrit. 1) It currently says: "You have to explicitly specify the return type, if the lambda contains more than a single expression. Otherwise it does not compile with VS2010." I guess this restriction does not apply for Qt 5.8 (dropped support for VS2010) and above? Or maybe it does, who knows. With gerrit I could add relevant reviewers, if I decide to change something in conventions page. 2) What is the convention regarding functor-based connections + signal/slot keyword usage? See: https://codereview.qt-project.org/#/c/203550/3/examples/widgets/itemviews/storageview/storagemodel.h Gatis. From: Development on behalf of André Hartmann Sent: Friday, September 15, 2017 6:42:34 AM To: development@qt-project.org Subject: [Development] Qt Coding style and C++11 Hi, since a while C++11 is allowed in Qt and there is ongoing effort porting e.g. examples to the new possibilities. 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 discussion, because if code is converted to a new base, it should be clear to everyone HOW to do so. What I like to add, is to encourage the use of C++11 member initialisation. They are already used in QtSerialBus (from the beginning) and QtCreator (ongoing changes to existing codebase). What do you think? Best regards, André [1] https://wiki.qt.io/Coding_Conventions ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt Coding style and C++11
> -Original Message- > From: Development [mailto:development-bounces+kai.koehne=qt.io@qt- > project.org] On Behalf Of Gatis Paeglis > Sent: Monday, September 18, 2017 12:43 PM > To: André Hartmann ; development@qt-project.org > Subject: Re: [Development] Qt Coding style and C++11 > > > I'd like to push this discussion, because if code is converted to a > > new base, it should be clear to everyone HOW to do so. > > I agree regarding consistency. If we are spending time on this, then it should > be done properly. I think Qt Coding Conventions wiki should be moved to > somewhere where changes can be reviewed via Gerrit. We've a place for this: QUIPs. http://quips-qt-io.herokuapp.com/ These can be properly reviewed and also finally approved, so having a coding style QUIP (for code inside Qt) there would be a good thing. Kai ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QRandomGenerator and boot times
On Monday, 18 September 2017 00:34:03 PDT Sami Nurmenniemi wrote: > > And that would be a non-Qt job. I wasn't worried about Qt on real devices > > because I don't expect it to be run early enough to matter. On VMs, > > that's > > another story, and if you don't trust your undercloud-provided /dev/hwrng, > > why are you using that cloud? (Though I'll say there's an Intel team > > working on figuring out how a VM can get trust from the actual hardware, > > skipping the hypervisor trust) > > We have made some safety critical customer demos where fast boot time of > Qt framework is essential. It was demoing boot time of 1.2s for a Qt > application to start after powering on the device. I suppose that demo > (and real safety critical use cases) is going to have problems with the > QRandomGenerator even with hwrng in use. That has an easy solution: use a real hardware random generator. That's a matter of making sure your SoC is correctly dimensioned for the use-case. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] [Announce] qbs 1.9.0 released
Hello, I'd like to announce the release of Qbs 1.9, which introduces major new features product multiplexing and dependency parameterization. You can find all the relevant information here: https://blog.qt.io/blog/2017/09/05/qbs-1-9-released/ Cheers, Joerg ___ Announce mailing list annou...@qt-project.org http://lists.qt-project.org/mailman/listinfo/announce ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] [Announce] New high-bandwidth Qt mirror for the San Francisco Bay Area / US west coast
Hello everyone, I'm happy to announce that we've just added a new mirror for download.qt.io in the San Francisco Bay Area (the first in the US west coast geographic area). This mirror is provided by UC Berkeley and is very high-bandwidth, which should result in a significant download performance boost for our users the area. For example, I consistently achieve 20 MB/s from roughly 20 km away in San Francisco (which is even faster than our commercial AWS CDN!). So, please thank the University of California, Berkeley Open Computing Facility for their support of the Qt Project, and happy downloading! Cheers, -- Jake Petroules - jake.petrou...@qt.io The Qt Company - Silicon Valley Qbs build tool evangelist - qbs.io ___ Announce mailing list annou...@qt-project.org http://lists.qt-project.org/mailman/listinfo/announce ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
