how/why it is written ... int &numberRef; vs int& numberRef;

[G G]

i know that is the same thing but i would ask the group
to discuss the reasoning, their thoughts, as to why
int& numberRef; is a better or more understandable way
in their mind set for those thinking that way

along with, int* aPointer;

my question is why associate the *, or & the the type instead of the
name? i do understand it is a preference.

[Mr Flibble]

OMFG not this again, pls.

/Flibble

--
"Snakes didn't evolve, instead talking snakes with legs changed into
snakes." - Rick C. Hodgin

“You won’t burn in hell. But be nice anyway.” – Ricky Gervais

“I see Atheists are fighting and killing each other again, over who
doesn’t believe in any God the most. Oh, no..wait.. that never happens.” –
Ricky Gervais

"Suppose it's all true, and you walk up to the pearly gates, and are
confronted by God," Bryne asked on his show The Meaning of Life. "What
will Stephen Fry say to him, her, or it?"
"I'd say, bone cancer in children? What's that about?" Fry replied.
"How dare you? How dare you create a world to which there is such misery
that is not our fault. It's not right, it's utterly, utterly evil."
"Why should I respect a capricious, mean-minded, stupid God who creates a
world that is so full of injustice and pain. That's what I would say."

[G G]

On Friday, July 12, 2019 at 6:17:08 PM UTC-4, Mr Flibble wrote:

>
> OMFG not this again, pls.
>
> /Flibble
>

no wars please...

just a thought or two as to the thinking.
the book i'm reading does not suggest one over the other

[James Kuyper]

A simple declaration consists of a decl-specifier-seq followed by an
init-declarator-list (10.1p1). In this case, int is the
decl-specifier-seq (10.1.7.2p1) and *aPointer or &numberRef are the only
declarators in their respective init-declarator-lists (11.1p4). That
distinction doesn't matter if the init-declarator-list only contains one
declarator. However, if it contains two or more declarators, I consider
it helpful to keep track of the fact that & and * only apply to the
immediately following declarators, and not to any of the other
declarators in the same list. I find it easier to do so if I keep a
space between the decl-specifier-seq and the init-declarator-list, and
if I don't insert a space between the * or & and the rest of the
declartor that it is part of:

int *aPointer, &numberRef;

* applies only to aPointer, and & applies only to numberRef. If I wrote
something like

int* aPointer, aFunc(void);

a newbie might easily make the mistake of thinking that aFunc() returns
an int*, rather than an int.

It's a minor advantage, and many people prefer not to declare more than
one declator per declaration, so for them it's no advantage at all.

[Öö Tiib]

Usually I don't care since reformatting between style
that I like to see and style required by coding standard
of project is just one click anyway.

[Szyk Cech]

In some book I read years ago were something stupid think like this:
"Pointers are not a type in C++ because when you write:
int* first, second;
second will be not pointer. So you should always write int *first; not
int* first."

In my opinion this is only matter of C++ compiler internals. From
Asembler point of view every thing variables are just different numbers.
In C++ we have pointers (among others) and we have to handle them in
different way than other things.
Pointers (and references) are different types and are logically
distinguishable from variable by value.
You should always write:
int* variable1;
or
int& variable2;

[Juha Nieminen]

G G <gdo...@gmail.com> wrote:
> my question is why associate the *, or & the the type instead of the
> name? i do understand it is a preference.

