[Development] toLower() vs. toCaseFolded()

Hi, http://doc.qt.io/qt-5/qstring.html#toCaseFolded is very vague on what case folding actually _is_ and how it's different from toLower(). Can someone please tell me the difference and why toCaseFolded() exists in the first place? Is it faster? Is it guaranteed to not make the string

Re: [Development] toLower() vs. toCaseFolded()

On Wednesday 09 December 2015 10:57:21 Florian Bruhin wrote: > * Marc Mutz [2015-12-09 11:54:54 +0100]: > > Hi, > > > > http://doc.qt.io/qt-5/qstring.html#toCaseFolded is very vague on what > > case folding actually _is_ and how it's different from toLower(). > > > > Can

[Development] Qt 5.7 feature freeze postponed, new date to be agreed

Hi all, According to original plans we should have Qt 5.7 FF next Friday (18th Dec). But we are still fighting to get Qt 5.6 (beta) out so there is no point to start freezing Qt 5.7 yet. We discussed about that yesterday's release team meeting & agreed to start discussion in ML about the

Re: [Development] toLower() vs. toCaseFolded()

* Marc Mutz [2015-12-09 11:54:54 +0100]: > Hi, > > http://doc.qt.io/qt-5/qstring.html#toCaseFolded is very vague on what case > folding actually _is_ and how it's different from toLower(). > > Can someone please tell me the difference and why toCaseFolded() exists in > the

Re: [Development] RFC: more liberal 'auto' rules?

On Wed, Dec 9, 2015 at 11:16 AM, Knoll Lars wrote: > And I’d say it’s about time to stop that particular sub-thread. It’s neither > productive nor leading anywhere. Is there a consensus otherwise about a more liberal use of auto in our source code? Cheers, --

Re: [Development] toLower() vs. toCaseFolded()

* Marc Mutz [2015-12-09 12:20:36 +0100]: > On Wednesday 09 December 2015 10:57:21 Florian Bruhin wrote: > > * Marc Mutz [2015-12-09 11:54:54 +0100]: > > > Hi, > > > > > > http://doc.qt.io/qt-5/qstring.html#toCaseFolded is very vague on what > > > case

Re: [Development] RFC: more liberal 'auto' rules?

On 09/12/15 11:00, "Development on behalf of Oswald Buddenhagen" wrote: >On Tue, Dec 08, 2015 at 08:43:53PM +0100, Marc Mutz wrote: >> On Tuesday 08 December 2015 15:52:06 Oswald Buddenhagen wrote: >> > your

Re: [Development] buildsystem now needs to keep behaviour compatibility

On Wed, Dec 02, 2015 at 01:04:40PM +0100, Olivier Goffart wrote: > On Wednesday 2. December 2015 10:17:57 Joerg Bornemann wrote: > > We should then keep build tests for these modules in the CI. > > Otherwise we won't notice breakages. > > I agree. > this is true. but that basically defeats the

Re: [Development] RFC: more liberal 'auto' rules?

On Tue, Dec 08, 2015 at 08:43:53PM +0100, Marc Mutz wrote: > On Tuesday 08 December 2015 15:52:06 Oswald Buddenhagen wrote: > > your triple emphasis that it's not necessary *anywhere* in python > > implied that you do indeed mean more than just locals. > > Only for someone who chimes in on a

Re: [Development] toLower() vs. toCaseFolded()

Hello Marc, I think the answer is into this Wikipedia page: http://www.w3.org/International/wiki/Case_folding As you can notice, case folding in languages different from English can be more difficult than just lowering the characters. So, I

Re: [Development] RFC: more liberal 'auto' rules?

I would like to bring up the a case from creator: const TextEditor::FontSettings = TextEditor::TextEditorSettings::instance()->fontS ettings(); I really prefer in that case const auto = TextEditor::TextEditorSettings::instance()->fontSettings(); Should we recommend forward(universal)

