Problem with array objects

[Paul]

On 01/06/2011 22:43, Paul wrote:

[snip]

So if char(*)[n] is, in your mind, a pointer to a 1d array what is a
pointer to a 2d array?
It surely cannot be the same type of pointer but I dunno. I presume it
must be a pointer of type int(*)[n][n]. Is this correct?

'int(*)[n][n]' is a pointer to a 2D array yes; if it where not the
following would not compile:

int array[7][42]; // this is a 2D array
int (*pointer_to_array)[7][42] = &array;

So does this point to an array of objects or a single object of array type?

 

[Paul]

Is this clearer?

class X
{
X& operator=(const X&);

public:

int n;
};

int main()
{
X x1 = {0};
X x2 = {1};

x1 = x2;
x1.n = x2.n;
}

--

If an object is region of sotrage, and that object is non modifiable then
you cannot modify that region of storage.

 

[Joshua Maurice]

-- Let me reproduce my const example:
--    int x = 0;
 --   int const& y = x;
 --   x = 1;
--I just modified the object referred to by "y", and it's not unusual to
--say that "y" is unmodifiable.

But when you say 'y' is non modifiable you usually mean it cannot be
assigned to refer to another object.

Minor semantic quibble: In the above example, y refers to the same
object. The value of the object has changed. Ex:
int x[3] = {};
x[0] = 1; //line A
Line A doesn't create nor destroy any objects. It doesn't make
something refer to a new object. Line A merely changes the value of an
already existing object.

--Yes. The class definition contains the member function. The object
--definition does not contain the member function declaration nor
--definition.
 --   class Foo { public: void f(); }; //class definition
--    Foo foo; //object definition

The class defines the object type. Above you have declared an object of type
Foo, objects of type Foo are defined by the class Foo.

No. Please go reread the ODR and the other parts of the standards
which describe "definitions" and "declarations". The terminology is
quite clear.

class Foo {};
That is a declaration. It brings into scope the name "Foo". It is a
declaration of the name "Foo". It is also a definition; it is a
definition of a class - it satisfies one of the bullets of the
standard, in this case it is a declaration of a class name which has
the class body.

Foo x;
This is a declaration. It brings into scope the name "x". It is also a
definition; it is a definition of an object - it satisfies one of the
bullets of the standard, in this case it is a declaration of an object
name without anything else that would make it not a definition (such
as "extern").

An object is /not/ defined by the class definition. That is simply
confusing and incorrect terminology. The definition of the object, or
more specifically the name of the object, is the declaration which
brings the name into scope, and which satisfies the requirements of
being a definition (one requirement is no "extern").

 

[Joshua Maurice]

If an object is region of sotrage, and that object is non modifiable then
you cannot modify that region of storage.

Incorrect. At least in this particular case, this is incorrect. That
is not what is meant by your citation of the standard which says that
array objects are not modifiable. If you want to call that a bug in
the standard, so be it.

 

[Paul]

On 2011-06-01 11:31:35 -1000, Paul said:

For example:
int* p = new int[100];
Creates an object of type array of 100 int, converts it to type int*,
and stores the result in p.
Ok this is interesting, so an object of array type is created but its
must be a temporary.

No, it's not a temporary. It's an object with dynamic storage duration.

Can you please give an example of how to access this object, I don't see
what this object is.

--You access it via the pointer to its first element, which was just
--handed to you:

--p[0] accesses the first element of the array object, etc.


Yes this is what I think too, but if that pointer points to only the sub
objects and not the array type object, how do we access the array type
object ?

 

[Paul]

-- Let me reproduce my const example:
-- int x = 0;
-- int const& y = x;
-- x = 1;
--I just modified the object referred to by "y", and it's not unusual to
--say that "y" is unmodifiable.

But when you say 'y' is non modifiable you usually mean it cannot be
assigned to refer to another object.

--Minor semantic quibble: In the above example, y refers to the same
--object. The value of the object has changed. Ex:
-- int x[3] = {};
-- x[0] = 1; //line A
--Line A doesn't create nor destroy any objects. It doesn't make
--something refer to a new object. Line A merely changes the value of an
--already existing object.


No, Major error.

The reference is not changed unless is it made to alias another object.

--Yes. The class definition contains the member function. The object
--definition does not contain the member function declaration nor
--definition.
-- class Foo { public: void f(); }; //class definition
-- Foo foo; //object definition

