On generally accepted terminology for pointers and arrays

[Noah Roberts]

Surely you must realize that you have chosen to make a point to debate the
wording of his statement rather than the subjectively misarticulated meaning of
his response with regards to the former example.

In my opinion I didn't "miss-articulate". The void* type is an "opaque
type" rather than a pointer. The standard calls it "pointer to void"
but as we all know there's no such thing as a "void object". The
standard also has all kinds of special clauses for this type. Alf has
also already claimed that the standard is not useful in defining
conversational language about C++. The only alternative that I can
think of is to speak in concepts.

The standard calls anything that looks like "type*" as a "pointer type".
Alf doesn't like using the standard for the definition of "pointer" so
I gave him a different one based on generic programming (and I was quite
explicit about it by calling "pointer" a concept). Such a definition is
perfectly consistent and allows for "smart pointers" (which Alf claimed
needed to be included) but is not *perfectly* consistent with the
language of the standard, which Alf has already discounted as authority
on this matter.

Alf on the other hand has not provided any other definition of pointer
that has any consistency. All he's done is say that "type*" can be a
pointer to array if the address it contains happens to be part of an
array. There's no useful definition of "pointer" that would seem to
allow for this. His only response to my explanation was to call it
silly and run back to the language of the standard (which seems to only
apply when it suits him).

We can either agree to the language of the standard, in which case void*
is a pointer that points at void and smart pointers are not pointers at
all, or we can use something else useful to talk about "things that
point at stuff". In this later regard we can think of multiple reasons
why "void*" is inconsistent with the concept of "pointer"; one
particularly reasonable example of this is that iterator_traits cannot
be instantiated on this type and iterators are pretty much the
definition of "pointer" as a concept.

Alf has called the former too "pedantic and useless" but has yet to
provide a useful alternative. I tried and got a pile of troll-shit for
thanks. Frankly I don't care if he wishes to continue asserting
absurdities and calling them truth and he can live in my killfile now.

 

[gwowen]

Am 12.04.2011 20:05, schrieb cpp4ever:

[in a huff - acting like a 6 year-old]

OMG is this kindergarten?

Peter

Yes. It really really is. It's very very sad to see (presumably)
grown up people behaving like 4 year olds. "You're a troll!" "No,
you're a troll!" "Takes one to know one!"

One can only wonder how (if?) these people manage in real life when
anything that contradicts their worldview is treated with denial and
contempt. (I suspect "not well" which might be part of the problem.)
You'd get calmer, better constructed arguments at a debating
competition between Donald Trump and Sarah Palin moderated by Keith
Olbermann. The sheer social incompetence of (presumably) employed
programmers does go some way to explain the usability of so much
modern software. Almost nobody appears even slightly interested in
anyone's opinion but their own.

And now another thread, that started reasonably and calmly and
intelligently has degenerated into almost-painfully-unimaginative name
calling, because no-one will possibly admit that other's viewpoints
are valid. We should all be ashamed of ourselves. Personally, I'm
embarassed on all our behalf. It's pitiful.

 

[Jorgen Grahn]

Speaking personally, I find it helpful to think of pointers as
modelling two distinct concepts.

i) A nullable, reseatable reference to a single (possibly polymorphic)
object.
I can use it to access the members of the base type to which it has
been declared to point. Trying anything else is fraught with danger
(even obtaiining a copy of the object (due to slicing)).

ii) A bi-directional iterator into a contiguous collection of non-
polymorphic objects.
Subject to staying within the bounds (or just off the end) I can
increment, decrement to iterate over the collection, access members or
otherwise manipulate however I like. Using an array variable name as a
value just obtains such an iterator for the start of the array. Sadly,
you don't get the equivalent of an std::vector.end() member function.

As a useful rule of thumb: if you mix these concepts up, bad things
will often happen. If you don't everything will be fine.

Excellent! The textbooks should explain it that way. It's how I
think of pointers too (but I never managed to put it into words
like that).

/Jorgen

 

[Öö Tiib]

And now another thread, that started reasonably and calmly and
intelligently has degenerated into almost-painfully-unimaginative name
calling, because no-one will possibly admit that other's viewpoints
are valid. We should all be ashamed of ourselves. Personally, I'm
embarassed on all our behalf. It's pitiful.