For some reason that I do not know (and possibly nobody does),
when C was originally devised (although it might have come from a
precursor language like B or BCPL, I don't know) they decided that
the indicator for a pointer variable, ie. the asterisk, would be
tied to the variable name rather than the type. In other words,
the asterisk is not, in fact, part of the type at all, but a sort
of indicator that "this variable is a pointer".

This distinction can be seen, as some have pointed out, when declaring
more than one variable in the same expression:

int *x, *y, z;

Here x and y are pointers, while z is not. The asterisk, the indicator
that means "this is a pointer", is tied to the variable name, not the
type.

Of course this can become a bit confusing when types are used in
contexts other than variable declarations. While C-style typedefs
kind of still follow this principle (as typedef syntax is essentially
just normal variable declaration syntax with just the 'typedef' keyword
added at the very beginning):

typedef int *IntPtr;

it depends on your point of view whether this is now confusing or not:

IntPtr ptr;

because now the "this is a pointer" part is part of the type alias,
rather than tied to the variable name.

When a function returns a pointer, it also can become a bit confusing,
if you follow that same convention:

int *function();

The "this is a pointer" asterisk kind of is part of the return type,
kind of isn't. It's a bit confusing. No wonder many prefer writing
it like this for clarity:

int* function();

which of course means the exact same thing, but is visually clearer.

And yes, this is valid C (and C++):

int *function1(), *function2(), function3();

even though it's quite rarely used. (I bet most C/C++ programmers
weren't aware of that.)

C++ makes this even more complicated because there are many more
situations where types are used on their own, without any sort of
variable (or function) name, such as:

std::vector<int*> vec;

Also here the asterisk kind of is part of the type, kind of isn't.
It's all confusing.

[Ben Bacarisse]

Juha Nieminen <nos...@thanks.invalid> writes:

> G G <gdo...@gmail.com> wrote:
>> my question is why associate the *, or & the the type instead of the
>> name? i do understand it is a preference.
>
> For some reason that I do not know (and possibly nobody does),
> when C was originally devised (although it might have come from a
> precursor language like B or BCPL, I don't know) they decided that
> the indicator for a pointer variable, ie. the asterisk, would be
> tied to the variable name rather than the type.

Neither B nor BCPL had types. C was originally "B with types".

> In other words,
> the asterisk is not, in fact, part of the type at all, but a sort
> of indicator that "this variable is a pointer".
>
> This distinction can be seen, as some have pointed out, when declaring
> more than one variable in the same expression:
>
> int *x, *y, z;
>
> Here x and y are pointers, while z is not. The asterisk, the indicator
> that means "this is a pointer", is tied to the variable name, not the
> type.
>
> Of course this can become a bit confusing when types are used in
> contexts other than variable declarations. While C-style typedefs
> kind of still follow this principle (as typedef syntax is essentially
> just normal variable declaration syntax with just the 'typedef' keyword
> added at the very beginning):
>
> typedef int *IntPtr;
>
> it depends on your point of view whether this is now confusing or not:
>
> IntPtr ptr;
>
> because now the "this is a pointer" part is part of the type alias,
> rather than tied to the variable name.
>
> When a function returns a pointer, it also can become a bit confusing,
> if you follow that same convention:
>
> int *function();
>
> The "this is a pointer" asterisk kind of is part of the return type,
> kind of isn't. It's a bit confusing.

The general idea (now rather battered by history and changes to the
language) is that declarations mirror use.

function

is a function designator. To call it, you mirror the declaration:

function()

The result is a pointer. To dereference that pointer you again mirror
the declaration and use *:

*function()

to get an int.

This idea of having declarations mirror use, gave rise to declarations
that have two parts: the base type (like int, double and so on) and what
C calls a declarator where operators like *, () and [] decorate the name
with the same priority as they appear in expressions.

Knowing both the history and syntax of declarations, I can't stand
seeing

int* function();

but I know I am on the wrong side of history here, at least as far as
C++ is concerned. I'm not going to defend it, but you wondered where
it came from.

> No wonder many prefer writing
> it like this for clarity:
>
> int* function();
>
> which of course means the exact same thing, but is visually clearer.

This is the form that used to confuse me. Not that I didn't understand
it, but I'd worry the author may not know how types work in C++. Now
that is it almost de rigeur to write it this way, there's no reason to
worry -- the programmer is simply following standard advice -- it just
looks odd to me, like writing

- a+b

where the spacing does not reflect the syntax.

> And yes, this is valid C (and C++):
>
> int *function1(), *function2(), function3();
>
> even though it's quite rarely used. (I bet most C/C++ programmers
> weren't aware of that.)

Don't people learn the syntax of the languages they use anymore? (I'm
joking, of course they don't, but C and C++ were designed in era when
they did.)

> C++ makes this even more complicated because there are many more
> situations where types are used on their own, without any sort of
> variable (or function) name, such as:
>
> std::vector<int*> vec;
>
> Also here the asterisk kind of is part of the type, kind of isn't.
> It's all confusing.

--
Ben.

[Öö Tiib]

On Tuesday, 16 July 2019 01:03:53 UTC+3, Ben Bacarisse wrote:

> Juha Nieminen <nos...@thanks.invalid> writes:
>
>
> > And yes, this is valid C (and C++):
> >
> > int *function1(), *function2(), function3();
> >
> > even though it's quite rarely used. (I bet most C/C++ programmers
> > weren't aware of that.)
>
> Don't people learn the syntax of the languages they use anymore? (I'm
> joking, of course they don't, but C and C++ were designed in era when
> they did.)