The class defines the object type. Above you have declared an object of
type
Foo, objects of type Foo are defined by the class Foo.

--No. Please go reread the ODR and the other parts of the standards
--which describe "definitions" and "declarations". The terminology is
--quite clear.

-- class Foo {};
--That is a declaration. It brings into scope the name "Foo". It is a
--declaration of the name "Foo". It is also a definition; it is a
--definition of a class - it satisfies one of the bullets of the
--standard, in this case it is a declaration of a class name which has
--the class body.

-- Foo x;
--This is a declaration. It brings into scope the name "x". It is also a
--definition; it is a definition of an object - it satisfies one of the
--bullets of the standard, in this case it is a declaration of an object
--name without anything else that would make it not a definition (such
--as "extern").

--An object is /not/ defined by the class definition. That is simply
--confusing and incorrect terminology. The definition of the object, or
--more specifically the name of the object, is the declaration which
--brings the name into scope, and which satisfies the requirements of
--being a definition (one requirement is no "extern").

There is no definition for each object created. An object instance is not
defined it's type is defined, and that defintion stands for all objects of
the given type..
An object type is defined by a class.

 

[Paul]

On 01/06/2011 22:43, Paul wrote:

[snip]

So if char(*)[n] is, in your mind, a pointer to a 1d array what is a
pointer to a 2d array?
It surely cannot be the same type of pointer but I dunno. I presume it
must be a pointer of type int(*)[n][n]. Is this correct?

'int(*)[n][n]' is a pointer to a 2D array yes; if it where not the
following would not compile:

int array[7][42]; // this is a 2D array
int (*pointer_to_array)[7][42] = &array;

So does this point to an array of objects or a single object of array
type?

The question makes no sense as "an array of objects" is "a single object
of array type" (a "sub-object" is also an "object").

An array of objects is not the same thing as a single object. It's you who
does not make sense.

 

[Paul]

If an object is region of sotrage, and that object is non modifiable then
you cannot modify that region of storage.

--Incorrect. At least in this particular case, this is incorrect. That
--is not what is meant by your citation of the standard which says that
--array objects are not modifiable. If you want to call that a bug in
--the standard, so be it.

So basically you are saying that the standard is a waste of time because the
text in it is incorrect?
Also the text I posted a link to, by Bjarne Stroustrup, is incorrect
therefore not worth reading.
The C FAQ's are also incorrect.

So basically almost all literature on this subject, which I have considered
to be a good source, is actually incorrect and not worth reading?


The only literature on C++ that seems to be acceptable to this community are
the parts of the standards that has text written in such a way that it can
be manipulated to mean whatever you want it to mean.

 

[Joshua Maurice]

--Incorrect. At least in this particular case, this is incorrect. That
--is not what is meant by your citation of the standard which says that
--array objects are not modifiable. If you want to call that a bug in
--the standard, so be it.

So basically you are saying that the standard is a waste of time because the
text in it is incorrect?
Also the text I posted a link to, by Bjarne Stroustrup, is incorrect
therefore not worth reading.
The C FAQ's are also incorrect.

So basically almost all literature on this subject, which I have considered
to be a good source, is actually incorrect and not worth reading?

The only literature on C++ that seems to be acceptable to this community are
the parts of the standards that has text written in such a way that it can
be manipulated to mean whatever you want it to mean.

I do not know to dissuade someone from deep seated delusions,
persecution complexes, and conspiracy theories. This is a common
problem I encounter in some of my discussions on other topics, and I
have not found a solution. All I can say is that you have a horribly
skewed perception of reality.

What would take to convince you? A notarized letter signed by all the
members of the standards committee and a representative from every
major compiler writer? If you're at all reasonable, you have to ask
yourself the question "What if I'm wrong? What would it take to change
my mind?". So, what is it?

 

[Miles Bader]

I do not know to dissuade someone from deep seated delusions,
persecution complexes, and conspiracy theories. This is a common
problem I encounter in some of my discussions on other topics, and I
have not found a solution. All I can say is that you have a horribly
skewed perception of reality.

So do you think paul is a troll, or a netkook?

I know, it's often hard to tell the difference, but I'm thinking a troll
would have gotten bored by now...

-miles

 

[Joshua Maurice]

So do you think paul is a troll, or a netkook?

I know, it's often hard to tell the difference, but I'm thinking a troll
would have gotten bored by now...

