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

[Bo Thorsen]

Den 29-12-2015 kl. 18:47 skrev Matthew Woehlke:

On 2015-12-26 20:17, Kevin Kofler wrote:

And what is hard to parse for humans? The "char* p,q" "issue"? That's a
formatting bug then, this ought to be written "char *p, q", which makes it
very clear what is going on.


That's... debatable. Personally, I dislike combining names and type
information. And it doesn't always work out so nicely. What, for
example, is the type of 'q' here?:

   char const* const *p, q;

Explicit pointer/reference types and multiple declarations should simply
not appear in the same statement¹. Period.


This is getting quite off-topic, even for this thread.

Bo Thorsen,
Director, Viking Software.

--
Viking Software
Qt and C++ developers for hire
http://www.vikingsoft.eu
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

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

[Matthew Woehlke]

On 2015-12-24 19:16, Kevin Kofler wrote:
> Matthew Woehlke wrote:
>>   auto result = QString{a + b};
> 
> IMHO, that's just a complicated and ugly way to write:
>   QString result = a + b;
> 
> There is no way the variable can be uninitialized if you initialize it right 
> there in the declaration.

That's nice, but what about when you forget to initialize something? If
you (almost) always use auto, the compiler will squawk. The benefit
comes from *consistency*.

Anyway, I'm not trying to argue passionately that Qt should follow AAA.
I'm just saying that it's incorrect to state that you have to deviate
from AAA because it might give you the wrong type. (And, as Marc notes,
AAA, used correctly, actually *better* documents code in such case.)

-- 
Matthew

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

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

[Matthew Woehlke]

On 2015-12-26 20:17, Kevin Kofler wrote:
> And what is hard to parse for humans? The "char* p,q" "issue"? That's a 
> formatting bug then, this ought to be written "char *p, q", which makes it 
> very clear what is going on.

That's... debatable. Personally, I dislike combining names and type
information. And it doesn't always work out so nicely. What, for
example, is the type of 'q' here?:

  char const* const *p, q;

Explicit pointer/reference types and multiple declarations should simply
not appear in the same statement¹. Period.

-- 
Matthew

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

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

[Alejandro Exojo]

El Sunday 27 December 2015, Kevin Kofler escribió:
> I consider the C declarator syntax just fine, it is very intuitive and has 
> served us well for 26 years, so I don't see a need to change it.

That some things have served up well for some time, that doesn't mean we can't 
find better things (either to complement, or completely replace the old ones). 
That doesn't mean the AAA style is better just because it's new, of course. I 
just state no opinion. But your justification is wrong.
 
> Implicit narrowing conversions are a feature.

const qlonglong pi = 3.141592653589793238462643383;

That compiles and runs without warnings or errors. A line exactly like this 
ended up in a real application for some alpha version. I don't like this 
feature at all, and I'm glad there is a way to guard you against it (I might 
not like how it has to be done yet, but there are good reasons for wanting to 
avoid this feature).

-- 
Alex (a.k.a. suy) | GPG ID 0x0B8B0BC2
http://barnacity.net/ | http://disperso.net
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

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

[Bubke Marco]

On December 25, 2015 13:24:43 Thiago Macieira  wrote:

> On Friday 25 December 2015 10:35:02 Marc Mutz wrote:
>> There are a lot of problems with the C declarator syntax (implicit
>> narrowing  conversions, hard-to-parse for humans, "most vexing parse",
>> non-uniformity), and auto and uniform init and template aliases are the
>> fixes. If you don't use them, then you're stuck in the C declarator syntax.
>> You need to use a radically different syntax to get the nicer rules.
>
> Except when they mean different things.
>
>   auto v1 = QVector{1, 2};
>   auto v2 = QVector(1, 2);
>

The second contructor looks misleading. ;-)

Actually I never used size in the constructor. And if you need something like 
that a factory function would would be much nicer. What I using today is 

function({1, 2, 3})
 for testing if the function expect an vector. And

auto values = createValues({{"one", 1}, {"two", 2} , {"three", 3});
If I use value classes. It makes test driven development much easier because I 
can change things easier. And the test code is more readable. 

or I use

Vector values;
values.reserve(4096);

To initialize a vector. 

auto values = reserve(Vector(),  4046); 
Could be nice too but that is C++ 17.

After using python for years C++ syntax looks still ugly to me but you get used 
to it.

So my advice is that you use it for some time and then judge. Taste is 
changing. ;-)
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

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

[Kevin Kofler]

Marc Mutz wrote:
> There are a lot of problems with the C declarator syntax (implicit
> narrowing conversions, hard-to-parse for humans, "most vexing parse",
> non-uniformity), and auto and uniform init and template aliases are the
> fixes. If you don't use them, then you're stuck in the C declarator
> syntax. You need to use a radically different syntax to get the nicer
> rules.

I consider the C declarator syntax just fine, it is very intuitive and has 
served us well for 26 years, so I don't see a need to change it.

Implicit narrowing conversions are a feature.

And what is hard to parse for humans? The "char* p,q" "issue"? That's a 
formatting bug then, this ought to be written "char *p, q", which makes it 
very clear what is going on.

Kevin Kofler

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

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

[Marc Mutz]

On Friday 25 December 2015 01:16:54 Kevin Kofler wrote:
> Matthew Woehlke wrote:
> >   auto result = QString{a + b};
> 
> IMHO, that's just a complicated and ugly way to write:
>   QString result = a + b;
> 
> There is no way the variable can be uninitialized if you initialize it
> right there in the declaration.

Actually, the point here is that this construction with an explicit type name 
is rare and signals an explicit type conversion, or a type constructor.

In the AAA style I know, this should have been a static_cast(a+b), 
btw, because it is a conversion.

The {}, in general, is preferred because it prevents narrowing conversions.

There are a lot of problems with the C declarator syntax (implicit narrowing 
conversions, hard-to-parse for humans, "most vexing parse", non-uniformity), 
and auto and uniform init and template aliases are the fixes. If you don't use 
them, then you're stuck in the C declarator syntax. You need to use a 
radically different syntax to get the nicer rules.

And yes, I also abhor QString s{a}, but in five years time, every C++ 
programmer's eyes will have become used to it. They must, if they don't want 
to be stuck in the past.

Thanks,
Marc

-- 
Marc Mutz  | Senior Software Engineer
KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
Tel: +49-30-521325470
KDAB - The Qt Experts
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

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

[Thiago Macieira]

On Friday 25 December 2015 10:35:02 Marc Mutz wrote:
> There are a lot of problems with the C declarator syntax (implicit
> narrowing  conversions, hard-to-parse for humans, "most vexing parse",
> non-uniformity), and auto and uniform init and template aliases are the
> fixes. If you don't use them, then you're stuck in the C declarator syntax.
> You need to use a radically different syntax to get the nicer rules.

Except when they mean different things.

auto v1 = QVector{1, 2};
auto v2 = QVector(1, 2);

-- 
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

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

[Kevin Kofler]

Matthew Woehlke wrote:
>   auto result = QString{a + b};

IMHO, that's just a complicated and ugly way to write:
  QString result = a + b;

There is no way the variable can be uninitialized if you initialize it right 
there in the declaration.

Kevin Kofler

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

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

[Marc Mutz]

On Tuesday 22 December 2015 15:40:01 Matthew Woehlke wrote:
> On 2015-12-22 09:50, Marc Mutz wrote:
> > foreach(const QString  : someLongExpression()->fooBar().names())
> > 
> > const auto strings = someLongExpression()->fooBar().names();
> > for (const QString  : strings)
> 
> On that note, is there any case in which Q_FOREACH is superior to a
> range-based for? (Besides the obvious one where the original list is
> modified from within the loop?)

No. range-for and for (auto it = begin(), end = end(); it != end; ++it) are 
equivalent. indexed access is less efficient (both from text size pov as well 
as 
address generation, where e.g. Haswell, where offsetting into L1 has latency 4 
whereas going though a pointer has latency 3), and foreach, due to the copy, 
is always much, much worse. Even when the RHS is an rvalue and you do the 
replacement you quoted above, the range-for is more efficient, probably 
Q_FOREACH forces another copy while assigning to const-auto uses (N)RVO.

Even in the case where the original list is modified in the loop, taking a copy 
and then using range-for may be more efficient. It is surely more readable, 
because you can (and should) comment on why the copy is necessary. That said, 
such loops as you describe will usually have very poor performance. Either due 
to the detach() that necessarily happens, or due to quadratic behaviour, e.g. 
calling erase(it) on a vector or QList while iterating.

Try to port all your Q_FOREACH to range-for loops. You will be surprised how 
much digging is required if you don't always want to take the hit of taking a 
copy.

In a change of mine, I estimated that by removing all Q_FOREACH uses in 
qtbase/src (all 880+ of them) would save 80KiB in text size across the qtbase 
libraries. I now think that it will be more, because QtCore is compiled with 
exceptions enabled, and then Q_FOREACH is really, really, horrendous. I posted 
side-by-side asm here: https://codereview.qt-project.org/112431

Thiago claims to have fixed that particular code explosion, but I think that 
the correct fix is to deprecate and port all Q_FOREACH/foreach to range-for.

Thanks,
Marc

-- 
Marc Mutz  | Senior Software Engineer
KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
Tel: +49-30-521325470
KDAB - The Qt Experts
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

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

[Giuseppe D'Angelo]

Il 22/12/2015 11:26, Ziller Eike ha scritto:

So funny/unwanted behavior can occur both because one used the wrong explicit 
type, and because one used auto instead of an explicit type.


These shortcomings of auto are recognized in the community, but yes, 
they're real and dangerous. Clazy [1] already has a warning for the 
danger of auto with QStringBuilder, I guess it can be extended to other 
cases.


N4035 [2] proposes general purpose workarounds ("operator auto", 
specializations to std::decay, etc.) to address these issues.



[1] https://github.com/KDE/clazy/blob/master/README
[2] http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4035.pdf


My 2 c,
--
Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Software Engineer
KDAB (UK) Ltd., a KDAB Group company | Tel: UK +44-1625-809908
KDAB - The Qt Experts



smime.p7s
Description: Firma crittografica S/MIME
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

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

[Ziller Eike]

> On Dec 8, 2015, at 10:46 AM, Ziller Eike  wrote:
> 
> 
>> On Dec 7, 2015, at 2:41 PM, Knoll Lars  wrote:
>> 
>> On 07/12/15 15:44, "Development on behalf of Marc Mutz" 
>>  wrote:
>> 
>> 
>> 
>>> On Monday 07 December 2015 13:48:58 Ziller Eike wrote:
 I do not think that more usage of ‘auto’ will make any code (or
 refactorings of it) ‘safer’. IMO this is only about convenience and
 readability.
>>> 
>>> std::map stdMap = ...;
>>> 
>>> for (const std::pair  : stdMap)
>>>doSomething(e.first, e.second);
>>> 
>>> for (const auto  : stdMap)
>>>doSomething(e.first, e.second);
>>> 
>>> The second loop is at least two orders of magnitude faster (doSomething() 
>>> is 
>>> an out-of-line no-op).
>> 
>> I think the summary here is that auto gives you one guarantee: It won’t do 
>> an implicit conversion for the initial assignment.

So, directly after the above example in Item 5, Item 6 in Effective Modern C++ 
continues with the examples of how you can shoot yourself in the foot _because_ 
you used auto.

std::vector features(const MyType );
MyType w;
auto someFeatureActive = features(w)[5];
doSomething(someFeatureActive); // < undefined behavior because 
someFeatureActive is _not_ a bool

We have something similar in Qt:

QString a = "ABC";
QString b = "abc";
auto result = a + b;
a.replace("A", "C");
qDebug() << result;

prints “CBCabc” instead of “ABCabc” when QT_USE_FAST_OPERATOR_PLUS is defined, 
because result is not a QString in that case.

So funny/unwanted behavior can occur both because one used the wrong explicit 
type, and because one used auto instead of an explicit type.

> Granted.
> I really wonder though, why it is possible to assign the wrong type to a 
> _reference_ here, even if it is const ?
> I cannot do that with e.g. a std::vector (std::vector v; 
> const std::vector  = v;), so is that some funny thing with 
> std::pair?
> The spirit of the “you can use auto when assigning iterator type” was to mean 
> “you can use auto when assigning long ugly template types” at least in case 
> of ‘known patterns' (of which we do not have too many in Qt API, therefore 
> iterator types). So I think this use of auto is covered by the “spirit” of 
> the rule.
> 
> Br, Eike

-- 
Eike Ziller, Senior Software Engineer - The Qt Company GmbH
 
The Qt Company GmbH, Rudower Chaussee 13, D-12489 Berlin
Geschäftsführer: Mika Pälsi, Juha Varelius, Tuula Haataja
Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 
144331 B

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

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

[Marc Mutz]

On Tuesday 22 December 2015 11:26:40 Ziller Eike wrote:
> We have something similar in Qt:
> 
> QString a = "ABC";
> QString b = "abc";
> auto result = a + b;
> a.replace("A", "C");
> qDebug() << result;
> 
> prints “CBCabc” instead of “ABCabc” when QT_USE_FAST_OPERATOR_PLUS is
> defined, because result is not a QString in that case.
> 
> So funny/unwanted behavior can occur both because one used the wrong
> explicit type, and because one used auto instead of an explicit type.

This is not specific to auto, though:

QStringView v = QLatin1Char('a');
const char *data = str.toLatin1(); // implicit conversion by default
QLatin1String l1 = str.toLatin1();
QVector v = {0, 1, 2};
QVector::iterator it = v.begin();
const QVector v2 = v;
*it = 1;
assert(v2.front() == 0); // boom

It's a general peril when working with C++.

Reminds me of the 1970s when we got a law requiring the use of the seat-belt 
in cars in Germany. My uncle used to tell the story how one of his friends 
survived a crash because he was ejected from the car since he was _not_ 
buckled up, just to follow up with the story how another friend was not harmed 
in a crash because he _was_ strapped in...

Thanks,
Marc


-- 
Marc Mutz  | Senior Software Engineer
KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
Tel: +49-30-521325470
KDAB - The Qt Experts
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

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

[Bubke Marco]

Clazy is nice but it's under GPL so it's not possible to integrate it in the 
creator clang code model. But I think we need something like clazy for the 
clang code model too.


From: Development <development-boun...@qt-project.org> on behalf of Giuseppe 
D'Angelo <giuseppe.dang...@kdab.com>
Sent: Tuesday, December 22, 2015 11:59 AM
To: development@qt-project.org
Subject: Re: [Development] RFC: more liberal 'auto' rules?

Il 22/12/2015 11:26, Ziller Eike ha scritto:
> So funny/unwanted behavior can occur both because one used the wrong explicit 
> type, and because one used auto instead of an explicit type.

These shortcomings of auto are recognized in the community, but yes,
they're real and dangerous. Clazy [1] already has a warning for the
danger of auto with QStringBuilder, I guess it can be extended to other
cases.

N4035 [2] proposes general purpose workarounds ("operator auto",
specializations to std::decay, etc.) to address these issues.

> [1] https://github.com/KDE/clazy/blob/master/README
> [2] http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4035.pdf

My 2 c,
--
Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Software Engineer
KDAB (UK) Ltd., a KDAB Group company | Tel: UK +44-1625-809908
KDAB - The Qt Experts

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

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

[Ziller Eike]

> On Dec 22, 2015, at 1:28 PM, Marc Mutz  wrote:
> 
> On Tuesday 22 December 2015 11:26:40 Ziller Eike wrote:
>> We have something similar in Qt:
>> 
>>QString a = "ABC";
>>QString b = "abc";
>>auto result = a + b;
>>a.replace("A", "C");
>>qDebug() << result;
>> 
>> prints “CBCabc” instead of “ABCabc” when QT_USE_FAST_OPERATOR_PLUS is
>> defined, because result is not a QString in that case.
>> 
>> So funny/unwanted behavior can occur both because one used the wrong
>> explicit type, and because one used auto instead of an explicit type.
> 
> This is not specific to auto, though:
> 
>QStringView v = QLatin1Char('a');
>const char *data = str.toLatin1(); // implicit conversion by default
>QLatin1String l1 = str.toLatin1();
>QVector v = {0, 1, 2};
>QVector::iterator it = v.begin();
>const QVector v2 = v;
>*it = 1;
>assert(v2.front() == 0); // boom
> 
> It's a general peril when working with C++.

I’m actually not arguing against the use of auto in principle. But I’m arguing 
against introducing auto because it (supposedly?) makes the code safe(r). (That 
context has unfortunately been cut off from the mail at some point.)
C++ is complicated, and type deduction and its results are no exception.
If you know what you are doing, auto can make code more readable and easier to 
write, especially with templated code.
When it makes code more readable or not tends to be pretty subjective it seems, 
so IMO someone just has to decide :)

> Reminds me of the 1970s when we got a law requiring the use of the seat-belt 
> in cars in Germany. My uncle used to tell the story how one of his friends 
> survived a crash because he was ejected from the car since he was _not_ 
> buckled up, just to follow up with the story how another friend was not 
> harmed 
> in a crash because he _was_ strapped in...

Not sure what you want to say with this analogy.
Anyhow, discussions about pros and cons are still necessary. I’m sure that 
there are laws in Germany that supposedly increase security but effectively 
don’t.
I would require that the decision to introduce a law requiring the use of 
seat-belts was based on extensive studies on how seat belts increase or 
decrease the security of a car’s occupants, and how they need to be designed to 
achieve that best. And not on stories at the bar, of how one or the other 
person was either saved or doomed by a seat belt, which you seem to be reminded 
of by the discussion here? ;)

-- 
Eike Ziller, Senior Software Engineer - The Qt Company GmbH
 
The Qt Company GmbH, Rudower Chaussee 13, D-12489 Berlin
Geschäftsführer: Mika Pälsi, Juha Varelius, Tuula Haataja
Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 
144331 B

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

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

[Bubke Marco]

I think in the end we will look if it is easier to implement something similar. 
It's a tradeoff. 


On December 22, 2015 13:06:42 Konstantin Tokarev <annu...@yandex.ru> wrote:

> 22.12.2015, 14:50, "Bubke Marco" <marco.bu...@theqtcompany.com>:
>> Clazy is nice but it's under GPL so it's not possible to integrate it in the 
>> creator clang code model. But I think we need something like clazy for the 
>> clang code model too.
>
> I see at least 2 options how to integrate clazy:
>
> 1. Include it as a separate GPL-only plugin, users of commercial edition will 
> be able to install it separately. If that's too cumbersome to separate this 
> checks from code model, guard them with ifdefs so Clang plugin could be 
> compiled as GPL or as LGPL

I don't think it is feasible but you must ask lawyers about that. 
>
> 2. Just use it as external tool and parse its output.

Sorry,  this is not how the code models works. It would be much easier to 
reimplement the functionality of clazy. 
>
>>
>> 
>> From: Development <development-boun...@qt-project.org> on behalf of Giuseppe 
>> D'Angelo <giuseppe.dang...@kdab.com>
>> Sent: Tuesday, December 22, 2015 11:59 AM
>> To: development@qt-project.org
>> Subject: Re: [Development] RFC: more liberal 'auto' rules?
>>
>> Il 22/12/2015 11:26, Ziller Eike ha scritto:
>>>  So funny/unwanted behavior can occur both because one used the wrong 
>>> explicit type, and because one used auto instead of an explicit type.
>>
>> These shortcomings of auto are recognized in the community, but yes,
>> they're real and dangerous. Clazy [1] already has a warning for the
>> danger of auto with QStringBuilder, I guess it can be extended to other
>> cases.
>>
>> N4035 [2] proposes general purpose workarounds ("operator auto",
>> specializations to std::decay, etc.) to address these issues.
>>
>>>  [1] https://github.com/KDE/clazy/blob/master/README
>>>  [2] http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4035.pdf
>>
>> My 2 c,
>> --
>> Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Software Engineer
>> KDAB (UK) Ltd., a KDAB Group company | Tel: UK +44-1625-809908
>> KDAB - The Qt Experts
>>
>> ___
>> Development mailing list
>> Development@qt-project.org
>> http://lists.qt-project.org/mailman/listinfo/development
>
> -- 
> Regards,
> Konstantin
Sent from cellphone 
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

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