You should not be ashamed for others. Your post about two models of
pointers was quite good. Software developers are assumed to be capable
to read a lot and fast and to filter irrelevant stuff out.

 

[Öö Tiib]

* gwowen, on 12.04.2011 09:16:

On Apr 12, 7:24 am, gwowen<[email protected]>  wrote:

[replying to self - bad me]

Speaking personally, I find it helpful to think of pointers as
modelling two distinct concepts.
i) A nullable, reseatable reference to a single (possibly polymorphic)
object.
I can use it to access the members of the base type to which it has
been declared to point.  Trying anything else is fraught with danger
(even obtaiining a copy of the object (due to slicing)).

[
  other safe things :-
  downcasting to a pointer-to-type-from-which-our-pointed-to-type is
derived.
  upcasting to a pointer-to-more-derived-type, as long as I check for
dynamic_cast<>  returning NULL
]

ii) A bi-directional iterator into a contiguous collection of non-
polymorphic objects.

[
  I meant "random access iterator" not bidirectional, with the array
access ptr[n] being syntactic sugar for *(ptr+n)
]

[...]

   * * *

Re the two kinds of pointers, yes it's technically a shortcoming of the C++ type
system. But then so is the failure to distinguish pointers to automatically
allocated objects from pointers to dynamically allocated objects. And so on. The
various combinations of properties to distinguish explodes exponentially.I'm
not aware of any good answer, although a RAND corporation employee (as I recall)
once posted to clc++m a proposal to replace use of raw pointers with use of
smart pointers that modeled these concepts/distinctions.

There are whole pile of smart pointers and these all already model the
sub-concepts of that i). Some are quite thin and efficient wrappers
like auto_ptr, scoped_ptr and unique_ptr. What he wanted to add?
About ii) i think that array<> and vector<> model whole arrays.
Iterators of those containers model the concept ii). Sole case when i
use array is when i have static array and want to initialize it C-
style. However C++2011 will extend ways to initialize containers so
that usage goes away as well it seems.

 

[Paul]

Snipping the greater points in my response, to myself, and certainly the
"general consensus" is a sign that you have simply chosen not to respond
to
greater points and not because they are actually irrelevant in the scope
of this
thread.

Alf, context has greater value than I think you are willing to admit.

Since I can see the logic in your rebuttle to Noah, I am convinced that
you are
not ignorant to the importance of technical correctness and well-defined
terminology.

So, let me ask you this directly. How does your logical assertion that an
int*
can "dynamically" point to an array fit into the pointer definition below?

For a type T, T* is the type "pointer to T." That is, a variable of type
T* can
hold the address of an object of type T.

Because, with pointers to arrays the standard makes a further definition in
the section about arrays.
I have told you this numerous times and quoted the relevant sections that
basically explain..When dereferenced, a pointer to an array yields an (n-1)
dimensional array.

If it wasn't for the fact that i have told you this so many times and you
refuse to accept this definition from the C++ standards, I would refrain
from calling you and most of the other total fucking idiots in this thread,
exactly that.

Plonk.

<snip>

 

[Öö Tiib]

In my opinion I didn't "miss-articulate".  The void* type is an "opaque
type" rather than a pointer.  The standard calls it "pointer to void"
but as we all know there's no such thing as a "void object".  The
standard also has all kinds of special clauses for this type.  Alf has
also already claimed that the standard is not useful in defining
conversational language about C++.  The only alternative that I can
think of is to speak in concepts.

So lets take char*. It is pointer to char (a byte).

char const* hi = "Hello World";

I don't know anyone who say in conversational language looking at that
code that hi points to first byte in string literal. It is true but no
one will say such silly nonsense.

 

[hanukas]

So lets take char*. It is pointer to char (a byte).

 char const* hi = "Hello World";

I don't know anyone who say in conversational language looking at that
code that hi points to first byte in string literal. It is true but no
one will say such silly nonsense.

Depends on whether it's pedantic nit-picking conversation or getting
some real work done. The consensus at my work place in our team would
be that a pointer is just abstraction of memory address with some type
sugar thrown on top. Most of us come from 6508/68k/z80 (Generation-X
dudes mostly, obviously).

 

[Paul]

So lets take char*. It is pointer to char (a byte).

