HELP: NEWBIE question on templates.

[mehrdad]

I would like to write a template function that approximately looks like:

template<class T>
void foo (const T &p, ....)
{
...
...
}

where the only requirement for p is that it must have operator []
defined for it, however I would like this function also work when p is a
pointer to type T, in other words I want both of these calls to work
with the same template function:

std::vector<double> v;
double *p;

foo(v, ...)
foo(x, ...)

Is that possible? Any help or guidance would be most welcome.

[Jorgen Grahn]

I'd consider changing T to be a random-access iterator; then you'd be
following a pattern used in the standard library. (And pointers are
random-access iterators.)

But how does foo() know which arguments to operator[] are safe, when
you don't pass a container like vector<double>?

/Jorgen

--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .

[Mr Flibble]

Nit: a pointer *might be* an iterator but not all pointers are iterators; I find the claim that a pointer to a single object that is not part of a controlled sequence or an array is an iterator bogus.

/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," Byrne 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."

[Alf P. Steinbach]

C++ has always supported using pointers to single objects as iterators.

You can form a pointer to past-the-object just as with an array.

C++17 §8.3.1/3
«
For purposes of pointer arithmetic (8.7) and comparison (8.9, 8.10), an
object that is not an array element whose address is taken in this way
is considered to belong to an array with one element of type T. [Example:
struct A { int i; };
struct B : A { };
... &B::i ... // has type int A::*
int a;
int* p1 = &a;
int* p2 = p1 + 1; // defined behavior
bool b = p2 > p1; // defined behavior, with value true
—end example]
»

Also,

C++17 §6.9.2/3.4
«
A value of a pointer type that is a pointer to or past the end of an
object represents the address of the first byte in memory (4.4) occupied
b the object 54 or the first byte in memory after the end of the storage
occupied by the object, respectively.
»


- Alf

[Mr Flibble]

I don't dispute that but the Standard, like me, doesn't call such a pointer an "iterator".

[The Real Non Homosexual]

I think referring to a pointed as an iterator can lead to some dangerous and untinded consequences for example, this could spell danger for the following problem...

Given an array of non-empty strings, return a Map<String, String> with a key for every different first character seen, with the value of all the strings starting with that character appended together in the order they appear in the array.


firstChar(["salt", "tea", "soda", "toast"]) → {"s": "saltsoda", "t": "teatoast"}
firstChar(["aa", "bb", "cc", "aAA", "cCC", "d"]) → {"a": "aaaAA", "b": "bb", "c": "cccCC", "d": "d"}
firstChar([]) → {}

[The Real Non Homosexual]

By the way, the following problem is a dumber down and simplified variation of a much much hard problem.

[Daniel P]

On Friday, May 22, 2020 at 5:28:30 PM UTC-4, Jorgen Grahn wrote:
>
> I'd consider changing T to be a random-access iterator; then you'd be
> following a pattern used in the standard library. (And pointers are
> random-access iterators.)
>

Except with the arrival of ranges, the standard library pattern changes
to passing the container, or a view thereon, rather than an iterator pair.

Daniel

[James Kuyper]

On Friday, May 22, 2020 at 7:17:05 PM UTC-4, Mr Flibble wrote:
> On 22/05/2020 23:40, Alf P. Steinbach wrote:

...

> > C++ has always supported using pointers to single objects as iterators.
> >
> > You can form a pointer to past-the-object just as with an array.
> >
> > C++17 §8.3.1/3
> > «
> > For purposes of pointer arithmetic (8.7) and comparison (8.9, 8.10), an object that is not an array element whose address is taken in this way is considered to belong to an array with one element of type T. [Example:
> >     struct A { int i; };
> >     struct B : A { };
> >     ... &B::i ... // has type int A::*
> >     int a;
> >     int* p1 = &a;
> >     int* p2 = p1 + 1; // defined behavior
> >     bool b = p2 > p1; // defined behavior, with value true
> > —end example]
> > »
> >
> > Also,
> >
> > C++17 §6.9.2/3.4
> > «
> > A value of a pointer type that is a pointer to or past the end of an object represents the address of the first byte in memory (4.4) occupied b the object 54 or the first byte in memory after the end of the storage occupied by the object, respectively.
> > »
> >
>
> I don't dispute that but the Standard, like me, doesn't call such a pointer an "iterator".

Consider an arbitrary object t. If t is const-qualified, then &t is a
constant iterator (27.2.1p4), and therefore doesn't "satisfy the
requirements for output iterators". However, if it's not const-
qualified, &t is a mutable iterator, and does meet those requirements.
Because of the clauses cited by Alf above, 1+&t is a past-the-end
iterator that is not dereferenceable (27.2.1p7). Other than that, can
you identify even a single iterator requirement listed in section 27.2
that either &t or 1+&t doesn't meet?

[Juha Nieminen]

//========================================================
#include <iostream>
#include <vector>

template<typename T>
void foo(const T& p)
{
std::cout << "Reference: " << p[0] << "\n";
}

template<typename T>
void foo(const T* p)
{
std::cout << "Pointer.\n";
foo(*p);
}

int main()
{
std::vector<int> vec(10, 20);
const std::vector<int>* ptr = &vec;

foo(vec);
foo(ptr);
}
//========================================================

[Jorgen Grahn]

I agree, and I suppose that ties in with the "how does foo() know"
question. If you pass a single pointer, and no length, what you're
passing is probably not an iterator.

[Mr Flibble]