Re: [Development] RFC: more liberal 'auto' rules?

On 09/12/15 11:19, "Giuseppe D'Angelo" wrote: >On Wed, Dec 9, 2015 at 11:16 AM, Knoll Lars >wrote: >> And I’d say it’s about time to stop that particular sub-thread. It’s neither >> productive nor leading anywhere. Just for the record here,

Re: [Development] Nominating Samuli Pippo for Approver status

+1! _ From: Meadows Louis > Sent: Wednesday, December 2, 2015 2:01 PM Subject: Re: [Development] Nominating Samuli Pippo for Approver status To:

Re: [Development] RFC: more liberal 'auto' rules?

Lars wrote: > I don’t think there is a full consensus. Indeed, there isn't. > Let me try to summarise where > we are, what I think we agree upon and then add my thoughts :) > > As a primary goal, auto should be used wherever it increases readability > of the code. I think we all agree here.

Re: [Development] RFC: more liberal 'auto' rules?

On Wednesday 09 December 2015 14:15:47 Bubke Marco wrote: > for (auto & : values) This is ok in generic code. In non-generic code, I think it's too clever. In general, I would always try to preserve which kind of type we're dealing with: const auto *e = auto e* = const auto =

Re: [Development] RFC: more liberal 'auto' rules?

On 2015-12-09 08:15, Bubke Marco wrote: > Should we recommend forward(universal) references in for loops (which are > "const " for "const values"): > > for (auto & : values) Someone remind me; what's the benefit of this vs. 'auto const&' (assuming that I won't be modifying 'value')? > or > >

[Development] RFF: nullptr rules

Hi, in 5.7, nullptr (Q_C_NULLPTR) is required to be supported by the compiler, but there are no guidelines as to its use in the coding conventions (to the extent they need to be in there). I propose the following, based on Thiago's proposal from January this year, considering the new

Re: [Development] RFC: more liberal 'auto' rules?