[Konstantin Tokarev]

22.12.2015, 14:50, "Bubke Marco" <marco.bu...@theqtcompany.com>:
> Clazy is nice but it's under GPL so it's not possible to integrate it in the 
> creator clang code model. But I think we need something like clazy for the 
> clang code model too.

I see at least 2 options how to integrate clazy:

1. Include it as a separate GPL-only plugin, users of commercial edition will 
be able to install it separately. If that's too cumbersome to separate this 
checks from code model, guard them with ifdefs so Clang plugin could be 
compiled as GPL or as LGPL

2. Just use it as external tool and parse its output.


>
> 
> From: Development <development-boun...@qt-project.org> on behalf of Giuseppe 
> D'Angelo <giuseppe.dang...@kdab.com>
> Sent: Tuesday, December 22, 2015 11:59 AM
> To: development@qt-project.org
> Subject: Re: [Development] RFC: more liberal 'auto' rules?
>
> Il 22/12/2015 11:26, Ziller Eike ha scritto:
>>  So funny/unwanted behavior can occur both because one used the wrong 
>> explicit type, and because one used auto instead of an explicit type.
>
> These shortcomings of auto are recognized in the community, but yes,
> they're real and dangerous. Clazy [1] already has a warning for the
> danger of auto with QStringBuilder, I guess it can be extended to other
> cases.
>
> N4035 [2] proposes general purpose workarounds ("operator auto",
> specializations to std::decay, etc.) to address these issues.
>
>>  [1] https://github.com/KDE/clazy/blob/master/README
>>  [2] http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4035.pdf
>
> My 2 c,
> --
> Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Software Engineer
> KDAB (UK) Ltd., a KDAB Group company | Tel: UK +44-1625-809908
> KDAB - The Qt Experts
>
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development

-- 
Regards,
Konstantin
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

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

[Konstantin Tokarev]

22.12.2015, 15:48, "Bubke Marco" <marco.bu...@theqtcompany.com>:
> I think in the end we will look if it is easier to implement something 
> similar. It's a tradeoff.
>
> On December 22, 2015 13:06:42 Konstantin Tokarev <annu...@yandex.ru> wrote:
>
>>  22.12.2015, 14:50, "Bubke Marco" <marco.bu...@theqtcompany.com>:
>>>  Clazy is nice but it's under GPL so it's not possible to integrate it in 
>>> the creator clang code model. But I think we need something like clazy for 
>>> the clang code model too.
>>
>>  I see at least 2 options how to integrate clazy:
>>
>>  1. Include it as a separate GPL-only plugin, users of commercial edition 
>> will be able to install it separately. If that's too cumbersome to separate 
>> this checks from code model, guard them with ifdefs so Clang plugin could be 
>> compiled as GPL or as LGPL
>
> I don't think it is feasible but you must ask lawyers about that.
>>  2. Just use it as external tool and parse its output.
>
> Sorry, this is not how the code models works.

I've meant to use it as static analyzer, not part of code model in this case.

 It would be much easier to reimplement the functionality of clazy.
>>>  
>>>  From: Development <development-boun...@qt-project.org> on behalf of 
>>> Giuseppe D'Angelo <giuseppe.dang...@kdab.com>
>>>  Sent: Tuesday, December 22, 2015 11:59 AM
>>>  To: development@qt-project.org
>>>  Subject: Re: [Development] RFC: more liberal 'auto' rules?
>>>
>>>  Il 22/12/2015 11:26, Ziller Eike ha scritto:
>>>>   So funny/unwanted behavior can occur both because one used the wrong 
>>>> explicit type, and because one used auto instead of an explicit type.
>>>
>>>  These shortcomings of auto are recognized in the community, but yes,
>>>  they're real and dangerous. Clazy [1] already has a warning for the
>>>  danger of auto with QStringBuilder, I guess it can be extended to other
>>>  cases.
>>>
>>>  N4035 [2] proposes general purpose workarounds ("operator auto",
>>>  specializations to std::decay, etc.) to address these issues.
>>>
>>>>   [1] https://github.com/KDE/clazy/blob/master/README
>>>>   [2] http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4035.pdf
>>>
>>>  My 2 c,
>>>  --
>>>  Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Software Engineer
>>>  KDAB (UK) Ltd., a KDAB Group company | Tel: UK +44-1625-809908
>>>  KDAB - The Qt Experts
>>>
>>>  ___
>>>  Development mailing list
>>>  Development@qt-project.org
>>>  http://lists.qt-project.org/mailman/listinfo/development
>>
>>  --
>>  Regards,
>>  Konstantin
>
> Sent from cellphone

-- 
Regards,
Konstantin
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

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

[Marc Mutz]

On Tuesday 22 December 2015 13:42:06 Ziller Eike wrote:
> > On Dec 22, 2015, at 1:28 PM, Marc Mutz  wrote:
> > 
> > On Tuesday 22 December 2015 11:26:40 Ziller Eike wrote:
> >> We have something similar in Qt:
> >>QString a = "ABC";
> >>QString b = "abc";
> >>auto result = a + b;
> >>a.replace("A", "C");
> >>qDebug() << result;
> >> 
> >> prints “CBCabc” instead of “ABCabc” when QT_USE_FAST_OPERATOR_PLUS is
> >> defined, because result is not a QString in that case.
> >> 
> >> So funny/unwanted behavior can occur both because one used the wrong
> >> explicit type, and because one used auto instead of an explicit type.
> > 
> > This is not specific to auto, though:
> >QStringView v = QLatin1Char('a');
> >const char *data = str.toLatin1(); // implicit conversion by default
> >QLatin1String l1 = str.toLatin1();
> >QVector v = {0, 1, 2};
> >QVector::iterator it = v.begin();
> >const QVector v2 = v;
> >*it = 1;
> >assert(v2.front() == 0); // boom
> > 
> > It's a general peril when working with C++.
> 
> I’m actually not arguing against the use of auto in principle. But I’m
> arguing against introducing auto because it (supposedly?) makes the code
> safe(r). (That context has unfortunately been cut off from the mail at
> some point.) C++ is complicated, and type deduction and its results are no
> exception. If you know what you are doing, auto can make code more
> readable and easier to write, especially with templated code. When it
> makes code more readable or not tends to be pretty subjective it seems, so
> IMO someone just has to decide :)
> 
> > Reminds me of the 1970s when we got a law requiring the use of the
> > seat-belt in cars in Germany. My uncle used to tell the story how one of
> > his friends survived a crash because he was ejected from the car since
> > he was _not_ buckled up, just to follow up with the story how another
> > friend was not harmed in a crash because he _was_ strapped in...
> 
> Not sure what you want to say with this analogy.
> Anyhow, discussions about pros and cons are still necessary. I’m sure that
> there are laws in Germany that supposedly increase security but
> effectively don’t. I would require that the decision to introduce a law
> requiring the use of seat-belts was based on extensive studies on how seat
> belts increase or decrease the security of a car’s occupants, and how they
> need to be designed to achieve that best. And not on stories at the bar,
> of how one or the other person was either saved or doomed by a seat belt,
> which you seem to be reminded of by the discussion here? ;)

It was just a story I was reminded of, but if you want an interpretation:

It's a reminder about how progress always needs to overcome the status quo. 
And about how humans rate personal experience (first hand, or perceived through 
third parties) higher than statistics.

You can see it over and over again here:

QList is a mistake, but people will try to find ways to argue that it's useful 
because they have this one contrieved use-case where it outperforms vector:

   struct payload { char data[1024]; };
   QList l(1);
   l.pop_front();

, say.

nullptr is obviously a better alternative than 0 or NULL, but people argue 
that there's this one corner of the huge C++ design space where nullptr 
doesn't add value over 0. Why should I learn a complicated rule if there's a 
simple one: always use nullptr?

Adding const to local variables is very important in a world of implicitly-
shared types, you can see the asm getting simpler, sometimes radically so, by 
just adding const when it avoids detaches, but people deny adding const as a 
drive-by and disallow commits that just add const without some kind of 
performance analysis).

I don't know whether auto creates more harm than it fixes. What I _do_ know is 
that it makes it much easier to write efficient code, because you _do_ think 
twice whether to submit something like

for (QHash::const_iterator
 it = m_veryExpressiveName.constBegin(),
 end = m_veryExpressiveName.constEnd();
 it != end; ++it)

as a replacement of

foreach(const QLongTypeName , m_veryExpressiveName.keys()) {
const QEvenLongerTypeName  = m_veryExpressiveName.value(key);

but not if you can say

for (auto it = m_veryExpressiveName.cbegin(), end = 
m_veryExpressiveName.cend(); it != end; ++it)

(yes, this use is uncontended, but this one isn't:

foreach(const QString  : someLongExpression()->fooBar().names())

const auto strings = someLongExpression()->fooBar().names();
for (const QString  : strings)

, but is essentially the same).

Thanks,
Marc

-- 
Marc Mutz  | Senior Software Engineer
KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
Tel: +49-30-521325470
KDAB - The Qt Experts
___
Development mailing list
Development@qt-project.org

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

[Sergio Martins]

On Tuesday, 22 December 2015 15:06:34 WET Konstantin Tokarev wrote:
> 22.12.2015, 14:50, "Bubke Marco" :
> > Clazy is nice but it's under GPL so it's not possible to integrate it in
> > the creator clang code model. But I think we need something like clazy
> > for the clang code model too.
> I see at least 2 options how to integrate clazy:
> 
> 1. Include it as a separate GPL-only plugin, users of commercial edition
> will be able to install it separately. If that's too cumbersome to separate
> this checks from code model, guard them with ifdefs so Clang plugin could
> be compiled as GPL or as LGPL
> 
> 2. Just use it as external tool and parse its output.

3. Change clazy's license to LGPL


Regards,
-- 
Sérgio Martins | sergio.mart...@kdab.com | Software Engineer
Klarälvdalens Datakonsult AB, a KDAB Group company
Tel: Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322)
KDAB - The Qt Experts
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

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

[Matthew Woehlke]

On 2015-12-22 09:50, Marc Mutz wrote:
> foreach(const QString  : someLongExpression()->fooBar().names())
> 
> const auto strings = someLongExpression()->fooBar().names();
> for (const QString  : strings)

On that note, is there any case in which Q_FOREACH is superior to a
range-based for? (Besides the obvious one where the original list is
modified from within the loop?)

-- 
Matthew

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

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

[Matthew Woehlke]

On 2015-12-22 05:26, Ziller Eike wrote:
> So, directly after the above example in Item 5, Item 6 in Effective
> Modern C++ continues with the examples of how you can shoot yourself
> in the foot _because_ you used auto. [...]
> 
> We have something similar in Qt:
> 
> QString a = "ABC";
> QString b = "abc";
> auto result = a + b;
> a.replace("A", "C");
> qDebug() << result;
> 
> prints “CBCabc” instead of “ABCabc” when QT_USE_FAST_OPERATOR_PLUS is
> defined, because result is not a QString in that case.

Someone ought to note... one of the arguments for AAA is that it avoids
uninitialized variables. It's actually still AAA to write:

  auto result = QString{a + b};

...and in fact that is what AAA recommends when you need to ensure a
specific type.

-- 
Matthew

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

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

[Olivier Goffart]

On Saturday 5. December 2015 00:57:23 Bubke Marco wrote:
> > You are basically assuming that there's no need for you to write sane
> > code to start with because during your development work you have a
> > decent IDE to help you out. This assumption is wrong, independent
> > of the existence of such an IDE.
> > 
> > Since the discussion here is about what to use in Qt, the whole Qt
> > development workflow matters. A lot of Qt code reading happens on Gerrit
> > without IDE features at hand. The context there usually just a few lines.
> > The appropriateness of an expression 'list[x]' is impossible to judge
> > on Gerrit after applying an 'Almost always auto' policy.
> 
> Oswald and I spoke about using the clang code model to provide the
> information to gerrit too. It should be not that hard.
> 
> But you have to import the code in the IDE anyway because of the missing
> context.  For non trivial change review the calling context is far to
> important to be ignored. A html code browser could change that but we don't
> have one in gerrit.

I have made a user script to integrate http://code.woboq.org/qt5/ with gerrit.

With that script, you can just click on a function in the code on gerrit and 
it will lookup in the code.woboq.org database and show the signature in a 
tooltip and links to code.woboq.org. (It shows a disambiguation popup if there 
are several possibilities.)
It also makes the filename in the header of the diff clickable to the 
corresponding file on code.woboq.org

Look at this screenshot: http://i.imgur.com/Q3a2ixz.png 
When you see the signature you can see the return type. And had 'auto' been 
used there, we would have known it's a QUrl. 

This does not work for all functions, but should already be of a great help 
when reviewing.

The user script is there: 
   https://code.woboq.org/qt-gerrit.user.js
You can use it with the Greasmonkey extension on Firefox or the Tampermonkey 
extension on Chrome, or whatever equivalent extension for your browser.

If qt-project's admins think it's a good idea they could enable it by default.

-- 
Olivier 

Woboq - Qt services and support - http://woboq.com - http://code.woboq.org

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

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

[Giuseppe D'Angelo]

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,
-- 
Giuseppe D'Angelo
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

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

[Knoll Lars]

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 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 side-line without having read the
>> thread's first mail...
>> 
>actually, it's quite reasonable to take someone by their word when they
>make such an effort to emphasize it without further qualification.
>
>> I don't *care* whether it's "var" or no keyword or JS variant or
>> _whatever_. I said it's about the omission of the _type name_.
>>
>you're still not getting it. python's property of omitting the type name
>is *inherently* linked to it being dynamic. it's *meaningless* to
>compare the two. you're essentially arguing that auto is *just* like
>QVariant because it shares some of the visible properties. how is that
>an argument for *anything*?
>
>> You deliberately misunderstand and drag this subthread on and then
>> zoom in on the first slip of mine. That's trolling at it's worst.
>> 
>i didn't misunderstand anything (deliberately or not), and didn't
>present it as such, either. all i did was pointing out that the analogy
>wasn't that apt, and that your "joke" actually backfired. *you* dragged
>it out by deciding to treat me like an idiot instead of trying to
>understand and acknowledge the point (however trivial you may find it).
>
>> > so let's state the purpose even more clearly: i'm giving you a lesson.
>> 
>> I should have known tr(Besserwisser).
>> 
>i'm sure the irony of *you* saying that is momentarily lost on you.

And I’d say it’s about time to stop that particular sub-thread. It’s neither 
productive nor leading anywhere.

Thanks,
Lars

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

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

[Oswald Buddenhagen]

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 side-line without having read the
> thread's first mail...
> 
actually, it's quite reasonable to take someone by their word when they
make such an effort to emphasize it without further qualification.

> I don't *care* whether it's "var" or no keyword or JS variant or
> _whatever_. I said it's about the omission of the _type name_.
>
you're still not getting it. python's property of omitting the type name
is *inherently* linked to it being dynamic. it's *meaningless* to
compare the two. you're essentially arguing that auto is *just* like
QVariant because it shares some of the visible properties. how is that
an argument for *anything*?

> You deliberately misunderstand and drag this subthread on and then
> zoom in on the first slip of mine. That's trolling at it's worst.
> 
i didn't misunderstand anything (deliberately or not), and didn't
present it as such, either. all i did was pointing out that the analogy
wasn't that apt, and that your "joke" actually backfired. *you* dragged
it out by deciding to treat me like an idiot instead of trying to
understand and acknowledge the point (however trivial you may find it).

> > so let's state the purpose even more clearly: i'm giving you a lesson.
> 
> I should have known tr(Besserwisser).
> 
i'm sure the irony of *you* saying that is momentarily lost on you.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

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

[Bubke Marco]

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) references in for loops (which are 
"const " for "const values"):

for (auto & : values)

or

for (const auto  : values)

to show the difference to

for (auto  : values)

From: Development <development-boun...@qt-project.org> on behalf of Knoll Lars 
<lars.kn...@theqtcompany.com>
Sent: Wednesday, December 09, 2015 1:18 PM
To: Giuseppe D'Angelo
Cc: development@qt-project.org
Subject: Re: [Development] RFC: more liberal 'auto' rules?

On 09/12/15 11:19, "Giuseppe D'Angelo" <dange...@gmail.com> wrote:



>On Wed, Dec 9, 2015 at 11:16 AM, Knoll Lars <lars.kn...@theqtcompany.com> 
>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, I was only asking to stop the off topic part of the 
discussion (about python and who’s right there). Let’s focus on auto in c++ and 
how we want to use it.

>
>Is there a consensus otherwise about a more liberal use of auto in our
>source code?

I don’t think there is a full consensus. 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. The problem is that there’s dissent in what 
‘more readable code’ is in practice.

I think everybody also agrees one the use cases listed in 
https://wiki.qt.io/Coding_Conventions#auto_Keyword , so the question now is 
what additional use cases do most of us agree to? And how to put that into 
rules, as a listing with 50 entries won’t help anybody.

While I don’t think we should go and implement aaa right now, I would probably 
be ok with a somewhat broader usage than the current coding conventions imply.

Marc presented some use cases. Going through those, I don’t think I heard any 
disagreement about using auto in template, so I think we can probably add that 
one to our guidelines.

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; ++i)’.

Are these cases something we can agree upon?

Cheers,
Lars

___
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] RFC: more liberal 'auto' rules?

[Knoll Lars]

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, I was only asking to stop the off topic part of the 
discussion (about python and who’s right there). Let’s focus on auto in c++ and 
how we want to use it.

>
>Is there a consensus otherwise about a more liberal use of auto in our
>source code?

I don’t think there is a full consensus. 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. The problem is that there’s dissent in what 
‘more readable code’ is in practice. 

I think everybody also agrees one the use cases listed in 
https://wiki.qt.io/Coding_Conventions#auto_Keyword , so the question now is 
what additional use cases do most of us agree to? And how to put that into 
rules, as a listing with 50 entries won’t help anybody.

While I don’t think we should go and implement aaa right now, I would probably 
be ok with a somewhat broader usage than the current coding conventions imply. 

Marc presented some use cases. Going through those, I don’t think I heard any 
disagreement about using auto in template, so I think we can probably add that 
one to our guidelines. 

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; ++i)’. 

Are these cases something we can agree upon?

Cheers,
Lars

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

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

[Poenitz Andre]

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. The problem is that there’s dissent
> in what ‘more readable code’ is in practice.
> 
> I think everybody also agrees one the use cases listed in 
> https://wiki.qt.io/Coding_Conventions#auto_Keyword , so the question now 
> is what additional use cases do most of us agree to? 
> 
> And how to put that into rules, as a listing with 50 entries won’t help 
> anybody.

I agree with that so far.

> While I don’t think we should go and implement aaa right now, I would 
> probably 
> be ok with a somewhat broader usage than the current coding conventions imply.

> Marc presented some use cases. Going through those, I don’t think I heard 
> any disagreement about using auto in template, so I think we can probably
> add that one to our guidelines.