I said I didn't dispute that however the Standard clearly states that iterators are abstractions of pointers; a pointer isn't an iterator because a thing can't be an abstraction of itself; the exact wording from the Standard is:

23.3.1 (ISO/IEC JTC1 SC22 WG21 N4860)

"Since iterators are an abstraction of pointers, their semantics are a generalization of most of the semantics of
pointers in C++. This ensures that every function template that takes iterators works as well with regular
pointers."

[James Kuyper]

The standard says "generalization", not "abstraction". I'm not sure
whether that distinction is relevant to your understanding of the
situation, but in general a category is a subset of any other category
that can properly be described as a generalization of that category.
123456789012345678901234567890123456789012345678901234567890123456789012

For instance, the integers, the rational numbers, the real numbers and
the complex numbers are all generalizations of the natural numbers. Each
of those categories is a proper subset of the next category I listed -
the natural numbers are a proper subset of all of them. The number 2 is
in all of those categories.

Iterators are a generalization of pointers in exactly the same sense.
Every object pointer type is an iterator type. This is not an accident -
the requirements for iterator types were deliberately designed to
guarantee that object pointer types could satisfy those requirements.

Given an unqualified object type T and the following declarations:
T t, *p = &t;

The only requirements something needs to meet to qualify as an iterator
are listed in 27.2.2. p meets all of them:.

T* is CopyConstructible
T* is CopyAssignable
T* Destructible
lvalues of type T* are swappable
*p is valid if p is dereferenceable
p++ is valid

Which of those requirements do you claim it doesn't satisfy? Since you
restricted your claim to pointers to a single object, I suspect that you
might think the last requirement would be a problem, but the clauses Alf
cited guarantee that, for the purposes of pointer addition, &t is
treated as pointing at the first element of a 1-element array, so p++ is
valid expression, which leaves p pointing one past the end of that
array.

However, p doesn't just meet the general iterator requirements, it also
qualifies as a mutable iterator (27.2.1p4), a contiguous iterator
(27.2.1p6), an input iterator (27.2.3), an output iterator (27.2.4), a
forward iterator (27.2.5), a bidirectional iterator (27.2.6), and a
random access iterator (27.2.7).

I reiterate my previous challenge: please identify a single iterator
requirement that is not satisfied by &t.

Footnote 261, while not normative, confirms this interpretation of the
normative text: "... pointers are iterators.".

All citations are from n4659.pdf, the most recent draft of the standard that I currently have available. Please let me know if anything relevant has changed in the current standard that renders that conclusion inaccurate.

[James Kuyper]

On 5/23/20 4:26 AM, Jorgen Grahn wrote:
> On Fri, 2020-05-22, Mr Flibble wrote:
...

>> Nit: a pointer *might be* an iterator but not all pointers are
>> iterators; I find the claim that a pointer to a single object that
>> is not part of a controlled sequence or an array is an iterator
>> bogus.
>
> I agree, and I suppose that ties in with the "how does foo() know"
> question.

I agree that the part of foo() that was provided is poorly designed -
but the additional parameters of foo() are unspecified - they might have
included either a count or an end-pointer, and the OP didn't think that
worth mentioning.

> If you pass a single pointer, and no length, what you're
> passing is probably not an iterator.

?
If the body of a function will be adding or subtracting an integer to
the pointer, it needs some way of determining how much it can safely add
or subtract - but there's at least two other ways to do that. Provide a
second pointer identifying the end of the range, or use a special value
in the array to mark the end, such as '\0' for strings.
A pointer for which no such method applies should generally be assumed
to point at a single object.

However, how is that relevant to whether or not the pointer qualifies as
an iterator? See my response to Flibble for a more detailed version of
that question.

[Mr Flibble]

> whether that distinction is relevant to your understanding of ... <snip>

Can't you fucking read or are just deliberately ignoring my reply so you can vomit out a load of drivel? Again, QUOTING FROM THE STANDARD:

23.3.1 (ISO/IEC JTC1 SC22 WG21 N4860)

"Since iterators are an abstraction of pointers, their semantics are a generalization of most of the semantics of
pointers in C++. This ensures that every function template that takes iterators works as well with regular
pointers."

Now either learn to fucking read or stop trolling you obtuse egregious cunt.

[Öö Tiib]

I suspect that here is again some kind of wordplay in action.
Pointer is usable as iterator but from that does not follow that
all pointers are iterators. Null iterators do not exist while null
pointers are very widely used. Other common usage of pointers
is as pointer to polymorphic base sub-object that also is not
valid iterator.

[mehrdad]

On 22/05/2020 22:28, Jorgen Grahn wrote:

Many many thanks, I wrote a simple iterator class and after a little bit
of wrestling with const and non const conflicts I got everything
working. It works a treat!

[mehrdad]

On 23/05/2020 15:48, James Kuyper wrote:

It does include a count in my case.

[James Kuyper]

On 5/23/20 11:19 AM, Öö Tiib wrote:
> On Saturday, 23 May 2020 17:48:39 UTC+3, James Kuyper wrote:

...

>> However, how is that relevant to whether or not the pointer qualifies as
>> an iterator? See my response to Flibble for a more detailed version of
>> that question.
>
> I suspect that here is again some kind of wordplay in action.
> Pointer is usable as iterator but from that does not follow that
> all pointers are iterators.

Possibly - what do you mean by "iterator"? As far as I can see, the
standard doesn't define the term "iterator" - it defines a wide variety
of specific iterator categories (several of them in 27.2.1p2, and
sporadically throughout section 27) in terms of the iterator type's
ability to meet the corresponding requirements, but oddly enough, it
doesn't do so for "iterator" itself.