It takes years to learn nuances of all C++ syntax. That syntax goes
back to times when count of punch cards used was concern on one
hand but it also receives substantial extensions after every few
years on the other hand.

struct obf {long ndx, *dun()&&, &gen(), mum() const, dat[42];};

Everybody use only subset of that syntax and everybody
agree that constraining it way more than the language requires
is very helpful. The only issue is that we sometimes want to
constrain it bit differently than others. From conflicting custom
constraints the white space is most trivial to solve.

[Ben Bacarisse]

嘱 Tiib <oot...@hot.ee> writes:

> On Tuesday, 16 July 2019 01:03:53 UTC+3, Ben Bacarisse wrote:
>> Juha Nieminen <nos...@thanks.invalid> writes:
>>
>>
>> > And yes, this is valid C (and C++):
>> >
>> > int *function1(), *function2(), function3();
>> >
>> > even though it's quite rarely used. (I bet most C/C++ programmers
>> > weren't aware of that.)
>>
>> Don't people learn the syntax of the languages they use anymore? (I'm
>> joking, of course they don't, but C and C++ were designed in era when
>> they did.)
>
> It takes years to learn nuances of all C++ syntax.

Yup. I was talking about the broad-brush syntax. I don't know the
details even after decades, but it's a fundamental part of both C and
C++'s syntax that "decoration" around the name alters the name's
relation to the base type:

int i, function(), array[], *pointer;

> That syntax goes
> back to times when count of punch cards used was concern on one
> hand but it also receives substantial extensions after every few
> years on the other hand.

It goes back to those days, but I would be surprised if that was ever a
concern. C was created for Unix, and Unix installations rarely used
punched cards.

<cut>
--
Ben.

[Alf P. Steinbach]

On 16.07.2019 03:31, Öö Tiib wrote:
> On Tuesday, 16 July 2019 01:03:53 UTC+3, Ben Bacarisse wrote:
>> Juha Nieminen <nos...@thanks.invalid> writes:
>>
>>
>>> And yes, this is valid C (and C++):
>>>
>>> int *function1(), *function2(), function3();
>>>
>>> even though it's quite rarely used. (I bet most C/C++ programmers
>>> weren't aware of that.)
>>
>> Don't people learn the syntax of the languages they use anymore? (I'm
>> joking, of course they don't, but C and C++ were designed in era when
>> they did.)
>
> It takes years to learn nuances of all C++ syntax. That syntax goes
> back to times when count of punch cards used was concern on one
> hand but it also receives substantial extensions after every few
> years on the other hand.
>
> struct obf {long ndx, *dun()&&, &gen(), mum() const, dat[42];};
>
> Everybody use only subset of that syntax and everybody
> agree that constraining it way more than the language requires
> is very helpful.

No, as a general statement that's not my experience.

For example, especially Juha and Mr. Fibble in this group complain
strenuously about my sometimes use of `P_<Type>` rather than `Type*`,
even though the former is a more constrained and in itself a uniform
notation, that supports always prefix `const` uniform notation.