On 2015-12-09 07:18, Knoll Lars wrote: > For loop variables, I don’t think we should require ‘auto’. Using it > can be the right thing to do in some cases, esp when using patterns > like ‘for(auto item: items)’ , but when looping using integer > indices, I still prefer ‘for (int i=...; cond;

Re: [Development] RFC: more liberal 'auto' rules?

>> Are these cases something we can agree upon? > Too little, imho. If we continue at this speed (one week for 1.5 more use- > cases of an already-allowed feature), then we're going to be done with C++11 > when C++22 is out. If I may ask, what is wrong with not using features of a language?

Re: [Development] RFF: nullptr rules

On 2015-12-09 10:14, Marc Mutz wrote: > in 5.7, nullptr (Q_C_NULLPTR) is required to be supported by the compiler, > but > there are no guidelines as to its use in the coding conventions (to the > extent > they need to be in there). > > I propose the following, based on Thiago's proposal from

Re: [Development] RFC: more liberal 'auto' rules?

On Wednesday 09 December 2015 13:18:06 Knoll Lars wrote: > as a listing with 50 entries won’t help anybody. Indeed. Therefore the suggestion to opt into C++ features, but optiing out of specific use cases. We have no indication that any compiler has problems with auto variables, so I don't see

Re: [Development] RFF: nullptr rules

On Wednesday, 9 December 2015 16:14:00 WET Marc Mutz wrote: > Arguments in favour: > - it's the C++ way of writing the null pointer constant these days > - we need to use it in headers, anyway, to allow people to use -Wzero-as..., > and it makes no sense to have two sets of rules for headers and

Re: [Development] RFF: nullptr rules

On 09-Dec-15 16:14, Marc Mutz wrote: in 5.7, nullptr (Q_C_NULLPTR) is required to be supported by the compiler, but there are no guidelines as to its use in the coding conventions (to the extent they need to be in there). There are also no guidelines for every other language feature, and I

Re: [Development] toLower() vs. toCaseFolded()

Am 09.12.2015 um 12:20 schrieb Marc Mutz: On Wednesday 09 December 2015 10:57:21 Florian Bruhin wrote: * Marc Mutz [2015-12-09 11:54:54 +0100]: Hi, http://doc.qt.io/qt-5/qstring.html#toCaseFolded is very vague on what case folding actually _is_ and how it's different

Re: [Development] RFF: nullptr rules

Am 09.12.2015 um 16:14 schrieb Marc Mutz: Arguments in favour: - it's the C++ way of writing the null pointer constant these days - we need to use it in headers, anyway, to allow people to use -Wzero-as..., and it makes no sense to have two sets of rules for headers and impl - it can

Re: [Development] Qt 5.7 feature freeze postponed, new date to be agreed

Hi, 15th Jan sounds good to me as the new FF time for Qt 5.7. The idea is to have the currently TP modules (at least many of them) supported with Qt 5.7 and also to drop the non-C++11 compilers as already discussed, agreed and implemented for dev. Therefore the content of Qt 5.7 is to a large

[Development] Fwd: RFF: nullptr rules

Resending from the right address. -- Forwarded message -- From: Richard Moore Date: 9 December 2015 at 17:22 Subject: Re: [Development] RFF: nullptr rules To: "development@qt-project.org" On 9 December 2015 at 15:14, Marc

Re: [Development] RFC: more liberal 'auto' rules?

On Wednesday 09 December 2015 16:02:01 Matthew Woehlke wrote: > Especially if there ever does end up being code in Qt > operating on STL objects where the correct type is something esoteric > like 'std::vector::size_type'. Already there: qmetaobjectbuilder.cpp -- Marc Mutz

Re: [Development] Qt 5.7 feature freeze postponed, new date to be agreed

Tuuka: I was looking around for "Coin CI" information on google. Can you provide links and additional insight into this CI? We have a thread on the interest list related to CI. md On 12/9/2015 9:58 AM, Turunen Tuukka wrote: Hi, 15th Jan sounds good to me as the new FF time for Qt 5.7.

Re: [Development] Fwd: RFF: nullptr rules

On 2015-12-09 12:23, Richard Moore wrote: > On 9 December 2015 at 15:14, Marc Mutz wrote: >> Arguments in favour: >> -Wzero-as..., >> and it makes no sense to have two sets of rules for headers and impl > > ​There's nothing that says we need to allow people to use that warning, ...except that

Re: [Development] toLower() vs. toCaseFolded()

On Wednesday 09 December 2015 11:54:54 Marc Mutz wrote: > Hi, > > http://doc.qt.io/qt-5/qstring.html#toCaseFolded is very vague on what case > folding actually _is_ and how it's different from toLower(). > > Can someone please tell me the difference and why toCaseFolded() exists in > the first

Re: [Development] RFF: nullptr rules

On Wednesday 09 December 2015 16:14:00 Marc Mutz wrote: > - 0 as a nullptr constant is banned except in tests testing APIs so > we don't accidentally require nullptr (ie. all tests should use 0, not > nullptr, as far as it makes sense) This is not what we had agreed to. We had said that

Re: [Development] RFF: nullptr rules

On Wednesday 09 December 2015 22:47:51 Marc Mutz wrote: > > const char *ptr = 0; > > What we agreed on was for Q_NULLPTR. > > Some developers back then were complaining that the *macro* is ugly, and > that by 5.7, we would be able to use the real thing and didn't want the > double

Re: [Development] RFF: nullptr rules

On Wednesday 09 December 2015 22:54:22 Marc Mutz wrote: > Whatever happened to KISS? That's a good reason not to run clang-modernize and force people to review. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center

Re: [Development] RFF: nullptr rules

On Wednesday 09 December 2015 16:14:00 Marc Mutz wrote: > Hi, > > in 5.7, nullptr (Q_C_NULLPTR) is required to be supported by the compiler, > but there are no guidelines as to its use in the coding conventions (to > the extent they need to be in there). > > I propose the following, based on

Re: [Development] toLower() vs. toCaseFolded()

On Wednesday 09 December 2015 22:56:48 Marc Mutz wrote: > On Wednesday 09 December 2015 11:54:54 Marc Mutz wrote: > > Can someone please tell me the difference and why toCaseFolded() exists in > > the first place? Is it faster? Is it guaranteed to not make the string > > longer/shorter? > > To

Re: [Development] RFF: nullptr rules

On 2015-12-09 17:29, Thiago Macieira wrote: > On Wednesday 09 December 2015 22:47:51 Marc Mutz wrote: > I'd like to propose this: > [...] > c) which means no -Werror=zero-as-nullptr outside of headersclean I just want to say that I think this is fair. The key phrase there is "outside of".

Re: [Development] RFF: nullptr rules

On Wednesday 09 December 2015 19:11:29 Thiago Macieira wrote: > On Wednesday 09 December 2015 16:14:00 Marc Mutz wrote: > > - 0 as a nullptr constant is banned except in tests testing APIs so > > > > we don't accidentally require nullptr (ie. all tests should use 0, not > > nullptr, as far as

Re: [Development] toLower() vs. toCaseFolded()

On Wednesday 09 December 2015 11:54:54 Marc Mutz wrote: > Can someone please tell me the difference and why toCaseFolded() exists in > the first place? Is it faster? Is it guaranteed to not make the string > longer/shorter? To be more precise: I'd like the docs to say when I should use

Re: [Development] RFF: nullptr rules

On Wednesday 09 December 2015 17:41:26 Matthew Woehlke wrote: > On 2015-12-09 17:29, Thiago Macieira wrote: > > On Wednesday 09 December 2015 22:47:51 Marc Mutz wrote: > > > > I'd like to propose this: > > [...] > > c) which means no -Werror=zero-as-nullptr outside of headersclean > > I just

Re: [Development] toLower() vs. toCaseFolded()

On Dec 9, 2015, at 1:27 PM, Thiago Macieira > wrote: For example, when title-casing in French, you drop accents ("école" becomes "Ecole"). This is off-topic but no, you don’t. Please, stop propagating this. This is a common mistake

Re: [Development] Qt 5.7 feature freeze postponed, new date to be agreed

Hi, A blog post is in the works, but not yet published. Now we have been focusing to get the Qt 5.6 beta out. We have not changed how Qt is built, codereview or the HW of CI, it is only the CI SW side that is renewed. Yours, -- Tuukka "m...@rpzdesign.com"

Re: [Development] RFC: more liberal 'auto' rules?

On Wednesday 09 December 2015 15:52:04 Rolland Dudemaine wrote: > If I may ask, what is wrong with not using features of a language? Nothing. Except that new generations of programmers will look at the code written in 90s style, label it "legacy", treat it with utmost disgust, slow down to a

Re: [Development] RFF: nullptr rules

On Wednesday 09 December 2015 16:38:02 Joerg Bornemann wrote: > > - if (!foo) vs. if (foo == nullptr), if (foo) vs. if (foo != nullptr): > >author's prerogative[1] [...] > > [1] I prefer the short form, but I don't think we'll gain a consensus > > here, so let's not even try > > So why do you

Re: [Development] Fwd: RFF: nullptr rules

On Wednesday 09 December 2015 18:23:20 Richard Moore wrote: > > Arguments in favour: [...] > > -Wzero-as..., > > > > and it makes no sense to have two sets of rules for headers and impl > > ​There's nothing that says we need to allow people to use that warning, and > nothing stopping us

Re: [Development] RFF: nullptr rules

On Wednesday 09 December 2015 16:19:38 Matthew Woehlke wrote: > > - APIs that require the use of nullptr for disambiguation are > > discouraged, > > > > but may be acceptable to be decided on a case-by-case basis. > > On that note, there is one case in which '0' as nullptr makes sense... >