To me, an iterator is something that meets the standard's iterator
requirements (27.2.2), which all pointer types do.
Regardless of what definition you use for "iterator", the standard's
definition for, for instance, "random access iterator" does apply, and a
pointer to any arbitrary object type fits that definition. The same
applies to all of the other iterator categories that the standard does
define (in a few cases, such as "constant iterator", that's true only
for some pointer types).

> ... Null iterators do not exist while null

> pointers are very widely used.

The existence of null pointers of a given type doesn't have any effect
on that type's ability to meet iterator requirements. If the standard's
description of a template has a template parameter with a name that ends
in "Iterator", it should accept any pointer to object type for that
parameter, so long as the values of corresponding objects meet the other
requirements of the template. As a general rule, a null pointer won't
meet those other requirements, but non-null pointer values should be
perfectly usable.

The only construct that code associated with such a template might
otherwise be able to use to run into trouble is T(). If T is a pointer
type, that would result in a null pointer. However, there's no
requirement that any iterator type be DefaultConstructible, and as a
result, no definition for what the result of such an expression for an
iterator type should be. If it results in a pointer value that is not
dereferenceable and can't be added to or subtracted from, that doesn't
violate any iterator requirements.

> ... Other common usage of pointers

> is as pointer to polymorphic base sub-object that also is not
> valid iterator.

A Base* object meets all of the iterator requirements, including the
requirement that p++ be a valid expression. Such a pointer is treated as
pointing to the first element of a one-element array of Base objects,
and p++ points one past the end of that array.

[James Kuyper]

On 5/23/20 12:16 PM, mehrdad wrote:
> On 23/05/2020 15:48, James Kuyper wrote:
>
> It does include a count in my case.

As a general rule, when posting a response you should remove any part of
the message that you're responding to that isn't directly relevant to
your response, and in usenet it's conventional to post your response
underneath the thing that it's a response to. It took me a little
searching to realize that your message was a response to the following
comment:

...>> I agree that the part of foo() that was provided is poorly designed -

[Mr Flibble]

On 23/05/2020 18:09, James Kuyper wrote:
> On 5/23/20 12:16 PM, mehrdad wrote:
>> On 23/05/2020 15:48, James Kuyper wrote:
>>
>> It does include a count in my case.
>
> As a general rule, when posting a response you should remove any part of
> the message that you're responding to that isn't directly relevant to
> your response, and in usenet it's conventional to post your response
> underneath the thing that it's a response to. It took me a little
> searching to realize that your message was a response to the following
> comment:

Do as I say but not as I do, eh, mate? Fucking. Egregious.

[Manfred]

From n4659 to n4860 the section number is changed (27.2 vs 23.3),
however the relevant wording is not:
Clause 1 says "Iterators are a generalization of pointers..."
Clause 2 says "Since iterators are an abstraction of pointers..."

Now you can properly enjoy your fight.

[James Kuyper]

On Saturday, May 23, 2020 at 1:22:47 PM UTC-4, Mr Flibble wrote:
> On 23/05/2020 18:09, James Kuyper wrote:

...

> > As a general rule, when posting a response you should remove any part of
> > the message that you're responding to that isn't directly relevant to
> > your response, and in usenet it's conventional to post your response

> > underneath the thing that it's a response to. ...
...
> Do as I say but not as I do, eh, mate? ...

What in the world are you talking about? My response was a prime example
of doing precisely what I was advising him to do, and deliberately so. I
responded to a message containing 36 lines, by removing all but the 8
lines that were actually directly relevant to my response, and placing
my response directly after the particular line I was responding to.

[Mr Flibble]

I am talking about you conveniently snipping parts of MY reply to allow you to conveniently ignore them and post vomit instead.

[Daniel P]

On Friday, May 22, 2020 at 7:17:05 PM UTC-4, Mr Flibble wrote:

> the Standard clearly states that iterators are abstractions of pointers;
> a pointer isn't an iterator because a thing can't be an abstraction of
> itself

But consider: in mathematics, a field may be considered an abstraction
(generalization) of some properties of the rational numbers, and the rational
numbers are (meet the requirements of) a field.

>
> ... but the Standard, like me, doesn't call such a pointer an "iterator".
>

And as James pointed out, quoting footnote 261 in n4659, "This definition
applies to pointers, since pointers are iterators."

Daniel

[James Kuyper]

On Monday, May 25, 2020 at 8:34:14 AM UTC-4, Mr Flibble wrote:
> On 25/05/2020 04:25, James Kuyper wrote:
> > On Saturday, May 23, 2020 at 1:22:47 PM UTC-4, Mr Flibble wrote:
> >> On 23/05/2020 18:09, James Kuyper wrote:
> > ...
> >>> As a general rule, when posting a response you should remove any part of
> >>> the message that you're responding to that isn't directly relevant to
> >>> your response, and in usenet it's conventional to post your response
> >>> underneath the thing that it's a response to. ...
> > ...
> >> Do as I say but not as I do, eh, mate? ...
> >
> > What in the world are you talking about? My response was a prime example
> > of doing precisely what I was advising him to do, and deliberately so. I
> > responded to a message containing 36 lines, by removing all but the 8
> > lines that were actually directly relevant to my response, and placing
> > my response directly after the particular line I was responding to.
>
> I am talking about you conveniently snipping parts of MY reply to allow you to conveniently ignore them and post vomit instead.