I think you meant that most everybody agrees that /adopting a
convention/ of a more constrained notation, instead of actually doing
what you wrote, “constraining it” (i.e. adding hard constraints, like
the `P_` notation and similar notations does). However, I generally
don't agree with the idea of using mere convention when it's possible
and practical to express something in the language and have it enforced
by the compiler. In the same way, I disagree with the common idea of
explaining via comments things that can be expressed in the code itself.

> The only issue is that we sometimes want to
> constrain it bit differently than others. From conflicting custom
> constraints the white space is most trivial to solve.

For use of the original C syntax the placement of whitespace, if any,
IMO signals and subtly pushes in the direction of a way of thinking.

That's not the case any more when a more constrained C++ level notation
is adopted.

Then whitespace is just a formatting issue, a personal preference
without any ties to how to think of the structure of a declaration,
because there's then only one single, well defined, clear structure.


Cheers!,

- Alf

[David Brown]

On 16/07/2019 05:48, Alf P. Steinbach wrote:
> On 16.07.2019 03:31, Öö Tiib wrote:
>> On Tuesday, 16 July 2019 01:03:53 UTC+3, Ben Bacarisse  wrote:
>>> Juha Nieminen <nos...@thanks.invalid> writes:
>>>
>>>
>>>> And yes, this is valid C (and C++):
>>>>
>>>>    int *function1(), *function2(), function3();
>>>>
>>>> even though it's quite rarely used. (I bet most C/C++ programmers
>>>> weren't aware of that.)
>>>
>>> Don't people learn the syntax of the languages they use anymore?  (I'm
>>> joking, of course they don't, but C and C++ were designed in era when
>>> they did.)
>>
>> It takes years to learn nuances of all C++ syntax. That syntax goes
>> back to times when count of punch cards used was concern on one
>> hand but it also receives substantial extensions after every few
>> years on the other hand.
>>
>>      struct obf {long ndx, *dun()&&, &gen(), mum() const, dat[42];};
>> Everybody use only subset of that syntax and everybody
>> agree that constraining it way more than the language requires
>> is very helpful.
>
> No, as a general statement that's not my experience.
>
> For example, especially Juha and Mr. Fibble in this group complain
> strenuously about my sometimes use of `P_<Type>` rather than `Type*`,
> even though the former is a more constrained and in itself a uniform
> notation, that supports always prefix `const` uniform notation.

There is a big difference between constraining the syntax, and adopting
a completely different syntax.

Constraining the syntax means rules like "only declare one identifier at
a time." That would mean you can avoid several common (but not all)
possible mixups and confusions with pointer declarations - since you can
no longer write "int* a, b;", no one can wonder if you meant "b" to be a
pointer also.

What you are doing with your "P_<Type>", and all your other macros and
your library, is changing the appearance and nature of the language.
Now, I can agree that for some purposes, there are advantages. And if
one were making a new programming language, a syntax like P_<Type> might
be chosen instead of "Type*". But this group is about C++, not AC++
written in Alf's own C++. It does not matter that the code is valid C++
(ignoring the dollar sign) and the library is available online.

What you write is akin to C programmers who start their code:

#define R return
#define G goto
#define I int

and then proceed to write their code in a way /they/ find clear but no
one else likes.

When you are writing your own code, and large scale projects where your
library and style might have advantages, it is fair enough - anyone
working on the code should be familiar with your system. When you are
posting to a newsgroup for a wide audience who are not familiar with
your library (some are barely familiar with C++), then it is important
to write as simply and clearly, and in as common and standard a manner,
as possible.

>
> I think you meant that most everybody agrees that /adopting a
> convention/ of a more constrained notation, instead of actually doing
> what you wrote, “constraining it” (i.e. adding hard constraints, like
> the `P_` notation and similar notations does).

Your notation is not a constraint - not as other people understand the
word. Please be careful with the word "constraint" until you agree on
the meaning with other people - you'll just cause confusion, and cause
arguments where people actually agree.

> However, I generally
> don't agree with the idea of using mere convention when it's possible
> and practical to express something in the language and have it enforced
> by the compiler. In the same way, I disagree with the common idea of
> explaining via comments things that can be expressed in the code itself.
>