Marc's proposal included to *require* use of "auto" in some cases.

I do not agree with that *required* use at all. That's not just because "auto 
is required in templates" would give the AAA supporters suddenly
a big incentive to start writing or converting normal functions to templates 
just because they can use auto freely there, but since I don't believe visible 
types are bad per-se and far less of a "problem" than the AAA faction tries 
to make me believe.

I would accept (and probably use myself) "optional use of auto" for

- *some* template code (e.g. the mentioned 'typename' case)
- references to elements in a collection *with "non-trivial" type*, i.e.
  something that is a template instance, or in deeply nested namespaces.
  (i.e. ok for  std::pair, not ok for 'int' or 'QString')

Marc's *optional* proposal "Optional use of auto: whereever it makes sense. 
Use your own judgement, but remember: fear is a bad advisor." pretty much
opens the door for AAA, as for an AAA supporter "auto" will *always* make
sense.

So effectively the proposal consists of two attempts to implement an AAA
policy. That's going way too far in one step.

Andre'
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

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

[Marc Mutz]

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  =
   auto  =
   auto e =
   const auto e =

But that's just the level of auto that _I_ feel comfortable with. YMMV.

Thanks,
Marc

-- 
Marc Mutz  | Senior Software Engineer
KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
Tel: +49-30-521325470
KDAB - The Qt Experts
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

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

[Matthew Woehlke]

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
> 
> for (const auto  : values)
> 
> to show the difference to
> 
> for (auto  : values)

I personally prefer making everything I can 'const'. That means 'const&'
returns from functions ("forces" a copy elision), 'const' local
variables, etc.. In the case of loops like the above, if I'm not going
to modify the value, I prefer to say so. If I *am* going to modify it, I
prefer 'auto&' to a) also say so, and b) statically ensure that I *can*.

That's just my 2¢ however; I'd be interested in hearing arguments for
'auto&&'.

-- 
Matthew

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

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

[Matthew Woehlke]

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; ++i)’.

For the record, while I still think 'for (auto const i :
qIndexRange(list.count()))' is better, my objection here isn't so much
to failing to mandate 'auto' in such cases as forbidding it entirely in
such cases. 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'.

-- 
Matthew

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

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

[Rolland Dudemaine]

>> 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?

I've always been a fan of Qt, not because of its conciseness,
portability, versatility (although these help), but really because a C++
beginner, a seasoned C engineer unfamiliar with C++, and several other
non-expert types can read and understand the Qt API, and also write
basic applications.

Preaching pragmatism, I'd happily vote for "what's convenient" inside
the Qt implementation, but also vote against the C++11-ification of the API.

Rolland

--
Rolland Dudemaine   tel direct:+33 143 143 702
Green Hills Software   tel:+33 143 143 700
4 rue de la Pierre Leveemailto:roll...@ghs.com
75011 Paris   fax: +33 143 143 707
France web: http://www.ghs.com
--


___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

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

[Marc Mutz]

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 a reason for the Coding Style to restrict their 
use.

We don't restrict the use of other C++ feature, such as do-while loops, 
either, even though they're inherently unreadable. Why do we need detailed, 
point-by-point rules micromanging the use of auto?

The problem with codifying what isn't codifiable (due to lack of consensus in 
the wider C++ community) is that it will set in stone something that should 
grow as understanding grows. Some people are scared of auto, other (_not_ me, 
in case that wasn't clear) want to go to the other extreme: AAA-style. 
Codifying any two of the positions is wrong. Picking something in-between is 
something for people with a crystal ball.

We should _require_ a small set of use-cases, for code consistency, and leave 
the rest for comments in reviews. That only works, of course, if people don't 
start running around -2'ing code just because they think there are too many or 
too few autos in there. It should be the prerogative of the patch author to 
decide, as she's the one doing the work. It's as subjective as variable 
naming, and we also only have very broad guidelines for that.

> 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.

It's ok to discuss things, but discussions on this mailing-list tend to be 
fruitless (there's no conclusion to Thiago's thread "Upgrading the source..." 
from January 2015), tend to be hijacked by people over and over again who are 
"against" every change, the OP getting side-tracked into offside discussions 
(his fault! :), and discouragement for all sides involved.

Please just _decide_. I, for one, pledge to live with the outcome. You heard 
all the arguments. Let's get it over with, and start over with nullptr :) For 
5.8, we can re-open the discussion for auto variables.

Thanks,
Marc

-- 
Marc Mutz  | Senior Software Engineer
KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
Tel: +49-30-521325470
KDAB - The Qt Experts
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

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

[Marc Mutz]

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  | Senior Software Engineer
KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
Tel: +49-30-521325470
KDAB - The Qt Experts
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

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

[Marc Mutz]

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 crwawl when making changes to it and demand 150% of the rates when 
going in.

This whole story of "code is written once, and read many times" is wrong (the 
"once" part). Code should be continuously evolved to stay current. Just try 
compiling Qt 3.x with a current GCC and you will know why.

> I've always been a fan of Qt, not because of its conciseness,
> portability, versatility (although these help), but really because a C++
> beginner, a seasoned C engineer unfamiliar with C++, and several other
> non-expert types can read and understand the Qt API, and also write
> basic applications.
> 
> Preaching pragmatism, I'd happily vote for "what's convenient" inside
> the Qt implementation, but also vote against the C++11-ification of the
> API.

This discussion is not about the Qt API. It is about its implementation.

Thanks,
Marc

-- 
Marc Mutz  | Senior Software Engineer
KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
Tel: +49-30-521325470
KDAB - The Qt Experts
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

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

[Ziller Eike]

> On Dec 7, 2015, at 2:41 PM, Knoll Lars  wrote:
> 
> On 07/12/15 15:44, "Development on behalf of Marc Mutz" 
>  wrote:
> 
> 
> 
>> On Monday 07 December 2015 13:48:58 Ziller Eike wrote:
>>> I do not think that more usage of ‘auto’ will make any code (or
>>> refactorings of it) ‘safer’. IMO this is only about convenience and
>>> readability.
>> 
>> std::map stdMap = ...;
>> 
>> for (const std::pair  : stdMap)
>> doSomething(e.first, e.second);
>> 
>> for (const auto  : stdMap)
>> doSomething(e.first, e.second);
>> 
>> The second loop is at least two orders of magnitude faster (doSomething() is 
>> an out-of-line no-op).
> 
> I think the summary here is that auto gives you one guarantee: It won’t do an 
> implicit conversion for the initial assignment.

Granted.
I really wonder though, why it is possible to assign the wrong type to a 
_reference_ here, even if it is const ?
I cannot do that with e.g. a std::vector (std::vector v; 
const std::vector  = v;), so is that some funny thing with 
std::pair?
The spirit of the “you can use auto when assigning iterator type” was to mean 
“you can use auto when assigning long ugly template types” at least in case of 
‘known patterns' (of which we do not have too many in Qt API, therefore 
iterator types). So I think this use of auto is covered by the “spirit” of the 
rule.

Br, Eike
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

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

[Giuseppe D'Angelo]

Il 08/12/2015 10:46, Ziller Eike ha scritto:

I really wonder though, why it is possible to assign the wrong type to 
a_reference_  here, even if it is const ?
I cannot do that with e.g. a std::vector (std::vector v; const 
std::vector  = v;), so is that some funny thing with std::pair?


Just that std::pair has a constructor performing implicit conversions 
from another pair's types, see the constructors 4/5



http://en.cppreference.com/w/cpp/utility/pair/pair


Those conversions silently succeed and kaboom, you're deep copying 
std::strings...


Cheers,
--
Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Software Engineer
KDAB (UK) Ltd., a KDAB Group company | Tel: UK +44-1625-809908
KDAB - The Qt Experts



smime.p7s
Description: Firma crittografica S/MIME
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

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

[Oswald Buddenhagen]

On Mon, Dec 07, 2015 at 03:39:25PM +0100, Marc Mutz wrote:
> OK, last try:
> 
> - auto everywhere in C++ means that the type of the rhs defines the
> type of the variable
>
it starts with the fact that you didn't specify that you mean just local
variables - it's your unstated assumption. your triple emphasis that
it's not necessary *anywhere* in python implied that you do indeed mean
more than just locals.

> - each variable is still statically typed.
> - In particular, you cannot assign, say, an int to the variable and later
>   assign it a string.

> - in Python, variables are declared with 'var' (IIRC)
>
well, wrong. in python, you don't explicitly declare variables *at all*.
you only ever assign them. just so.

"var" is c#'s auto. or js' variant (aka c#'s "dynamic"). these are
actually the two opposite concepts, so maybe you're the one who's
confused? ;)

> - the simiarity with C++ auto is that no type name is visible
>   - this is what I was referring to
> - the difference to C++ (auto or not) is that in Python, the variable is 
> weakly
>   typed / dynamically typed / duck-typed, however you may want to call it.
> - in particular, the variable can hold an integer first, then a string, and
>   later an object of class type. Conversely, any type can be held in any
>   variable.

>   - this is orthogonal to the omission of the type name, which C++ auto and
> the whole thread is all about, thus *completely irrelevant* to the
> discussion.
>
no, it's actually not orthogonal, and that's the whole point. in the
generic case, it's impossible to implement "auto *everywhere*" without
going dynamic. this is such a fundamental property of the language, that
it is patently absurd to infer anything from it for statically typed
languages, especially if you look at just one particular case.

> I, indeed, have no idea why you ride that particular horse so
> vehemently.
> 
so let's state the purpose even more clearly: i'm giving you a lesson.
you tried to prove your point with a bogus analogy, and screwed up even
more by underestimating the downsides of the paradigm you were comparing
to. just admit it, and we're done - i'm actually convinced by your
non-bogus arguments.

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

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

[Matthew Woehlke]

On 2015-12-08 09:52, Oswald Buddenhagen wrote:
> On Mon, Dec 07, 2015 at 03:39:25PM +0100, Marc Mutz wrote:
>> - auto everywhere in C++ means that the type of the rhs defines the
>> type of the variable
>
> it starts with the fact that you didn't specify that you mean just local
> variables - it's your unstated assumption. your triple emphasis that
> it's not necessary *anywhere* in python implied that you do indeed mean
> more than just locals.

Any variable definitions, actually... not just local, but also member
(static or otherwise) and global. Although IME, AAA is not pushed so
much for other than local variables. (Also, 'auto' for NSDM's requires
compiler support for default initializers, which is less widely
available than 'auto' itself.)

>> - the simiarity with C++ auto is that no type name is visible
>>   - this is what I was referring to
>> - the difference to C++ (auto or not) is that in Python, the variable is 
>> weakly
>>   typed / dynamically typed / duck-typed, however you may want to call it.
>> - in particular, the variable can hold an integer first, then a string, and
>>   later an object of class type. Conversely, any type can be held in any
>>   variable.
>> 
>>   - this is orthogonal to the omission of the type name, which C++ auto and
>> the whole thread is all about, thus *completely irrelevant* to the
>> discussion.
>
> no, it's actually not orthogonal, and that's the whole point. in the
> generic case, it's impossible to implement "auto *everywhere*" without
> going dynamic.

To be clear, the "everywhere" here is limited to variable declarations.
(Which must be definitions. Which is one of the objectives of AAA; it
prevents uninitialized variables.) Function/method parameters are
specifically excluded.

(Although using 'auto' there - which C++ is actually moving to allow,
although I'm not necessarily thrilled by such - is still not dynamic
typing; rather, it is implicit templatization. There are some possible
benefits to this, along the lines of AAA, but overall there are many
more drawbacks.)

-- 
Matthew

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

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

[Marc Mutz]

On Tuesday 08 December 2015 15:52:06 Oswald Buddenhagen wrote:
> On Mon, Dec 07, 2015 at 03:39:25PM +0100, Marc Mutz wrote:
> > OK, last try:
> > 
> > - auto everywhere in C++ means that the type of the rhs defines the
> > type of the variable
> 
> it starts with the fact that you didn't specify that you mean just local
> variables - it's your unstated assumption.

Wrong. This whole thread was never about anything but auto variables:

On Thursday 03 December 2015 19:49:46 Marc Mutz wrote:
> The wiki[1] currently contains some rules for how to use automatic type 
> deduction for variables (Q_C_AUTO_TYPE) that are very restrictive.


> 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 side-line without having read the thread's 
first mail...

 > > - each variable is still statically typed.
> > - In particular, you cannot assign, say, an int to the variable and later
> > 
> >   assign it a string.
> > 
> > - in Python, variables are declared with 'var' (IIRC)
> 
> well, wrong. in python, you don't explicitly declare variables *at all*.
> you only ever assign them. just so.
>
> "var" is c#'s auto. or js' variant (aka c#'s "dynamic"). these are
> actually the two opposite concepts, so maybe you're the one who's
> confused? ;)

I don't *care* whether it's "var" or no keyword or JS variant or _whatever_. I 
said it's about the omission of the _type name_. You deliberately 
misunderstand and drag this subthread on and then zoom in on the first slip of 
mine. That's trolling at it's worst.

> > - the simiarity with C++ auto is that no type name is visible
> > 
> >   - this is what I was referring to
> > 
> > - the difference to C++ (auto or not) is that in Python, the variable is
> > weakly
> > 
> >   typed / dynamically typed / duck-typed, however you may want to call
> >   it.
> > 
> > - in particular, the variable can hold an integer first, then a string,
> > and
> > 
> >   later an object of class type. Conversely, any type can be held in any
> >   variable.
> >   
> >   - this is orthogonal to the omission of the type name, which C++ auto
> >   and
> >   
> > the whole thread is all about, thus *completely irrelevant* to the
> > discussion.
> 
> no, it's actually not orthogonal, and that's the whole point. in the
> generic case, it's impossible to implement "auto *everywhere*" without
> going dynamic. this is such a fundamental property of the language, that
> it is patently absurd to infer anything from it for statically typed
> languages, especially if you look at just one particular case.
> 
> > I, indeed, have no idea why you ride that particular horse so
> > vehemently.
> 
> so let's state the purpose even more clearly: i'm giving you a lesson.
> you tried to prove your point with a bogus analogy, and screwed up even
> more by underestimating the downsides of the paradigm you were comparing
> to. just admit it, and we're done - i'm actually convinced by your
> non-bogus arguments.

I should have known tr(Besserwisser).

Thanks,
Marc

-- 
Marc Mutz  | Senior Software Engineer
KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
Tel: +49-30-521325470
KDAB - The Qt Experts
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

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

[Marc Mutz]

On Monday 07 December 2015 13:48:58 Ziller Eike wrote:
> I do not think that more usage of ‘auto’ will make any code (or
> refactorings of it) ‘safer’. IMO this is only about convenience and
> readability.

  std::map stdMap = ...;

  for (const std::pair  : stdMap)
  doSomething(e.first, e.second);

  for (const auto  : stdMap)
  doSomething(e.first, e.second);

The second loop is at least two orders of magnitude faster (doSomething() is 
an out-of-line no-op).

Thanks,
Marc

-- 
Marc Mutz  | Senior Software Engineer
KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
Tel: +49-30-521325470
KDAB - The Qt Experts
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

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

[Marc Mutz]

On Monday 07 December 2015 13:16:14 Oswald Buddenhagen wrote:
> On Mon, Dec 07, 2015 at 02:05:38PM +0100, Marc Mutz wrote:
> > On Monday 07 December 2015 12:23:41 Oswald Buddenhagen wrote:
> > > On Fri, Dec 04, 2015 at 10:29:09PM +0100, Marc Mutz wrote:
> > > > On Friday 04 December 2015 19:06:51 Oswald Buddenhagen wrote:
> > > > > it's not that anyone is confused, it's that your "aside" was
> > > > > inherently flawed: variables in python are dynamically typed, so
> > > > > the suggestion that they are "auto" in any way related to c++
> > > > > makes no sense whatsoever. my response aimed merely at showing
> > > > > that even your little "joke" was off.
> > > > 
> > > > Again: I was referring to the omission of any form of type name when
> > > > declaring variables. That Python is _also_ dynamically typed is
> > > > correct, but irrelevant.
> > > 
> > > then maybe you want to explain how you want to implement auto
> > > *everywhere* without going dynamic. until you provide a credible answer
> > > to that, your "aside" is patently irrelevant. hint: c# type inference
> > > does *not* provide that answer.
> > 
> > I have explained it as good as I can. If you can or do not want to
> > understand, then I'm sorry that I cannot explain it so you understand.
> 
> have you considered the possibility that *you* are the one who's not
> getting the point? you have not provided *any* sensible argument to
> refute my claim that your analogy is fucked. you just keep repeating
> the obvious.

OK, last try:

- auto everywhere in C++ means that the type of the rhs defines the type of the
  variable
- each variable is still statically typed.
- In particular, you cannot assign, say, an int to the variable and later
  assign it a string.

- in Python, variables are declared with 'var' (IIRC)
- the simiarity with C++ auto is that no type name is visible
  - this is what I was referring to
- the difference to C++ (auto or not) is that in Python, the variable is weakly
  typed / dynamically typed / duck-typed, however you may want to call it.
- in particular, the variable can hold an integer first, then a string, and
  later an object of class type. Conversely, any type can be held in any
  variable.
  - this is orthogonal to the omission of the type name, which C++ auto and
the whole thread is all about, thus *completely irrelevant* to the
discussion. I, indeed, have no idea why you ride that particular horse so
vehemently.

Thanks,
Marc

-- 
Marc Mutz  | Senior Software Engineer
KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
Tel: +49-30-521325470
KDAB - The Qt Experts
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

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

[Matthew Woehlke]

On 2015-12-05 06:08, Julien Blanc wrote:
> Am I the only one to think that this example is inherently broken ? I
> mean, why wouldn’t any sane person write :
> 
> for(auto const& element : list)
> foo(element)

If you don't actually *need* the index, then yes. "Broken" might be
strong, but yes, the example is somewhat lacking. A better example would be:

  foo(i, list[i]);

(And yes, if you don't need the index, *please do* iterate over the
elements directly!)

> On 2015-12-03 13:49, Marc Mutz wrote:
>> - all loop variables (both index and iterators)
>>   the reason being that spelling out the name is usually wrong:
>>  size_t i = stdVector.size() // wrong, should be
>>  std::vector::size_type...
>>  also helps when porting from Qt containers to STL ones
> 
> That looks perfectly fine for me. Index based loops should be avoided
> whenever it is possible, and for iterator based loops auto makes no harm
> (seriously, who wants to write
> std::vector::const_iterator instead of auto ?).

Agreed. But the above started with objections to using 'auto' for
indexed iteration :-).

-- 
Matthew

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

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

[Marc Mutz]

On Thursday 03 December 2015 19:49:46 Marc Mutz wrote:
> The remainder of the C++ world is moving towards an "always auto" scheme.
> We  don't need to go there, but I'd at least like to propose, for new code
> and as a drive-by, the required use of auto for:
> 
> - template code (esp., but not necessarily only, when the type name would
>   require the use of 'typename')
> - all loop variables (both index and iterators)
>   the reason being that spelling out the name is usually wrong:
>   size_t i = stdVector.size() // wrong, should be std::vector::size_type...
>   also helps when porting from Qt containers to STL ones
> - all references to elements in a collection (same problem - way too easy
> to misspell std::pair for std::pair...)

Let me extend that:

- whenever possible when declaring a QList
  It seems like we all agree that QList as-is will not be in Qt 6[1]. To me,
  it sounds prudent to anticipate that and to hold QList (whereever possible)
  in auto variables only, so they port themselves automatically (no pun
  intended) to, say, QVector, std::vector, or QArrayList.