I interpreted your comment as referring to the message it was responding
to, as the example you were referring to of me not following my own
advice. That's the normal interpretation of such a comment in such a
context. Since you actually intended to refer to a different message,
you could have avoided creating confusion by saying so explicitly.

However, "snipping parts of MY reply" was a prime example of following
my own advice, not violating it. I snipped those parts because, in my
judgment, they weren't relevant to my response. You obviously disagree
with that judgment, but that disagreement doesn't make my behavior a
violation of my own advice. Failing to snip the part that you're
criticizing me for snipping would have constituted a violation of that
advice.

If you wish, I can modify the wording of my advice to make the point
clearer:

"... remove any part of the message that you're responding to that is
not, according to your own judgment, directly relevant to your response,
..."

I didn't add that clause in my original advice, because I considered it
to be implicitly obvious that only the author's own judgment can be used
for this purpose. Even if the author goes to other people for advice on
how to write a given message, it is ultimately the author's
responsibility to judge which such advice to follow. It would, in my
opinion, be seriously bad advice if I changed "your own judgment" to
"Mr. Fibble's judgment".

In my opinion, the clause from the standard that you quoted and I
snipped clearly supports my interpretation, and not yours. In your
opinion, it clearly supports your opinion, and not mine. We have already
both expressed those opinions, and given our reasons for them - I didn't
see anything more worth saying about the matter. Therefore, I didn't say
anything about that citation, and therefore, I snipped it.

A useful response on your part would be to cite the clause in which the
standard defines the term "iterator" - I couldn't find one.

I found some relevant definitions in 27.2.1p2: "This International
Standard defines five categories of iterators, according to the
operations defined on them: input iterators, output iterators, forward
iterators, bidirectional iterators and random access iterators, ...".
Each of those category names is in italics, an ISO convention
identifying this clause as providing the definitions for those terms,
but the term "iterator" on it's own is not so marked, neither here nor
anywhere else that I could find.

I just realized that there's an important rule for interpreting ISO
standards that helps with this issue. When an ISO standard provides a
list like that, it is meant to be an exhaustive list unless otherwise
specified, which would imply that an iterator is anything that meets the
requirements of at least one of those categories. Note that forward,
bidirectional, and random access iterators are all defined as subsets of
input iterators, so that would imply that an iterator is anything that
meets the requirements for being either an input iterator or an output
iterator. But the standard fails to say so explicitly.

Every non-null pointer to an object type meets the requirements for a
random access iterator. Every non-null pointer to an object type which
isn't const-qualified also meets the requirements for an output
iterator. If you believe otherwise, the most useful response you could
make would be to identify at least one specific requirement that at
least one such pointer fails to meet.

From past experience, I don't expect a useful response from you, merely
more foul-mouthed insults - but I can hope.

[Mr Flibble]

On 25/05/2020 14:28, Daniel P wrote:
> On Friday, May 22, 2020 at 7:17:05 PM UTC-4, Mr Flibble wrote:
>
>> the Standard clearly states that iterators are abstractions of pointers;
>> a pointer isn't an iterator because a thing can't be an abstraction of
>> itself
>
> But consider: in mathematics, a field may be considered an abstraction
> (generalization) of some properties of the rational numbers, and the rational
> numbers are (meet the requirements of) a field.

An apple might be green but it doesn't follow that all green things are apples.

>
>>
>> ... but the Standard, like me, doesn't call such a pointer an "iterator".
>>
>
> And as James pointed out, quoting footnote 261 in n4659, "This definition
> applies to pointers, since pointers are iterators."

Then the Standard is inconsistent. A thing cannot be an abstraction of itself; not all pointers are iterators.

[Daniel P]

On Monday, May 25, 2020 at 12:45:27 PM UTC-4, Mr Flibble wrote:
> On 25/05/2020 14:28, Daniel P wrote:

.> >

> > But consider: in mathematics, a field may be considered an abstraction
> > (generalization) of some properties of the rational numbers, and the rational
> > numbers are (meet the requirements of) a field.
>
> An apple might be green but it doesn't follow that all green things are
> apples.
>

The property "green" cannot be sensibly be regarded as an abstraction or
generalization of "apple".

> >
> >>
> >> ... but the Standard, like me, doesn't call such a pointer an "iterator".
> >>
> >
> > And as James pointed out, quoting footnote 261 in n4659, "This definition
> > applies to pointers, since pointers are iterators."
>
> Then the Standard is inconsistent. A thing cannot be an abstraction of itself; not all pointers are iterators.
>

I don't know what "a thing cannot be an abstraction of itself" means.

In logic, if a pointer meets the requirements of an iterator category, then
it _is_ a member of that category. As James notes, "Every non-null pointer to

an object type meets the requirements for a random access iterator. Every
non-null pointer to an object type which isn't const-qualified also meets the
requirements for an output iterator."

Agree? Disagree?

Daniel

[Mr Flibble]

On 25/05/2020 18:46, Daniel P wrote:
> On Monday, May 25, 2020 at 12:45:27 PM UTC-4, Mr Flibble wrote:
>> On 25/05/2020 14:28, Daniel P wrote:
> .> >
>>> But consider: in mathematics, a field may be considered an abstraction
>>> (generalization) of some properties of the rational numbers, and the rational
>>> numbers are (meet the requirements of) a field.
>>
>> An apple might be green but it doesn't follow that all green things are
>> apples.
>>
> The property "green" cannot be sensibly be regarded as an abstraction or
> generalization of "apple".

I see you dislike my analogy probably because you enjoy indulging in pedantic fucktardary just like the other guy.

