Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:

> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>
>> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>>
>>> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>>>
>>>> Andrey Tarasevich <andreytarasevich@hotmail.com> writes:
>>>>
>>>>> On 02/21/23 6:12 AM, Alf P. Steinbach wrote:
>>>>>
>>>>>> Not what you're asking, but the common convention in C++ is to
>>>>>> separate the type specification from the variable, i.e. `auto& c`
>>>>>> not `auto &c`.
>>>>>>
>>>>>> But on the third and gripping hand, in this case I'd write `char&
>>>>>> c`, since there's no advantage in `auto` here and it obscures
>>>>>> things.
>>>>>
>>>>> Not really. This is a misleading "convention" that has no reason to
>>>>> exist. In this case the `&` is a part of an individual declarator,
>>>>> not a part of decl-specifier-seq. There's no reason to group the
>>>>> syntactic elements differently. It achieves nothing.
>>>>
>>>> I would say it achieves less than nothing, because it's misleading.
>>>> It's like writing a+b * c ; the grouping suggested by the spacing
>>>> doesn't match the actual precedence. In almost all cases it's a
>>>> mistake to use "contra-syntactic" spacing, and attaching '&' or '*'
>>>> to a type specifier is definitely one of those mistakes.
>>>
>>> I prefer the "int *foo;" spacing (conventional in C) because it follows
>>> the syntax, but the "int* foo;" spacing has become a convention in C++
>>> (probably because Stroustrup uses it in his books), and I use it in C++
>>> for that reason. I also avoid declarations where it would make a
>>> difference to a human reader, like "int* foo, bar;".
>>>
>>> Most development is on existing code. It would be poor practice to use
>>> the "better" spacing on new code while leaving the existing code (which
>>> most likely uses the C++ conventional spacing) as it is. It would also
>>> be poor practice to change all the spacing in a large body of existing
>>> code.
>>
>> I'm sure there are lots of people who agree with that opinion,
>> but that doesn't make it anything more than just an opinion.
>
> Obviously.
>
> Did you have anything *useful* to add?

As a rule I don't like to participate in discussions of programming
style that are purely subjective.

I object to assertions that are solely statements of opinion being
made as though they were something more than that.

When you have something to say that is more than simply statements
of personal opinion, then I expect I might have something useful
to say about it.

Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>>> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>>>> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>>>>> Andrey Tarasevich <andreytarasevich@hotmail.com> writes:
>>>>>> On 02/21/23 6:12 AM, Alf P. Steinbach wrote:
>>>>>>> Not what you're asking, but the common convention in C++ is to
>>>>>>> separate the type specification from the variable, i.e. `auto& c`
>>>>>>> not `auto &c`.
>>>>>>>
>>>>>>> But on the third and gripping hand, in this case I'd write `char&
>>>>>>> c`, since there's no advantage in `auto` here and it obscures
>>>>>>> things.
>>>>>>
>>>>>> Not really. This is a misleading "convention" that has no reason to
>>>>>> exist. In this case the `&` is a part of an individual declarator,
>>>>>> not a part of decl-specifier-seq. There's no reason to group the
>>>>>> syntactic elements differently. It achieves nothing.
>>>>>
>>>>> I would say it achieves less than nothing, because it's misleading.
>>>>> It's like writing a+b * c ; the grouping suggested by the spacing
>>>>> doesn't match the actual precedence. In almost all cases it's a
>>>>> mistake to use "contra-syntactic" spacing, and attaching '&' or '*'
>>>>> to a type specifier is definitely one of those mistakes.
>>>>
>>>> I prefer the "int *foo;" spacing (conventional in C) because it follows
>>>> the syntax, but the "int* foo;" spacing has become a convention in C++
>>>> (probably because Stroustrup uses it in his books), and I use it in C++
>>>> for that reason. I also avoid declarations where it would make a
>>>> difference to a human reader, like "int* foo, bar;".
>>>>
>>>> Most development is on existing code. It would be poor practice to use
>>>> the "better" spacing on new code while leaving the existing code (which
>>>> most likely uses the C++ conventional spacing) as it is. It would also
>>>> be poor practice to change all the spacing in a large body of existing
>>>> code.
>>>
>>> I'm sure there are lots of people who agree with that opinion,
>>> but that doesn't make it anything more than just an opinion.
>>
>> Obviously.
>>
>> Did you have anything *useful* to add?
>
> As a rule I don't like to participate in discussions of programming
> style that are purely subjective.

Then by all means don't.

> I object to assertions that are solely statements of opinion being
> made as though they were something more than that.

I don't believe I did that. What I wrote (several months ago)
was partly my opinion, partly what I believe to be facts. I did
not intend to present it as anything else. (And I don't think what
I wrote was particularly controversial.)

> When you have something to say that is more than simply statements
> of personal opinion, then I expect I might have something useful
> to say about it.

If you have nothing useful to say, as appears to be the case here, I
suggest saying nothing.

Should I configure my newsreader to add an "X-In-My-Opinion:"
header to everything I post? (To be clear, I will not do so.)

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Will write code for food.
void Void(void) { Void(); } /* The recursive call of the void */

Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:

> If you have nothing useful to say, as appears to be the case
> here, I suggest saying nothing.

I follow my own judgment as to whether what I say is
relevant or useful. I expect you do likewise.