[1] Before you flame again: Independant of the exit strategy, it should be 
consensus that the *name* QList will only exist as a porting vehicle 
(deprecated class or deprecated template alias or something entirely 
different). Whether the actual implementation lives on as QArrayList (say) is 
orthogonal to that.

Thanks,
Marc

-- 
Marc Mutz  | Senior Software Engineer
KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
Tel: +49-30-521325470
KDAB - The Qt Experts
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

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

[Mathias Hasselmann]

Am 07.12.2015 um 15:39 schrieb Marc Mutz:

- auto everywhere in C++ means that the type of the rhs defines the type of the
   variable


To the extreme of having:

auto x = Type { init };

Instead of:

Type x(init);

...if you follow Herb Sutter to the extreme[1]. It feels quite extreme 
in the first moment, but undeniable has some inner logic if you read 
that article to the end. I am undecided by myself still since that 
proposal is that extreme. Well, but this could just mean I am getting 
old and inflexible.


[1]: 
http://herbsutter.com/2013/08/12/gotw-94-solution-aaa-style-almost-always-auto/

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

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

[Marc Mutz]

On Monday 07 December 2015 14:41:00 Knoll Lars wrote:
> On 07/12/15 15:44, "Development on behalf of Marc Mutz"  wrote:
> >On Monday 07 December 2015 13:48:58 Ziller Eike wrote:
> >> I do not think that more usage of ‘auto’ will make any code (or
> >> refactorings of it) ‘safer’. IMO this is only about convenience and
> >> readability.
> >> 
> >  std::map stdMap = ...;
> >  
> >  for (const std::pair  : stdMap)
> >  
> >  doSomething(e.first, e.second);
> >  
> >  for (const auto  : stdMap)
> >  
> >  doSomething(e.first, e.second);
> >
> >The second loop is at least two orders of magnitude faster (doSomething()
> >is an out-of-line no-op).
> 
> I think the summary here is that auto gives you one guarantee: It won’t do
> an implicit conversion for the initial assignment.

Correct. The first line is missing the const in the pair's first type, thus 
forces an implicit conversion to the declared type (the const-& conveniently 
extending the lifetime of the temporary so everything appears to work, execept 
you're deep-copying two std::strings now).

-- 
Marc Mutz  | Senior Software Engineer
KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
Tel: +49-30-521325470
KDAB - The Qt Experts
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

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

[Knoll Lars]

On 07/12/15 15:44, "Development on behalf of Marc Mutz" 
 wrote:



>On Monday 07 December 2015 13:48:58 Ziller Eike wrote:
>> I do not think that more usage of ‘auto’ will make any code (or
>> refactorings of it) ‘safer’. IMO this is only about convenience and
>> readability.
>
>  std::map stdMap = ...;
>
>  for (const std::pair  : stdMap)
>  doSomething(e.first, e.second);
>
>  for (const auto  : stdMap)
>  doSomething(e.first, e.second);
>
>The second loop is at least two orders of magnitude faster (doSomething() is 
>an out-of-line no-op).

I think the summary here is that auto gives you one guarantee: It won’t do an 
implicit conversion for the initial assignment.

Cheers,
Lars

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

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

[Matthew Woehlke]

On 2015-12-07 07:48, Ziller Eike wrote:
> On Dec 4, 2015, at 8:01 PM, Olivier Goffart wrote:
>> Because the type is redundent and it's one reason less to make errors:
>> Using 'int' instead of 'quint64' or 'size_t', or QString instead of 
>> QByteArray 
>> is way to frequent. (and the compiler won't complain)
> 
> The compiler will then still not complain if you pass that ‘auto’
> variable to a function taking ‘int’ (or QString, if you don’t have
> NO_CAST_...), will it?

...it won't complain any *less* than if you'd done the cast in an
assignment. But it *might* complain, e.g. if you use the auto in an
initializer list that results in narrowing. Or it might call an
appropriate function overload for the larger type.

At worst, is equally dangerous. But in some cases it will be less dangerous.

Another argument is that the correct way to use 'int' is:

  auto i = int{list.size()};

...which will fail to compile if a narrowing conversion occurs. (Or if
you're *truly* paranoid, use 'auto' and then static_assert the actual
resulting type.)

-- 
Matthew

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

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

[Marc Mutz]

On Monday 07 December 2015 17:28:53 Thiago Macieira wrote:
> On Monday 07 December 2015 17:42:50 Marc Mutz wrote:
> > > >  std::map stdMap = ...;
> > > >  
> > > >  for (const std::pair  : stdMap)
> > > >  
> > > >  doSomething(e.first, e.second);
> > > >  
> > > >  for (const auto  : stdMap)
> > > >  
> > > >  doSomething(e.first, e.second);
> > > >
> > > >The second loop is at least two orders of magnitude faster
> > > >(doSomething() is an out-of-line no-op).
> > > 
> > > I think the summary here is that auto gives you one guarantee: It won’t
> > > do an implicit conversion for the initial assignment.
> > 
> > Correct. The first line is missing the const in the pair's first type,
> > thus forces an implicit conversion to the declared type (the const-&
> > conveniently extending the lifetime of the temporary so everything
> > appears to work, execept you're deep-copying two std::strings now).
> 
> What const is missing? Are you saying it should have been
> 
>   for (const std::pair : stdMap)

Yes.

> If so, I consider that an API defect in std::map or an implementation
> defect in std::string in the first place.

It is not an API defect, it is necessary to preserve class invariants 
(maintain sort order).

> It wouldn't cause a magnitude of
> performance difference if they were implicitly shared, like QString.

No comment...

Thanks,
Marc

-- 
Marc Mutz  | Senior Software Engineer
KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
Tel: +49-30-521325470
KDAB - The Qt Experts
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

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

[Thiago Macieira]

On Monday 07 December 2015 17:53:41 Olivier Goffart wrote:
> On Monday 7. December 2015 08:28:53 Thiago Macieira wrote:
> > What const is missing? Are you saying it should have been
> > 
> > for (const std::pair : stdMap)
> 
> Yes.
> 
> The value_type of a std::map  is std::pair.
> 
> It allows to do this:
> 
>// add "foobar" to all the entries
>for (auto : stdMap)
>  e.second += "foobar";
> 
> But it does not allow to change the key because that cannot be changed via
> an iterator.

Ah, right, this is a *mutating* iterator. Sorry, I missed that fact.

I was thinking of the usual read-only iteration that we get from foreach. 
Mutating with a range for is something I've never done.

> > If so, I consider that an API defect in std::map
> 
> Quite the contrary.

I stand corrected.

-- 
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

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

[Olivier Goffart]

On Monday 7. December 2015 08:28:53 Thiago Macieira wrote:
> What const is missing? Are you saying it should have been
> 
>   for (const std::pair : stdMap)

Yes.

The value_type of a std::map  is std::pair.

It allows to do this:

   // add "foobar" to all the entries
   for (auto : stdMap)
 e.second += "foobar";

But it does not allow to change the key because that cannot be changed via an 
iterator.  

> If so, I consider that an API defect in std::map 

Quite the contrary.

> or an implementation defect in std::string in the first place. It wouldn't
> cause a magnitude of performance difference if they were implicitly shared,
> like QString.

That's another issue.

-- 
Olivier 

Woboq - Qt services and support - http://woboq.com - http://code.woboq.org


___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

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

[Thiago Macieira]

On Monday 07 December 2015 17:42:50 Marc Mutz wrote:
> > >  std::map stdMap = ...;
> > >  
> > >  for (const std::pair  : stdMap)
> > >  
> > >  doSomething(e.first, e.second);
> > >  
> > >  for (const auto  : stdMap)
> > >  
> > >  doSomething(e.first, e.second);
> > >
> > >The second loop is at least two orders of magnitude faster (doSomething()
> > >is an out-of-line no-op).
> > 
> > I think the summary here is that auto gives you one guarantee: It won’t do
> > an implicit conversion for the initial assignment.
> 
> Correct. The first line is missing the const in the pair's first type, thus
> forces an implicit conversion to the declared type (the const-& conveniently
> extending the lifetime of the temporary so everything appears to work,
> execept you're deep-copying two std::strings now).

What const is missing? Are you saying it should have been

for (const std::pair : stdMap)

If so, I consider that an API defect in std::map or an implementation defect 
in std::string in the first place. It wouldn't cause a magnitude of performance 
difference if they were implicitly shared, like QString.

-- 
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

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

[Thiago Macieira]

On Monday 07 December 2015 17:50:41 Marc Mutz wrote:
> [1] Before you flame again: Independant of the exit strategy, it should be 
> consensus that the *name* QList will only exist as a porting vehicle 
> (deprecated class or deprecated template alias or something entirely 
> different). Whether the actual implementation lives on as QArrayList (say)
> is  orthogonal to that.

Yes, we are in agreement. There will be a "QList" in Qt 6, but not with its 
current memory layout. How we'll implement it, that's a discussion for another 
day.

-- 
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

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

[Oswald Buddenhagen]

On Fri, Dec 04, 2015 at 10:29:09PM +0100, Marc Mutz wrote:
> On Friday 04 December 2015 19:06:51 Oswald Buddenhagen wrote:
> > it's not that anyone is confused, it's that your "aside" was
> > inherently flawed: variables in python are dynamically typed, so the
> > suggestion that they are "auto" in any way related to c++ makes no
> > sense whatsoever. my response aimed merely at showing that even your
> > little "joke" was off.
> 
> Again: I was referring to the omission of any form of type name when
> declaring variables. That Python is _also_ dynamically typed is
> correct, but irrelevant. 
>
then maybe you want to explain how you want to implement auto
*everywhere* without going dynamic. until you provide a credible answer
to that, your "aside" is patently irrelevant. hint: c# type inference
does *not* provide that answer.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

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

[Oswald Buddenhagen]

On Mon, Dec 07, 2015 at 02:05:38PM +0100, Marc Mutz wrote:
> On Monday 07 December 2015 12:23:41 Oswald Buddenhagen wrote:
> > On Fri, Dec 04, 2015 at 10:29:09PM +0100, Marc Mutz wrote:
> > > On Friday 04 December 2015 19:06:51 Oswald Buddenhagen wrote:
> > > > it's not that anyone is confused, it's that your "aside" was
> > > > inherently flawed: variables in python are dynamically typed, so the
> > > > suggestion that they are "auto" in any way related to c++ makes no
> > > > sense whatsoever. my response aimed merely at showing that even your
> > > > little "joke" was off.
> > > 
> > > Again: I was referring to the omission of any form of type name when
> > > declaring variables. That Python is _also_ dynamically typed is
> > > correct, but irrelevant.
> > 
> > then maybe you want to explain how you want to implement auto
> > *everywhere* without going dynamic. until you provide a credible answer
> > to that, your "aside" is patently irrelevant. hint: c# type inference
> > does *not* provide that answer.
> 
> I have explained it as good as I can. If you can or do not want to 
> understand, 
> then I'm sorry that I cannot explain it so you understand.
> 
have you considered the possibility that *you* are the one who's not
getting the point? you have not provided *any* sensible argument to
refute my claim that your analogy is fucked. you just keep repeating
the obvious.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

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

[Marc Mutz]

On Monday 07 December 2015 12:23:41 Oswald Buddenhagen wrote:
> On Fri, Dec 04, 2015 at 10:29:09PM +0100, Marc Mutz wrote:
> > On Friday 04 December 2015 19:06:51 Oswald Buddenhagen wrote:
> > > it's not that anyone is confused, it's that your "aside" was
> > > inherently flawed: variables in python are dynamically typed, so the
> > > suggestion that they are "auto" in any way related to c++ makes no
> > > sense whatsoever. my response aimed merely at showing that even your
> > > little "joke" was off.
> > 
> > Again: I was referring to the omission of any form of type name when
> > declaring variables. That Python is _also_ dynamically typed is
> > correct, but irrelevant.
> 
> then maybe you want to explain how you want to implement auto
> *everywhere* without going dynamic. until you provide a credible answer
> to that, your "aside" is patently irrelevant. hint: c# type inference
> does *not* provide that answer.

I have explained it as good as I can. If you can or do not want to understand, 
then I'm sorry that I cannot explain it so you understand.

Sorry,
Marc

-- 
Marc Mutz  | Senior Software Engineer
KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
Tel: +49-30-521325470
KDAB - The Qt Experts
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

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

[Knoll Lars]

On 07/12/15 14:05, "Development on behalf of Marc Mutz" 
 wrote:



>On Monday 07 December 2015 12:23:41 Oswald Buddenhagen wrote:
>> On Fri, Dec 04, 2015 at 10:29:09PM +0100, Marc Mutz wrote:
>> > On Friday 04 December 2015 19:06:51 Oswald Buddenhagen wrote:
>> > > it's not that anyone is confused, it's that your "aside" was
>> > > inherently flawed: variables in python are dynamically typed, so the
>> > > suggestion that they are "auto" in any way related to c++ makes no
>> > > sense whatsoever. my response aimed merely at showing that even your
>> > > little "joke" was off.
>> > 
>> > Again: I was referring to the omission of any form of type name when
>> > declaring variables. That Python is _also_ dynamically typed is
>> > correct, but irrelevant.
>> 
>> then maybe you want to explain how you want to implement auto
>> *everywhere* without going dynamic. until you provide a credible answer
>> to that, your "aside" is patently irrelevant. hint: c# type inference
>> does *not* provide that answer.
>
>I have explained it as good as I can. If you can or do not want to understand, 
>then I'm sorry that I cannot explain it so you understand.

Auto has nothing to do with anything being dynamically typed, as the type of an 
auto variable is defined by the way it’s being initialised. So let’s close that 
part of the discussion. We aren’t loosing static type information/checking just 
because we start using auto.

I am personally not seeing why we need extremely strict and/or detailed rules 
governing our usage of auto. Basically we should optimise our code for 
readability. If that makes refactoring easier, it’s an added benefit, but it’s 
not the primary goal I believe we should aim for. So let's start using auto in 
all places where it helps readability. I personally think an ‘always use auto’ 
policy is overdoing it, but I do believe we can be relatively liberal in it’s 
use without sacrificing readability (and often improving it by doing so).

Cheers,
Lars

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

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

[Ziller Eike]

> On Dec 4, 2015, at 8:01 PM, Olivier Goffart <oliv...@woboq.com> wrote:
> 
> On Friday 4. December 2015 15:39:01 Curtis Mitch wrote:
>>> -Original Message-
>>> From: Development [mailto:development-boun...@qt-project.org] On Behalf Of
>>> Olivier Goffart
>>> Sent: Friday, 4 December 2015 2:25 PM
>>> To: development@qt-project.org
>>> Subject: Re: [Development] RFC: more liberal 'auto' rules?
>>> 
>>> On Friday 4. December 2015 14:11:48 Oswald Buddenhagen wrote:
>>>> On Fri, Dec 04, 2015 at 02:07:10PM +0100, Marc Mutz wrote:
>>>>> And as an aside, since it has been mentioned in this thread: in
>>>>> Python _all_ variables are 'auto'. All. Without exception. Are
>>>>> Python programmers more intelligent? Or do they just tolerate more
>>>>> pain? :)
>>>> 
>>>> i'd suggest the latter.
>>>> no, really. people use external static checkers because the language
>>>> lacks the feature.
>>>> the lack of static typing is a common feature of scripting languages
>>>> and makes them convenient to a degree, but it is an utter nightmare
>>>> for any "real" software development. i really wouldn't want to go there.
>>> 
>>> But auto is still staticaly typed.
>>> 
>>> 
>>> When you have code like
>>> 
>>>   foo->bar()->setFaz(m_factory->createFaz(foo->bar()->type()));
>>> 
>>> You don't see any type.
>>> 
>>> This code that use auto is not less readable. Even if you don't know
>>> what's the type of bar without looking it up.
>>> 
>>>  auto *bar = foo->bar();
>>>  bar->setFaz(m_factory->createFaz(bar->type()));
>> 
>> Isn't this kind of a bad example, because there was no type declared/visible
>> in the first place?
> 
> Precisely my point!   
> There is no type visible before and nobody complains.  So why should one 
> suddenly complains there are no types in the second snippet
> 
>> Anyway, if you're going to take the time to move the result of foo->bar()
>> onto its own line, why not just declare a type? What benefit does auto give
>> here?
>> 
>> I really dislike hiding types behind a generic keyword.
> 
> Because the type is redundent and it's one reason less to make errors:
> Using 'int' instead of 'quint64' or 'size_t', or QString instead of 
> QByteArray 
> is way to frequent. (and the compiler won't complain)

The compiler will then still not complain if you pass that ‘auto’ variable to a 
function taking ‘int’ (or QString, if you don’t have NO_CAST_...), will it?
So in the end people will still just need to know what they are doing, or, 
since IDE support is mentioned several times in this thread, use an IDE with 
stricter warning policy.
(The default setting for the Clang code model in Qt Creator is to warn when 
assigning or comparing 'unsigned int' and ‘int' etc ;) )

> It is also refactoring-proof.  Because you might want to change the name of 
> the type from "FazManager" to "FazHolder", and then you need to touch less 
> code in your refactoring. 

On the other hand if you are changing the return value of a function, there 
will be cases where it would be better if you (and anyone using your function) 
had to explicitly look at the usages.

I do not think that more usage of ‘auto’ will make any code (or refactorings of 
it) ‘safer’. IMO this is only about convenience and readability.

Br, Eike

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

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

[Julien Blanc]

Le samedi 05 décembre 2015 à 12:08 +, Bubke Marco a écrit :

> >
> >> - template code (esp., but not necessarily only, when the type name
> >> would require the use of 'typename')
> >
> > This is the one i’m not at ease with. Template code tends to be
> > difficult to read, partly *because* there’s no type information. For
> > readability concerns, i would prefer a local typedef named by the
> > concept. Yes, that makes it two lines instead of one, but i think that’s
> > one case where hinting the reader with a well-chosen type name makes a
> > lot of sense.
> 
> Most typedefs I have seen was about hiding pointer or container types like 
> CursorPointer or Cursors. But is CursorPointer a unique pointer,  a shared 
> pointer and which flavor is it. Cursors is the same because it could be 
> std::vector or QList. Some would hide a dictionary behind this name. So the 
> typedef can be misleading. In that case I prefer auto. 
> 
> std::shared cursorPointer = document.cursorAtPostion(46);
> 
> CursorPointer cursorPointer = document.cursorAtPostion(46);
> 
> auto cursorPointer = document.cursorAtPostion(46);
> 
> I prefer the last but we need good tooling to show the type. It would be nice 
> to have much more information like size,  is it movable or copyable. It is 
> not only the type and we can provide that information. 

My understanding of Marc’s proposal was that it was more for the
following case :

template void algorithm(List& input)
{
typename List::value_type& first = input.front();
...
}

replaced by :
template void algorithm(List& input)
{
auto& first = input.front();
...
}

whereas i prefer 
template void algorithm(List& input)
{
typedef typename List::value_type Serializable;
// there are some requirements on List : item_type must be
// Serializable : now i can look the doc to see what a
// Serializable is
Serializable& first = input.front(); 
// i know what to expect from first, which methods i can call
...
}

I think the latter improves readability over the two others, because it
just gives more information to the reader. And this information is
currently *not* given by the type system, because concepts do not exists
in the type system yet. No tooling will ever give you a type information
here : it depends on the template instanciation.

Regards,

Julien Blanc

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

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

[Marc Mutz]

On Saturday 05 December 2015 13:46:53 Julien Blanc wrote:
> Le samedi 05 décembre 2015 à 12:08 +, Bubke Marco a écrit :
[...]
> whereas i prefer
> template void algorithm(List& input)
> {
> typedef typename List::value_type Serializable;
> // there are some requirements on List : item_type must be
> // Serializable : now i can look the doc to see what a
> // Serializable is
> Serializable& first = input.front();
> // i know what to expect from first, which methods i can call
> ...
> }
[...]

Thank YOU! That's the PERFECT example of why you should use _auto_! In the 
best of Qt traditions:

   You're Doing It Wrong!

If you don't see why, try to pass a C array to your function... There's a 
_reason_ we have std::begin(), and a _reason_ why we have iterator_traits.

The _correct_ way to write this is without auto or decltype is:

template 
void algorithm(List ) {
using namespace std;
// no decltype, so way to refer to decltype(begin(list),
// so need to defer to a helper:
algorithm_impl(begin(list), end(list));
}
template 
void algorithm_impl(ForwardIterator first, ForwardIterator last) {
if (first == last)
return;
typedef typename std::iterator_traits::value_type
Serializable;
// useless comments
Serializable  = *first:
}

Well, or, with auto:

   template 
   void algorithm(List ) {
   using namespace std;
   auto first = begin(list), last = end(list);
   if (first == last)
   return;
   auto  = *first;
   
   }

Everyone who claims that the first one is more readable is crazy.

And please don't _anyone_ out yourself as _actually_ believing that the first 
is more readable, because then I would have personally insulted you, and I 
don't want to do that. Let's hope common sense prevails and we all get out of 
this awkward situation with saved faces...

Thanks,
Marc

-- 
Marc Mutz  | Senior Software Engineer
KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
Tel: +49-30-521325470
KDAB - The Qt Experts
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

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

[Bubke Marco]

On December 5, 2015 12:08:51 Julien Blanc  wrote:

> Le vendredi 04 décembre 2015 à 18:10 -0500, Matthew Woehlke a écrit : 
>> On 2015-12-04 17:43, André Pönitz wrote:
>> > On Fri, Dec 04, 2015 at 04:33:26PM -0500, Matthew Woehlke wrote:
>> >> Which of these is easier to read? (More importantly, which is easier to
>> >> *verify* that it is correct?)
>> >>
>> >>   for (int i = 0; i < list.size(); ++i)
>> >> foo(list[i]);
> [snip] 
>> 
>> >>   for (auto i : qtIndexRange(list.size())
>> >> foo(list[i]);
>> > 
>> > In any case, this is an uncommon pattern, using some unknown qtIndexRange()
>> > function.
>> 
>> Really?
>> 
>>   (Python)
>>   for i in range(len(list))
>
> Am I the only one to think that this example is inherently broken ? I
> mean, why wouldn’t any sane person write :
>
> for(auto const& element : list)
> foo(element)
>
> or
> std::for_each(list.begin(), list.end(), foo);
>
> Because :
> - it’s shorter
> - it’s more readable
> - it works for non random-access-container types
> - bonus : range checking is not needed, so it should be more performant
> - bonus : it doesn’t resort to a temporary value, same remark

What if you want to iterate over two lists.

for token,  cursors in zip(tokens,  cursors):
   ... 

is quite handy. 

You can use std::transform for some cases but C++ is sometimes very far behind. 
To my understanding Ranges should provide a good solution for it but they hide 
the type for good reasons. 

>
> Now, getting back to what Marc proposed initially, because the debate
> has gone far away from his initial proposal :
>
>> - template code (esp., but not necessarily only, when the type name
>> would require the use of 'typename')
>
> This is the one i’m not at ease with. Template code tends to be
> difficult to read, partly *because* there’s no type information. For
> readability concerns, i would prefer a local typedef named by the
> concept. Yes, that makes it two lines instead of one, but i think that’s
> one case where hinting the reader with a well-chosen type name makes a
> lot of sense.

Most typedefs I have seen was about hiding pointer or container types like 
CursorPointer or Cursors. But is CursorPointer a unique pointer,  a shared 
pointer and which flavor is it. Cursors is the same because it could be 
std::vector or QList. Some would hide a dictionary behind this name. So the 
typedef can be misleading. In that case I prefer auto. 

std::shared cursorPointer = document.cursorAtPostion(46);

CursorPointer cursorPointer = document.cursorAtPostion(46);

auto cursorPointer = document.cursorAtPostion(46);

I prefer the last but we need good tooling to show the type. It would be nice 
to have much more information like size,  is it movable or copyable. It is not 
only the type and we can provide that information. 

>> - all loop variables (both index and iterators)
>>   the reason being that spelling out the name is usually wrong:
>>  size_t i = stdVector.size() // wrong, should be
>>  std::vector::size_type...
>>  also helps when porting from Qt containers to STL ones
>
> That looks perfectly fine for me. Index based loops should be avoided
> whenever it is possible, and for iterator based loops auto makes no harm
> (seriously, who wants to write
> std::vector::const_iterator instead of auto ?).
>
>> - all references to elements in a collection (same problem - way too
>> easy to misspell std::pair for std::pair...)
>
> Same thing.
>
> Regards,
>
> Julien
>
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
Sent from cellphone 
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

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

[Marc Mutz]

On Friday 04 December 2015 08:35:05 Randall O'Reilly wrote:
> So anyway, this is just a vote to keep with the solid tradition of favoring
> simplicity, clarity, usability, readability, etc, instead of just
> following the std:: C++ crowd!  Without Qt, I would have to suck it up and
> rewrite everything in Go or Python or something.. :)

You should be monitoring the community you are so quick to judge. Google GSL. 
Just because something has been done that way for decades doesn't mean it's 
best, for any definiton of the word.

-- 
Marc Mutz  | Senior Software Engineer
KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
Tel: +49-30-521325470
KDAB - The Qt Experts
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

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

[Thiago Macieira]

On Friday 04 December 2015 08:49:14 Marc Mutz wrote:
> > Qt has enough market share by itself that we can choose our own direction
> > and still be relevant. We are allowed to disagree with what others do.
> 
> Yes, but only if we know *better*.
> 
> I very much doubt that more than very few people in Qt development have the
> knowledge to objectively overrule the accepted C++ authorities. 

That's why we use the mailing list and discuss the issue. Our collective minds 
together are quite powerful.

> So the default should be to follow what the greater C++ community is doing,
> while *divergence* from that needs to be argued for.

You're calling for "opt-in by default" approach, while I am calling for an 
"opt-out by default" approach. Since we need to decide which C++ features to 
use in the first place due to old compilers we need to support, I think we're 
effectively "opt-out by default".

But either way, the end result is the same.

> > we don't use underscores
> 
> ... except we do (grep "qt_"). And there's *nothing* wrong with that!

Not in our API. Those qt_ functions are private API. The underscore is, in 
fact, the marker that it is private.

-- 
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

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

[Olivier Goffart]

On Friday 4. December 2015 00:13:33 Thiago Macieira wrote:
> On Friday 04 December 2015 08:49:14 Marc Mutz wrote:
> > > we don't use underscores
> > 
> > ... except we do (grep "qt_"). And there's *nothing* wrong with that!
> 
> Not in our API. Those qt_ functions are private API. The underscore is, in
> fact, the marker that it is private.

Except in macros.  (Ok, this is going too far :-))
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

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

[Blasche Alexander]

> -Original Message-
> From: Development [mailto:development-boun...@qt-project.org] On Behalf
> Of Thiago Macieira
> Sent: Friday, 4 December 2015 9:14
> To: development@qt-project.org
> Subject: Re: [Development] RFC: more liberal 'auto' rules?
> 
> On Friday 04 December 2015 08:49:14 Marc Mutz wrote:
> > > Qt has enough market share by itself that we can choose our own direction
> > > and still be relevant. We are allowed to disagree with what others do.
> >
> > Yes, but only if we know *better*.
> >
> > I very much doubt that more than very few people in Qt development have the
> > knowledge to objectively overrule the accepted C++ authorities.
> 
> That's why we use the mailing list and discuss the issue. Our collective minds
> together are quite powerful.

First of all I'd like to point out that I agree with Thiago and Randall. In 
fact, I added the auto policy to the Qt coding conventions.

This policy has been in place for much longer in Qt Creator (and therefore the 
Qt version  just an adoption). I had my fair share of arguing over what is 
better or worse readability wise. At the end of the day it's subjective which 
makes argumentation about right or wrong harder. For me the point is that if I 
have to look up a function signature to figure out what type is behind the 
return values auto type then that's bad. An always auto policy is just asking 
for such situations. 

> You're calling for "opt-in by default" approach, while I am calling for an
> "opt-out by default" approach.

+1
--
Alex


___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

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

[Marc Mutz]

On Friday 04 December 2015 09:13:33 Thiago Macieira wrote:
> You're calling for "opt-in by default" approach, while I am calling for an 
> "opt-out by default" approach. Since we need to decide which C++ features
> to  use in the first place due to old compilers we need to support, I
> think we're effectively "opt-out by default".

Opt-in for _which_ C++ features to use, sure.

But opt-out of _how_ to use them, vis a vis the greater C++ community.

The guidelines on lambdas in the coding standard are pretty good in that 
regard. They point out specific compiler bugs (some of which may no longer play 
a role in 5.7, e.g. MSVC 2010), and mandate certain workarounds, but do not 
further restrict the use of lambdas.

The guideline for auto is not at all like that, though.

Given a (beautiful) auto variable and an (ugly) lambda, I'd say that it's 
lambdas which make the code less readable, not auto. But if readability is 
only defined as "I can see all types", then the reverse it true, yes.


On Friday 04 December 2015 10:45:06 Blasche Alexander wrote:
>  For me the point is that if I have to look up a function signature to
>  figure out what type is behind the return values auto type then that's
>  bad.

Playing the devil's advocate here, I wonder how we could have accepted code 
like this before:

le->setText(foo.description());

after all, you have to "look up the description() signature to figure out which 
type" is being passed to setText(), as defined above. We all write code like 
the above. And not only if the involved functions scream "it's QString, 
stupid".

But now people (not saying 'you') will be vehemently -1'ing the completely 
equivalent code

   const auto desc = foo.description();
   le->setText(desc);

on grounds of reduced readbility compared to

   const QString desc = foo.description();
   le->setText(desc);

That makes no sense.

And as an aside, since it has been mentioned in this thread: in Python _all_ 
variables are 'auto'. All. Without exception. Are Python programmers more 
intelligent? Or do they just tolerate more pain? :)

Thanks,
Marc

-- 
Marc Mutz  | Senior Software Engineer
KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
Tel: +49-30-521325470
KDAB - The Qt Experts
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

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

[Rafael Roquetto]

On Fri, Dec 04, 2015 at 02:25:14PM +0100, Olivier Goffart wrote:
> On Friday 4. December 2015 14:11:48 Oswald Buddenhagen wrote:
> > On Fri, Dec 04, 2015 at 02:07:10PM +0100, Marc Mutz wrote:
> > > And as an aside, since it has been mentioned in this thread: in Python
> > > _all_ variables are 'auto'. All. Without exception. Are Python
> > > programmers more intelligent? Or do they just tolerate more pain? :)
> > 
> > i'd suggest the latter.
> > no, really. people use external static checkers because the language
> > lacks the feature.
> > the lack of static typing is a common feature of scripting languages and
> > makes them convenient to a degree, but it is an utter nightmare for any
> > "real" software development. i really wouldn't want to go there.
> 
> But auto is still staticaly typed.
> 
> 
> When you have code like
> 
>foo->bar()->setFaz(m_factory->createFaz(foo->bar()->type()));
> 
> You don't see any type. 
> 
> This code that use auto is not less readable. Even if you don't know what's 
> the type of bar without looking it up.
> 
>   auto *bar = foo->bar();
>   bar->setFaz(m_factory->createFaz(bar->type()));

Until you need to change your code and call any method of bar. Suppose I
need to change the following code, to print the first item of the collection:

auto *bar = foo->collection();

/*TODO: print first item here */

model->setCollection(bar); // we know bar is a collection, but of what kind?


Choose the right alternative:

a) qDebug() << bar->first();
b) qDebug() << bar->values().first();
c) qDebug() << bar[0]
d) none of the above