I think he's for serious. As you said, it's hard to know for sure, but
that's just my guess. Paul's beliefs have enough grounding in reality
that I can see as plausible. Also his antics are too similar to
someone else I used to be friends with, whom I know is not a troll.

 

[crisgoogle]

news:2011060111582146590-pete@versatilecodingcom...

On 2011-06-01 11:31:35 -1000, Paul said:

For example:
int* p = new int[100];
Creates an object of type array of 100 int, converts it to type int*,
and stores the result in p.
Ok this is interesting, so an object of array type is created but its
must be a temporary.
No, it's not a temporary. It's an object with dynamic storage duration.

Can you please give an example of how to access this object, I don't see
what this object is.

--You access it via the pointer to its first element, which was just
--handed to you:

--p[0] accesses the first element of the array object, etc.

Yes this is what I think too, but if that pointer points to only the sub
objects and not the array type object, how do we access the array type
object ?

What _exactly_ do you mean by "access the array type object"?

All we have in the above is an (anonymous) array, and a pointer to its
first element. There is no identifier for the array as a whole. There
is no "array type object" independent of the array-of-int-subobjects
itself.

So the only way to "access the array" is element-by-element, using
pointers to individual elements.

 

[Paul]

For example:
int* p = new int[100];
Creates an object of type array of 100 int, converts it to type
int*,
and stores the result in p.
Ok this is interesting, so an object of array type is created but its
must be a temporary.
No, it's not a temporary. It's an object with dynamic storage
duration.

Can you please give an example of how to access this object, I don't see
what this object is.

--You access it via the pointer to its first element, which was just
--handed to you:

--p[0] accesses the first element of the array object, etc.

Yes this is what I think too, but if that pointer points to only the sub
objects and not the array type object, how do we access the array type
object ?

-- What _exactly_ do you mean by "access the array type object"?

Read it from memory.


--All we have in the above is an (anonymous) array, and a pointer to its
--first element. There is no identifier for the array as a whole. There
--is no "array type object" independent of the array-of-int-subobjects
--itself.

Well there either is or there isn't an onject of array type.
Your initial response was to my question asking how to access this object of
array-type.
I can't decide if you think there si an object of array type or not.

--So the only way to "access the array" is element-by-element, using
--pointers to individual elements.

 

[Paul]

[snip]

Section 8.3.4 Arrays

5 [ Note: conversions affecting expressions of array type are
described
in
4.2. Objects of array types cannot be modified, see 3.10. -end note ]
§

[snip]

The sections of the C++ standard cited in the above note give the
details of why assigning to an array type is not allowed. Paragraph
1 of section 4.2 (Array-to-pointer conversion) is:

An lvalue or rvalue of type "array of N T" or "array of unknown
bound of T" can be converted to an rvalue of type "pointer to T."
The result is a pointer to the first element of the array.

Note that the result of an array-to-pointer conversion is an rvalue
of type pointer.

The first two paragraphs of 3.10 (Lvalues and rvalues) are

Every expression is either an lvalue or an rvalue.

An lvalue refers to an object or function. Some rvalue expressions
--- those of class or cv-qualified class type --- also refer to
objects.

Given the declaration

int z;

the result of the expression z is an lvalue that refers to the object
where the value of the variable z is stored.

Because a pointer is not of a class or cv-qualified class type, the
rvalue result of array-to-pointer conversion does not refer to an
object. In a assignment the left operand needs to refer to an object,
the one whose value is replaced with that of the right operand of the
assignment.

What did you have for breakfast?

What I had for breakfast is irrelevant.

A pointer is not a class , period.

I never stated it was. I wrote: "Because a pointer is not of a
class or cv-qualified class type, the rvalue result of
array-to-pointer conversion does not refer to an object." The "of
class or cv-qualified class type" part is from the C++ standard about
rvalues that refer to objects. I simply reasoned from statements in
the C++ standard to reach a conclusion about details behind why
assigning to an array type is not allowed.

So the rvalue result of an array to pointer conversion does not refer to
an
object?
Well what does it refer to? And what does it mean by "refer to", does
this
mean the same as what it "points to"?

Yes, the result of an array-to-pointer conversion does not refer to
an object. The result is a value that is not in a C++ object.

The C++ standard does not define the term "refer to", although the
term occurs a number of times. It is used in the above quote from
3.10 (Lvalues and rvalues) of the standard, the first sentence of
the second paragraph is:

An lvalue refers to an object or function.

