[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-frameworks-devel
Subject:    Re: Updating our coding conventions and coding style for C++11
From:       David Edmundson <david () davidedmundson ! co ! uk>
Date:       2020-01-17 9:09:39
Message-ID: CAGeFrHCC6vvLu3KAN8Eyo3XGhLcwCg-odMzeYZrsg0mWXbKO6g () mail ! gmail ! com
[Download RAW message or body]

On Thu, 16 Jan 2020, 22:46 Kai Uwe Broulik, <kde@privat.broulik.de> wrote:

>
> > Well, the * is completely redundant in those cases, so it doesn't bring
> anything.
> > I'd be tempted to say, let's not require it.
> > But then it raises the question of consistency (without a guideline,
> we'll have some places with * and some places without *).
>
> It provides useful visual information.
>


> auto foo = bar();
> auto baz = &bla;
>

Neither of those examples abide by the proposed Qt/Vlad rules, which I
think would render your issue moot.

I don't think I really understand your potential issue anyway, if you tried
to use baz form and it wasn't the type I expected it just wouldn't compile?

This is somewhat different to the case where have you have overloaded & and
non& operators, such as [] where I do I understand why it's useful.

I'll continue mandating that in code I maintain, even if it's not
> official policy.
>

The context of this original email being sent was that I got extremely
frustrated with per-project seemingly random rules.
I can happily follow a global policy even if I don't agree with it, but we
need to define things. Otherwise, we'll end up in this situation again.

David

[Attachment #3 (text/html)]

<div dir="ltr"><div dir="auto"><div><div class="gmail_quote"><div dir="ltr" \
class="gmail_attr">On Thu, 16 Jan 2020, 22:46 Kai Uwe Broulik, &lt;<a \
href="mailto:kde@privat.broulik.de" target="_blank">kde@privat.broulik.de</a>&gt; \
wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 \
.8ex;border-left:1px #ccc solid;padding-left:1ex"><br> &gt; Well, the * is completely \
redundant in those cases, so it doesn&#39;t bring anything.<br> &gt; I&#39;d be \
tempted to say, let&#39;s not require it.<br> &gt; But then it raises the question of \
consistency (without a guideline, we&#39;ll have some places with * and some places \
without *).<br> <br>
It provides useful visual information.<br></blockquote></div></div><div><div \
class="gmail_quote"><br><blockquote class="gmail_quote" style="margin:0 0 0 \
.8ex;border-left:1px #ccc solid;padding-left:1ex"> <br>
auto foo = bar();<br>
auto baz = &amp;bla;<br></blockquote><div><br></div><div>Neither of those examples \
abide by the proposed Qt/Vlad rules, which I think would render your issue \
moot.</div><div><br></div><div>I don&#39;t think I really understand your potential \
issue anyway, if you tried to use baz form and it wasn&#39;t the type I expected it \
just wouldn&#39;t compile?</div><div></div><div><br></div><div>This is somewhat \
different to the case where have you have overloaded &amp; and non&amp; operators, \
such as [] where I do I understand why it&#39;s useful.<br></div></div><div \
class="gmail_quote"><br><blockquote class="gmail_quote" style="margin:0 0 0 \
.8ex;border-left:1px #ccc solid;padding-left:1ex">I&#39;ll continue mandating that in \
code I maintain, even if it&#39;s not <br> official \
policy.<br></blockquote></div></div><div dir="auto"><br></div><div>The context of \
this original email being sent was that I got extremely frustrated with per-project \
seemingly random rules. <br></div><div>I can happily follow a global policy even if I \
don&#39;t agree with it, but we need to define things. Otherwise, we&#39;ll end up in \
this situation again.<br></div><div dir="auto"></div><div></div><div \
dir="auto"><br></div></div><div>David<br></div> </div>



[prev in list] [next in list] [prev in thread] [next in thread]