To answer this, you will need to find out the return type of
Foo::collection(); The compiler knows it, but the reader does not. And the
answer depends on whether it is  a QList/QVector, QHash/QMap, etc... Had it
been explicit, any programmer familiar with the Qt API (or any API in context)
would be able to directly write down the right statement.


Just an idea.

Cheers,
Rafael

-- 
Rafael Roquetto | rafael.roque...@kdab.com | Software Engineer
Klarälvdalens Datakonsult AB, a KDAB Group company
Tel. Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322)
KDAB - Qt 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] RFC: more liberal 'auto' rules?

[Bubke Marco]

On December 4, 2015 08:35:19 Randall O'Reilly  
wrote:

> This debate between the std:: lib and wider C++ community vs. the Qt 
> traditions seems never-ending :)  At the risk of perpetuating the inevitable 
> flame war, my perspective is well captured in this article:  
> http://simpleprogrammer.com/2012/12/01/why-c-is-not-back/
>
> C++ is WAY too complex of a language, and other alternatives are rapidly 
> gaining users (particularly Python in the domain of scientific computing).  
> The STL and its sea of recursive templates has in particular been incredibly 
> daunting.  C++11 helps, but the complexity remains..
>
> Of course, there is no “right” answer in any of these language debates: only 
> different people optimizing different ends of many different fundamental 
> tradeoffs.
>
> C and C++ in general tend to attract people who favor optimization over 
> simplicity / usability of the language.  Marc is clearly in that camp, 
> advocating many ways of optimizing performance..  With all the new language 
> options, presumably those that stick with C++ are even more apt to be 
> obsessed with performance..
>
> But Qt is beloved by many (myself included) because it provides a *simple*, 
> elegant, well-designed, well-named API, that does a lot of stuff..  Not 
> because of its optimal performance or cutting-edge language features and 
> adherence to the C++ standard..

Hmm,  do you really believe we cannot improve? If you compare signal and slots 
with resumable functions it looks quite complicated for many use cases. Look 
how complicated our network API is. It could be much easier with resumable 
functions. I don't say signal slots should go away but should be used in places 
their they have still an advantage. 

Ranges are quite nice too. With Qt we made C++ of the nineties much nicer but 
now C++ is incorporating many advanced features for concurrency and other areas 
from C#,  Python and other interesting languages. The world is changing and we 
should adapt to this changing context. 

> I got “stuck” in C++ for historical reasons: it was the only viable option 
> for object-oriented programming in the 1990’s.  Sure, I care about 
> optimization for my critical inner loops.  But for everything else, I really 
> wish it was a lot simpler.  And again, I value Qt for making it so in the 
> GUI, which consumes a huge amount of my code, and has minimal performance 
> demands, because it is a GUI and the human in the loop is almost always the 
> rate limiting factor.  Of course we don’t want exponential slowdowns with 
> large numbers of Widgets etc, but I’ve never found that to be a problem in Qt.
>
> So anyway, this is just a vote to keep with the solid tradition of favoring 
> simplicity, clarity, usability, readability, etc, instead of just following 
> the std:: C++ crowd!  Without Qt, I would have to suck it up and rewrite 
> everything in Go or Python or something.. :)
>
> - Randy
>
>> On Dec 4, 2015, at 12:49 AM, Marc Mutz  wrote:
>> 
>> On Friday 04 December 2015 02:56:11 Thiago Macieira wrote:
>>> On Thursday 03 December 2015 14:14:19 Thiago Macieira wrote:
 That depends on how big the remainder is. I argue that we're relevant
 enough  that our own direction is big enough to be of relevance.
>>> 
>>> That didn't come out right. Rephrasing:
>>> 
>>> Qt has enough market share by itself that we can choose our own direction
>>> and still be relevant. We are allowed to disagree with what others do.
>> 
>> Yes, but only if we know *better*.
>> 
>> I very much doubt that more than very few people in Qt development have the 
>> knowledge to objectively overrule the accepted C++ authorities. I myself 
>> have 
>> seen over and over again that how I thought a feature should be used was 
>> blown 
>> to smithereens by members of the committee, usually rightfully so.
>> 
>> So the default should be to follow what the greater C++ community is doing, 
>> while *divergence* from that needs to be argued for.
>> 
>> Everything else is approaching hubris, imo.
>> 
>>> we don't use exceptions
>> 
>> ...and look at the sorry state of error handling in Qt - every class does it 
>> differently... It's ok not to use exceptions, but not having a consistent 
>> error 
>> handling strategy doesn't put us into a position to throw that stone.
>> 
>>> we don't use underscores
>> 
>> ... except we do (grep "qt_"). And there's *nothing* wrong with that!
>> 
>> Thanks,
>> Marc
>> 
>> -- 
>> Marc Mutz  | Senior Software Engineer
>> KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
>> Tel: +49-30-521325470
>> KDAB - The Qt Experts
>> ___
>> Development mailing list
>> Development@qt-project.org
>> http://lists.qt-project.org/mailman/listinfo/development
>
> ___
> Development mailing list
> Development@qt-project.org
> 

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

[Bubke Marco]

On December 4, 2015 10:45:19 Blasche Alexander 
<alexander.blas...@theqtcompany.com> wrote:

>> -Original Message-
>> From: Development [mailto:development-boun...@qt-project.org] On Behalf
>> Of Thiago Macieira
>> Sent: Friday, 4 December 2015 9:14
>> To: development@qt-project.org
>> Subject: Re: [Development] RFC: more liberal 'auto' rules?
>> 
>> On Friday 04 December 2015 08:49:14 Marc Mutz wrote:
>> > > Qt has enough market share by itself that we can choose our own direction
>> > > and still be relevant. We are allowed to disagree with what others do.
>> >
>> > Yes, but only if we know *better*.
>> >
>> > I very much doubt that more than very few people in Qt development have the
>> > knowledge to objectively overrule the accepted C++ authorities.
>> 
>> That's why we use the mailing list and discuss the issue. Our collective 
>> minds
>> together are quite powerful.
>
> First of all I'd like to point out that I agree with Thiago and Randall. In 
> fact, I added the auto policy to the Qt coding conventions.
>
> This policy has been in place for much longer in Qt Creator (and therefore 
> the Qt version  just an adoption). I had my fair share of arguing over what 
> is better or worse readability wise. At the end of the day it's subjective 
> which makes argumentation about right or wrong harder. For me the point is 
> that if I have to look up a function signature to figure out what type is 
> behind the return values auto type then that's bad. An always auto policy is 
> just asking for such situations. 

With the clang code model it is quite easy to provide that information. In my 
opinion it is better to give your functions and variables descriptive names so 
you don't need to look for the declaration. 

For Test Driven Development it is better to use auto if you must exchange types 
with mocks. So the interface(concepts) is important but not the type.

>> You're calling for "opt-in by default" approach, while I am calling for an
>> "opt-out by default" approach.
>
> +1
> --
> Alex
>
>
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
Sent from cellphone 
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

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

[Knoll Lars]

I think we all agree with the goal we have with Qt to make C++ development 
accessible and easy. This is something we will continue to do. 

But the question asked here was about how we use a certain c++11 feature in our 
*implementation*. This is clearly different from what we do with our APIs and 
what we ask our users to know.

To implement Qt, we can and should use C++ in the most efficient way. If it 
makes sense to use certain features (and we can actually use them on all 
platforms), let's use them. But of course let's not force all of these upon our 
users.

Cheers,
Lars




On 04/12/15 08:58, "Development on behalf of Smith Martin" 
<development-boun...@qt-project.org on behalf of martin.sm...@theqtcompany.com> 
wrote:

>+1
>
>martin
>
>
>From: Development <development-boun...@qt-project.org> on behalf of Randall 
>O'Reilly <randy.orei...@colorado.edu>
>Sent: Friday, December 04, 2015 8:35 AM
>To: Marc Mutz
>Cc: development@qt-project.org
>Subject: Re: [Development] RFC: more liberal 'auto' rules?
>
>This debate between the std:: lib and wider C++ community vs. the Qt 
>traditions seems never-ending :)  At the risk of perpetuating the inevitable 
>flame war, my perspective is well captured in this article:  
>http://simpleprogrammer.com/2012/12/01/why-c-is-not-back/
>
>C++ is WAY too complex of a language, and other alternatives are rapidly 
>gaining users (particularly Python in the domain of scientific computing).  
>The STL and its sea of recursive templates has in particular been incredibly 
>daunting.  C++11 helps, but the complexity remains..
>
>Of course, there is no “right” answer in any of these language debates: only 
>different people optimizing different ends of many different fundamental 
>tradeoffs.
>
>C and C++ in general tend to attract people who favor optimization over 
>simplicity / usability of the language.  Marc is clearly in that camp, 
>advocating many ways of optimizing performance..  With all the new language 
>options, presumably those that stick with C++ are even more apt to be obsessed 
>with performance..
>
>But Qt is beloved by many (myself included) because it provides a *simple*, 
>elegant, well-designed, well-named API, that does a lot of stuff..  Not 
>because of its optimal performance or cutting-edge language features and 
>adherence to the C++ standard..
>
>I got “stuck” in C++ for historical reasons: it was the only viable option for 
>object-oriented programming in the 1990’s.  Sure, I care about optimization 
>for my critical inner loops.  But for everything else, I really wish it was a 
>lot simpler.  And again, I value Qt for making it so in the GUI, which 
>consumes a huge amount of my code, and has minimal performance demands, 
>because it is a GUI and the human in the loop is almost always the rate 
>limiting factor.  Of course we don’t want exponential slowdowns with large 
>numbers of Widgets etc, but I’ve never found that to be a problem in Qt.
>
>So anyway, this is just a vote to keep with the solid tradition of favoring 
>simplicity, clarity, usability, readability, etc, instead of just following 
>the std:: C++ crowd!  Without Qt, I would have to suck it up and rewrite 
>everything in Go or Python or something.. :)
>
>- Randy
>
>> On Dec 4, 2015, at 12:49 AM, Marc Mutz <marc.m...@kdab.com> wrote:
>>
>> On Friday 04 December 2015 02:56:11 Thiago Macieira wrote:
>>> On Thursday 03 December 2015 14:14:19 Thiago Macieira wrote:
>>>> That depends on how big the remainder is. I argue that we're relevant
>>>> enough  that our own direction is big enough to be of relevance.
>>>
>>> That didn't come out right. Rephrasing:
>>>
>>> Qt has enough market share by itself that we can choose our own direction
>>> and still be relevant. We are allowed to disagree with what others do.
>>
>> Yes, but only if we know *better*.
>>
>> I very much doubt that more than very few people in Qt development have the
>> knowledge to objectively overrule the accepted C++ authorities. I myself have
>> seen over and over again that how I thought a feature should be used was 
>> blown
>> to smithereens by members of the committee, usually rightfully so.
>>
>> So the default should be to follow what the greater C++ community is doing,
>> while *divergence* from that needs to be argued for.
>>
>> Everything else is approaching hubris, imo.
>>
>>> we don't use exceptions
>>
>> ...and look at the sorry state of error handling in Qt - every class does it
>> differently... It's ok not to use exceptions, but not having a 

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

[Olivier Goffart]

On Friday 4. December 2015 14:11:48 Oswald Buddenhagen wrote:
> On Fri, Dec 04, 2015 at 02:07:10PM +0100, Marc Mutz wrote:
> > And as an aside, since it has been mentioned in this thread: in Python
> > _all_ variables are 'auto'. All. Without exception. Are Python
> > programmers more intelligent? Or do they just tolerate more pain? :)
> 
> i'd suggest the latter.
> no, really. people use external static checkers because the language
> lacks the feature.
> the lack of static typing is a common feature of scripting languages and
> makes them convenient to a degree, but it is an utter nightmare for any
> "real" software development. i really wouldn't want to go there.

But auto is still staticaly typed.


When you have code like

   foo->bar()->setFaz(m_factory->createFaz(foo->bar()->type()));

You don't see any type. 

This code that use auto is not less readable. Even if you don't know what's 
the type of bar without looking it up.

  auto *bar = foo->bar();
  bar->setFaz(m_factory->createFaz(bar->type()));



___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

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

[Koehne Kai]

> -Original Message-
> From: Development [mailto:development-boun...@qt-project.org] On Behalf
> Subject: [Development] RFC: more liberal 'auto' rules?
> 
>[..]
> The remainder of the C++ world is moving towards an "always auto" scheme.
> We don't need to go there, but I'd at least like to propose, for new code and 
> as
> a drive-by, the *required* use of auto for:
> 

Just want to comment on this argument ...

I know that some influential members are suggesting the AAA (almost always 
auto), 
but I think it's a bit overboard to claim that this is "the C++ world".

Take for instance the coding guidelines of Clang:

http://llvm.org/docs/CodingStandards.html#use-auto-type-deduction-to-make-code-more-readable

Or google:

https://google.github.io/styleguide/cppguide.html#auto

Even the C++ core guidelines don't explicitly say 'use auto always', but only 
to avoid redundant repetition of type names:

https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md#Res-auto

So I think the ruling is still out whether the "AAA style" is really picked up 
by a lot of projects.

Regards

Kai
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

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

[Oswald Buddenhagen]

On Fri, Dec 04, 2015 at 02:07:10PM +0100, Marc Mutz wrote:
> And as an aside, since it has been mentioned in this thread: in Python _all_ 
> variables are 'auto'. All. Without exception. Are Python programmers more 
> intelligent? Or do they just tolerate more pain? :)
> 
i'd suggest the latter.
no, really. people use external static checkers because the language
lacks the feature.
the lack of static typing is a common feature of scripting languages and
makes them convenient to a degree, but it is an utter nightmare for any
"real" software development. i really wouldn't want to go there.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

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

[Oswald Buddenhagen]

On Fri, Dec 04, 2015 at 02:25:14PM +0100, Olivier Goffart wrote:
> On Friday 4. December 2015 14:11:48 Oswald Buddenhagen wrote:
> > On Fri, Dec 04, 2015 at 02:07:10PM +0100, Marc Mutz wrote:
> > > And as an aside, since it has been mentioned in this thread: in Python
> > > _all_ variables are 'auto'. All. Without exception. Are Python
> > > programmers more intelligent? Or do they just tolerate more pain? :)
> > 
> > i'd suggest the latter.
> > no, really. people use external static checkers because the language
> > lacks the feature.
> > the lack of static typing is a common feature of scripting languages and
> > makes them convenient to a degree, but it is an utter nightmare for any
> > "real" software development. i really wouldn't want to go there.
> 
> But auto is still staticaly typed.
> 
that's why using a scripting language as a source of arguments wasn't a
very wise move tactically, even as an aside. ;)
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

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

[Marc Mutz]

On Friday 04 December 2015 14:12:00 Rafael Roquetto wrote:
> Until you need to change your code and call any method of bar.

QtC prints the signature of the function when you hover the mouse over it — 
since _ages_. It also completes function names of auto variables. Since 
_ages_. Even if it should be the case that it doesn't, yet, show the deduced 
type when you hover over the 'auto', the lhs can be inspected by hovering, and 
the rhs's type is clear[1].

But ok, for those of us using vi, I motion to ban function chaining like

le->setText(foo.description());

or

   foo->bar()->setFaz(m_factory->createFaz(foo->bar()->type()));

Everyone in favour of restricting auto use due to readability concerns is 
automatically (no pun intended) counted as in-favour of the motion, with 
prejudice.

Thanks,
Marc

[1] If it's not clear, we need to ban the use of template functions.

-- 
Marc Mutz  | Senior Software Engineer
KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
Tel: +49-30-521325470
KDAB - The Qt Experts
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

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

[Nicolás Ulrich]

Would be great something like Android Studio does with some things.
For example it shows the "deduced" string in a different format (top) and
when you click/modify it shows the "real" code (bottom)

[image: Screenshot 2015-12-04 13.55.13.png]


On Fri, Dec 4, 2015 at 1:49 PM Thiago Macieira 
wrote:

On Friday 04 December 2015 16:20:44 Bubke Marco wrote:
> The clang code model completes auto so it should be not that hard.
Actually
> I would call an ordered map or unordered map a dictionary.

Does Creator have a way to reveal the deduced type of an auto? That would
go a
long way to alleviating the pain of using it.

--
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 mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

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

[Marc Mutz]

On Friday 04 December 2015 14:32:22 Oswald Buddenhagen wrote:
> > But auto is still staticaly typed.
> >
> > 
> 
> that's why using a scripting language as a source of arguments wasn't a
> very wise move tactically, even as an aside. ;)

I, indeed, did not anticipate that anyone here would be able to seriously 
confuse static typing and var/auto, the omitting of the type name in variable 
declarations.

I have the feeling I wasn't wrong, though.

-- 
Marc Mutz  | Senior Software Engineer
KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
Tel: +49-30-521325470
KDAB - The Qt Experts
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

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

[Thiago Macieira]

On Friday 04 December 2015 16:20:44 Bubke Marco wrote:
> The clang code model completes auto so it should be not that hard.  Actually
> I would call an ordered map or unordered map a dictionary. 

Does Creator have a way to reveal the deduced type of an auto? That would go a 
long way to alleviating the pain of using it.

-- 
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

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

[Thiago Macieira]

On Friday 04 December 2015 15:01:07 Knoll Lars wrote:
> To implement Qt, we can and should use C++ in the most efficient way. If it
> makes sense to use certain features (and we can actually use them on all
> platforms), let's use them. But of course let's not force all of these upon
> our users.

Let me say again that our source code is product and it must be readable (to 
an extent) by our users. We should write efficient code, but not to a point 
that 
it's not understandable anymore by an advanced Qt application developer.

-- 
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

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

[Thiago Macieira]

On Friday 04 December 2015 15:46:58 Bubke Marco wrote:
> Hmm,  do you really believe we cannot improve? If you compare signal and
> slots with resumable functions it looks quite complicated for many use
> cases. Look how complicated our network API is. It could be much easier
> with resumable functions. I don't say signal slots should go away but
> should be used in places their they have still an advantage. 

Our networking API is quite complex, but it could be worse. It could be like 
Boost.Asio and what's being proposed to the C++ standard networking API.

Let me put it this way: *I* do not understand it.

So yeah, we should use new things that make our lives and our users' lives 
easier, like we've done with variadic templates. We do not have to use things 
that make it worse.
-- 
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

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

[Bubke Marco]

On December 4, 2015 16:39:14 Curtis Mitch <mitch.cur...@theqtcompany.com> wrote:

>> -Original Message-
>> From: Development [mailto:development-boun...@qt-project.org] On Behalf Of
>> Olivier Goffart
>> Sent: Friday, 4 December 2015 2:25 PM
>> To: development@qt-project.org
>> Subject: Re: [Development] RFC: more liberal 'auto' rules?
>> 
>> On Friday 4. December 2015 14:11:48 Oswald Buddenhagen wrote:
>> > On Fri, Dec 04, 2015 at 02:07:10PM +0100, Marc Mutz wrote:
>> > > And as an aside, since it has been mentioned in this thread: in
>> > > Python _all_ variables are 'auto'. All. Without exception. Are
>> > > Python programmers more intelligent? Or do they just tolerate more
>> > > pain? :)
>> >
>> > i'd suggest the latter.
>> > no, really. people use external static checkers because the language
>> > lacks the feature.
>> > the lack of static typing is a common feature of scripting languages
>> > and makes them convenient to a degree, but it is an utter nightmare
>> > for any "real" software development. i really wouldn't want to go there.
>> 
>> But auto is still staticaly typed.
>> 
>> 
>> When you have code like
>> 
>>foo->bar()->setFaz(m_factory->createFaz(foo->bar()->type()));
>>
>> You don't see any type.
>> 
>> This code that use auto is not less readable. Even if you don't know
>> what's the type of bar without looking it up.
>> 
>>   auto *bar = foo->bar();
>>   bar->setFaz(m_factory->createFaz(bar->type()));
>> 
>
> Isn't this kind of a bad example, because there was no type declared/visible 
> in the first place?
>
> Anyway, if you're going to take the time to move the result of foo->bar() 
> onto its own line, why not just declare a type? What benefit does auto give 
> here?

We have a maximum length in the coding style.  So if you give your variables 
and functions descriptive names you cannot chain them so you needs variables 
inbetween. The type information is not that important in that case. Anyway we 
can provide the actual type for auto in creator. Like we will provide 
highlighting for output parameters. A good tool can provide all the 
informations so we don't need to overload the source code with that 
information. So we can make the intent of the code much more clear. 

> I really dislike hiding types behind a generic keyword.
>  
>> 
>> ___
>> 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
Sent from cellphone 
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

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

[André Pönitz]