Another place it is used is in paragraph 8 of section 3 (Basic
concepts):

An identifier used in more than one translation unit can
potentially refer to the same entity in these translation units
depending on the linkage (3.5) of the identifier specified in each
translation unit.

"Refers to" is not the same as "points to". Points to is what a
pointer does. An lvalue of a pointer type refers to the object that
contains the pointer value. Given the declaration

int x, *px = &x;

x refers to the object that contains the value of x. px refers to
the object that contains the value of px. px points to the object
that contains the value of x.

I think you are getting to tied up with language lawyeresque. You cannot
see
the the wood for the trees.

I am not getting tied up with language lawyeresque. When there are
questions about details of C++, the C++ standard is the definitive
source of information about those details.

Well it's you that is introducing all this language lawyeresque stuff.

I am simply trying to get to the bottom of why you think a pointer of type
int* cannot point to an array of integer objects.

 

[crisgoogle]

For example:
int* p = new int[100];
Creates an object of type array of 100 int, converts it to type
int*,
and stores the result in p.
Ok this is interesting, so an object of array type is created but its
must be a temporary.
No, it's not a temporary. It's an object with dynamic storage
duration.
Can you please give an example of how to access this object, I don't see
what this object is.

--You access it via the pointer to its first element, which was just
--handed to you:

--p[0] accesses the first element of the array object, etc.

Yes this is what I think too, but if that pointer points to only the sub
objects and not the array type object, how do we access the array type
object ?

-- What _exactly_ do you mean by "access the array type object"?

Read it from memory.

This hardly describes "exactly" what you mean:
Read _what_ from memory? How is "access the array type object"
different from reading individual array elements via pointers to those
elements? IOW, how does my answer "p[0] accesses the first element
of the array object" NOT tell you how to "access the array type
object"?

--All we have in the above is an (anonymous) array, and a pointer to its
--first element. There is no identifier for the array as a whole. There
--is no "array type object" independent of the array-of-int-subobjects
--itself.

Well there either is or there isn't an onject of array type.
Your initial response was to my question asking how to access this objectof
array-type.
I can't decide if you think there si an object of array type or not.

Of course there is. The object of array type is exactly the group
of 100 int subobjects.

Let me clarify. The _is_ an array; it is an object of array type.

There is _not_ an "array type object" that is _distinct_ from this
object of array type -- as least, as best I can tell, because I've
never seen a definition from you saying what you mean by
"array type object" that would allow this.

 

[Paul]

For example:
int* p = new int[100];
Creates an object of type array of 100 int, converts it to type
int*,
and stores the result in p.
Ok this is interesting, so an object of array type is created but
its
must be a temporary.
No, it's not a temporary. It's an object with dynamic storage
duration.
Can you please give an example of how to access this object, I don't
see
what this object is.

--You access it via the pointer to its first element, which was just
--handed to you:

--p[0] accesses the first element of the array object, etc.

Yes this is what I think too, but if that pointer points to only the sub
objects and not the array type object, how do we access the array type
object ?

-- What _exactly_ do you mean by "access the array type object"?

Read it from memory.

--This hardly describes "exactly" what you mean:
--Read _what_ from memory? How is "access the array type object"
--different from reading individual array elements via pointers to those
--elements? IOW, how does my answer "p[0] accesses the first element
--of the array object" NOT tell you how to "access the array type
--object"?

Read the object of array type from memory.
Does a single object of array type exist in memory ? If so how do we access
this single object, as a whole.

--All we have in the above is an (anonymous) array, and a pointer to its
--first element. There is no identifier for the array as a whole. There
--is no "array type object" independent of the array-of-int-subobjects
--itself.

Well there either is or there isn't an onject of array type.
Your initial response was to my question asking how to access this object
of
array-type.
I can't decide if you think there si an object of array type or not.

--Of course there is. The object of array type is exactly the group
--of 100 int subobjects.

--Let me clarify. The _is_ an array; it is an object of array type.

--There is _not_ an "array type object" that is _distinct_ from this
--object of array type -- as least, as best I can tell, because I've
--never seen a definition from you saying what you mean by
--"array type object" that would allow this.

As far as I can see there is no difference between the terms "array type
object" and "object of array type".
If you see a difference between those terms please enlighten me because an
"object of T type" means the same as a "T type object" , AFAICT.