I think most will agree with that - but it is an entirely orthogonal
point, and no one has been suggesting otherwise.

[Alf P. Steinbach]

Yes, that's literally correct, but the in-context implication that
`P_<Type>` is a different syntax is wrong.

It's still C++ syntax.

The compiler would not accept it if it were not.

Since it's a constrained use of C++ syntax you find it “completely
different” than purely C syntax, but that is at best a colored
associative perception.

That is, you /feel/ that limiting oneself to the C++ template syntax for
pointer declarations is “completely different”, but as a technical
statement that's incorrect misleading bollocks.

Confusing that feeling with technical fact is a fallacy.

> Constraining the syntax means rules like "only declare one identifier at
> a time."  That would mean you can avoid several common (but not all)
> possible mixups and confusions with pointer declarations - since you can
> no longer write "int* a, b;", no one can wonder if you meant "b" to be a
> pointer also.

Yes, that's one thing `P_<Type>` does.

But from context you're implying that it does not.

That's a second fallacy, the assertion of a plainly incorrect “fact”.

> What you are doing with your "P_<Type>", and all your other macros and
> your library, is changing the appearance and nature of the language.

Yes, changing the /appearance/ to something simpler, is part of what one
does by systematically constraining one's use of features.

And that's what you've argued for yourself up-thread, still quoted in
this reply; “very helpful”, you wrote about it.

So, with the interpretation that for `P_` you refer to the declaration
simplifications as negative, while earlier, for use of more brittle
by-convention constraints you referred to it as positive, you're
contradicting yourself, a third fallacy.

Since you contradict yourself you are apparently failing to see that
you're doing it.

One common reason for such blindness, a blind zone regarding one's
self-contradictions about something, is that one is writing in a haze of
vision-defeating emotion.

> Now, I can agree that for some purposes, there are advantages.  And if
> one were making a new programming language, a syntax like P_<Type> might
> be chosen instead of "Type*".  But this group is about C++, not AC++
> written in Alf's own C++.  It does not matter that the code is valid C++
> (ignoring the dollar sign) and the library is available online.
>
> What you write is akin to C programmers who start their code:
>
> #define R return
> #define G goto
> #define I int
>
> and then proceed to write their code in a way /they/ find clear but no
> one else likes.

This is a straw-man fallacious argument against use of the library I
sometimes choose to employ, a fourth fallacy.

Arguing against use of that library is itself a straw-man fallacious
argument against notation like `P_`. It's also a kind of fallacy called
a faulty or hasty generalization, two fallacies in one. But let's count
this as just one combined fifth fallacy.

The two fallacies above come on top of your three fallacies some
paragraphs earlier, i.e. five fallacies so far in just a few paragraphs,
which again indicates to me that you're writing in a haze of emotion — I
would presume with a main component that of belonging to a group — that
clouds and defeats your critical thinking.

> When you are writing your own code, and large scale projects where your
> library and style might have advantages, it is fair enough - anyone
> working on the code should be familiar with your system.  When you are
> posting to a newsgroup for a wide audience who are not familiar with
> your library (some are barely familiar with C++), then it is important
> to write as simply and clearly, and in as common and standard a manner,
> as possible.

This is again incorrect in so many ways.

A main way that it's wrong: an argument against my use of a library is,
again, not valid as an argument against `P_` notation.

So, that single aspect of the wrongness is a sixth fallacy so far.

>> I think you meant that most everybody agrees that /adopting a
>> convention/ of a more constrained notation, instead of actually doing
>> what you wrote, “constraining it” (i.e. adding hard constraints, like
>> the `P_` notation and similar notations does).
>
> Your notation is not a constraint - not as other people understand the
> word.

Seventh fallacy.

>  Please be careful with the word "constraint" until you agree on
> the meaning with other people - you'll just cause confusion, and cause
> arguments where people actually agree.

Eight fallacies.

This is like some text out of a lunatic asylum, just all
self-contradictions and fallacies.