On Fri, Dec 04, 2015 at 04:33:26PM -0500, Matthew Woehlke wrote:
> On 2015-12-04 15:35, André Pönitz wrote:
> > On Fri, Dec 04, 2015 at 08:01:59PM +0100, Olivier Goffart wrote:
> >> and it's one reason less to make errors:
> >> Using 'int' instead of 'quint64' or 'size_t', or QString instead of 
> >> QByteArray 
> >> is way to frequent. (and the compiler won't complain)
> > 
> > ["QString instead of QByteArray" does not happen with proper
> > QT_NO__CAST_*_ASCII settings.  Not to mention the cases where mindless
> > replacement of explicit types by 'auto' doesn't produce identical results.]
> 
> But wrongly mixing integer types *does* happen. I speak from personal
> experience based on a code base that has a relatively large mess of
> *exactly* such errors.
> 
> > Code is typically read more often than changed. Targeting at making
> > specific refactorings easier is optimizing the wrong utility function.
> 
> Which of these is easier to read? (More importantly, which is easier to
> *verify* that it is correct?)
> 
>   for (int i = 0; i < list.size(); ++i)
> foo(list[i]);

Whether the access is correct depends on the type of list, which you don't
disclose.

In any case, this loop follows a well-known pattern.

>   for (auto i : qtIndexRange(list.size())
> foo(list[i]);


Whether the access is correct depends on the type of list, which you don't
disclose.

In any case, this is an uncommon pattern, using some unknown qtIndexRange()
function. Moreover it is more to type. The extra level of parantheses makes
it harder to parse for humans, introducing an aditional source of errors,
which you nicely demonstrated by making the example non-compilable.

> Which is *really* more meaningful?

The first one.

> "The type of 'i' is 'int', and I
> really, really hope that 'list' is actually indexed by 'int'", or "the
> type of 'i' is the index type of 'list'¹"?
> 
> Do you really *care* what is the type of 'i'?

Yes, I do care about types, almost always.

> Or do you care that it is
> the *correct* type. I (and others) submit that the latter is more valuable.

Your message has been heard. I do not agree with you.

I feel more comfortable arguing about whether a type is the right one
if the type is known than when it is unknown.

There *are* some sensible uses of 'auto', those are pretty much the ones
listed in Creator's coding-style.qdoc. Overuse of 'auto' reduces
code readability and maintainability, I would not like to see the Qt
code base move there.

Andre'
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

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

[Matthew Woehlke]

On 2015-12-04 15:35, André Pönitz wrote:
> On Fri, Dec 04, 2015 at 08:01:59PM +0100, Olivier Goffart wrote:
>> and it's one reason less to make errors:
>> Using 'int' instead of 'quint64' or 'size_t', or QString instead of 
>> QByteArray 
>> is way to frequent. (and the compiler won't complain)
> 
> ["QString instead of QByteArray" does not happen with proper
> QT_NO__CAST_*_ASCII settings.  Not to mention the cases where mindless
> replacement of explicit types by 'auto' doesn't produce identical results.]

But wrongly mixing integer types *does* happen. I speak from personal
experience based on a code base that has a relatively large mess of
*exactly* such errors.

> Code is typically read more often than changed. Targeting at making
> specific refactorings easier is optimizing the wrong utility function.

Which of these is easier to read? (More importantly, which is easier to
*verify* that it is correct?)

  for (int i = 0; i < list.size(); ++i)
foo(list[i]);

  for (auto i : qtIndexRange(list.size())
foo(list[i]);

Which is *really* more meaningful? "The type of 'i' is 'int', and I
really, really hope that 'list' is actually indexed by 'int'", or "the
type of 'i' is the index type of 'list'¹"?

Do you really *care* what is the type of 'i'? Or do you care that it is
the *correct* type. I (and others) submit that the latter is more valuable.

(¹ ...assuming that decltype(list.size()) is the index type, which it
had darned well better be or whoever wrote the API of decltype(list)
needs to have their coding privileges revoked.)

-- 
Matthew

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

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

[Matthew Woehlke]

On 2015-12-04 17:43, André Pönitz wrote:
> On Fri, Dec 04, 2015 at 04:33:26PM -0500, Matthew Woehlke wrote:
>> Which of these is easier to read? (More importantly, which is easier to
>> *verify* that it is correct?)
>>
>>   for (int i = 0; i < list.size(); ++i)
>> foo(list[i]);
> 
> Whether the access is correct depends on the type of list, which you don't
> disclose.

That's sort of *the point*. I can't tell if the above is correct or not.
If it used 'auto', I'd know.

(And it's sort of implied that it *is* wrong. Because, y'know, I see
loops like the above quite often where, indeed, they do in fact use the
wrong type. Actually, QList/QVector are about the *only* times the above
is written correctly without using 'auto'. More often than not, a loop
like that written against a non-Qt container uses the wrong index type.)

> In any case, this loop follows a well-known pattern.

It also follows a really *bad* pattern. The count is reevaluated every
time (well, you hope the compiler will hoist it, but the code says that
it is). Using type deduction... well, sucks:

  for (auto i = decltype(list.size()){0}; i < list.size(); ++i)

>>   for (auto i : qtIndexRange(list.size())
>> foo(list[i]);
> 
> In any case, this is an uncommon pattern, using some unknown qtIndexRange()
> function.

Really?

  (Python)
  for i in range(len(list))

Just because it isn't standardized (or in Qt) yet doesn't mean it's
"unheard of". It's just that C++ users have been suffering with the
difficult to use form while programmers in other languages have had the
much more sensible form for a long time.

Really, it's not hard... nasty glorified while loop vs. 'I want to
iterate over the indices [starting at zero] up to list.size()'.

There's a reason I strongly prefer the latter form and use it whenever I
can (usually subject to compiler compatibility limitations).

> Moreover it is more to type.

Really?

  for (auto i : qtInlist.si))
 - vs. -
  for (int i = 0; i < list.si; ++i)

Hey, look... mine's *fewer* keystrokes. And much more importantly, it's
*correct*. Yours... may or may not be... as you pointed out, I don't
know without knowing decltype(list). (Or I could use the much longer,
*much* uglier old-style for loop with decltype that is correct, but then
mine wins hands-down.)

> The extra level of parantheses makes it harder to parse for
> humans,introducing an aditional source of errors, which you nicely
> demonstrated by making the example non-compilable.

Bah. A decent IDE would have flagged that as soon as I stopped typing.
(Actually, a decent *text editor* would have shown me () matches, so I
would have noticed *as* I was typing. I challenge you to write bug-free
code the first time in a text editor whose most advanced feature is cut
and paste.)

>> Which is *really* more meaningful?
> 
> The first one.

Sorry, but I must strongly disagree.

>> "The type of 'i' is 'int', and I
>> really, really hope that 'list' is actually indexed by 'int'", or "the
>> type of 'i' is the index type of 'list'¹"?
>>
>> Do you really *care* what is the type of 'i'?
> 
> Yes, I do care about types, almost always.

Why? As long as it's the *correct* type, what difference did it make?

Let's say that the correct type is my_list::index_t. Let's say I used that:

  for (my_list::index_t i = 0; i < list.size(); ++i)

How is that better? Do you know now what is the actual type of 'i'?

I submit that writing 'my_list::index_t' is not a significant
improvement over 'auto'. It didn't tell you anything about the actual
type of 'i'. (It does suggest that the type of 'list' might be 'my_list'
and that a 'my_list' probably uses 'my_list::index_t' as its indexing
type. But there's still that "probably". Whereas 'auto' says the type
*is* the indexing type.)

> Your message has been heard. I do not agree with you.

Likewise.

> I feel more comfortable arguing about whether a type is the right one
> if the type is known than when it is unknown.

Then you are missing the point. In fact, you are missing the whole point
of 'auto'. By using 'auto' correctly, it's possible to know that the
type *is correct*, even if you don't know what the type actually *is*.
(Or if a change elsewhere should change what is the correct type.)

-- 
Matthew

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

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

[Marc Mutz]

On Friday 04 December 2015 19:06:51 Oswald Buddenhagen wrote:
> it's not that anyone is confused, it's that your "aside" was inherently
> flawed: variables in python are dynamically typed, so the suggestion
> that they are "auto" in any way related to c++ makes no sense
> whatsoever. my response aimed merely at showing that even your little
> "joke" was off.

Again: I was referring to the omission of any form of type name when declaring 
variables. That Python is _also_ dynamically typed is correct, but irrelevant. 
If you have a problem distinguishing these two orthogonal issues, s/Python/C#/

Thanks,
Marc

-- 
Marc Mutz  | Senior Software Engineer
KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
Tel: +49-30-521325470
KDAB - The Qt Experts
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

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

[André Pönitz]

On Fri, Dec 04, 2015 at 08:01:59PM +0100, Olivier Goffart wrote:
> > > You don't see any type.
> > > 
> > > This code that use auto is not less readable. Even if you don't know
> > > what's the type of bar without looking it up.
> > > 
> > >   auto *bar = foo->bar();
> > >   bar->setFaz(m_factory->createFaz(bar->type()));
> > 
> > Isn't this kind of a bad example, because there was no type declared/visible
> > in the first place?
> 
> Precisely my point!   
> There is no type visible before and nobody complains.  So why should one 
> suddenly complains there are no types in the second snippet

Because they are different from a human reader's point of view.

In the second snippet the scope of the 'bar' is larger than for an immediate
use. This loses the context in which it is used, i.e. makes it harder to
reason about whether the use is ok, and adds load on a human reader that
needs to keep mental track of this 'untyped' item when reading the code until
it goes out of scope in case there's another use of this item.

Both alternatives help to reduce that load:

- immediate consumption of the temporary makes it explicit that the item is
  used exactly once and provides the consumer as additional context, helping
  judging whether the use is ok,

- using a separate line with a real type provides a stepping stone by
  giving additional information about the intermediate item *to the
  human reader*, helping him to split the task of verifying that
  'the right thing is produced and consumed' into smaller subtasks.

> > I really dislike hiding types behind a generic keyword.
> 
> Because the type is redundent

It might be redundant for the compiler, but it is not for human
readers of the code.

> and it's one reason less to make errors:
> Using 'int' instead of 'quint64' or 'size_t', or QString instead of 
> QByteArray 
> is way to frequent. (and the compiler won't complain)

["QString instead of QByteArray" does not happen with proper
QT_NO__CAST_*_ASCII settings.  Not to mention the cases where mindless
replacement of explicit types by 'auto' doesn't produce identical results.]

> It is also refactoring-proof.  Because you might want to change the name of
> the type from "FazManager" to "FazHolder", and then you need to touch less
> code in your refactoring

Code is typically read more often than changed. Targeting at making
specific refactorings easier is optimizing the wrong utility function.

Andre'
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

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

[Bubke Marco]

On December 4, 2015 21:33:57 André Pönitz  wrote:

> On Fri, Dec 04, 2015 at 08:01:59PM +0100, Olivier Goffart wrote:
>> > > You don't see any type.
>> > > 
>> > > This code that use auto is not less readable. Even if you don't know
>> > > what's the type of bar without looking it up.
>> > > 
>> > >   auto *bar = foo->bar();
>> > >   bar->setFaz(m_factory->createFaz(bar->type()));
>> > 
>> > Isn't this kind of a bad example, because there was no type 
>> > declared/visible
>> > in the first place?
>> 
>> Precisely my point!   
>> There is no type visible before and nobody complains.  So why should one 
>> suddenly complains there are no types in the second snippet
>
> Because they are different from a human reader's point of view.
>
> In the second snippet the scope of the 'bar' is larger than for an immediate
> use. This loses the context in which it is used, i.e. makes it harder to
> reason about whether the use is ok, and adds load on a human reader that
> needs to keep mental track of this 'untyped' item when reading the code until
> it goes out of scope in case there's another use of this item.
>
> Both alternatives help to reduce that load:
>
> - immediate consumption of the temporary makes it explicit that the item is
>   used exactly once and provides the consumer as additional context, helping
>   judging whether the use is ok,
>
> - using a separate line with a real type provides a stepping stone by
>   giving additional information about the intermediate item *to the
>   human reader*, helping him to split the task of verifying that
>   'the right thing is produced and consumed' into smaller subtasks.

For subtask you should write a new function with a descriptive name. Actually I 
don't buy they argument that explicit types improve readability so much as we 
allow long functions which do many subtasks. In python a never missed the types 
and python code in general is in my opinion much more readable. In my opinion 
is the culture and not so much the style guides. 

I think readable code is produced by programmers who care and not so much by 
style guides. It is easy to write unreadable code which complies to a style 
guide but much harder to write good readable code. And if I look at our code I 
must say I have seen much more readable code. So we have plenty space to 
improve. ;-)

I think we discuss the matter of types so much because we have not a good 
culture to give variables and functions descriptive names. And how to decompose 
larger functions in smaller thanks to describe the intention. It's not only Qt 
but C++ in general.

My argument for auto is quite simple that it is makes dependency  breaking 
easier which is very important for Test Driven Development. And if you have 
good tests you can refactore your code much easier because you know the 
probability to introduce new bugs by code changes is much lower. This 
refactorings leads to much better readable code. So my argument is that should 
be used if it leads to more readable code. Our style guide can only gives hints 
about it.  So developing rigid rules which stop the code to envolve in a more 
readable state is maybe not that smart.

In the end you have always trust in the developers that they cares about the 
readability of what they produce. 

So I would like to add the advise to use auto if it makes unit testing easier.

And with the clang code model we could add refactorings which change auto to 
the actual type too. But I  prefer to visulize it in a other way. We could 
provide some kind of overlay.

>> > I really dislike hiding types behind a generic keyword.
>> 
>> Because the type is redundent
>
> It might be redundant for the compiler, but it is not for human
> readers of the code.
>
>> and it's one reason less to make errors:
>> Using 'int' instead of 'quint64' or 'size_t', or QString instead of 
>> QByteArray 
>> is way to frequent. (and the compiler won't complain)
>
> ["QString instead of QByteArray" does not happen with proper
> QT_NO__CAST_*_ASCII settings.  Not to mention the cases where mindless
> replacement of explicit types by 'auto' doesn't produce identical results.]
>
>> It is also refactoring-proof.  Because you might want to change the name of
>> the type from "FazManager" to "FazHolder", and then you need to touch less
>> code in your refactoring
>
> Code is typically read more often than changed. Targeting at making
> specific refactorings easier is optimizing the wrong utility function.
>
> Andre'
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
Sent from cellphone 
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

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

[Bubke Marco]

On December 5, 2015 01:43:40 André Pönitz  wrote:

> On Fri, Dec 04, 2015 at 06:10:45PM -0500, Matthew Woehlke wrote:
>> On 2015-12-04 17:43, André Pönitz wrote:
>> > On Fri, Dec 04, 2015 at 04:33:26PM -0500, Matthew Woehlke wrote:
>> >> Which of these is easier to read? (More importantly, which is easier to
>> >> *verify* that it is correct?)
>> >>
>> >>   for (int i = 0; i < list.size(); ++i)
>> >> foo(list[i]);
>> > 
>> > Whether the access is correct depends on the type of list, which you don't
>> > disclose.
>> 
>> That's sort of *the point*. I can't tell if the above is correct or not.
>> If it used 'auto', I'd know.
>
> You don't know whether operator[] or .at() is the best way to access
> by index until you know the type of list. Once you know the type of
> list, you also know what the type of i should be. There's no point
> in being fuzzy about it unless there is a *significant* advantage
> to it (like using 'auto' for iterator types which are mostly line
> noise).
>
>> (And it's sort of implied that it *is* wrong. Because, y'know, I see
>> loops like the above quite often where, indeed, they do in fact use the
>> wrong type. Actually, QList/QVector are about the *only* times the above
>> is written correctly without using 'auto'. More often than not, a loop
>> like that written against a non-Qt container uses the wrong index type.)
>
> The context of this discussion is the development of Qt. Thank you for
> confirming that 'int' is the right thing to use.
>
>> > In any case, this loop follows a well-known pattern.
>> 
>> It also follows a really *bad* pattern. The count is reevaluated every
>> time (well, you hope the compiler will hoist it, but the code says that
>> it is). Using type deduction... well, sucks:
>> 
>>   for (auto i = decltype(list.size()){0}; i < list.size(); ++i)
>
> [
> If you care about size() re-evaluation:
>
> for (int i = 0, n = list.size(); i < n; ++i)
> ... 
> ]
>
>>   for (auto i : qtIndexRange(list.size())
>> >> foo(list[i]);
>> > 
>> > In any case, this is an uncommon pattern, using some unknown qtIndexRange()
>> > function.
>> 
>> Really?
>> 
>>   (Python)
>
> Please stay on topic. The topic was whether to be more 'liberal' with
> the use of auto in Qt, written mostly in C++, not Python.
>  
>> > 
>> > The extra level of parantheses makes it harder to parse for
>> > humans,introducing an aditional source of errors, which you nicely
>> > demonstrated by making the example non-compilable.
>> 
>> Bah. A decent IDE would have flagged that as soon as I stopped typing.
>
> You are basically assuming that there's no need for you to write sane
> code to start with because during your development work you have a
> decent IDE to help you out. This assumption is wrong, independent
> of the existence of such an IDE.
>
> Since the discussion here is about what to use in Qt, the whole Qt
> development workflow matters. A lot of Qt code reading happens on Gerrit
> without IDE features at hand. The context there usually just a few lines.
> The appropriateness of an expression 'list[x]' is impossible to judge
> on Gerrit after applying an 'Almost always auto' policy.

Oswald and I spoke about using the clang code model to provide the information 
to gerrit too. It should be not that hard.

But you have to import the code in the IDE anyway because of the missing 
context.  For non trivial change review the calling context is far to important 
to be ignored. A html code browser could change that but we don't have one in 
gerrit. 

> This argument is not restricted to 'auto'. In general, code patterns
> that rely completely on IDE support are not beneficial for Qt
> development.
>
>> [...]
>> >> Which is *really* more meaningful?
>> > 
>> > The first one.
>> 
>> Sorry, but I must strongly disagree.
>
> So we agree to disagree. This was a call for comments. We've now 
> established the fact that there's no consensus on this matter.
>
>> In fact, you are missing the whole point of 'auto'.
>
> I don't think so.
>
>> By using 'auto' correctly, it's possible to know that the
>> type *is correct*, even if you don't know what the type actually *is*.
>
> You are missing the fact that Qt development is not an IDE-only workflow
> and does in general not operate on complete translation unit. You also
> do not seem to believe that at least some humans need a bit more explicit
> context than compilers to efficiently read code.
>
> Andre'
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
Sent from cellphone 
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

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

[André Pönitz]

On Fri, Dec 04, 2015 at 06:10:45PM -0500, Matthew Woehlke wrote:
> On 2015-12-04 17:43, André Pönitz wrote:
> > On Fri, Dec 04, 2015 at 04:33:26PM -0500, Matthew Woehlke wrote:
> >> Which of these is easier to read? (More importantly, which is easier to
> >> *verify* that it is correct?)
> >>
> >>   for (int i = 0; i < list.size(); ++i)
> >> foo(list[i]);
> > 
> > Whether the access is correct depends on the type of list, which you don't
> > disclose.
> 
> That's sort of *the point*. I can't tell if the above is correct or not.
> If it used 'auto', I'd know.

You don't know whether operator[] or .at() is the best way to access
by index until you know the type of list. Once you know the type of
list, you also know what the type of i should be. There's no point
in being fuzzy about it unless there is a *significant* advantage
to it (like using 'auto' for iterator types which are mostly line
noise).

> (And it's sort of implied that it *is* wrong. Because, y'know, I see
> loops like the above quite often where, indeed, they do in fact use the
> wrong type. Actually, QList/QVector are about the *only* times the above
> is written correctly without using 'auto'. More often than not, a loop
> like that written against a non-Qt container uses the wrong index type.)

The context of this discussion is the development of Qt. Thank you for
confirming that 'int' is the right thing to use.

> > In any case, this loop follows a well-known pattern.
> 
> It also follows a really *bad* pattern. The count is reevaluated every
> time (well, you hope the compiler will hoist it, but the code says that
> it is). Using type deduction... well, sucks:
> 
>   for (auto i = decltype(list.size()){0}; i < list.size(); ++i)

[
If you care about size() re-evaluation:

for (int i = 0, n = list.size(); i < n; ++i)
... 
]

>   for (auto i : qtIndexRange(list.size())
> >> foo(list[i]);
> > 
> > In any case, this is an uncommon pattern, using some unknown qtIndexRange()
> > function.
> 
> Really?
> 
>   (Python)

Please stay on topic. The topic was whether to be more 'liberal' with
the use of auto in Qt, written mostly in C++, not Python.
 
> > 
> > The extra level of parantheses makes it harder to parse for
> > humans,introducing an aditional source of errors, which you nicely
> > demonstrated by making the example non-compilable.
> 
> Bah. A decent IDE would have flagged that as soon as I stopped typing.

You are basically assuming that there's no need for you to write sane
code to start with because during your development work you have a
decent IDE to help you out. This assumption is wrong, independent
of the existence of such an IDE.

Since the discussion here is about what to use in Qt, the whole Qt
development workflow matters. A lot of Qt code reading happens on Gerrit
without IDE features at hand. The context there usually just a few lines.
The appropriateness of an expression 'list[x]' is impossible to judge
on Gerrit after applying an 'Almost always auto' policy.

This argument is not restricted to 'auto'. In general, code patterns
that rely completely on IDE support are not beneficial for Qt
development.

> [...]
> >> Which is *really* more meaningful?
> > 
> > The first one.
> 
> Sorry, but I must strongly disagree.

So we agree to disagree. This was a call for comments. We've now 
established the fact that there's no consensus on this matter.

> In fact, you are missing the whole point of 'auto'.

I don't think so.

> By using 'auto' correctly, it's possible to know that the
> type *is correct*, even if you don't know what the type actually *is*.

You are missing the fact that Qt development is not an IDE-only workflow
and does in general not operate on complete translation unit. You also
do not seem to believe that at least some humans need a bit more explicit
context than compilers to efficiently read code.

Andre'
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

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

[Olivier Goffart]

On Friday 4. December 2015 21:35:16 André Pönitz wrote:
> On Fri, Dec 04, 2015 at 08:01:59PM +0100, Olivier Goffart wrote:
> > > > You don't see any type.
> > > > 
> > > > This code that use auto is not less readable. Even if you don't know
> > > > what's the type of bar without looking it up.
> > > > 
> > > >   auto *bar = foo->bar();
> > > >   bar->setFaz(m_factory->createFaz(bar->type()));
> > > 
> > > Isn't this kind of a bad example, because there was no type
> > > declared/visible in the first place?
> > 
> > Precisely my point!
> > There is no type visible before and nobody complains.  So why should one
> > suddenly complains there are no types in the second snippet
> 
> Because they are different from a human reader's point of view.
> 
> In the second snippet the scope of the 'bar' is larger than for an immediate
> use.

That's a good argument for the need of sensible variable name,  but not for 
mandating to write explicitly the type.

> This loses the context in which it is used, i.e. makes it harder to
> reason about whether the use is ok, and adds load on a human reader that
> needs to keep mental track of this 'untyped' item when reading the code
> until it goes out of scope in case there's another use of this item.

If you were able to reason about   foo->bar()  in the first snippet without 
having the type explicitly written, why would the human reader need to see the 
type explicitly written in the second siuppet?

> Both alternatives help to reduce that load:
> 
> - immediate consumption of the temporary makes it explicit that the item is
>   used exactly once and provides the consumer as additional context, helping
> judging whether the use is ok,
> 
> - using a separate line with a real type provides a stepping stone by
>   giving additional information about the intermediate item *to the
>   human reader*, helping him to split the task of verifying that
>   'the right thing is produced and consumed' into smaller subtasks.

There might be cases where the type name is an important information and in 
that case we should put it of course.  But in many case it is not.
In the given example, 'bar' is only used locally.
What might be more interesting is a decent variable name. 
Yet, it is frequent to see non-descriptive names for such localy used 
variable. That's because this information is obvious and redundant.

> > > I really dislike hiding types behind a generic keyword.
> > 
> > Because the type is redundent
> 
> It might be redundant for the compiler, but it is not for human
> readers of the code.


Another example:

   fazCount++; // Increment the fazCount by one.
   name.remove(' '); // Remove all the spaces from the name.

Following your argument, the comments makes the code more readable? The human 
reader might not know what remove() does? Then such comments should be 
mandatory? In practice, someone familiar with the code base will know what 
Foo::bar() returns.

> > and it's one reason less to make errors:
> > Using 'int' instead of 'quint64' or 'size_t', or QString instead of
> > QByteArray is way to frequent. (and the compiler won't complain)
> 
> ["QString instead of QByteArray" does not happen with proper
> QT_NO__CAST_*_ASCII settings.  Not to mention the cases where mindless
> replacement of explicit types by 'auto' doesn't produce identical results.]

The point is: it is just another oportunity to make mistakes.

> > It is also refactoring-proof.  Because you might want to change the name
> > of the type from "FazManager" to "FazHolder", and then you need to touch
> > less code in your refactoring
> 
> Code is typically read more often than changed. Targeting at making
> specific refactorings easier is optimizing the wrong utility function.

I'm claiming that auto often does not harm readability.
Given that, optimizing to make refactoring easier will allow the code base to 
evolve and to stay readable when things are changing



Just to be clear. I'm not advocating to use auto everywhere. I'm just saying 
that the coding style is currently too strict by forbiding auto in most cases.



___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

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

[Bubke Marco]

I think the discussion is getting in an antagonistic direction and we should 
get back to our normal agonistic way or maybe being cooperative. ;-)

I have seen big systems in dynamically languages like small talk or python and 
except that they were slower they look actually much more readable. So I think 
history have shown that type declaration is not the key to readable code. In my 
opinion it is the excuse to find good names. ;-)

And what we should not forget is that tools getting better. So old rules can 
getting unproductive in a changing context. In my opinion we have to adapt to a 
changing context all the time and old wisdom can  loose it's usefulness fast.

So what about reviewing our style guides from time to time.  With tools like 
clang format and clang tidy it should be not that hard to adapt code to a 
changed style guide. 

On December 5, 2015 00:11:14 Matthew Woehlke  wrote:

> On 2015-12-04 17:43, André Pönitz wrote:
>> On Fri, Dec 04, 2015 at 04:33:26PM -0500, Matthew Woehlke wrote:
>>> Which of these is easier to read? (More importantly, which is easier to
>>> *verify* that it is correct?)
>>>
>>>   for (int i = 0; i < list.size(); ++i)
>>> foo(list[i]);
>> 
>> Whether the access is correct depends on the type of list, which you don't
>> disclose.
>
> That's sort of *the point*. I can't tell if the above is correct or not.
> If it used 'auto', I'd know.
>
> (And it's sort of implied that it *is* wrong. Because, y'know, I see
> loops like the above quite often where, indeed, they do in fact use the
> wrong type. Actually, QList/QVector are about the *only* times the above
> is written correctly without using 'auto'. More often than not, a loop
> like that written against a non-Qt container uses the wrong index type.)
>
>> In any case, this loop follows a well-known pattern.
>
> It also follows a really *bad* pattern. The count is reevaluated every
> time (well, you hope the compiler will hoist it, but the code says that
> it is). Using type deduction... well, sucks:
>
>   for (auto i = decltype(list.size()){0}; i < list.size(); ++i)
>
>>>   for (auto i : qtIndexRange(list.size())
>>> foo(list[i]);
>> 
>> In any case, this is an uncommon pattern, using some unknown qtIndexRange()
>> function.
>
> Really?
>
>   (Python)
>   for i in range(len(list))

for index,  value in enumerate(iteratable):
print(index,  value) 

would be much better because index accesses are quite slow. But it shows nicely 
why types can reduce readability. 

for (auto {index,  value} : enumerate(iteratable)) 

Is so far I understand the new syntax in C++. Actually I  want to use that 
because it makes code much more readable. 

Think about 

auto {value ,  isConvertable}  = variant.toDouble();

In that case auto would enforce the test much more and the code is very 
readable too. 

> Just because it isn't standardized (or in Qt) yet doesn't mean it's
> "unheard of". It's just that C++ users have been suffering with the
> difficult to use form while programmers in other languages have had the
> much more sensible form for a long time.
>
> Really, it's not hard... nasty glorified while loop vs. 'I want to
> iterate over the indices [starting at zero] up to list.size()'.
>
> There's a reason I strongly prefer the latter form and use it whenever I
> can (usually subject to compiler compatibility limitations).
>
>> Moreover it is more to type.
>
> Really?
>
>   for (auto i : qtInlist.si))
>  - vs. -
>   for (int i = 0; i < list.si; ++i)
>
> Hey, look... mine's *fewer* keystrokes. And much more importantly, it's
> *correct*. Yours... may or may not be... as you pointed out, I don't
> know without knowing decltype(list). (Or I could use the much longer,
> *much* uglier old-style for loop with decltype that is correct, but then
> mine wins hands-down.)
>
>> The extra level of parantheses makes it harder to parse for
>> humans,introducing an aditional source of errors, which you nicely
>> demonstrated by making the example non-compilable.
>
> Bah. A decent IDE would have flagged that as soon as I stopped typing.
> (Actually, a decent *text editor* would have shown me () matches, so I
> would have noticed *as* I was typing. I challenge you to write bug-free
> code the first time in a text editor whose most advanced feature is cut
> and paste.)
>
>>> Which is *really* more meaningful?
>> 
>> The first one.
>
> Sorry, but I must strongly disagree.
>
>>> "The type of 'i' is 'int', and I
>>> really, really hope that 'list' is actually indexed by 'int'", or "the
>>> type of 'i' is the index type of 'list'¹"?
>>>
>>> Do you really *care* what is the type of 'i'?
>> 
>> Yes, I do care about types, almost always.
>
> Why? As long as it's the *correct* type, what difference did it make?
>
> Let's say that the correct type is my_list::index_t. Let's say I used that:
>
>   for (my_list::index_t i = 0; i < list.size(); ++i)
>
> How is that better? Do you know now what is the actual type of 'i'?

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

[Thiago Macieira]

On Saturday 05 December 2015 00:57:23 Bubke Marco wrote:
> Oswald and I spoke about using the clang code model to provide the
> information to gerrit too. It should be not that hard.

Please make sure those changes are making their way to Gerrit upstream.

Forking Gerrit is not a good idea.
-- 
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

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

[Oswald Buddenhagen]

On Fri, Dec 04, 2015 at 07:30:10PM +0100, Marc Mutz wrote:
> On Friday 04 December 2015 14:32:22 Oswald Buddenhagen wrote:
> > > But auto is still staticaly typed.
> > > 
> > 
> > that's why using a scripting language as a source of arguments wasn't a
> > very wise move tactically, even as an aside. ;)
> 
> I, indeed, did not anticipate that anyone here would be able to seriously 
> confuse static typing and var/auto, the omitting of the type name in variable 
> declarations.
> 
it's not that anyone is confused, it's that your "aside" was inherently
flawed: variables in python are dynamically typed, so the suggestion
that they are "auto" in any way related to c++ makes no sense
whatsoever. my response aimed merely at showing that even your little
"joke" was off.

> I have the feeling I wasn't wrong, though.
> 
???
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

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

[Bubke Marco]

On December 4, 2015 17:49:08 Thiago Macieira  wrote:

> On Friday 04 December 2015 16:20:44 Bubke Marco wrote:
>> The clang code model completes auto so it should be not that hard.  Actually
>> I would call an ordered map or unordered map a dictionary. 
>
> Does Creator have a way to reveal the deduced type of an auto? That would go 
> a 
> long way to alleviating the pain of using it.

In the clang code model we use the clang AST. So if the compiler knows it, we 
can show it. It's on the roadmap for 3.7.

> -- 
> 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
Sent from cellphone 
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

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

[Olivier Goffart]

On Friday 4. December 2015 15:39:01 Curtis Mitch wrote:
> > -Original Message-
> > From: Development [mailto:development-boun...@qt-project.org] On Behalf Of
> > Olivier Goffart
> > Sent: Friday, 4 December 2015 2:25 PM
> > To: development@qt-project.org
> > Subject: Re: [Development] RFC: more liberal 'auto' rules?
> > 
> > On Friday 4. December 2015 14:11:48 Oswald Buddenhagen wrote:
> > > On Fri, Dec 04, 2015 at 02:07:10PM +0100, Marc Mutz wrote:
> > > > And as an aside, since it has been mentioned in this thread: in
> > > > Python _all_ variables are 'auto'. All. Without exception. Are
> > > > Python programmers more intelligent? Or do they just tolerate more
> > > > pain? :)
> > > 
> > > i'd suggest the latter.
> > > no, really. people use external static checkers because the language
> > > lacks the feature.
> > > the lack of static typing is a common feature of scripting languages
> > > and makes them convenient to a degree, but it is an utter nightmare
> > > for any "real" software development. i really wouldn't want to go there.
> > 
> > But auto is still staticaly typed.
> > 
> > 
> > When you have code like
> > 
> >foo->bar()->setFaz(m_factory->createFaz(foo->bar()->type()));
> > 
> > You don't see any type.
> > 
> > This code that use auto is not less readable. Even if you don't know
> > what's the type of bar without looking it up.
> > 
> >   auto *bar = foo->bar();
> >   bar->setFaz(m_factory->createFaz(bar->type()));
> 
> Isn't this kind of a bad example, because there was no type declared/visible
> in the first place?

Precisely my point!   
There is no type visible before and nobody complains.  So why should one 
suddenly complains there are no types in the second snippet

> Anyway, if you're going to take the time to move the result of foo->bar()
> onto its own line, why not just declare a type? What benefit does auto give
> here?
> 
> I really dislike hiding types behind a generic keyword.

Because the type is redundent and it's one reason less to make errors:
Using 'int' instead of 'quint64' or 'size_t', or QString instead of QByteArray 
is way to frequent. (and the compiler won't complain)

It is also refactoring-proof.  Because you might want to change the name of 
the type from "FazManager" to "FazHolder", and then you need to touch less 
code in your refactoring. 

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

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

[Olivier Goffart]

On Friday 4. December 2015 13:12:00 Rafael Roquetto wrote:
> On Fri, Dec 04, 2015 at 02:25:14PM +0100, Olivier Goffart wrote:
> > On Friday 4. December 2015 14:11:48 Oswald Buddenhagen wrote:
> > > On Fri, Dec 04, 2015 at 02:07:10PM +0100, Marc Mutz wrote:
> > > > And as an aside, since it has been mentioned in this thread: in Python
> > > > _all_ variables are 'auto'. All. Without exception. Are Python
> > > > programmers more intelligent? Or do they just tolerate more pain? :)
> > > 
> > > i'd suggest the latter.
> > > no, really. people use external static checkers because the language
> > > lacks the feature.
> > > the lack of static typing is a common feature of scripting languages and
> > > makes them convenient to a degree, but it is an utter nightmare for any
> > > "real" software development. i really wouldn't want to go there.
> > 
> > But auto is still staticaly typed.
> > 
> > 
> > When you have code like
> > 
> >foo->bar()->setFaz(m_factory->createFaz(foo->bar()->type()));
> > 
> > You don't see any type.
> > 
> > This code that use auto is not less readable. Even if you don't know
> > what's
> > the type of bar without looking it up.
> > 
> >   auto *bar = foo->bar();
> >   bar->setFaz(m_factory->createFaz(bar->type()));
> 
> Until you need to change your code and call any method of bar. Suppose I
> need to change the following code, to print the first item of the
> collection:
> 
> auto *bar = foo->collection();
> 
> /*TODO: print first item here */
> 
> model->setCollection(bar); // we know bar is a collection, but of what
> kind?
> 
> 
> Choose the right alternative:
> 
> a) qDebug() << bar->first();
> b) qDebug() << bar->values().first();
> c) qDebug() << bar[0]
> d) none of the above
> 
> 
> To answer this, you will need to find out the return type of
> Foo::collection(); The compiler knows it, but the reader does not. And the
> answer depends on whether it is  a QList/QVector, QHash/QMap, etc... Had it
> been explicit, any programmer familiar with the Qt API (or any API in
> context) would be able to directly write down the right statement.

Ok, so i'll write it like this:

  AddresseeList *bar = foo->collection();

Is it better? do you know how to print the first element? You anyway need to 
look up what the AdresseeList typedef is. (Yes, it was made a typedef so one 
can more easily change what is the underlying, it's not so untypical)
You anyway have to know or lookup all the code you play around. 
Someone familiar with the codebase knows what Foo::collection() returns or can 
quickly look it up.
But the day somebody fixes the API and returns a  "const AddresseeList*" 
instead, you have to fix the locations you did not use auto.


___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

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

[Randall O'Reilly]

This debate between the std:: lib and wider C++ community vs. the Qt traditions 
seems never-ending :)  At the risk of perpetuating the inevitable flame war, my 
perspective is well captured in this article:  
http://simpleprogrammer.com/2012/12/01/why-c-is-not-back/

C++ is WAY too complex of a language, and other alternatives are rapidly 
gaining users (particularly Python in the domain of scientific computing).  The 
STL and its sea of recursive templates has in particular been incredibly 
daunting.  C++11 helps, but the complexity remains..

Of course, there is no “right” answer in any of these language debates: only 
different people optimizing different ends of many different fundamental 
tradeoffs.

C and C++ in general tend to attract people who favor optimization over 
simplicity / usability of the language.  Marc is clearly in that camp, 
advocating many ways of optimizing performance..  With all the new language 
options, presumably those that stick with C++ are even more apt to be obsessed 
with performance..

But Qt is beloved by many (myself included) because it provides a *simple*, 
elegant, well-designed, well-named API, that does a lot of stuff..  Not because 
of its optimal performance or cutting-edge language features and adherence to 
the C++ standard..

I got “stuck” in C++ for historical reasons: it was the only viable option for 
object-oriented programming in the 1990’s.  Sure, I care about optimization for 
my critical inner loops.  But for everything else, I really wish it was a lot 
simpler.  And again, I value Qt for making it so in the GUI, which consumes a 
huge amount of my code, and has minimal performance demands, because it is a 
GUI and the human in the loop is almost always the rate limiting factor.  Of 
course we don’t want exponential slowdowns with large numbers of Widgets etc, 
but I’ve never found that to be a problem in Qt.

So anyway, this is just a vote to keep with the solid tradition of favoring 
simplicity, clarity, usability, readability, etc, instead of just following the 
std:: C++ crowd!  Without Qt, I would have to suck it up and rewrite everything 
in Go or Python or something.. :)

- Randy

> On Dec 4, 2015, at 12:49 AM, Marc Mutz  wrote:
> 
> On Friday 04 December 2015 02:56:11 Thiago Macieira wrote:
>> On Thursday 03 December 2015 14:14:19 Thiago Macieira wrote:
>>> That depends on how big the remainder is. I argue that we're relevant
>>> enough  that our own direction is big enough to be of relevance.
>> 
>> That didn't come out right. Rephrasing:
>> 
>> Qt has enough market share by itself that we can choose our own direction
>> and still be relevant. We are allowed to disagree with what others do.
> 
> Yes, but only if we know *better*.
> 
> I very much doubt that more than very few people in Qt development have the 
> knowledge to objectively overrule the accepted C++ authorities. I myself have 
> seen over and over again that how I thought a feature should be used was 
> blown 
> to smithereens by members of the committee, usually rightfully so.
> 
> So the default should be to follow what the greater C++ community is doing, 
> while *divergence* from that needs to be argued for.
> 
> Everything else is approaching hubris, imo.
> 
>> we don't use exceptions
> 
> ...and look at the sorry state of error handling in Qt - every class does it 
> differently... It's ok not to use exceptions, but not having a consistent 
> error 
> handling strategy doesn't put us into a position to throw that stone.
> 
>> we don't use underscores
> 
> ... except we do (grep "qt_"). And there's *nothing* wrong with that!
> 
> Thanks,
> Marc
> 
> -- 
> Marc Mutz  | Senior Software Engineer
> KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
> Tel: +49-30-521325470
> KDAB - The Qt Experts
> ___
> 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] RFC: more liberal 'auto' rules?

[Smith Martin]

+1

martin


From: Development <development-boun...@qt-project.org> on behalf of Randall 
O'Reilly <randy.orei...@colorado.edu>
Sent: Friday, December 04, 2015 8:35 AM
To: Marc Mutz
Cc: development@qt-project.org
Subject: Re: [Development] RFC: more liberal 'auto' rules?

This debate between the std:: lib and wider C++ community vs. the Qt traditions 
seems never-ending :)  At the risk of perpetuating the inevitable flame war, my 
perspective is well captured in this article:  
http://simpleprogrammer.com/2012/12/01/why-c-is-not-back/

C++ is WAY too complex of a language, and other alternatives are rapidly 
gaining users (particularly Python in the domain of scientific computing).  The 
STL and its sea of recursive templates has in particular been incredibly 
daunting.  C++11 helps, but the complexity remains..

Of course, there is no “right” answer in any of these language debates: only 
different people optimizing different ends of many different fundamental 
tradeoffs.

C and C++ in general tend to attract people who favor optimization over 
simplicity / usability of the language.  Marc is clearly in that camp, 
advocating many ways of optimizing performance..  With all the new language 
options, presumably those that stick with C++ are even more apt to be obsessed 
with performance..

But Qt is beloved by many (myself included) because it provides a *simple*, 
elegant, well-designed, well-named API, that does a lot of stuff..  Not because 
of its optimal performance or cutting-edge language features and adherence to 
the C++ standard..

I got “stuck” in C++ for historical reasons: it was the only viable option for 
object-oriented programming in the 1990’s.  Sure, I care about optimization for 
my critical inner loops.  But for everything else, I really wish it was a lot 
simpler.  And again, I value Qt for making it so in the GUI, which consumes a 
huge amount of my code, and has minimal performance demands, because it is a 
GUI and the human in the loop is almost always the rate limiting factor.  Of 
course we don’t want exponential slowdowns with large numbers of Widgets etc, 
but I’ve never found that to be a problem in Qt.

So anyway, this is just a vote to keep with the solid tradition of favoring 
simplicity, clarity, usability, readability, etc, instead of just following the 
std:: C++ crowd!  Without Qt, I would have to suck it up and rewrite everything 
in Go or Python or something.. :)

- Randy

> On Dec 4, 2015, at 12:49 AM, Marc Mutz <marc.m...@kdab.com> wrote:
>
> On Friday 04 December 2015 02:56:11 Thiago Macieira wrote:
>> On Thursday 03 December 2015 14:14:19 Thiago Macieira wrote:
>>> That depends on how big the remainder is. I argue that we're relevant
>>> enough  that our own direction is big enough to be of relevance.
>>
>> That didn't come out right. Rephrasing:
>>
>> Qt has enough market share by itself that we can choose our own direction
>> and still be relevant. We are allowed to disagree with what others do.
>
> Yes, but only if we know *better*.
>
> I very much doubt that more than very few people in Qt development have the
> knowledge to objectively overrule the accepted C++ authorities. I myself have
> seen over and over again that how I thought a feature should be used was blown
> to smithereens by members of the committee, usually rightfully so.
>
> So the default should be to follow what the greater C++ community is doing,
> while *divergence* from that needs to be argued for.
>
> Everything else is approaching hubris, imo.
>
>> we don't use exceptions
>
> ...and look at the sorry state of error handling in Qt - every class does it
> differently... It's ok not to use exceptions, but not having a consistent 
> error
> handling strategy doesn't put us into a position to throw that stone.
>
>> we don't use underscores
>
> ... except we do (grep "qt_"). And there's *nothing* wrong with that!
>
> Thanks,
> Marc
>
> --
> Marc Mutz <marc.m...@kdab.com> | Senior Software Engineer
> KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
> Tel: +49-30-521325470
> KDAB - The Qt Experts
> ___
> 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
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

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

[Marc Mutz]

On Friday 04 December 2015 02:56:11 Thiago Macieira wrote:
> On Thursday 03 December 2015 14:14:19 Thiago Macieira wrote:
> > That depends on how big the remainder is. I argue that we're relevant
> > enough  that our own direction is big enough to be of relevance.
> 
> That didn't come out right. Rephrasing:
> 
> Qt has enough market share by itself that we can choose our own direction
> and still be relevant. We are allowed to disagree with what others do.

Yes, but only if we know *better*.

I very much doubt that more than very few people in Qt development have the 
knowledge to objectively overrule the accepted C++ authorities. I myself have 
seen over and over again that how I thought a feature should be used was blown 
to smithereens by members of the committee, usually rightfully so.

So the default should be to follow what the greater C++ community is doing, 
while *divergence* from that needs to be argued for.

Everything else is approaching hubris, imo.

> we don't use exceptions

...and look at the sorry state of error handling in Qt - every class does it 
differently... It's ok not to use exceptions, but not having a consistent error 
handling strategy doesn't put us into a position to throw that stone.

> we don't use underscores

... except we do (grep "qt_"). And there's *nothing* wrong with that!

Thanks,
Marc

-- 
Marc Mutz  | Senior Software Engineer
KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
Tel: +49-30-521325470
KDAB - The Qt Experts
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development