OK, I improve my fucking analogy:

An apple might be a fruit but not all fruits are apples,

i.e.

an iterator might be a pointer but not all pointers are iterators.

>>>
>>>>
>>>> ... but the Standard, like me, doesn't call such a pointer an "iterator".
>>>>
>>>
>>> And as James pointed out, quoting footnote 261 in n4659, "This definition
>>> applies to pointers, since pointers are iterators."
>>
>> Then the Standard is inconsistent. A thing cannot be an abstraction of itself; not all pointers are iterators.
>>
> I don't know what "a thing cannot be an abstraction of itself" means.

I will try re-wording so it is less technical to help you understand:

a thing cannot be an abstraction of itself

If you still don't understand then I suggest you learn fucking English.

>
> In logic, if a pointer meets the requirements of an iterator category, then
> it _is_ a member of that category. As James notes, "Every non-null pointer to
> an object type meets the requirements for a random access iterator. Every
> non-null pointer to an object type which isn't const-qualified also meets the
> requirements for an output iterator."
>
> Agree? Disagree?

Disagree.

A null pointer doesn't meet the requirements of an iterator ergo you have to accept that what a pointer points to is relevant; given that and the fact that the Standard itself states that iterators are an abstraction/generalization of pointers then you have to accept that a) the Standard is inconsistent and b) not all pointers are iterators. The footnote the other guy pointed out is probably non-normative but this doesn't stop the Standard from being inconsistent.

[James Kuyper]

On Monday, May 25, 2020 at 4:57:58 PM UTC-4, Mr Flibble wrote:
> On 25/05/2020 18:46, Daniel P wrote:
> > On Monday, May 25, 2020 at 12:45:27 PM UTC-4, Mr Flibble wrote:
> >> On 25/05/2020 14:28, Daniel P wrote:
> > .> >
> >>> But consider: in mathematics, a field may be considered an abstraction
> >>> (generalization) of some properties of the rational numbers, and the rational
> >>> numbers are (meet the requirements of) a field.
> >>
> >> An apple might be green but it doesn't follow that all green things are
> >> apples.
> >>
> > The property "green" cannot be sensibly be regarded as an abstraction or
> > generalization of "apple".
>
> I see you dislike my analogy probably because you enjoy indulging in pedantic fucktardary just like the other guy.

There's nothing particularly pedantic about it, it's simply the fact that the concept of green is not in any sense (pedantic or otherwise) an abstraction of the concept of apples, so your analogy is completely unconnected with the point under discussion.

Now, the concept of green objects is an abstraction of the concept of green apples, so you could say "A green apple might be green object, but it doesn't follow that all green objects are green apples.", and that would be perfectly correct. The problem is, to complete that analogy, you'd have replace "green apple" with "pointer type" and "green object" with "iterator type", and that substitution doesn't produce the result you want to see.

> OK, I improve my fucking analogy:
>
> An apple might be a fruit but not all fruits are apples,
>
> i.e.
>
> an iterator might be a pointer but not all pointers are iterators.

The concept of a fruit is an abstraction of the concept of an apple,
just as the concept of an iterator is an abstraction of the concept of a
pointer. The category of fruits is a generalization of the category of
apples, just as the category of iterator types is a generalization of
the category of pointer types. As a result, your analogy is precisely
backwards. The correctly constructed analogy is:

A pointer might be an iterator, but not all iterators are pointers.

Which is also perfectly correct, for precisely the same reason. I can
understand why you wouldn't want to say it that way, but how in the
world can you justify trying to pass off the reverse order as if it were
a proper analogy?

...

> A null pointer doesn't meet the requirements of an iterator ergo you
> have to accept that what a pointer points to is relevant; given that
> and the fact that the Standard itself states that iterators are an
> abstraction/generalization of pointers then you have to accept that a)
> the Standard is inconsistent and b) not all pointers are iterators.

Null pointers don't disqualify pointers from meeting iterator
requirements. They are examples of singular iterators: "Iterators can
also have singular values that are not associated with any sequence.
Example: After the declaration of an uninitialized pointer x (as with
int* x;), x must always be assumed to have a singular value of a
pointer. — end example ] Results of most expressions are undefined for
singular values ...". (27.2.1p7).

You can't pass a null pointer to most standard library functions that
require iterator types, for the same reason that you can't pass any
other kind of singular iterators to them. But that doesn't mean that
there's anything wrong with passing non-null pointers of the same type
to such functions.

If you know that something is a pointer type, you know you can safely do
some things with instances of that type which you would not know were
safe if all you knew about it was that it was an iterator type.
Specifically, you can compare null pointers for equality with any other
pointer of the same type, with well-defined behavior, something that is
not the case for singular iterators in general. That doesn't mean that
pointers violate iterator requirements. An iterator type is not
prohibited from having singular values that can be compared for equality.
It's the other way around: an iterator type is allowed to have singular
values that cannot be compared for equality, a very different concept.

Note: both of your conclusions are, however, perfectly correct.
a) The standard is inconsistent. This isn't an example of that fact, but
it would be extremely odd if any document as big as the standard were
perfectly consistent.
b) Not all pointers are iterators. Pointers to function types cannot be incremented, and neither can pointers to incomplete object types. Pointers to incomplete object type cannot even be dereferenced. Pointers to function types can be dereferenced, but the result of doing so does not satisfy any of the applicable iterator requirements.

However, all pointers to complete object types are iterators. I apologize for the fact that I failed to specify "complete" in my previous statements about this point.