But I believe you'll find support in this group, because (I presume)
that's the main driver, the group membership.

With emotions, rational thinking doesn't really apply.

However, how you landed on perceiving the group's view as coincident
with the vitriol spewed out by Mr. Fibble, is beyond me.

>> However, I generally don't agree with the idea of using mere
>> convention when it's possible and practical to express something in
>> the language and have it enforced by the compiler. In the same way, I
>> disagree with the common idea of explaining via comments things that
>> can be expressed in the code itself.
>>
>
> I think most will agree with that - but it is an entirely orthogonal
> point, and no one has been suggesting otherwise.

Ninth fallacy, in the denial area.

[David Brown]

On 16/07/2019 11:52, Alf P. Steinbach wrote:

I'm snipping most of what you wrote - going through it point for point
would be, well, pointless.

> But I believe you'll find support in this group, because (I presume)
> that's the main driver, the group membership.

You will find that most people in the group ignore the code you post
when it contains your special language. The fact that it can be
compiled by a C++ compiler, assuming one goes to the bother of finding
and downloading your library, is irrelevant.

>
> With emotions, rational thinking doesn't really apply.
>
> However, how you landed on perceiving the group's view as coincident
> with the vitriol spewed out by Mr. Fibble, is beyond me.

I don't approve of the hate posts Mr. Flibble makes. That does not mean
he is wrong in saying that your code is regularly unhelpful at best, and
incomprehensible at worst. But I dislike the way he says it.

>
> Ninth fallacy, in the denial area.
>

And you wonder why people aren't always appreciative of your posts.


You are an experienced C++ developer, sitting on a lot of good advice
and suggestions. But you choose to make your code posts in an
unconstructive way - an arrogant "my code is better than the rest of the
world" way. You are not alone in this - there are other numpties who
insist on adding "::std::" to everything, or who post with a layout and
spacing style that is, to be diplomatic, "unique".

You should learn that the way to communicate is by using a /common/
language - not what you personally believe to be the "best" language.
If that means posting code in a style that you consider sub-par, then
that is what you do.

Of course you can then have your own threads extolling the virtues of
your methods - they are interesting in their own rights, just not
usually as answers to other people's queries.



>
>
> Cheers!,
>
> - Alf

[Öö Tiib]

On Tuesday, 16 July 2019 05:04:13 UTC+3, Ben Bacarisse wrote:

> Öö Tiib <oot...@hot.ee> writes:
>
> > On Tuesday, 16 July 2019 01:03:53 UTC+3, Ben Bacarisse wrote:
> >> Juha Nieminen <nos...@thanks.invalid> writes:
> >>
> >>
> >> > And yes, this is valid C (and C++):
> >> >
> >> > int *function1(), *function2(), function3();
> >> >
> >> > even though it's quite rarely used. (I bet most C/C++ programmers
> >> > weren't aware of that.)
> >>
> >> Don't people learn the syntax of the languages they use anymore? (I'm
> >> joking, of course they don't, but C and C++ were designed in era when
> >> they did.)
> >
> > It takes years to learn nuances of all C++ syntax.
>
> Yup. I was talking about the broad-brush syntax. I don't know the
> details even after decades, but it's a fundamental part of both C and
> C++'s syntax that "decoration" around the name alters the name's
> relation to the base type:
>
> int i, function(), array[], *pointer;

I understand the translation logic of syntax, but I also understand
that it is not what most programmers see intuitive to read. Major C++
compilers have lot of code for producing better diagnostics
about errors in declarations and even warn about potential illusions
(like vexing parse) but programmers are still frequently confused.
Other C-like languages have constrained and often also rearranged the
syntax of declaration and initialization of C.

>
> > That syntax goes
> > back to times when count of punch cards used was concern on one
> > hand but it also receives substantial extensions after every few
> > years on the other hand.
>
> It goes back to those days, but I would be surprised if that was ever a
> concern. C was created for Unix, and Unix installations rarely used
> punched cards.