Its a pointer type declaration. The statement, on its own, doesn't even
create a pointer.

char const* hi = "Hello World";

Now you have a pointer of type char*, which addresses a byte.
What does it point to? Its quite obvious, it points to a char array. If you
want to get specific you can say it points to the first element but
primarily it points to an array.

I don't know anyone who say in conversational language looking at that
code that hi points to first byte in string literal. It is true but no
one will say such silly nonsense.

No its not silly nonsesne to say, for example: that new[] returns a pointer
to the first element of an array, sometimes it is ok to be specific.
What IS silly nonsense is to say that because it points to the first
element, it doesn't point to the array.

 

[Paul]

Interesting that Paul should feel the need to step up and answer a direct
question to Alf, that Alf has yet to respond to.

But since he did, aside from the painfully obvious fact that this is a
mis-citation because this section of the Standard explicitly refers to
_multi-dimensional arrays_, and the controversial example in this
discussion is
a 1-dimensiona array, you fail to realize that you are proving yourself
wrong
when you yourself fail to apply this case for when it is actually
applicable.

You obviously cannot read or understand the C++ standards.
IDIOT
Plonk..

<snip>.

 

[Paul]

On 4/12/2011 1:01 PM, cg_chas wrote:

Surely you must realize that you have chosen to make a point to
debate
the
wording of his statement rather than the subjectively misarticulated
meaning of
his response with regards to the former example.

In my opinion I didn't "miss-articulate". The void* type is an "opaque
type" rather than a pointer. The standard calls it "pointer to void"
but as we all know there's no such thing as a "void object". The
standard also has all kinds of special clauses for this type. Alf has
also already claimed that the standard is not useful in defining
conversational language about C++. The only alternative that I can
think of is to speak in concepts.

So lets take char*. It is pointer to char (a byte).

Its a pointer type declaration. The statement, on its own, doesn't even
create a pointer.

char const* hi = "Hello World";

Now you have a pointer of type char*, which addresses a byte.
What does it point to? Its quite obvious, it points to a char array. If
you
want to get specific you can say it points to the first element but
primarily it points to an array.

I don't know anyone who say in conversational language looking at that
code that hi points to first byte in string literal. It is true but no
one will say such silly nonsense.

No its not silly nonsesne to say, for example: that new[] returns a
pointer
to the first element of an array, sometimes it is ok to be specific.
What IS silly nonsense is to say that because it points to the first
element, it doesn't point to the array.

As usual, you are misunderstanding the entire nature of the discussion.
It is not merely because it points to <snip>

Apparently you think you define the langauge. Well you don't and you
blatantly refuse to acknowledge what is defined in the C++ standards.

Until you can accept the C++ language, as defined in the standards, please
keep your stupid, annoying posts out of my discussions.

 

[Paul]

Read what exactly? The only one who is bothering to cite a valid part of
the
Standard is me. In this case it is 8.3.4 paragraph 7 that explicitly
refers to
multi-dimensional arrays.

Read the relevant sections about pointers to arrays.

To what case do you refer? Or are you neglecting to name it because you
want it
to serve your point telepathically rather than rationally?

Your word, and it serves you most appropriately.

The word was used to describe you. A spade is a spade.

 

[Paul]

Surely you must realize that you have chosen to make a point to
debate
the
wording of his statement rather than the subjectively
misarticulated
meaning of
his response with regards to the former example.

In my opinion I didn't "miss-articulate". The void* type is an
"opaque
type" rather than a pointer. The standard calls it "pointer to void"
but as we all know there's no such thing as a "void object". The
standard also has all kinds of special clauses for this type. Alf has
also already claimed that the standard is not useful in defining
conversational language about C++. The only alternative that I can
think of is to speak in concepts.

So lets take char*. It is pointer to char (a byte).

Its a pointer type declaration. The statement, on its own, doesn't even
create a pointer.


char const* hi = "Hello World";

Now you have a pointer of type char*, which addresses a byte.
What does it point to? Its quite obvious, it points to a char array. If
you
want to get specific you can say it points to the first element but
primarily it points to an array.


I don't know anyone who say in conversational language looking at that
code that hi points to first byte in string literal. It is true but no
one will say such silly nonsense.