So you are saying an array is an object in its own right, as well as being
an array of objects. If so I can understand that but I cannot understand how
we access this object as a whole.
Is it a non accessable object? Or, with dynamic arrays, does it even exist?

This object obviously has some differences from the array of objects, most
obviously the difference in pluralisation, ie:
Array of objects.(plural objects)
An array type object. (singular object)
So the plural objects are accessable and the sigular object is not , is it
just a concept of all the objects grouped together as one?
Its not an object that has been declared or anything, its non modifiable,
its not accessable, a there are different opinions about whether or not it
even exists.


Some people say that there is no array object, with dynamic arrays, and that
an array object is 'arr' in the following:
int arr[55];
This is an array type object because when you examine it with typeid its
type is int[55].
This makes sense because this object is non modifiable. Its also not
accessable, as an object in its own right, because any attempt to access it
yields a pointer to its first element.
That means that your explanation of an array being the collective for all
the elements in memory does not make sense because your explanation of an
array object would also exist with a dynamic array, would it not?

So you ask what is my definition of an array type object. Well I think and
array type object is an object in its own right , that represents the memory
as a whole sequence of objects.
This object is something that the compiler creates as a pointer to the first
element with some additional info that allows the size and typeinfo to be
carried with it.
I think that in memory no objects exist other than the sequence of element
objects. However given this C++ type mechanism that allows an identifier to
represent this array as a whole, we can say that the sequence of objects is
one object as a whole.
This is the only way I can see how it works with no conflicting defintions.
The only argument I have seen against this is the "an array is not a
pointer" argument, which is nonsense because I am not saying an array is a
pointer.
Many people give negative comments such as its not this or not that but they
do not produce a reasonable defintion of their own that fits all the rules ,
such as I have done.

 

[Paul]

The reason is simple: a pointer of type int* points to an int. That's what
int* means. An int is not an array of integer objects.

int arr1[1];
This is an int(singular)
int arr2[16];
These are ints(plural)
A pointer to all these ints can be, and usually is, of type int*.

A pointer references a memory location and when its dereferenced we get the
value from that location.
You cannot reference a whole array unless you have an array of pointers. You
can only represent a pointer to the whole array using the C++ type system.

I can appreciate both pointer types as pointing to an array of objects, in
different ways. I do not think that an int* cannot point to an array of int
objects.

 

[crisgoogle]

For example:
int* p = new int[100];
Creates an object of type array of 100 int, converts it to type
int*,
and stores the result in p.
Ok this is interesting, so an object of array type is created but
its
must be a temporary.
No, it's not a temporary. It's an object with dynamic storage
duration.
Can you please give an example of how to access this object, I don't
see
what this object is.
--You access it via the pointer to its first element, which was just
--handed to you:
--p[0] accesses the first element of the array object, etc.
Yes this is what I think too, but if that pointer points to only the sub
objects and not the array type object, how do we access the array type
object ?

-- What _exactly_ do you mean by "access the array type object"?

Read it from memory.

--This hardly describes "exactly" what you mean:
--Read _what_ from memory? How is "access the array type object"
--different from reading individual array elements via pointers to those
--elements? IOW, how does my answer "p[0] accesses the first element
--of the array object" NOT tell you how to "access the array type
--object"?

Read the object of array type from memory.
Does a single object of array type exist in memory ? If so how do we access
this single object, as a whole.

Yes, a single object of array type exists in memory.

We _cannot_ access this single object as a whole. It's as simple as
that.

So what? That's a quirk of the language.

--Of course there is. The object of array type is exactly the group
--of 100 int subobjects.

--Let me clarify. The _is_ an array; it is an object of array type.

--There is _not_ an "array type object" that is _distinct_ from this
--object of array type -- as least, as best I can tell, because I've
--never seen a definition from you saying what you mean by
--"array type object" that would allow this.

As far as I can see there is no difference between the terms "array type
object" and "object of array type".
If you see a difference between those terms please enlighten me because an
"object of T type" means the same as a "T type object" , AFAICT.

It's not a matter of seeing a difference, it's a matter of defining
the terms.
If you stipulate that when you say "array type object" you mean
exactly
the same thing as "object of array type", then I'm quite happy to
agree
that, by definition, there _is_ no difference, so I'll _see_ no
difference =)

So you are saying an array is an object in its own right, as well as being
an array of objects. If so I can understand that but I cannot understand how
we access this object as a whole.