Good catch! It was not the most important concern of course.
I can't find any papers by Ken Thompson depicting it but Dennis
Ritchie describes it in detail. By him the major concern it solved
was memory used by compiler.

"The BCPL compiler readily handled such constructs by storing and
analyzing a parsed representation of the entire program in memory
before producing output. Storage limitations on the B compiler
demanded a one-pass technique in which output was generated as soon
as possible, and the syntactic redesign that made this possible was
carried forward into C."
http://www.bell-labs.com/usr/dmr/www/chist.html

Still my point remains, these concerns have long gone by now.

[Öö Tiib]

On Tuesday, 16 July 2019 06:48:49 UTC+3, Alf P. Steinbach wrote:
> On 16.07.2019 03:31, Öö Tiib wrote:
> >
> > Everybody use only subset of that syntax and everybody
> > agree that constraining it way more than the language requires
> > is very helpful.
>
> No, as a general statement that's not my experience.
>
> For example, especially Juha and Mr. Fibble in this group complain
> strenuously about my sometimes use of `P_<Type>` rather than `Type*`,
> even though the former is a more constrained and in itself a uniform
> notation, that supports always prefix `const` uniform notation.

Yes, I was saying that everybody agree that constraining is important
but disagree in how to constrain it. Within a team of project it is
solved either by dictatorship of lead developers or by democratic vote
of team members. Reaching agreements more globally is backbreaking if
not impossible.

> I think you meant that most everybody agrees that /adopting a
> convention/ of a more constrained notation, instead of actually doing
> what you wrote, “constraining it” (i.e. adding hard constraints, like
> the `P_` notation and similar notations does). However, I generally
> don't agree with the idea of using mere convention when it's possible
> and practical to express something in the language and have it enforced
> by the compiler. In the same way, I disagree with the common idea of
> explaining via comments things that can be expressed in the code itself.

I did not mean only coding conventions. Often also tools of checking,
tools of aiding refactoring and supporting libraries are made to ease
the process of constraining and living with the constraints.
For example that is Microsoft's implementation of library to support
coding guidelines of Stroustrup and Sutter:
https://github.com/Microsoft/GSL
It is obvious that the more of such real support there is the easier
it is to adopt.

>
> > The only issue is that we sometimes want to
> > constrain it bit differently than others. From conflicting custom
> > constraints the white space is most trivial to solve.
>
> For use of the original C syntax the placement of whitespace, if any,
> IMO signals and subtly pushes in the direction of a way of thinking.
>
> That's not the case any more when a more constrained C++ level notation
> is adopted.
>
> Then whitespace is just a formatting issue, a personal preference
> without any ties to how to think of the structure of a declaration,
> because there's then only one single, well defined, clear structure.

The issue that different people want to constrain it differently still
remains. Discussions of those differences tend to get ... not
too charming. ;)

[Alf P. Steinbach]

On 16.07.2019 12:45, David Brown wrote:
> On 16/07/2019 11:52, Alf P. Steinbach wrote:
>
> I'm snipping most of what you wrote - going through it point for point
> would be, well, pointless.

Yes, nine fallacies in one posting is a lot.

And I only pointed out the top-level ones.

>> But I believe you'll find support in this group, because (I presume)
>> that's the main driver, the group membership.
>
> You will find that most people in the group ignore the code you post
> when it contains your special language. The fact that it can be
> compiled by a C++ compiler, assuming one goes to the bother of finding
> and downloading your library, is irrelevant.

The first sentence contains two assertions, both incorrect. The last
sentence is an assertion that is incorrect. I don't think they qualify
as fallacies, they're just being wrong about things, having an incorrect
perception, so it's an improvement. :)

>> With emotions, rational thinking doesn't really apply.
>>
>> However, how you landed on perceiving the group's view as coincident
>> with the vitriol spewed out by Mr. Fibble, is beyond me.
>
> I don't approve of the hate posts Mr. Flibble makes. That does not mean
> he is wrong in saying that your code is regularly unhelpful at best, and
> incomprehensible at worst. But I dislike the way he says it.
>
>>
>> Ninth fallacy, in the denial area.
>>
>
> And you wonder why people aren't always appreciative of your posts.