[Mr Flibble]

Wrong, for the following reason:

apples are NOT an abstraction or generalization of apples.

[Mr Flibble]

And by that I mean the following is bogus:

1) Iterator is an abstraction of pointer
2) Given (1) pointer is an iterator
3) Given (1) and (2) iterator is an abstraction of iterator

If you don't think that is bogus then:

1) Learn logic
2) Learn fucking English

[Manfred]

On 5/26/20 12:18 AM, Mr Flibble wrote:
> On 25/05/2020 23:06, Mr Flibble wrote:
>> On 25/05/2020 23:00, James Kuyper wrote:

[...]

>>> However, all pointers to complete object types are iterators. I
>>> apologize for the fact that I failed to specify "complete" in my
>>> previous statements about this point.
>>
>> Wrong, for the following reason:
>>
>> apples are NOT an abstraction or generalization of apples.
>
> And by that I mean the following is bogus:
>
> 1) Iterator is an abstraction of pointer
> 2) Given (1) pointer is an iterator
> 3) Given (1) and (2) iterator is an abstraction of iterator

Error: step 3 is wrong because step 2 states that pointer is /an/
iterator (and not all iterators are pointers), thus the correct step 3
becomes:
3) Given (1) and (2) iterator is an abstraction of *a specific type of*
iterator (which a pointer is)

Which is a perfecly valid statement

>
> If you don't think that is bogus then:
>
> 1) Learn logic

In fact logic is not something you can easily mess with.

[Mr Flibble]

On 25/05/2020 23:44, Manfred wrote:
> On 5/26/20 12:18 AM, Mr Flibble wrote:
>> On 25/05/2020 23:06, Mr Flibble wrote:
>>> On 25/05/2020 23:00, James Kuyper wrote:
>
> [...]
>
>>>> However, all pointers to complete object types are iterators. I apologize for the fact that I failed to specify "complete" in my previous statements about this point.
>>>
>>> Wrong, for the following reason:
>>>
>>> apples are NOT an abstraction or generalization of apples.
>>
>> And by that I mean the following is bogus:
>>
>> 1) Iterator is an abstraction of pointer
>> 2) Given (1) pointer is an iterator
>> 3) Given (1) and (2) iterator is an abstraction of iterator
>
> Error: step 3 is wrong because step 2 states that pointer is /an/ iterator (and not all iterators are pointers), thus the correct step 3 becomes:
> 3) Given (1) and (2) iterator is an abstraction of *a specific type of* iterator (which a pointer is)
>
> Which is a perfecly valid statement

No, it isn't, because it makes no absolutely sense whatsoever to anyone who can correctly comprehend the English language.

[Manfred]

On 5/26/20 12:57 AM, Mr Flibble wrote:
> On 25/05/2020 23:44, Manfred wrote:
>> On 5/26/20 12:18 AM, Mr Flibble wrote:
>>> On 25/05/2020 23:06, Mr Flibble wrote:
>>>> On 25/05/2020 23:00, James Kuyper wrote:
>>
>> [...]
>>
>>>>> However, all pointers to complete object types are iterators. I
>>>>> apologize for the fact that I failed to specify "complete" in my
>>>>> previous statements about this point.
>>>>
>>>> Wrong, for the following reason:
>>>>
>>>> apples are NOT an abstraction or generalization of apples.
>>>
>>> And by that I mean the following is bogus:
>>>
>>> 1) Iterator is an abstraction of pointer
>>> 2) Given (1) pointer is an iterator
>>> 3) Given (1) and (2) iterator is an abstraction of iterator
>>
>> Error: step 3 is wrong because step 2 states that pointer is /an/
>> iterator (and not all iterators are pointers), thus the correct step 3
>> becomes:
>> 3) Given (1) and (2) iterator is an abstraction of *a specific type
>> of* iterator (which a pointer is)
>>
>> Which is a perfecly valid statement
>
> No, it isn't, because it makes no absolutely sense whatsoever to anyone
> who can correctly comprehend the English language.

It is a basic example of the "is a" relationship.

>
> /Flibble
>

[Mr Flibble]

No, it is, a) meaningless as far as the English language is concerned and b) circular reasoning from the point of view of logic. SELF-REFERENTIAL DEFINITIONS ARE BOGUS (SEE ANY DICTIONARY).

[Manfred]

class Fruit
{
// generalization of apple
};

class Apple : public Fruit
{
// specialization of fruit
};

Using the "is a" logic relationship:
An apple "is a" fruit.

In human language:
An apple is a fruit, but not all fruits are apples.

How else would you express the above in proper English?

Back to the topic:
The standard says that "Iterators are a generalization of pointers",
i.e. a pointer is an iterator, but not all iterators are pointers [*].

This is a "is a" relationship, in your step 3) above you assume that a
"is a" relationship is an identity. In logic it is not.
Hence my correction of your step 3) above.


[*] exceptions of null pointers and singular iterators left out because
they are, well... exceptions.

>
> /Flibble
>

[Mr Flibble]

Yes, it is, however:

class Apple : public Apple
{
// what we are actually taking about which is bogus.
};

>
> In human language:
> An apple is a fruit, but not all fruits are apples.

I already used that as an example.

>
> How else would you express the above in proper English?

Try reading a post properly before replying to it.

>
> Back to the topic:
> The standard says that "Iterators are a generalization of pointers", i.e. a pointer is an iterator, but not all iterators are pointers [*].
>
> This is a "is a" relationship, in your step 3) above you assume that a "is a" relationship is an identity. In logic it is not.
> Hence my correction of your step 3) above.