Yes, that's right. Being very loose with terminology, _all_ variables,
data, what-have-you, are objects. Anything to which you can write, or
from which you can read, a value, is an object. Anything that takes up
measureable memory space is an object. Objects can have subobjects.
So the array is a single object, made up of subobjects.

But we cannot access the array object as a whole, if by "access" you
mean
read the whole thing as a lump.

It just so happens that structs are assignable. But if the language
didn't
support struct assignment, would you say that structs weren't objects?

Is it a non accessable object? Or, with dynamic arrays, does it even exist?

Yes, it exists. Yes it can be accessed on an element-by-element basis,
just not as one big lump.

This object obviously has some differences from the array of objects, most
obviously the difference in pluralisation, ie:
Array of objects.(plural objects)
An array type object. (singular object)

Well, yes, they are different objects though not disjoint. The
subobjects
are fully contained within the array object.

And I don't get what you're saying about
the "pluralisation". Yes, there is a single array object containing
multiple subobjects. An int has multiple bits. Does this mean that the
int is different than it's component bits? That's either trivially
true
or trivially false depending on how you interpret it, but either way
it's trivial.

So the plural objects are accessable and the sigular object is not , is it
just a concept of all the objects grouped together as one?
Its not an object that has been declared or anything, its non modifiable,
its not accessable, a there are different opinions about whether or not it
even exists.

Some people say that there is no array object, with dynamic arrays, and that
an array object is 'arr' in the following:
int arr[55];
This is an array type object because when you examine it with typeid its
type is int[55].
This makes sense because this object is non modifiable. Its also not
accessable, as an object in its own right, because any attempt to access it
yields a pointer to its first element.
That means that your explanation of an array being the collective for all
the elements in memory does not make sense because your explanation of an
array object would also exist with a dynamic array, would it not?

No, the "problem" with dynamic arrays is that there is no identifier
for the
array as a whole. It is anonymous. _All_ we have is a pointer to its
first
element. Since we don't have a name for it, we don't have a way of
identifying
the array-as-a-whole to find its typeid, or size, for that matter.
Again,
this is really just a quirk of the language.

So you ask what is my definition of an array type object. Well I think and
array type object is an object in its own right

Okay, good.

, that represents the memory
as a whole sequence of objects.

I'm not sure what you mean by "represents the memory". I say that the
array
object simply _is_ that chunk of memory. There may or may not be a
name
identifying that chunk of memory as a whole. There is such a name for
non-dynamic arrays, there is not for dynamics arrays. (Of course, the
name
may not be visible in all scopes, but the point is, it exists
_somewhere_
in the case of non-dynamic arrays.)

This object is something that the compiler creates as a pointer to the first
element with some additional info that allows the size and typeinfo to be
carried with it.

You say that the compiler "creates [this array object] as a pointer".
I don't
agree, but leave it for a moment. [*]

I think that in memory no objects exist other than the sequence of element
objects.
However given this C++ type mechanism that allows an identifier to
represent this array as a whole, we can say that the sequence of objects is
one object as a whole.
This is the only way I can see how it works with no conflicting defintions.
The only argument I have seen against this is the "an array is not a
pointer" argument, which is nonsense because I am not saying an array is a
pointer.

[*] But you just said that the array object is "[created] as a
pointer". So it's
created as a pointer, but isn't a pointer? I agree that it isn't a
pointer, but
then what do you mean that it's created "as a pointer".

 

[Ian Collins]

So, why not leave Paul's favorite TROLLING question alone? It was quiet for a
while here. Then Ian Collins and you started responding to Paul again. Argh.

Alf, use the 'k' key in thunderbird and all will be quiet once again

 

[Alf P. Steinbach /Usenet]

* Pete Becker, on 03.06.2011 04:06:

Which is what I said above: an int* points to an int. It does not point to an
array of int objects, because an array of int objects is not an int.

It's just a question of terminology, common sense & effective communication.

If you want I can cite you umpteen examples from the standard that employ far
worse terminological shortcuts.

Intelligent folks don't write to you requiring that you do editorial fixes of
those places, because to anyone with half a mind it's obvious what's meant.

---

So, why not leave Paul's favorite TROLLING question alone? It was quiet for a
while here. Then Ian Collins and you started responding to Paul again. Argh.

Please keep in mind: many of us have much invested in using particular software
such as Thunderbird, and can't easily switch to newsreaders with general scoring.


Cheers, & exasperated,

- Alf