No its not silly nonsesne to say, for example: that new[] returns a
pointer
to the first element of an array, sometimes it is ok to be specific.
What IS silly nonsense is to say that because it points to the first
element, it doesn't point to the array.

As usual, you are misunderstanding the entire nature of the discussion.
It is not merely because it points to <snip>

Apparently you think you define the langauge. Well you don't and you
blatantly refuse to acknowledge what is defined in the C++ standards.

You mistake me thinking that I define the language with my ability to
correctly
cite the Standard.

Until you can accept the C++ language, as defined in the standards, please
keep your stupid, annoying posts out of my discussions.

I wholeheartedly accept the Standard, that's why I am not afraid to
include the
section number, title, and paragraph, when I cite it.

There is a big section in the C++ standards titled ARRAYS.
It fully details the behaviour of pointers to arrays in the C++ language.

If you go away and read that instead of posting your bullshit incorrect
opinions then you'd do everyone a big favour.

 

[Paul]

I have. Was there something specific that you feel one of them says that
asserts
your case that an int* points to an array?

Read it again then , you obviously don't understand it.

And keep reading it until you do understand it.

 

[Paul]

Read what section exactly?

THE FUCKIN SECTION ABOUT POINTERS TO ARRAYS.

FFS stop being so stupid , how many times do I have to explain?

 

[Alf P. Steinbach /Usenet]

* cg_chas, on 12.04.2011 22:01:

Yes I read and understood his statement expressely for the face value of every
word in the sentence. Where we differ though is that I can see the greater
value in his point regardless if he botched the wording or not.

I'm sure that with enough empathy any self-contradictory statement can be viewed
as an attempted expression of some beautiful thought.

But, you can't require utmost precision of others, and think your own side is
exempt from that requirement.

At least if you want to be taken seriously.



[snip]

Since I can see the logic in your rebuttle to Noah, I am convinced that you are
not ignorant to the importance of technical correctness and well-defined
terminology.

Ah, good.

So, let me ask you this directly. How does your logical assertion that an int*
can "dynamically" point to an array fit into the pointer definition below?

For a type T, T* is the type "pointer to T." That is, a variable of type T* can
hold the address of an object of type T.

For most of us there is no problem.

Consider this function:

void upcase( char* p )

If caller and implementor disagree on whether p points to single char object, or
to a zero-terminated string, or whatever, then result might be core dump...

Now I pass by your desk and see you struggling with this function. Someone has
noticed that too many core dumps seem to indicate that this 'upcase' function is
the culprit, and you are attempting to fix it. As I pass you by you remark on
the competentency (or lack thereof) of the original programmer, "jeez, this call
to toupper passes negative values, he forgot to cast!".

I glance at it, and remark "he he, and he also seems to have assumed he's passed
a pointer to a single char, instead of a pointer to a string!".

You say, "pointer to string? that's technically meaningless! see, here, it says
'char*"

I think you're joking, and go on to whatever I was going to.

Two days later I notice that you're STILL struggling with the 'upcase' function.

What's going on, I ask you. How come you're still working on that trivial function?

As it turns out, after fixing the cast issue (which caused UB in the standard
library) you thought you'd fixed it, but you got it back. No more core dumps,
OK, but it doesn't pass the unit tests anymore. And you cannot figure out *why*.

I look at it, and say, "hey, that p, it's surely a pointer to a string?".

You just shake your head sadly, "Sorry Alf, that's meaningless, a 'char*' can't
point to a string, it can only point to a 'char', that's what the type is about.
But thanks for your attempt to help. Argh, this is really difficult: the code is
trivial, yet it doesn't pass unit tests; do you have any other idea?"

I consider suggesting that you change the textual function declaration, like
'void upcase( char s[] )', but it doesn't take more than a milli-second of
reflection to see that you would not see the point of that. I could expect some
retort like "Alf, Alf, thanks, but that means exactly the same, so it would not
help with the unit test issue". And likewise for some other suggestions.

So, I just fetch myself yet another cup of coffee, and leave you to it.


Cheers & hth.,

- Alf

 

[Öö Tiib]

You are of course correct about the conversational language part, Öö Tiib.
And you are of course correct when you acknowledge that, it is true that the
code that hi points to is the first byte in the array.

But to say that something is true and then say that no one will say it. I do
not need to tell you that this statement in itself is moderately contradictory.