It's not true that people are not usually appreciative of my posts.

Consequently it's not true that I've wondered about that, either.

Since you know that I haven't wondered about this, that last
incorrectness is a lie.

---

That's usually the way it goes: self-contradictions, an avalanche of
fallacies, topical blindness, pure associations and generalizations,
followed by plain lies. Then there's a further known pattern of
development if the discussion about the topic continues, then involving
more social tools. I suggest we just stop it.

---

Since you haven't resorted to those techniques in other areas of
discussion here, since in fact you're generally one of the most decent
people in the group and generally know what you're talking about, it
doesn't matter much, I think. We can simply agree to not discuss this
topic where you (apparently) go emotionally overboard.

> You are an experienced C++ developer, sitting on a lot of good advice
> and suggestions. But you choose to make your code posts in an
> unconstructive way - an arrogant "my code is better than the rest of the
> world" way. You are not alone in this - there are other numpties who
> insist on adding "::std::" to everything, or who post with a layout and
> spacing style that is, to be diplomatic, "unique".

Yes, the matter of style and how that's perceived, that's a valid point.

Still that is only vaguely associated with the usefulness or not of
restricting oneself to C++ template notation for pointer declarations.
Which by the way is objectively a constraint on the notation, not a
different notation. Though it may look different in style.

I know of no other way to use prefix `const` consistently, disregarding
the to me abhorrent practice of /naming/ every part.

> You should learn that the way to communicate is by using a /common/
> language - not what you personally believe to be the "best" language.
> If that means posting code in a style that you consider sub-par, then
> that is what you do.

But here you go again, with a groundless accusation.

And an apparent quote that isn't a quote.

I'm just mentioning it in order to not let it go by unchallenged as an
apparent truth, because it's a more personal thing. Such accusations
(and the self-contradictions, and the fallacies, and...) mean that you
not only fail to see things as they are, the usual blindness effect, but
also see things that don't exist. We should not discuss this further.

[David Brown]

On 17/07/2019 07:06, Alf P. Steinbach wrote:
<snip>

I think I'll leave it at that.

Hopefully the next time we correspond in a thread, things will go better.

mvh.,

David

[Juha Nieminen]

Ben Bacarisse <ben.u...@bsb.me.uk> wrote:
> Neither B nor BCPL had types. C was originally "B with types".

Is that the reason why in pre-standard C specifying types was
optional, and if you didn't specify them, they defaulted to int?

[Juha Nieminen]

Alf P. Steinbach <alf.p.stein...@gmail.com> wrote:
> For example, especially Juha and Mr. Fibble in this group complain
> strenuously about my sometimes use of `P_<Type>` rather than `Type*`,

I have never done such a thing.

[Ben Bacarisse]

Almost certainly. In B you'd write

auto a, b, c;

in a function a just

a, b, c;

at file scope. I am sure it was considered a good idea to be able to
convert B programs to "new B" and later to early C with as few edits as
possible.

--
Ben.

[Scott Lurndal]

"Alf P. Steinbach" <alf.p.stein...@gmail.com> writes:
>On 16.07.2019 12:45, David Brown wrote:
>> On 16/07/2019 11:52, Alf P. Steinbach wrote:
>>
>> I'm snipping most of what you wrote - going through it point for point
>> would be, well, pointless.
>
>Yes, nine fallacies in one posting is a lot.
>
>And I only pointed out the top-level ones.
>
>
>>> But I believe you'll find support in this group, because (I presume)
>>> that's the main driver, the group membership.
>>
>> You will find that most people in the group ignore the code you post
>> when it contains your special language. The fact that it can be
>> compiled by a C++ compiler, assuming one goes to the bother of finding
>> and downloading your library, is irrelevant.
>
>The first sentence contains two assertions, both incorrect.

I will admit that I also ignore your code as not useful and your coding
style as baroque and unreadable. So at least two people in the group ignore your
code when it contains your special language. I believe David's
assertion to be correct in this case.