See above for why you remain wrong.

[James Kuyper]

On Monday, May 25, 2020 at 6:19:06 PM UTC-4, Mr Flibble wrote:
...

> And by that I mean the following is bogus:
>
> 1) Iterator is an abstraction of pointer
> 2) Given (1) pointer is an iterator
> 3) Given (1) and (2) iterator is an abstraction of iterator

If you think that has even the remotest connection to what we were saying, that misconception would explain a lot.

> 2) Learn fucking English

While I'm familiar with many different dialects of English, "fucking
English" is not one of them. If the rules of that dialect are
sufficiently different from those of conventional English to support
your claims, I'd prefer not to become familiar with it.

And because you seem dumb enough that this might need to be said: yes, I
know exactly what you actually meant by that sentence; I'm just
expressing my disapproval, both of what you said, and of how you chose
to say it, by deliberately misinterpreting it.

I see no point in further discussion. Feel free to respond with a vulgar
insult, as is your wont.

[Mr Flibble]

On 26/05/2020 14:58, James Kuyper wrote:
> On Monday, May 25, 2020 at 6:19:06 PM UTC-4, Mr Flibble wrote:
> ...
>> And by that I mean the following is bogus:
>>
>> 1) Iterator is an abstraction of pointer
>> 2) Given (1) pointer is an iterator
>> 3) Given (1) and (2) iterator is an abstraction of iterator
>
> If you think that has even the remotest connection to what we were saying, that misconception would explain a lot.

That is EXACTLY what you are saying, mate. So I assume you are now backtracking as I have finally got through your thick skull to show you your error in SELF REFERENTIAL CIRCULAR LOGIC.

[Manfred]

I'll give this one last chance.
This thread already sounds pretty much like a dialogue between deaf people.

>
> Yes, it is, however:
>
> class Apple : public Apple
> {
>     // what we are actually taking about which is bogus.
> };

This is what you have been repeating, but that's not what the standard
says about the relationship between pointers and iterators.
As far as I can understand you got this idea from Daniel quoting

footnote 261 in n4659, "This definition applies to pointers, since
pointers are iterators."

What I have been trying really hard to explain to you is that the
footnote sentence "pointers are iterators" states a "is a" relationship,
which is /not/ an identity relationship.
Your conclusion of "self-referential definition" (your point 3 above)
can only follow from the interpretation of the sentence "pointers are
iterators" as identity between pointers and iterators (your point 2
above), which is /not/ the case, and /not/ what the standard says.

>
>>
>> In human language:
>> An apple is a fruit, but not all fruits are apples.
>
> I already used that as an example.

So what?

>
>>
>> How else would you express the above in proper English?
>
> Try reading a post properly before replying to it.

This sounds like a lightning of theater of the absurd - which I find
great, by the way (the theater, not your comment: Beckett was
considerably better than you in the creative field).

>
>>
>> Back to the topic:
>> The standard says that "Iterators are a generalization of pointers",
>> i.e. a pointer is an iterator, but not all iterators are pointers [*].
>>
>> This is a "is a" relationship, in your step 3) above you assume that a
>> "is a" relationship is an identity. In logic it is not.
>> Hence my correction of your step 3) above.
>
> See above for why you remain wrong.

Maybe you can see above why my correction of your conclusion is correct.
If not, too bad - I'm going to stop here anyway.

>
> /Flibble
>

[Daniel P]

On Tuesday, May 26, 2020 at 7:18:37 AM UTC-4, Mr Flibble wrote:
>
> class Apple : public Apple
> {
> // what we are actually taking about which is bogus.
> };
>

I think Mr Flibble attributes a meaning to "abstraction" that is not present in
the Standard, and certainly not in logic or mathematics. That reductio absurdum
doesn't follow.

Daniel

[James Kuyper]

On 5/27/20 9:21 AM, Manfred wrote:
> On 5/26/2020 1:18 PM, Mr Flibble wrote:

...

>> Yes, it is, however:
>>
>> class Apple : public Apple
>> {
>>     // what we are actually taking about which is bogus.
>> };
>
> This is what you have been repeating, but that's not what the standard
> says about the relationship between pointers and iterators.
> As far as I can understand you got this idea from Daniel quoting
> footnote 261 in n4659, "This definition applies to pointers, since
> pointers are iterators."
>
> What I have been trying really hard to explain to you is that the
> footnote sentence "pointers are iterators" states a "is a" relationship,
> which is /not/ an identity relationship.

I've been trying hard, and failing, to figure out what he might have
been misunderstanding to justify his incorrect conclusions about the
circularity of our arguments. Misinterpreting such statements as
implying an identity relationship would make our arguments appear
circular, so that might be the explanation.

[Mr Flibble]

My conclusion is correct.

The Standard says that an iterator is an abstraction of a pointer. A thing cannot be an abstraction of itself ergo a pointer is not an iterator.

[Daniel P]

On Wednesday, May 27, 2020 at 4:47:32 PM UTC-4, Mr Flibble wrote:
>
> The Standard says that an iterator is an abstraction of a pointer. A thing
> cannot be an abstraction of itself ergo a pointer is not an iterator.
>

In type theory, any type is trivially a subtype of itself.

In mathematics, a group may be regarded as an abstraction of the set of integers, and the set of integers _is_ a group.

The considerations here are analogous.

Daniel

[Mr Flibble]

Erroneous analogy. False analogy. A thing cannot be an abstraction of itself. An iterator is an abstraction of iterators? Have a word, mate.