Not sure that i see the contradiction. Precise truth about exact
details is very rarely said out by specialists of any field when they
talk with each other about problems of their work. Usually they have
formed a slang that simplifies and makes things short-to-say despite
it is wrong if to take it precisely word-by-word.

However, i agree that when someone discusses the very precise nature
of something then there they should not use loose terms unless they
especially want to annoy the others.

[...]

This is what Alf and Paul seem to refuse to acknowledge.

Alf and Paul ... difficult for me to find something common about them
two. I think that it was Joshua Maurice who first pointed out (weeks
ago) that people go bit too far when disagreeing with Paul about that
specific aspect of his "array is pointer" theory. Paul certainly loves
to argue endlessly so he will be available for next strange thing if
to let that one to rest.

My second and final point is that lose terminology has no place or correct
foundation in a technically precise discussion, especially, when specificity
with regards to well-defined meaning is the topic of debate.

Can we at least agree on that, Öö Tiib?

Oh ... certainly. Such behavior is common about most deep specialists.
For example scientists. They can use their slang when they talk in
laboratory extremely loosely. However when they post their findings in
some magazine (for other scientists to nit-pick) then they are
absurdly precise and accurate.

 

[Noah Roberts]

So lets take char*. It is pointer to char (a byte).

char const* hi = "Hello World";

I don't know anyone who say in conversational language looking at that
code that hi points to first byte in string literal.

[rudeness snipped]

Then obviously such people don't consider it a pointer. Do they treat
it like a pointer or do they treat it like a null-terminated string literal?

You're still performing a category error. If we need a language to
discuss pointers that includes things like shared_ptr and other smart
pointers (which are not, standardly speaking, pointers) then we need to
discuss terms. A pointer concept is, again, the only thing I can think
of that provides a reasonable alternative to the standard language. The
concept of course adds things not considered pointers by the standard
and we might also assume that it excludes things that are (such as void*).

Of course, people who are still using char* for strings are stuck in the
old days. Further, they're use of incorrect language to call any char
const* a string literal is bound to cause them problems some day. If we
want a reasonable, correct, useful conversational language than a better
response is probably that 'hi' happens to point INTO a string literal at
the moment.

 

[Noah Roberts]

Yes I read and understood his statement expressely for the face value of every
word in the sentence. Where we differ though is that I can see the greater
value in his point regardless if he botched the wording or not.

This also was not botched. There are several ways to look at why this
statement is true:

1) void f(int * ptr); <- the only useful thing that can be said of ptr
is that it points at int. If that is true here, it is true everywhere
else we no longer have a consistent language about pointers.

2) double * ptr = &int_var; <- Though is some hypothetical languages
this might be possible, a strongly typed one like C++ does not allow
this. You have to cast one or the other. In other words you can't
assign the wrong variable type and what ptr points at defines what that
is (by both language and concept).

3) double * ptr; decltype(*ptr) <- returns double, regardless of any
casting you've done to bypass types.

C++ allows you to cast types into other things. This does not mean that
a double pointer is going to point at an int if you've casted the
address of that int to double*. The simple truth is that from a
conceptual/semantic (and in C++, syntatic) viewpoint, deref(ptr)->T
means that ptr points at a T; to claim anything else is unsupportable.

 

[Paul]

So lets take char*. It is pointer to char (a byte).

char const* hi = "Hello World";

I don't know anyone who say in conversational language looking at that
code that hi points to first byte in string literal.

[rudeness snipped]

Then obviously such people don't consider it a pointer. Do they treat it
like a pointer or do they treat it like a null-terminated string literal?

You're still performing a category error. If we need a language to
discuss pointers that includes things like shared_ptr and other smart
pointers (which are not, standardly speaking, pointers) then we need to
discuss terms. A pointer concept is, again, the only thing I can think of
that provides a reasonable alternative to the standard language. The
concept of course adds things not considered pointers by the standard and
we might also assume that it excludes things that are (such as void*).

Of course, people who are still using char* for strings are stuck in the
old days. Further, they're use of incorrect language to call any char
const* a string literal is bound to cause them problems some day. If we
want a reasonable, correct, useful conversational language than a better
response is probably that 'hi' happens to point INTO a string literal at
the moment.

--

Slightly inssne, I funno