[James Kuyper]

When the standard says "Iterators are a generalization of pointers ...",
"... iterators are an abstraction of pointers, ...", and "... pointers
are iterators.", what it means by all three of those statements is that
the relationship between pointer types and iterator type is exactly the
same as the relationship between apples and fruits. All pointer types
are iterator types, but not all iterator types are pointer type, just as
all apples are fruits, but not all fruits are apples. In other words,
pointer types are a proper subset of iterator types.

If Mr. Fibble interprets any of those three statements as conveying a
meaning other than "pointer types are a proper subset of iterator
types", it might be because the standard is misusing the terms
"generalization" or "abstraction" (or even the verb "are"), though
personally I think it reflects a misunderstanding on his part of what
those words mean. Regardless of whether those are appropriate words to
convey that meaning, I am quite certain that this is the intended
meaning of all three of those statements. There is nothing more circular
about believing that to be the case, than there is in believing that the
set of apples is a proper subset of the set of fruits. It might be an
incorrect belief, but it's incorrectness has nothing to do with circular
logic.

[Manfred]

On 5/28/2020 5:37 AM, James Kuyper wrote:
> On 5/27/20 5:15 PM, Daniel P wrote:
>> On Wednesday, May 27, 2020 at 4:47:32 PM UTC-4, Mr Flibble wrote:
>>>
>>> The Standard says that an iterator is an abstraction of a pointer. A thing
>>> cannot be an abstraction of itself ergo a pointer is not an iterator.
>>>
>> In type theory, any type is trivially a subtype of itself.
>>
>> In mathematics, a group may be regarded as an abstraction of the set of integers, and the set of integers _is_ a group.
>>
>> The considerations here are analogous.
>
> When the standard says "Iterators are a generalization of pointers ...",
> "... iterators are an abstraction of pointers, ...", and "... pointers
> are iterators.", what it means by all three of those statements is that
> the relationship between pointer types and iterator type is exactly the
> same as the relationship between apples and fruits. All pointer types
> are iterator types, but not all iterator types are pointer type, just as
> all apples are fruits, but not all fruits are apples. In other words,
> pointer types are a proper subset of iterator types.
>
> If Mr. Fibble interprets any of those three statements as conveying a
> meaning other than "pointer types are a proper subset of iterator
> types", it might be because the standard is misusing the terms
> "generalization" or "abstraction" (or even the verb "are"),

There is definitely no room for doubt in a statement like "Iterators are
a generalization of pointers", and the other two sentences do not
contradict that statement either, so there is no misuse of the terms in
the standard.
In fact this is a very basic example of hierarchical type relationship
that we all are (or should be) very much used to.

Flibble's problem is that he can't see that when he says "A thing cannot
be an abstraction of itself" the term "itself" assumes that iterators
and pointers are the same thing.

Clearly that is not true, but he is trapped inside his loop, and he
can't get out of it by now.

[By the way, Daniel is right in his comment about type theory, but I
find this somewhat tangent to the issue at hand]

[Daniel P]

On Thursday, May 28, 2020 at 8:05:44 AM UTC-4, Manfred wrote:
> On 5/28/2020 5:37 AM, James Kuyper wrote:
> >
> > When the standard says "Iterators are a generalization of pointers ...",
> > "... iterators are an abstraction of pointers, ...", and "... pointers
> > are iterators.", what it means by all three of those statements is that
> > the relationship between pointer types and iterator type is exactly the
> > same as the relationship between apples and fruits. All pointer types
> > are iterator types, but not all iterator types are pointer type, just as
> > all apples are fruits, but not all fruits are apples. In other words,
> > pointer types are a proper subset of iterator types.
> >
>

> There is definitely no room for doubt in a statement like "Iterators are
> a generalization of pointers", and the other two sentences do not
> contradict that statement either, so there is no misuse of the terms in
> the standard.
> In fact this is a very basic example of hierarchical type relationship
> that we all are (or should be) very much used to.
>
> Flibble's problem is that he can't see that when he says "A thing cannot
> be an abstraction of itself" the term "itself" assumes that iterators
> and pointers are the same thing.
>
> Clearly that is not true

Flibble appears to ascribe a meaning to the word "abstraction" that I don't
think is there.

In mathematics, if a text book states "a group is an abstraction of the set
of integers", the word "abstraction" has no formal meaning, it is merely
suggestive, it conveys to the student something about the motivation for how
we came to have groups. Once that's established, we no longer care, the word
"abstraction" plays no part in our reasoning. We say that the set of integers
is a group, because it satisfies all the axioms of a group, so results
obtained from studying groups also apply to the set of integers.

I would suggest that the same applies to the use of the words
"generalization" and "abstraction" in the sentences "Iterators are a
generalization of pointers ..." and "... iterators are an abstraction of
pointers". They serve only to motivate the construction of the iterator
categories. Once we have the iterator categories, we can ask whether a
pointer satisfies the requirements of those categories, and if yes, we can
say it is an iterator.

Daniel

[Mr Flibble]

So you are saying that iterators are an abstraction of iterators. Have a word, mate.

[Daniel P]

On Thursday, May 28, 2020 at 12:39:02 PM UTC-4, Mr Flibble wrote:
>
> So you are saying that iterators are an abstraction of iterators. Have a word, mate.
>

I would say that a pointer is an iterator if it satisfies the requirements for
being an iterator. It is the same as in logic and mathematics. That is all.

Best regards,
Daniel

[Mr Flibble]