Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c++ > #3566 > unrolled thread
| Started by | cg_chas <cg_chas@hotmail.com> |
|---|---|
| First post | 2011-04-13 08:27 -0400 |
| Last post | 2011-04-18 14:38 +1200 |
| Articles | 20 on this page of 139 — 12 participants |
Back to article view | Back to comp.lang.c++
well-defined terminology versus generally accepted terminology regarding pointers and arrays cg_chas <cg_chas@hotmail.com> - 2011-04-13 08:27 -0400
Re: well-defined terminology versus generally accepted terminology regarding pointers and arrays SG <s.gesemann@gmail.com> - 2011-04-13 07:00 -0700
Re: well-defined terminology versus generally accepted terminology regarding pointers and arrays SG <s.gesemann@gmail.com> - 2011-04-13 07:26 -0700
Re: well-defined terminology versus generally accepted terminology regarding pointers and arrays Noah Roberts <dont@email.me> - 2011-04-13 10:21 -0700
Re: well-defined terminology versus generally accepted terminology regarding pointers and arrays cg_chas <cg_chas@hotmail.com> - 2011-04-13 11:45 -0400
Re: well-defined terminology versus generally accepted terminology regarding pointers and arrays Joshua Maurice <joshuamaurice@gmail.com> - 2011-04-13 20:57 -0700
Re: well-defined terminology versus generally accepted terminology regarding pointers and arrays Peter Remmers <p.remmers@expires-2011-04-30.arcornews.de> - 2011-04-14 12:40 +0200
Re: well-defined terminology versus generally accepted terminology regarding pointers and arrays cg_chas <cg_chas@hotmail.com> - 2011-04-14 07:24 -0400
Re: well-defined terminology versus generally accepted terminology regarding pointers and arrays cg_chas <cg_chas@hotmail.com> - 2011-04-14 07:32 -0400
Re: well-defined terminology versus generally accepted terminology regarding pointers and arrays gwowen <gwowen@gmail.com> - 2011-04-13 07:51 -0700
Re: well-defined terminology versus generally accepted terminology regarding pointers and arrays cg_chas <cg_chas@hotmail.com> - 2011-04-13 12:00 -0400
Re: well-defined terminology versus generally accepted terminology regarding pointers and arrays Peter Remmers <p.remmers@expires-2011-04-30.arcornews.de> - 2011-04-13 20:29 +0200
Re: well-defined terminology versus generally accepted terminology regarding pointers and arrays cg_chas <cg_chas@hotmail.com> - 2011-04-13 15:35 -0400
Re: well-defined terminology versus generally accepted terminology regarding pointers and arrays "Alf P. Steinbach /Usenet" <alf.p.steinbach+usenet@gmail.com> - 2011-04-13 22:36 +0200
Re: well-defined terminology versus generally accepted terminology regarding pointers and arrays cg_chas <cg_chas@hotmail.com> - 2011-04-13 17:37 -0400
Re: well-defined terminology versus generally accepted terminology regarding pointers and arrays Peter Remmers <p.remmers@expires-2011-04-30.arcornews.de> - 2011-04-14 02:12 +0200
Re: well-defined terminology versus generally accepted terminology regarding pointers and arrays cg_chas <cg_chas@hotmail.com> - 2011-04-13 20:23 -0400
Re: well-defined terminology versus generally accepted terminology regarding pointers and arrays Ian Collins <ian-news@hotmail.com> - 2011-04-14 09:37 +1200
Re: well-defined terminology versus generally accepted terminology regarding pointers and arrays cg_chas <cg_chas@hotmail.com> - 2011-04-13 17:41 -0400
Re: well-defined terminology versus generally accepted terminology regarding pointers and arrays Noah Roberts <dont@email.me> - 2011-04-13 17:01 -0700
Re: well-defined terminology versus generally accepted terminology regarding pointers and arrays cg_chas <cg_chas@hotmail.com> - 2011-04-13 20:25 -0400
Re: well-defined terminology versus generally accepted terminology regarding pointers and arrays "Alf P. Steinbach /Usenet" <alf.p.steinbach+usenet@gmail.com> - 2011-04-13 23:52 +0200
Re: well-defined terminology versus generally accepted terminology regarding pointers and arrays cg_chas <cg_chas@hotmail.com> - 2011-04-13 18:19 -0400
Re: well-defined terminology versus generally accepted terminology regarding pointers and arrays "Alf P. Steinbach /Usenet" <alf.p.steinbach+usenet@gmail.com> - 2011-04-14 00:30 +0200
Re: well-defined terminology versus generally accepted terminology regarding pointers and arrays cg_chas <cg_chas@hotmail.com> - 2011-04-13 19:21 -0400
Re: well-defined terminology versus generally accepted terminology regarding pointers and arrays "Alf P. Steinbach /Usenet" <alf.p.steinbach+usenet@gmail.com> - 2011-04-14 03:11 +0200
Re: well-defined terminology versus generally accepted terminology regarding pointers and arrays cg_chas <cg_chas@hotmail.com> - 2011-04-13 23:12 -0400
Re: well-defined terminology versus generally accepted terminology regarding pointers and arrays "Alf P. Steinbach /Usenet" <alf.p.steinbach+usenet@gmail.com> - 2011-04-14 06:39 +0200
Re: well-defined terminology versus generally accepted terminology regarding pointers and arrays Noah Roberts <dont@email.me> - 2011-04-13 17:04 -0700
Re: well-defined terminology versus generally accepted terminology regarding pointers and arrays Ian Collins <ian-news@hotmail.com> - 2011-04-14 10:32 +1200
Re: well-defined terminology versus generally accepted terminology regarding pointers and arrays "Alf P. Steinbach /Usenet" <alf.p.steinbach+usenet@gmail.com> - 2011-04-14 00:45 +0200
Re: well-defined terminology versus generally accepted terminology regarding pointers and arrays Ian Collins <ian-news@hotmail.com> - 2011-04-14 10:54 +1200
Re: well-defined terminology versus generally accepted terminology regarding pointers and arrays "Paul" <pchristor@yahoo.co.uk> - 2011-04-17 22:00 +0100
Re: well-defined terminology versus generally accepted terminology regarding pointers and arrays cg_chas <cg_chas@hotmail.com> - 2011-04-17 19:37 -0400
Re: well-defined terminology versus generally accepted terminology regarding pointers and arrays "Paul" <pchristor@yahoo.co.uk> - 2011-04-18 02:54 +0100
Re: well-defined terminology versus generally accepted terminology regarding pointers and arrays Ian Collins <ian-news@hotmail.com> - 2011-04-18 14:15 +1200
Re: well-defined terminology versus generally accepted terminology regarding pointers and arrays cg_chas <cg_chas@hotmail.com> - 2011-04-17 22:26 -0400
Re: well-defined terminology versus generally accepted terminology regarding pointers and arrays Peter Remmers <p.remmers@expires-2011-04-30.arcornews.de> - 2011-04-18 10:57 +0200
Re: well-defined terminology versus generally accepted terminology regarding pointers and arrays cg_chas <cg_chas@hotmail.com> - 2011-04-18 08:31 -0400
Re: well-defined terminology versus generally accepted terminology regarding pointers and arrays "Paul" <pchristor@yahoo.co.uk> - 2011-04-18 15:00 +0100
Re: well-defined terminology versus generally accepted terminology regarding pointers and arrays cg_chas <cg_chas@hotmail.com> - 2011-04-18 12:19 -0400
Re: well-defined terminology versus generally accepted terminology regarding pointers and arrays "Paul" <pchristor@yahoo.co.uk> - 2011-04-18 17:49 +0100
Re: well-defined terminology versus generally accepted terminology regarding pointers and arrays cg_chas <cg_chas@hotmail.com> - 2011-04-18 14:18 -0400
Re: well-defined terminology versus generally accepted terminology regarding pointers and arrays "Paul" <pchristor@yahoo.co.uk> - 2011-04-18 20:56 +0100
Re: well-defined terminology versus generally accepted terminology regarding pointers and arrays cg_chas <cg_chas@hotmail.com> - 2011-04-18 16:20 -0400
Re: well-defined terminology versus generally accepted terminology regarding pointers and arrays "Paul" <pchristor@yahoo.co.uk> - 2011-04-18 22:09 +0100
Re: well-defined terminology versus generally accepted terminology regarding pointers and arrays cg_chas <cg_chas@hotmail.com> - 2011-04-18 17:22 -0400
Re: well-defined terminology versus generally accepted terminology regarding pointers and arrays "Paul" <pchristor@yahoo.co.uk> - 2011-04-18 22:36 +0100
Re: well-defined terminology versus generally accepted terminology regarding pointers and arrays cg_chas <cg_chas@hotmail.com> - 2011-04-18 17:43 -0400
Re: well-defined terminology versus generally accepted terminology regarding pointers and arrays "Paul" <pchristor@yahoo.co.uk> - 2011-04-18 23:47 +0100
Re: well-defined terminology versus generally accepted terminology regarding pointers and arrays cg_chas <cg_chas@hotmail.com> - 2011-04-18 20:59 -0400
Re: well-defined terminology versus generally accepted terminology regarding pointers and arrays "Paul" <pchristor@yahoo.co.uk> - 2011-04-19 11:29 +0100
Re: well-defined terminology versus generally accepted terminology regarding pointers and arrays cg_chas <cg_chas@hotmail.com> - 2011-04-19 06:43 -0400
Re: well-defined terminology versus generally accepted terminology regarding pointers and arrays "Paul" <pchristor@yahoo.co.uk> - 2011-04-19 12:24 +0100
Re: well-defined terminology versus generally accepted terminology regarding pointers and arrays cg_chas <cg_chas@hotmail.com> - 2011-04-20 05:52 -0400
Re: well-defined terminology versus generally accepted terminology regarding pointers and arrays "Paul" <pchristor@yahoo.co.uk> - 2011-04-20 14:28 +0100
Re: well-defined terminology versus generally accepted terminology regarding pointers and arrays cg_chas <cg_chas@hotmail.com> - 2011-04-20 09:36 -0400
Re: well-defined terminology versus generally accepted terminology regarding pointers and arrays "Paul" <pchristor@yahoo.co.uk> - 2011-04-20 15:29 +0100
Re: well-defined terminology versus generally accepted terminology regarding pointers and arrays cg_chas <cg_chas@hotmail.com> - 2011-04-20 11:00 -0400
Re: well-defined terminology versus generally accepted terminology regarding pointers and arrays "Paul" <pchristor@yahoo.co.uk> - 2011-04-20 16:15 +0100
Re: well-defined terminology versus generally accepted terminology regarding pointers and arrays cg_chas <cg_chas@hotmail.com> - 2011-04-21 07:15 -0400
Re: well-defined terminology versus generally accepted terminology regarding pointers and arrays "Paul" <pchristor@yahoo.co.uk> - 2011-04-21 14:03 +0100
Re: well-defined terminology versus generally accepted terminology regarding pointers and arrays cg_chas <cg_chas@hotmail.com> - 2011-04-21 09:22 -0400
Re: well-defined terminology versus generally accepted terminology regarding pointers and arrays "Paul" <pchristor@yahoo.co.uk> - 2011-04-21 15:10 +0100
Re: well-defined terminology versus generally accepted terminology regarding pointers and arrays Peter Remmers <p.remmers@expires-2011-04-30.arcornews.de> - 2011-04-22 19:28 +0200
Re: well-defined terminology versus generally accepted terminology regarding pointers and arrays Leigh Johnston <leigh@i42.co.uk> - 2011-04-22 18:31 +0100
Re: well-defined terminology versus generally accepted terminology regarding pointers and arrays "Paul" <pchristor@yahoo.co.uk> - 2011-04-22 18:44 +0100
Re: well-defined terminology versus generally accepted terminology regarding pointers and arrays Peter Remmers <p.remmers@expires-2011-04-30.arcornews.de> - 2011-04-22 20:04 +0200
Re: well-defined terminology versus generally accepted terminology regarding pointers and arrays "Paul" <pchristor@yahoo.co.uk> - 2011-04-22 21:42 +0100
Re: well-defined terminology versus generally accepted terminology regarding pointers and arrays TJorgenson <tjorgenson@infinera.com> - 2011-04-22 14:21 -0700
Re: well-defined terminology versus generally accepted terminology regarding pointers and arrays Leigh Johnston <leigh@i42.co.uk> - 2011-04-22 22:24 +0100
Re: well-defined terminology versus generally accepted terminology regarding pointers and arrays "Paul" <pchristor@yahoo.co.uk> - 2011-04-22 23:47 +0100
Re: well-defined terminology versus generally accepted terminology regarding pointers and arrays Joshua Maurice <joshuamaurice@gmail.com> - 2011-04-22 15:56 -0700
Re: well-defined terminology versus generally accepted terminology regarding pointers and arrays "Paul" <pchristor@yahoo.co.uk> - 2011-04-23 02:45 +0100
Re: well-defined terminology versus generally accepted terminology regarding pointers and arrays Joshua Maurice <joshuamaurice@gmail.com> - 2011-04-22 20:30 -0700
Re: well-defined terminology versus generally accepted terminology regarding pointers and arrays "Paul" <pchristor@yahoo.co.uk> - 2011-04-23 05:15 +0100
Re: well-defined terminology versus generally accepted terminology regarding pointers and arrays "Paul" <pchristor@yahoo.co.uk> - 2011-04-23 17:25 +0100
Re: well-defined terminology versus generally accepted terminology regarding pointers and arrays "Alf P. Steinbach /Usenet" <alf.p.steinbach+usenet@gmail.com> - 2011-04-23 06:37 +0200
Re: well-defined terminology versus generally accepted terminology regarding pointers and arrays "Paul" <pchristor@yahoo.co.uk> - 2011-04-23 12:56 +0100
Re: well-defined terminology versus generally accepted terminology regarding pointers and arrays Joshua Maurice <joshuamaurice@gmail.com> - 2011-04-23 20:25 -0700
Re: well-defined terminology versus generally accepted terminology regarding pointers and arrays "Paul" <pchristor@yahoo.co.uk> - 2011-04-24 13:42 +0100
Re: well-defined terminology versus generally accepted terminology regarding pointers and arrays TJorgenson <tjorgenson@infinera.com> - 2011-04-22 18:15 -0700
Re: well-defined terminology versus generally accepted terminology regarding pointers and arrays "Paul" <pchristor@yahoo.co.uk> - 2011-04-23 03:29 +0100
Re: well-defined terminology versus generally accepted terminology regarding pointers and arrays Peter Remmers <p.remmers@expires-2011-04-30.arcornews.de> - 2011-04-19 01:06 +0200
Re: well-defined terminology versus generally accepted terminology regarding pointers and arrays cg_chas <cg_chas@hotmail.com> - 2011-04-18 21:06 -0400
Re: well-defined terminology versus generally accepted terminology regarding pointers and arrays cg_chas <cg_chas@hotmail.com> - 2011-04-18 21:27 -0400
Re: well-defined terminology versus generally accepted terminology regarding pointers and arrays Peter Remmers <p.remmers@expires-2011-04-30.arcornews.de> - 2011-04-19 11:23 +0200
Re: well-defined terminology versus generally accepted terminology regarding pointers and arrays cg_chas <cg_chas@hotmail.com> - 2011-04-19 06:41 -0400
Re: well-defined terminology versus generally accepted terminology regarding pointers and arrays Peter Remmers <p.remmers@expires-2011-04-30.arcornews.de> - 2011-04-20 01:37 +0200
Re: well-defined terminology versus generally accepted terminology regarding pointers and arrays cg_chas <cg_chas@hotmail.com> - 2011-04-20 05:33 -0400
Re: well-defined terminology versus generally accepted terminology regarding pointers and arrays Peter Remmers <p.remmers@expires-2011-04-30.arcornews.de> - 2011-04-20 13:57 +0200
Re: well-defined terminology versus generally accepted terminology regarding pointers and arrays cg_chas <cg_chas@hotmail.com> - 2011-04-20 09:25 -0400
Re: well-defined terminology versus generally accepted terminology regarding pointers and arrays Peter Remmers <p.remmers@expires-2011-04-30.arcornews.de> - 2011-04-20 17:18 +0200
Re: well-defined terminology versus generally accepted terminology regarding pointers and arrays cg_chas <cg_chas@hotmail.com> - 2011-04-20 14:07 -0400
Re: well-defined terminology versus generally accepted terminology regarding pointers and arrays Peter Remmers <p.remmers@expires-2011-04-30.arcornews.de> - 2011-04-20 22:42 +0200
Re: well-defined terminology versus generally accepted terminology regarding pointers and arrays cg_chas <cg_chas@hotmail.com> - 2011-04-20 17:44 -0400
Re: well-defined terminology versus generally accepted terminology regarding pointers and arrays Peter Remmers <p.remmers@expires-2011-04-30.arcornews.de> - 2011-04-21 00:56 +0200
Re: well-defined terminology versus generally accepted terminology regarding pointers and arrays cg_chas <cg_chas@hotmail.com> - 2011-04-21 08:12 -0400
Re: well-defined terminology versus generally accepted terminology regarding pointers and arrays Peter Remmers <p.remmers@expires-2011-04-30.arcornews.de> - 2011-04-22 19:34 +0200
Re: well-defined terminology versus generally accepted terminology regarding pointers and arrays Öö Tiib <ootiib@hot.ee> - 2011-04-20 16:08 -0700
Re: well-defined terminology versus generally accepted terminology regarding pointers and arrays Peter Remmers <p.remmers@expires-2011-04-30.arcornews.de> - 2011-04-20 18:41 +0200
Re: well-defined terminology versus generally accepted terminology regarding pointers and arrays Peter Remmers <p.remmers@expires-2011-04-30.arcornews.de> - 2011-04-20 14:37 +0200
Re: well-defined terminology versus generally accepted terminology regarding pointers and arrays cg_chas <cg_chas@hotmail.com> - 2011-04-20 09:33 -0400
Re: well-defined terminology versus generally accepted terminology regarding pointers and arrays Peter Remmers <p.remmers@expires-2011-04-30.arcornews.de> - 2011-04-20 19:09 +0200
Re: well-defined terminology versus generally accepted terminology regarding pointers and arrays cg_chas <cg_chas@hotmail.com> - 2011-04-20 14:36 -0400
Re: well-defined terminology versus generally accepted terminology regarding pointers and arrays Peter Remmers <p.remmers@expires-2011-04-30.arcornews.de> - 2011-04-20 22:53 +0200
Re: well-defined terminology versus generally accepted terminology regarding pointers and arrays cg_chas <cg_chas@hotmail.com> - 2011-04-20 17:49 -0400
Re: well-defined terminology versus generally accepted terminology regarding pointers and arrays "Paul" <pchristor@yahoo.co.uk> - 2011-04-21 00:52 +0100
Re: well-defined terminology versus generally accepted terminology regarding pointers and arrays cg_chas <cg_chas@hotmail.com> - 2011-04-21 07:21 -0400
Re: well-defined terminology versus generally accepted terminology regarding pointers and arrays "Paul" <pchristor@yahoo.co.uk> - 2011-04-21 14:24 +0100
Re: well-defined terminology versus generally accepted terminology regarding pointers and arrays Peter Remmers <p.remmers@expires-2011-04-30.arcornews.de> - 2011-04-22 20:00 +0200
Re: well-defined terminology versus generally accepted terminology regarding pointers and arrays "Paul" <pchristor@yahoo.co.uk> - 2011-04-22 20:09 +0100
Re: well-defined terminology versus generally accepted terminology regarding pointers and arrays Peter Remmers <p.remmers@expires-2011-04-30.arcornews.de> - 2011-04-18 16:08 +0200
Re: well-defined terminology versus generally accepted terminology regarding pointers and arrays cg_chas <cg_chas@hotmail.com> - 2011-04-18 11:08 -0400
Re: well-defined terminology versus generally accepted terminology regarding pointers and arrays Peter Remmers <p.remmers@expires-2011-04-30.arcornews.de> - 2011-04-19 01:20 +0200
Re: well-defined terminology versus generally accepted terminology regarding pointers and arrays cg_chas <cg_chas@hotmail.com> - 2011-04-18 21:18 -0400
Re: well-defined terminology versus generally accepted terminology regarding pointers and arrays Peter Remmers <p.remmers@expires-2011-04-30.arcornews.de> - 2011-04-19 11:15 +0200
Re: well-defined terminology versus generally accepted terminology regarding pointers and arrays cg_chas <cg_chas@hotmail.com> - 2011-04-19 05:40 -0400
Re: well-defined terminology versus generally accepted terminology regarding pointers and arrays Peter Remmers <p.remmers@expires-2011-04-30.arcornews.de> - 2011-04-20 19:36 +0200
Re: well-defined terminology versus generally accepted terminology regarding pointers and arrays cg_chas <cg_chas@hotmail.com> - 2011-04-20 16:07 -0400
OT: Re: well-defined terminology versus generally accepted terminology regarding pointers and arrays Peter Remmers <p.remmers@expires-2011-04-30.arcornews.de> - 2011-04-21 00:31 +0200
Re: OT: Re: well-defined terminology versus generally accepted terminology regarding pointers and arrays cg_chas <cg_chas@hotmail.com> - 2011-04-21 00:16 -0400
Re: OT: Re: well-defined terminology versus generally accepted terminology regarding pointers and arrays cg_chas <cg_chas@hotmail.com> - 2011-04-21 09:00 -0400
Re: OT: Re: well-defined terminology versus generally accepted terminology regarding pointers and arrays "Paul" <pchristor@yahoo.co.uk> - 2011-04-21 14:12 +0100
Re: OT: Re: well-defined terminology versus generally accepted terminology regarding pointers and arrays Leigh Johnston <leigh@i42.co.uk> - 2011-04-21 14:32 +0100
Re: OT: Re: well-defined terminology versus generally accepted terminology regarding pointers and arrays cg_chas <cg_chas@hotmail.com> - 2011-04-21 09:36 -0400
Re: OT: Re: well-defined terminology versus generally accepted terminology regarding pointers and arrays "Paul" <pchristor@yahoo.co.uk> - 2011-04-21 17:54 +0100
Re: OT: Re: well-defined terminology versus generally accepted terminology regarding pointers and arrays cg_chas <cg_chas@hotmail.com> - 2011-04-21 16:46 -0400
Re: OT: Re: well-defined terminology versus generally accepted terminology regarding pointers and arrays "Paul" <pchristor@yahoo.co.uk> - 2011-04-21 23:45 +0100
Re: OT: Re: well-defined terminology versus generally accepted terminology regarding pointers and arrays Peter Remmers <p.remmers@expires-2011-04-30.arcornews.de> - 2011-04-22 12:02 +0200
Re: OT: Re: well-defined terminology versus generally accepted terminology regarding pointers and arrays cg_chas <cg_chas@hotmail.com> - 2011-04-21 00:56 -0400
Re: well-defined terminology versus generally accepted terminology regarding pointers and arrays "Paul" <pchristor@yahoo.co.uk> - 2011-04-18 02:40 +0100
Re: well-defined terminology versus generally accepted terminology regarding pointers and arrays cg_chas <cg_chas@hotmail.com> - 2011-04-17 22:31 -0400
Re: well-defined terminology versus generally accepted terminology regarding pointers and arrays cg_chas <cg_chas@hotmail.com> - 2011-04-17 22:47 -0400
Re: well-defined terminology versus generally accepted terminology regarding pointers and arrays "Paul" <pchristor@yahoo.co.uk> - 2011-04-18 16:54 +0100
Re: well-defined terminology versus generally accepted terminology regarding pointers and arrays Leigh Johnston <leigh@i42.co.uk> - 2011-04-18 17:00 +0100
Re: well-defined terminology versus generally accepted terminology regarding pointers and arrays "Paul" <pchristor@yahoo.co.uk> - 2011-04-18 17:17 +0100
Re: well-defined terminology versus generally accepted terminology regarding pointers and arrays cg_chas <cg_chas@hotmail.com> - 2011-04-18 12:26 -0400
Re: well-defined terminology versus generally accepted terminology regarding pointers and arrays Ian Collins <ian-news@hotmail.com> - 2011-04-18 14:38 +1200
Page 1 of 7 [1] 2 3 4 5 6 7 Next page →
| From | cg_chas <cg_chas@hotmail.com> |
|---|---|
| Date | 2011-04-13 08:27 -0400 |
| Subject | well-defined terminology versus generally accepted terminology regarding pointers and arrays |
| Message-ID | <q53bq6h2eg80qaj58eov4ep2kb9kq65th2@4ax.com> |
Needless to say, there is significant dissension regarding when, or even if, it is ever preferrable to use well-defined terminology instead of loose or casual but generally accepted terminology regarding pointers and arrays. Examples such as: int a[42]; int* p2 = a; apparently create huge debates about how to describe the above expressions. Similar examples include expressions like: int* p1 = new int[42]; I gleen two cases representing the major divisions of opinion in this matter and I happen to not agree entirely with either. 1) Nobody is actually saying that the int pointers p1 and p2 do not point to the initial element of an array, but more than one has expressed that it is silly to put it that way. 2) More than one has said that it is "generally acceptable" to say that the above expressions are both int pointers that point to arrays. My thoughts are: In any C++ discussion about pointer to T, is it really ever silly to say that an int* points to the initial element of an array of int when it is well-defined to do so? No. It is not silly because widely recognized C++ sources say it just that way. 1) The C++ Programming Language, Bjarne Stroustrup section 5.3 Pointers into Arrays 2) Accelerated C++, Andrew Koenig 10.1.3 Arrays (last paragraph, second sentence) 3) ISO/IEC 14882 5.3.4 New (paragraph 1, last two senctences) In any C++ discussion about pointer to T, is what is claimed to be "generally acceptable" (the statement that an int* points to an array) ever truly technically correct? No. If the discussion is about "pointer to T" then it is both inaccurate and irresponsible to say that an int* points to an array. Only in the most casual and general sense is this statement acceptable and only when the discussion is not about "pointer to T". Does case #2 from above hold up under this pointer defintion? From "The C++ Programming Language" 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. No. Is there any well-defined pointer definition that agrees with the assertion that an int* points to an array? None that I am aware. I ask that if anybody knows of one to please feel free to add it to this discussion. As my closing thought, I do not impose "lawyeresque verbiage" onto those that choose loose terminology in general discussions. I do, however, make the very important disctinction that there is a time to be "general" and a time to be "technically precise". For the case of a C++ discussion about "pointer to T" then the time is not to be general, but rather, and simply put, technically precise. Charles
[toc] | [next] | [standalone]
| From | SG <s.gesemann@gmail.com> |
|---|---|
| Date | 2011-04-13 07:00 -0700 |
| Message-ID | <b3bae1a2-9958-4bd2-8349-e2faf8a0051d@17g2000prr.googlegroups.com> |
| In reply to | #3566 |
On 13 Apr., 14:27, cg_chas wrote:
> Needless to say, there is significant dissension regarding when, or even if, it
> is ever preferrable to use well-defined terminology instead of loose or casual
> but generally accepted terminology regarding pointers and arrays.
>
> Examples such as:
> int a[42];
> int* p2 = a;
> apparently create huge debates about how to describe the above expressions.
>
> Similar examples include expressions like:
> int* p1 = new int[42];
>
> [...]
> In any C++ discussion about pointer to T, is what is claimed to be "generally
> acceptable" (the statement that an int* points to an array) ever truly
> technically correct?
> No.
That depends on your definition of "points to", does it not?
Personally, I distinguish between two cases here:
(a) "p IS a pointer to..." as in
"the static type of p is pointer to..."
(b) "p points to..." as in
"p currently points to..."
For me, what "p IS" depends on its declaration. Its declaration
introduces p with a certain type and this type defines what it IS --
regardless of the value it holds. This is analogous to "x IS an int"
or "y IS a double".
Also, I find it acceptable to say that a pointer p which has been
declared like this
int *p;
"points to an array" after it has been initialized "to do so". I
regard this phrasing as "loose but acceptable". But I would not say
that "p IS a pointer to an array" because "BEING a pointer to an
array" implies for me that the static type is a pointer to an array.
So, p IS a pointer to an int object (which may or may not be an
element of an array) depending on its runtime value.
If we check the standard for occurences of "pointer to" we'll find the
following things:
"if a pointer p whose static type is 'pointer to class B' is
pointing an object of class D, derived from B, the dynamic type
of the expression *p is 'D.' [...]"
So, p with a static type B* can point to an object of type D (derived
from B).
"argv[0] shall be a pointer to initial character of a..."
Note the explicitness here w.r.t. initial character.
"class X; // X is an incomplete type
extern X* rp; // rp is a pointer to an incomplete type"
This is an example of "is a" referring to the static type.
I just searched clause 1-3 and did not find definitions that would
unambiguously attach a precise meaning to "p is a poitner to..." nor
"p points to...". So, I don't think, my interpretations from above are
in conflict with the C++ ISO standard.
Cheers!
SG
[toc] | [prev] | [next] | [standalone]
| From | SG <s.gesemann@gmail.com> |
|---|---|
| Date | 2011-04-13 07:26 -0700 |
| Message-ID | <68c68cf3-76bf-45dd-b35e-ef7f826068d4@j35g2000prb.googlegroups.com> |
| In reply to | #3570 |
On 13 Apr., 16:00, SG wrote: > On 13 Apr., 14:27, cg_chas wrote: > > > Needless to say, there is significant dissension regarding when, or even if, it > > is ever preferrable to use well-defined terminology instead of loose or casual > > but generally accepted terminology regarding pointers and arrays. > > > Examples such as: > > int a[42]; > > int* p2 = a; > > apparently create huge debates about how to describe the above expressions. > > > Similar examples include expressions like: > > int* p1 = new int[42]; > > > [...] > > In any C++ discussion about pointer to T, is what is claimed to be "generally > > acceptable" (the statement that an int* points to an array) ever truly > > technically correct? > > No. > > That depends on your definition of "points to", does it not? > Personally, I distinguish between two cases here: > > (a) "p IS a pointer to..." as in > "the static type of p is pointer to..." > > (b) "p points to..." as in > "p currently points to..." > > For me, what "p IS" depends on its declaration. Its declaration > introduces p with a certain type and this type defines what it IS -- > regardless of the value it holds. This is analogous to "x IS an int" > or "y IS a double". > > Also, I find it acceptable to say that a pointer p which has been > declared like this > > int *p; > > "points to an array" after it has been initialized "to do so". I > regard this phrasing as "loose but acceptable". But I would not say > that "p IS a pointer to an array" because "BEING a pointer to an > array" implies for me that the static type is a pointer to an array. > So, p IS a pointer to an int object (which may or may not be an > element of an array) depending on its runtime value. > > If we check the standard for occurences of "pointer to" we'll find the > following things: > > "if a pointer p whose static type is 'pointer to class B' is > pointing an object of class D, derived from B, the dynamic type > of the expression *p is 'D.' [...]" > > So, p with a static type B* can point to an object of type D (derived > from B). Adding to that: It's an example where "points to" has been used to refer to a dynamic (aka runtime) property of a pointer. > "argv[0] shall be a pointer to initial character of a..." > > Note the explicitness here w.r.t. initial character. I consider this noteworthy. I did not find any instance where the C++ standard would use the kind of phrasing I regard as "loose but acceptable". > "class X; // X is an incomplete type > extern X* rp; // rp is a pointer to an incomplete type" > > This is an example of "is a" referring to the static type. Throughout the standard "is a..." seems to be only used as shortcut for "has the static type...". > I don't think, my interpretations from above are > in conflict with the C++ ISO standard. In fact, I would say, that it actually supports my distinction between "being a pointer to..." when it comes to the static type and "points to..." when it's about a dynamic (aka runtime) property of the pointer. Cheers! SG
[toc] | [prev] | [next] | [standalone]
| From | Noah Roberts <dont@email.me> |
|---|---|
| Date | 2011-04-13 10:21 -0700 |
| Message-ID | <4da5db9e$0$15512$cc2e38e6@news.uslec.net> |
| In reply to | #3573 |
On 4/13/2011 7:26 AM, SG wrote:
> On 13 Apr., 16:00, SG wrote:
>> If we check the standard for occurences of "pointer to" we'll find the
>> following things:
>>
>> "if a pointer p whose static type is 'pointer to class B' is
>> pointing an object of class D, derived from B, the dynamic type
>> of the expression *p is 'D.' [...]"
>>
>> So, p with a static type B* can point to an object of type D (derived
>> from B).
>
> Adding to that: It's an example where "points to" has been used to
> refer to a dynamic (aka runtime) property of a pointer.
Yes, but not in the same way that int* has been said to "point to" an
array. This clause, and clauses like it, are explicitly about
polymorphic objects. Polymorphic objects behave differently than other
objects.
#include <typeinfo>
#include <iostream>
struct B0 {};
struct B1 { virtual ~ B1() {}};
struct D0 : B0 {};
struct D1 : B1 {};
int main()
{
D0 d0; B0 * b0p = &d0;
D1 d1; B1 * b1p = &d1;
std::cout << typeid(*b0p).name() << std::endl;
std::cout << typeid(*b1p).name() << std::endl;
}
Compile that code and you'll see that b0p does not have any extra
information while b1p does. Only polymorphic types have "dynamic"
types. What we're really seeing here is not an exception to what
pointers point at, but the fact that when you ask a polymorphic object
for its type it will give you its "dynamic" type while a non-polymorphic
one won't even respond, leaving the compiler to interpret the request by
simply checking the type information of the pointer itself, which of
course remains B and not D.
As you'll note it actually says that, "the dynamic type of the
expression is of type D." It does not say that the type of the
expression is of type D. Dynamic lookup is a different, extra beast
allowed for and by polymorphic types. You still can't get enough
information from the pointer to call members only in the derived class,
or functions that work directly with it. You still have to cast in
order to do so.
>> I don't think, my interpretations from above are
>> in conflict with the C++ ISO standard.
>
> In fact, I would say, that it actually supports my distinction between
> "being a pointer to..." when it comes to the static type and "points
> to..." when it's about a dynamic (aka runtime) property of the
> pointer.
Not really. The distinction would seem to more accurately be that the
pointer "points to..." a polymorphic type and polymorphic types allow
extra RTTI look-up procedures.
--
http://crazycpp.wordpress.com
[toc] | [prev] | [next] | [standalone]
| From | cg_chas <cg_chas@hotmail.com> |
|---|---|
| Date | 2011-04-13 11:45 -0400 |
| Message-ID | <09fbq6pvu20klv278tjefkv7uqie6d20os@4ax.com> |
| In reply to | #3570 |
On Wed, 13 Apr 2011 07:00:00 -0700 (PDT), SG <s.gesemann@gmail.com> wrote: >On 13 Apr., 14:27, cg_chas wrote: >> Needless to say, there is significant dissension regarding when, or even if, it >> is ever preferrable to use well-defined terminology instead of loose or casual >> but generally accepted terminology regarding pointers and arrays. >> >> Examples such as: >> int a[42]; >> int* p2 = a; >> apparently create huge debates about how to describe the above expressions. >> >> Similar examples include expressions like: >> int* p1 = new int[42]; >> >> [...] >> In any C++ discussion about pointer to T, is what is claimed to be "generally >> acceptable" (the statement that an int* points to an array) ever truly >> technically correct? >> No. > >That depends on your definition of "points to", does it not? >Personally, I distinguish between two cases here: Indeed and I had not presented it by this point in the post, but I did get to it. I think we can agree that defining any word is best done by not using the word itself in the definition. Not saying you did this, but it becomes a bigger part of my response as it progresses. For example: drivers drive. If you have to define driving, a good definition would not include the word drive. The definition for "points to" (your (b) case) I can apply to this well-defined definition which defines a pointer two ways. The first way addresses the significant abstraction, "pointer to" and the second defines what a pointer is." I don't think the definition is faulty in any way that it does not explictly say that "pointers point" since it is obvious that pointers point. 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. > > (a) "p IS a pointer to..." as in > "the static type of p is pointer to..." > > (b) "p points to..." as in > "p currently points to..." This is very similar to Alf's point. The latter of course is what Alf described as the dynamic case. The definition I provided above does not discern between your (a) and (b) cases because it explicitly defines "pointer to T" not "points to T". What it does do is dispense with the abstraction that "pointers point" by literally defining what a pointer is and what it holds. If you read the definition backwards: a variable of type T* can hold the address of an object of type T. T* is the type "pointer to T. Since it does not exclude either (a) and (b) case, it is not an error to test against this definition for both cases. Strictly speaking, the (b) case does fail for the following example: int* p = new int[5]; // p points to an array By the definition above, that comment is false because when logically plug into the definition as such, you get: p is a variable of type int* int* can hold the address of an object of type int p is the type pointer to int and now applying the (b) case: p (which is a variable of type int*) points to an (can hold the address of an object of type) array (should be int because int* can hold the address of an object of type int - not an array ) > >For me, what "p IS" depends on its declaration. Its declaration >introduces p with a certain type and this type defines what it IS -- >regardless of the value it holds. This is analogous to "x IS an int" >or "y IS a double". For me as well as this is the only case that holds validity with the above definition. > >Also, I find it acceptable to say that a pointer p which has been >declared like this > > int *p; > >"points to an array" after it has been initialized "to do so". I >regard this phrasing as "loose but acceptable". But I would not say >that "p IS a pointer to an array" because "BEING a pointer to an >array" implies for me that the static type is a pointer to an array. >So, p IS a pointer to an int object (which may or may not be an >element of an array) depending on its runtime value. I think we are in agreement here regarding "loose but acceptable." As we have seen though, the problem does arise when saying "points to an array" is held to a discussion about a "pointer to T". > >If we check the standard for occurences of "pointer to" we'll find the >following things: > > "if a pointer p whose static type is 'pointer to class B' is > pointing an object of class D, derived from B, the dynamic type > of the expression *p is 'D.' [...]" > >So, p with a static type B* can point to an object of type D (derived >from B). > > "argv[0] shall be a pointer to initial character of a..." > >Note the explicitness here w.r.t. initial character. > > "class X; // X is an incomplete type > extern X* rp; // rp is a pointer to an incomplete type" > >This is an example of "is a" referring to the static type. > >I just searched clause 1-3 and did not find definitions that would >unambiguously attach a precise meaning to "p is a poitner to..." nor >"p points to...". So, I don't think, my interpretations from above are >in conflict with the C++ ISO standard. > >Cheers! >SG Thank you for your response, Charles
[toc] | [prev] | [next] | [standalone]
| From | Joshua Maurice <joshuamaurice@gmail.com> |
|---|---|
| Date | 2011-04-13 20:57 -0700 |
| Message-ID | <0c83153a-19a6-4f33-8ac1-da222afdd657@a21g2000prj.googlegroups.com> |
| In reply to | #3570 |
On Apr 13, 7:00 am, SG <s.gesem...@gmail.com> wrote: > Personally, I distinguish between two cases here: > > (a) "p IS a pointer to..." as in > "the static type of p is pointer to..." > > (b) "p points to..." as in > "p currently points to..." > > For me, what "p IS" depends on its declaration. Its declaration > introduces p with a certain type and this type defines what it IS -- > regardless of the value it holds. This is analogous to "x IS an int" > or "y IS a double". I fully agree, and I would be highly dubious of anyone who spoke differently. I've stated as much several times elsewhere, but I just want to make this clear. "X is a pointer to <some type>" is a statement about the (static) type of the variable X. "X points to <some object>" is a statement about the runtime value of the variable X. Moreover, it's presumably a description of the runtime value under the interpretation of the static type of X. Discussions of static types are clearly defined by the standard. IMHO, discussions of "points to" is less clearly defined, and frankly I think that pedantic debates on this are not useful, which is why I haven't really participated. To sum it up: int* x = new int[10]; Is x a pointer to int? Yes. Is x a pointer to an array of int? No. This is not open to reasonable debate. Its (static) type is clearly "int*", and its (static) type is clearly not "int (*)[N]". Does x point to an array of int? Maybe. AFAIK, under normal conversation, it would not be confusing to say that, nor would it normally be considered incorrect or uncouth to say that. I have said that, and I think I'll continue to say that in my everyday programming discussions, including in my future postings here. Pedantically, is that wrong? Again, I'm not sure that I care. Either way Paul still has no clue what he's talking about, and should be ignored for the troll or troll-in-effect that he is.
[toc] | [prev] | [next] | [standalone]
| From | Peter Remmers <p.remmers@expires-2011-04-30.arcornews.de> |
|---|---|
| Date | 2011-04-14 12:40 +0200 |
| Message-ID | <4da6cf3d$0$7663$9b4e6d93@newsspool1.arcor-online.net> |
| In reply to | #3636 |
Am 14.04.2011 05:57, schrieb Joshua Maurice: > On Apr 13, 7:00 am, SG<s.gesem...@gmail.com> wrote: >> Personally, I distinguish between two cases here: >> >> (a) "p IS a pointer to..." as in >> "the static type of p is pointer to..." >> >> (b) "p points to..." as in >> "p currently points to..." >> >> For me, what "p IS" depends on its declaration. Its declaration >> introduces p with a certain type and this type defines what it IS -- >> regardless of the value it holds. This is analogous to "x IS an int" >> or "y IS a double". > > I fully agree, and I would be highly dubious of anyone who spoke > differently. I've stated as much several times elsewhere, but I just > want to make this clear. "X is a pointer to<some type>" is a > statement about the (static) type of the variable X. "X points to > <some object>" is a statement about the runtime value of the variable > X. Moreover, it's presumably a description of the runtime value under > the interpretation of the static type of X. > > Discussions of static types are clearly defined by the standard. IMHO, > discussions of "points to" is less clearly defined, and frankly I > think that pedantic debates on this are not useful, which is why I > haven't really participated. > > To sum it up: > int* x = new int[10]; > > Is x a pointer to int? Yes. Is x a pointer to an array of int? No. > This is not open to reasonable debate. Its (static) type is clearly > "int*", and its (static) type is clearly not "int (*)[N]". > > Does x point to an array of int? Maybe. AFAIK, under normal > conversation, it would not be confusing to say that, nor would it > normally be considered incorrect or uncouth to say that. I have said > that, and I think I'll continue to say that in my everyday programming > discussions, including in my future postings here. Pedantically, is > that wrong? Again, I'm not sure that I care. > > Either way Paul still has no clue what he's talking about, and should > be ignored for the troll or troll-in-effect that he is. Well said (the whole post). Whole-heartedly agree. Thumbs up, and all that... Peter
[toc] | [prev] | [next] | [standalone]
| From | cg_chas <cg_chas@hotmail.com> |
|---|---|
| Date | 2011-04-14 07:24 -0400 |
| Message-ID | <hcldq69s4dv244cik70jfifhsdfmgqpst5@4ax.com> |
| In reply to | #3653 |
On Thu, 14 Apr 2011 12:40:55 +0200, Peter Remmers <p.remmers@expires-2011-04-30.arcornews.de> wrote: >Am 14.04.2011 05:57, schrieb Joshua Maurice: >> On Apr 13, 7:00 am, SG<s.gesem...@gmail.com> wrote: >>> Personally, I distinguish between two cases here: >>> >>> (a) "p IS a pointer to..." as in >>> "the static type of p is pointer to..." >>> >>> (b) "p points to..." as in >>> "p currently points to..." >>> >>> For me, what "p IS" depends on its declaration. Its declaration >>> introduces p with a certain type and this type defines what it IS -- >>> regardless of the value it holds. This is analogous to "x IS an int" >>> or "y IS a double". >> >> I fully agree, and I would be highly dubious of anyone who spoke >> differently. I've stated as much several times elsewhere, but I just >> want to make this clear. "X is a pointer to<some type>" is a >> statement about the (static) type of the variable X. "X points to >> <some object>" is a statement about the runtime value of the variable >> X. Moreover, it's presumably a description of the runtime value under >> the interpretation of the static type of X. >> >> Discussions of static types are clearly defined by the standard. IMHO, >> discussions of "points to" is less clearly defined, and frankly I >> think that pedantic debates on this are not useful, which is why I >> haven't really participated. >> >> To sum it up: >> int* x = new int[10]; >> >> Is x a pointer to int? Yes. Is x a pointer to an array of int? No. >> This is not open to reasonable debate. Its (static) type is clearly >> "int*", and its (static) type is clearly not "int (*)[N]". >> >> Does x point to an array of int? Maybe. AFAIK, under normal >> conversation, it would not be confusing to say that, nor would it >> normally be considered incorrect or uncouth to say that. I have said >> that, and I think I'll continue to say that in my everyday programming >> discussions, including in my future postings here. Pedantically, is >> that wrong? Again, I'm not sure that I care. >> >> Either way Paul still has no clue what he's talking about, and should >> be ignored for the troll or troll-in-effect that he is. > >Well said (the whole post). Whole-heartedly agree. Thumbs up, and all >that... > > >Peter I agree too. His coverage of the perspective is most concise and I find no flaw with it. The only thing I can think of that might even be worth adding is further elaboration on something he points out which is that discussions of "points to" are less clearly defined. (or perhaps not at all). Where mileage may vary with many posters here is when it might be suitable to fully qualify a runtime value under the interpretation of the static type of X (in other words apply well-defined meaning of "a pointer to" with respect to "points to"). For some, this time is only during initially learning the language and every other time its is harmles too say "points to" while referring to something that is not the static type of X. I happen to think there are a few more relevant times than that, but that is just my .02. I am truly graveful for those that chose to participate in this discussion who were able to do so without losing focus of the topic. Cheers, Charles
[toc] | [prev] | [next] | [standalone]
| From | cg_chas <cg_chas@hotmail.com> |
|---|---|
| Date | 2011-04-14 07:32 -0400 |
| Message-ID | <6omdq6994oqjq4v170fk4e118j4nn19v1b@4ax.com> |
| In reply to | #3659 |
On Thu, 14 Apr 2011 07:24:15 -0400, cg_chas <cg_chas@hotmail.com> wrote: [..] > >I am truly graveful for those that chose to participate in this discussion who >were able to do so without losing focus of the topic. edit: grateful hope i'm not graveful just yet. i am old, but not that old :) > >Cheers, > >Charles >
[toc] | [prev] | [next] | [standalone]
| From | gwowen <gwowen@gmail.com> |
|---|---|
| Date | 2011-04-13 07:51 -0700 |
| Message-ID | <8157435f-a05d-4138-b25d-9bfa5c54d614@b13g2000prf.googlegroups.com> |
| In reply to | #3566 |
On Apr 13, 1:27 pm, cg_chas <cg_c...@hotmail.com> wrote: > Needless to say, there is significant dissension regarding when, or even if, it > is ever preferrable to use well-defined terminology instead of loose or casual > but generally accepted terminology regarding pointers and arrays. > > Examples such as: > int a[42]; > int* p2 = a; > apparently create huge debates about how to describe the above expressions. Only if you conflate "create huge debates" with "cause a relatively small number of people, with seemingly nothing better to do with their lives, to repeatedly start pissing contests to determine who's precise interpretation of a few slightly-vague sentences can be shouted most loudly, most often". Since, as far as I can tell, no-one actually disagrees on what any particular bit of well-formed code actually *does*, we're strictly in "How many angels can dance on the head of a pin?"[0] territory.[1] Maybe I'm being unduly pessimistic, but I suspect that starting yet another thread on essentially the same subject, will not actually get the (clearly utterly intransigent) participants to a state of mutual satisfaction. I further suspect that several of the key participants prefer the chaos of antagonism and conflict to mutual understanding, anyway. [0] It's 27, by the way, although seraphim count double. [1] Actually, a better analogy would seem to be between the original little-endians and big-endians, but the original Swiftian reference has rather been usurped by the byte-ordering meaning.
[toc] | [prev] | [next] | [standalone]
| From | cg_chas <cg_chas@hotmail.com> |
|---|---|
| Date | 2011-04-13 12:00 -0400 |
| Message-ID | <h8hbq6d7hdj2ensi1uva0ivihrv9a55m6e@4ax.com> |
| In reply to | #3574 |
On Wed, 13 Apr 2011 07:51:38 -0700 (PDT), gwowen <gwowen@gmail.com> wrote: >On Apr 13, 1:27 pm, cg_chas <cg_c...@hotmail.com> wrote: >> Needless to say, there is significant dissension regarding when, or even if, it >> is ever preferrable to use well-defined terminology instead of loose or casual >> but generally accepted terminology regarding pointers and arrays. >> >> Examples such as: >> int a[42]; >> int* p2 = a; >> apparently create huge debates about how to describe the above expressions. > >Only if you conflate "create huge debates" with "cause a relatively >small number of people, with seemingly nothing better to do with their >lives, to repeatedly start pissing contests to determine who's precise >interpretation of a few slightly-vague sentences can be shouted most >loudly, most often". Actually it was the hundreds of responses that actually expressed something beyond vagueness to similar topics that I was referring to, not the mere dozens of posters. > >Since, as far as I can tell, no-one actually disagrees on what any >particular bit of well-formed code actually *does*, we're strictly in >"How many angels can dance on the head of a pin?"[0] territory.[1] Your opinion is noted and I respect it, but it is hardly reasonable to imply that a discussion about C++ is useful only if everybody agrees similarly how code snippets in the examples run. > >Maybe I'm being unduly pessimistic, but I suspect that starting yet >another thread on essentially the same subject, will not actually get >the (clearly utterly intransigent) participants to a state of mutual >satisfaction. I further suspect that several of the key participants >prefer the chaos of antagonism and conflict to mutual understanding, >anyway. I am sorry that you do not approve of the thread. I have not started one in a very long time in C++ (years iirc) and I did so, not to seek any form of satisfaction, but rather it was to do what I said it would do, express my thoughts regarding what I observe to be a significant division in rather large number of opinions and to test validity of both major opinions against a well-defined pointer definition. > >[0] It's 27, by the way, although seraphim count double. >[1] Actually, a better analogy would seem to be between the original >little-endians and big-endians, but the original Swiftian reference >has rather been usurped by the byte-ordering meaning. If you don't like pissing contests, they why piss on my thread with sarcasm.
[toc] | [prev] | [next] | [standalone]
| From | Peter Remmers <p.remmers@expires-2011-04-30.arcornews.de> |
|---|---|
| Date | 2011-04-13 20:29 +0200 |
| Message-ID | <4da5eba9$0$6771$9b4e6d93@newsspool3.arcor-online.net> |
| In reply to | #3566 |
Am 13.04.2011 14:27, schrieb cg_chas: > Needless to say, there is significant dissension regarding when, or even if, it > is ever preferrable to use well-defined terminology instead of loose or casual > but generally accepted terminology regarding pointers and arrays. > > Examples such as: > int a[42]; > int* p2 = a; > apparently create huge debates about how to describe the above expressions. > > Similar examples include expressions like: > int* p1 = new int[42]; > > I gleen two cases representing the major divisions of opinion in this matter and > I happen to not agree entirely with either. > > 1) Nobody is actually saying that the int pointers p1 and p2 do not point to the > initial element of an array, but more than one has expressed that it is silly to > put it that way. If by "more than one" you refer to me agreeing with Alf, then I'm sorry, but that's not what I said. At least not what I meant. I never denied the necessity of precise language. I did not claim that p1 and p2 would not point to the initial element of an array. I did not claim that it would be silly to say so. > 2) More than one has said that it is "generally acceptable" to say that the > above expressions are both int pointers that point to arrays. My point was that although saying "p1 points to an array" is not literally conforming to the definition in the standard, it is a valid point of view because there is some amount of useful truth to it, and that denying the validity and usefulness of this POV is impractical, and therefore silly. > My thoughts are: > > In any C++ discussion about pointer to T, is it really ever silly to say that an > int* points to the initial element of an array of int when it is well-defined to > do so? > No. I did not claim that. > It is not silly because widely recognized C++ sources say it just that way. > 1) The C++ Programming Language, Bjarne Stroustrup section 5.3 Pointers into > Arrays > 2) Accelerated C++, Andrew Koenig 10.1.3 Arrays (last paragraph, second > sentence) > 3) ISO/IEC 14882 5.3.4 New (paragraph 1, last two senctences) > > In any C++ discussion about pointer to T, is what is claimed to be "generally > acceptable" (the statement that an int* points to an array) ever truly > technically correct? > No. I did not claim that, either. But just because it is not 100% technically correct, that does not mean that saying it must be avoided at all cost. It is certainly useful to think about it this way in practice, and it makes life easier when talking about code. If you don't forget the fact that it is not 100% technically correct, I would say it is perfectly "acceptable" as you put it. The appropriate level of formality depends on the kind of discussion. > If the discussion is about "pointer to T" then it is both inaccurate and > irresponsible to say that an int* points to an array. Only in the most casual > and general sense is this statement acceptable and only when the discussion is > not about "pointer to T". We certainly don't seem to agree on the level of casualness needed for the statement to be acceptable. But that is not the core point. Again, my quarrel is with the complete denial of any validity whatsoever of this POV. > Does case #2 from above hold up under this pointer defintion? No, and it does not have to under all circumstances. > From "The C++ Programming Language" > 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. > No. > > Is there any well-defined pointer definition that agrees with the assertion that > an int* points to an array? > None that I am aware. And there doesn't have to be... > I ask that if anybody knows of one to please feel free to add it to this > discussion. > > As my closing thought, I do not impose "lawyeresque verbiage" onto those that > choose loose terminology in general discussions. I do, however, make the very > important disctinction that there is a time to be "general" and a time to be > "technically precise". For the case of a C++ discussion about "pointer to T" > then the time is not to be general, but rather, and simply put, technically > precise. I'm happy to hear that we agree that there are times when technical correctness is not all that counts. What Alf wanted to point out is, in my understanding, that his "3)" is something to be considered and not to be ignored, and nothing more. Too bad that some people did not see this and instead felt the need to raise their finger again, and be quick to dissect his post and insist on technical correctness, even though that completely misses the point. > > Charles Peter
[toc] | [prev] | [next] | [standalone]
| From | cg_chas <cg_chas@hotmail.com> |
|---|---|
| Date | 2011-04-13 15:35 -0400 |
| Message-ID | <15rbq6h4j4tnm0o2ha247vv8g0r5m91vg2@4ax.com> |
| In reply to | #3591 |
On Wed, 13 Apr 2011 20:29:54 +0200, Peter Remmers <p.remmers@expires-2011-04-30.arcornews.de> wrote: >Am 13.04.2011 14:27, schrieb cg_chas: >> Needless to say, there is significant dissension regarding when, or even if, it >> is ever preferrable to use well-defined terminology instead of loose or casual >> but generally accepted terminology regarding pointers and arrays. >> >> Examples such as: >> int a[42]; >> int* p2 = a; >> apparently create huge debates about how to describe the above expressions. >> >> Similar examples include expressions like: >> int* p1 = new int[42]; >> >> I gleen two cases representing the major divisions of opinion in this matter and >> I happen to not agree entirely with either. >> >> 1) Nobody is actually saying that the int pointers p1 and p2 do not point to the >> initial element of an array, but more than one has expressed that it is silly to >> put it that way. > >If by "more than one" you refer to me agreeing with Alf, then I'm sorry, >but that's not what I said. At least not what I meant. I never denied >the necessity of precise language. I did not claim that p1 and p2 would >not point to the initial element of an array. I did not claim that it >would be silly to say so. Actually none of this post has referred to anything you've said, but I want you to know though, that before responding to you here, I have read all of your response and give it complete consideration in mine. > >> 2) More than one has said that it is "generally acceptable" to say that the >> above expressions are both int pointers that point to arrays. > >My point was that although saying "p1 points to an array" is not >literally conforming to the definition in the standard, it is a valid >point of view because there is some amount of useful truth to it, and >that denying the validity and usefulness of this POV is impractical, and >therefore silly. It is a valid point of view in that it eases discussion. If the level of formality is suitable then its fine. Nothing I have said discounts the value of that. When the topic of discussion however is already about "pointer to T" then all bets are off. You are either acknowledging T is the type of the pointer that it was declared with or you are not. Only because the discussion is literally already about "pointer to T". I do not see any difficulty with this assertion. > >> My thoughts are: >> >> In any C++ discussion about pointer to T, is it really ever silly to say that an >> int* points to the initial element of an array of int when it is well-defined to >> do so? >> No. >I did not claim that. > >> It is not silly because widely recognized C++ sources say it just that way. >> 1) The C++ Programming Language, Bjarne Stroustrup section 5.3 Pointers into >> Arrays >> 2) Accelerated C++, Andrew Koenig 10.1.3 Arrays (last paragraph, second >> sentence) >> 3) ISO/IEC 14882 5.3.4 New (paragraph 1, last two senctences) >> >> In any C++ discussion about pointer to T, is what is claimed to be "generally >> acceptable" (the statement that an int* points to an array) ever truly >> technically correct? >> No. >I did not claim that, either. But just because it is not 100% >technically correct, that does not mean that saying it must be avoided >at all cost. It is certainly useful to think about it this way in >practice, and it makes life easier when talking about code. If you don't >forget the fact that it is not 100% technically correct, I would say it >is perfectly "acceptable" as you put it. The appropriate level of >formality depends on the kind of discussion. Again, I did not have you in mind when writing this. I had my perspective in mind. I hold nobody's point of view hostage here. That being said, I don't think anybody is saying it must be avoided at all costs. The key point in my statement though, is if the discussion is already about "pointer to T" in other words "where T matters" and the discussion is about T, then the appropriate level of formality must be greater technical precision than to loosely state that int* p points to an array. T is not subjective. T is not gray area, and it is not up for debate. T is a specific type. A casual discussion using "points to" might be fine in whole gamut of topics, but not when the topic is litterally about "pointer to T". Does that clear it up a bit? > >> If the discussion is about "pointer to T" then it is both inaccurate and >> irresponsible to say that an int* points to an array. Only in the most casual >> and general sense is this statement acceptable and only when the discussion is >> not about "pointer to T". >We certainly don't seem to agree on the level of casualness needed for >the statement to be acceptable. But that is not the core point. Again, >my quarrel is with the complete denial of any validity whatsoever of >this POV. Apparently we do not agree, and that is fine, but what I have expressed is that when the discussion is already about T then T must remain constant. We are not talking about T1 and T2. If the topic is about something other than "pointer to T" then the POV is fine so long as it does not find itself to be the foundation for other concepts that end up requiring specificity regarding T. ex. such as with the case of an educator explaining a function that takes a pointer and the function is unaware that an array was allocated, further bringing the class up to their first introduction to STL containers for example. > >> Does case #2 from above hold up under this pointer defintion? >No, and it does not have to under all circumstances. > > >> From "The C++ Programming Language" >> 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. >> No. >> >> Is there any well-defined pointer definition that agrees with the assertion that >> an int* points to an array? >> None that I am aware. >And there doesn't have to be... > >> I ask that if anybody knows of one to please feel free to add it to this >> discussion. >> >> As my closing thought, I do not impose "lawyeresque verbiage" onto those that >> choose loose terminology in general discussions. I do, however, make the very >> important disctinction that there is a time to be "general" and a time to be >> "technically precise". For the case of a C++ discussion about "pointer to T" >> then the time is not to be general, but rather, and simply put, technically >> precise. >I'm happy to hear that we agree that there are times when technical >correctness is not all that counts. Of course. > >What Alf wanted to point out is, in my understanding, that his "3)" is >something to be considered and not to be ignored, and nothing more. Too >bad that some people did not see this and instead felt the need to raise >their finger again, and be quick to dissect his post and insist on >technical correctness, even though that completely misses the point. I guess by "some people" you include me, which is fine. I own what I've said. He did not merely say that his "3)" was not to be ignored, and if he did, I would not have responded. He did say, and I quote, "I've seen that some people think (3) is just metaphorical. That to be technically correct one would need to insert lawyeresque verbiage like "first element of". That seems silly to me, and except for the trolling-threads here I've never heard anyone speaking that way, or read anyone writing that way." So of course after such a statement I was inspired to cite 3 authoritative sources that are written precisely in a way he claims to be silly and to not have read. I respect your defense for Alf's POV. Do you respect mine as well? Additionally, I emphatically disagree that it is at all "lawyeresque" to say "first element of" in any context. But when the context specifically is regarding "pointer to T" and when T matters, I then assert exactly the opposite of what Alf did, and that is "to be technically correct one would need to insert first element of" since T is not a loose abstraction, it is a type. My point is that context does matter every bit as much as the level of formality. Further elaboration: Even if "points to" is an abstraction of an abstraction, which is really how I perceive what Alf and SG have stated, the abstractions themselves must still rely on some well-definition of pointer. Any such definition is always going to include "stores the address of an object of type T". And for any such definition where T* is declared, the address stored once initialized, by well-definition, ( not casual conversation or subjectivity, or opinion, ) MUST be the address of an object of type T. (no, we are not explicitly naming polymorphic types here) Once again, I do not discount the usefulness for easy language and loose terminology. Even said, we probably do not agree on the proper time for technical specificity which is ok with me. > >> >> Charles > >Peter Charles Thank you for your response.
[toc] | [prev] | [next] | [standalone]
| From | "Alf P. Steinbach /Usenet" <alf.p.steinbach+usenet@gmail.com> |
|---|---|
| Date | 2011-04-13 22:36 +0200 |
| Message-ID | <io51fo$n20$1@dont-email.me> |
| In reply to | #3593 |
* cg_chas, on 13.04.2011 21:35: > > He did not merely say that his "3)" was not to be ignored, and if he did, I > would not have responded. > > He did say, and I quote, "I've seen that some people think (3) is just > metaphorical. That to be technically correct one would need to insert > lawyeresque verbiage like "first element of". That seems silly to me, and except > for the trolling-threads here I've never heard anyone speaking that way, or read > anyone writing that way." > > So of course after such a statement I was inspired to cite 3 authoritative > sources that are written precisely in a way he claims to be silly and to not > have read. It would be rather difficult to define what pointing to array means, without mentioning that first element. Having done that, you don't go around mentioning it again and again. You just say "chair" or "car" or "steak" without trying to define what a chair or car or a steak is every time, which would be pretty silly. C++ programmers are in general smart enough to understand this. It's simply impractical to have to assume that you're talking to idiots all the time. For the in practice you have to assume that the person you're talking to is capable of understanding what e.g. "points to array" means, at least after having had it explained. If not, then that person will not be productive. Cheers & rhth., - Alf -- blog at <url: http://alfps.wordpress.com>
[toc] | [prev] | [next] | [standalone]
| From | cg_chas <cg_chas@hotmail.com> |
|---|---|
| Date | 2011-04-13 17:37 -0400 |
| Message-ID | <1r2cq6hjm09t8gih0h9cs9o4e0fur3jncu@4ax.com> |
| In reply to | #3595 |
On Wed, 13 Apr 2011 22:36:05 +0200, "Alf P. Steinbach /Usenet" <alf.p.steinbach+usenet@gmail.com> wrote: >* cg_chas, on 13.04.2011 21:35: >> >> He did not merely say that his "3)" was not to be ignored, and if he did, I >> would not have responded. >> >> He did say, and I quote, "I've seen that some people think (3) is just >> metaphorical. That to be technically correct one would need to insert >> lawyeresque verbiage like "first element of". That seems silly to me, and except >> for the trolling-threads here I've never heard anyone speaking that way, or read >> anyone writing that way." >> >> So of course after such a statement I was inspired to cite 3 authoritative >> sources that are written precisely in a way he claims to be silly and to not >> have read. > >It would be rather difficult to define what pointing to array means, without >mentioning that first element. It would be difficult to define because "pointing to an array" in the context if your (3) literally means pointing to that first element. However, I am not just talking about defining and I do not mean for that to be taken as argumentative. > >Having done that, you don't go around mentioning it again and again. Of course not, that actually would be silly. > >You just say "chair" or "car" or "steak" without trying to define what a chair >or car or a steak is every time, which would be pretty silly. I agree. Although, I think you still may be implying that there are no more relevant situations or contexts beyond an initial presentation of a definition of "pointing to an array" that might call for high specificity as to what the type of object is that the pointer stores the address to. I can think of quite a few very relevant scenarious and after the vivid story you told where you forgot my coffee, I think you could probably come up with a few yourself. That story being the first. > >C++ programmers are in general smart enough to understand this. I hope so too. Nevertheless there are those who spend their days in UB land because they actually take abstractions for granted without giving proper consideration to more technically valid meanings. > >It's simply impractical to have to assume that you're talking to idiots all the >time. For the in practice you have to assume that the person you're talking to >is capable of understanding what e.g. "points to array" means, at least after >having had it explained. If not, then that person will not be productive. That would indeed be impractical, and I think putting it that way takes my meaning to an extreme that I did not actually represent. > > >Cheers & rhth., > >- Alf Your response was helpful and it showed me a few things. The first is entirely on me. I am conditioned differently with regards to C++ than some of you. I can see that some of you got their beginnings with C. I went straight from motorolla assembly in 82-83 into C++ in the early 90's. I never learned C outside of a C++ CS course, highly rated C++ books, and GNU and MS C++ compilers. I have not picked up many of the bad habbits like using c-style casts on the return of new which has shown its face here more than once. The second is that it seems that I am being perceived as saying that it is necessary to define "points to" every time I see it. I can remedy that quickly by saying. Not each and every time. Just each and every time when the topic of discussion actually is about "pointer to T" or when a concept is built upon "pointer to T", whether it be in planning stage, or development stage . If we're talking about "pointer to T", then it is best to dispense with the looseness of "points to" and think in the more precise terms regarding T* and the address that it holds. Perhaps that sounds crazy to you, but that is how I think it is closely resembles well-definiton. If you say char* c points to an array and we're going to read a file into that array, by passing c off to an ifstream object, then fine. If you say char* c points to an array and we are trying to figure out why the byte processing algorithm failed to parse a case, then no, c is a pointer to a byte of data in an array. Maybe the cases seem silly to you. I get it if thats the case, but regardless, they are quite different perspectives. The last thing is something I already knew. You are fair and wise enough to acknowlege at least a single context where technical specificity is necessary. Consider that there might be more than one and we can actually part ways in complete agreement. Thank you for your response, Charles
[toc] | [prev] | [next] | [standalone]
| From | Peter Remmers <p.remmers@expires-2011-04-30.arcornews.de> |
|---|---|
| Date | 2011-04-14 02:12 +0200 |
| Message-ID | <4da63bff$0$6777$9b4e6d93@newsspool3.arcor-online.net> |
| In reply to | #3593 |
Am 13.04.2011 21:35, schrieb cg_chas: > On Wed, 13 Apr 2011 20:29:54 +0200, Peter Remmers > <p.remmers@expires-2011-04-30.arcornews.de> wrote: > >>Am 13.04.2011 14:27, schrieb cg_chas: >>> Needless to say, there is significant dissension regarding when, or even if, it >>> is ever preferrable to use well-defined terminology instead of loose or casual >>> but generally accepted terminology regarding pointers and arrays. >>> >>> Examples such as: >>> int a[42]; >>> int* p2 = a; >>> apparently create huge debates about how to describe the above expressions. >>> >>> Similar examples include expressions like: >>> int* p1 = new int[42]; >>> >>> I gleen two cases representing the major divisions of opinion in this matter and >>> I happen to not agree entirely with either. >>> >>> 1) Nobody is actually saying that the int pointers p1 and p2 do not point to the >>> initial element of an array, but more than one has expressed that it is silly to >>> put it that way. >> >>If by "more than one" you refer to me agreeing with Alf, then I'm sorry, >>but that's not what I said. At least not what I meant. I never denied >>the necessity of precise language. I did not claim that p1 and p2 would >>not point to the initial element of an array. I did not claim that it >>would be silly to say so. > Actually none of this post has referred to anything you've said, but I want you > to know though, that before responding to you here, I have read all of your > response and give it complete consideration in mine. It is refreshing to see that I don't get a storm of hostility in response :) >>> 2) More than one has said that it is "generally acceptable" to say that the >>> above expressions are both int pointers that point to arrays. >> >>My point was that although saying "p1 points to an array" is not >>literally conforming to the definition in the standard, it is a valid >>point of view because there is some amount of useful truth to it, and >>that denying the validity and usefulness of this POV is impractical, and >>therefore silly. > It is a valid point of view in that it eases discussion. If the level of > formality is suitable then its fine. Nothing I have said discounts the value of > that. Ok. > When the topic of discussion however is already about "pointer to T" then all > bets are off. You are either acknowledging T is the type of the pointer that it > was declared with or you are not. Only because the discussion is literally > already about "pointer to T". I do not see any difficulty with this assertion. I agree that once the topic of the discussion has shifted to the bottom of the basics, i.e. what a pointer actually is, then the level of formal definitions has been reached, which requires definition-grade precision in the language.. However, Alf did not ignore the formal definition (something that Paul did - at least in the beginning), but instead expanded the view on the pointer topic by adding a less formal way of thinking about them, and saying that it cannot be completely wrong to do that. Even more so when in practice this is by far the more common case (as opposed to a real pointer-to-array type). And I think that Alf's post was not meant to be yet another attempt at giving a consistent definition of what a pointer is, and must therefore not be rejected by pointing out the flaws in that non-attempt. "Me on the subject" clearly introduces a personal view on the matter, just like gwowen's excellent post about the reference/iterator view. >>> My thoughts are: >>> >>> In any C++ discussion about pointer to T, is it really ever silly to say that an >>> int* points to the initial element of an array of int when it is well-defined to >>> do so? >>> No. >>I did not claim that. >> >>> It is not silly because widely recognized C++ sources say it just that way. >>> 1) The C++ Programming Language, Bjarne Stroustrup section 5.3 Pointers into >>> Arrays >>> 2) Accelerated C++, Andrew Koenig 10.1.3 Arrays (last paragraph, second >>> sentence) >>> 3) ISO/IEC 14882 5.3.4 New (paragraph 1, last two senctences) >>> >>> In any C++ discussion about pointer to T, is what is claimed to be "generally >>> acceptable" (the statement that an int* points to an array) ever truly >>> technically correct? >>> No. >>I did not claim that, either. But just because it is not 100% >>technically correct, that does not mean that saying it must be avoided >>at all cost. It is certainly useful to think about it this way in >>practice, and it makes life easier when talking about code. If you don't >>forget the fact that it is not 100% technically correct, I would say it >>is perfectly "acceptable" as you put it. The appropriate level of >>formality depends on the kind of discussion. > Again, I did not have you in mind when writing this. I had my perspective in > mind. I hold nobody's point of view hostage here. > > That being said, I don't think anybody is saying it must be avoided at all > costs. The key point in my statement though, is if the discussion is already > about "pointer to T" in other words "where T matters" and the discussion is > about T, then the appropriate level of formality must be greater technical > precision than to loosely state that int* p points to an array. T is not > subjective. T is not gray area, and it is not up for debate. T is a specific > type. A casual discussion using "points to" might be fine in whole gamut of > topics, but not when the topic is litterally about "pointer to T". Does that > clear it up a bit? Yes. But I think the mistake here is that concentrating too much on the definition of a pointer narrows the view too much to only one part of the story. The object that is being pointed to is the other side. And in the end it is about a combination of static types and dynamic values and constellations of pointers and pointees. It's funny but I have to agree with Paul here, that the type of an object that lives at a certain memory location is not affected by some pointer that points to it (like, it's embarassing, and the color of the object changes to red :) ). Hm, ok. Here's me on that topic: A pointer is effectively like a pair of glasses that you see through when you dereference it. Like, everything looks like a T when you look at the memory through a T*... The type is something that is determined at compile-time. I.e. it's either a pair of green glasses or red glasses, and the color can't be changed. It is sort of an automatic reinterpret_cast, where the cast has been done in advance (or was not necessary) during the assignment/initialization. Pointers and pointees are orthogonal. Pointers can point to anything (maybe by force, using a cast), and pointees can be pointed to by anything (unaffected by them until actually accessed through one of them). Some of the combinations are valid, some are UB. Ultimately, it's the run-time act of actually dereferencing the pointer and accessing the actual memory location that decides whether it's a crash or not (Note that I intentionally used the more general word "crash" and not "UB" here, even though it does not always have to end in a crash). That does not mean this is the earliest opportunity for "formally UB" or "implementation specific". It does not mean that some UB cannot be proven at compile time. It also means that not all dereferences actually access a memory location (e.g. for sizeof(*p), p does not have to point to something valid). The definition of a pointer defines how a pointer behaves when you use it, and what you are formally allowed to do with it. Noah said: > The important parts about pointers are that you can gain them in certain > ways (like using &) and you can dereference them. Those two conceptual > operations make a pointer what it is. Perfectly clear up to here. > The type that you get when you > dereference the pointer is what it points to. That's the source for much of the recent discussion. It's a compile-time centric view. It ignores the possibility that at run-time, there may not actually be an object of that type at the respective memory location. Sure, if you did not have to use a cast to force it to point to something else, chances are that it actually points to what its type says. But you don't even need to use a cast to create a situation where it's different, and that is for example when you destroy the object and create a new one at the same location but with different type. As for arrays... They are tricky because they are composed of elements that have a type while the whole array itself has another type. The whole discussion about that is understandable... Let me introduce some old friends to talk about: int a[10]; int *p = a; Formally, p is of type "pointer to int", i.e. p points to a memory location that is interpreted to be an int when accessed through p by dereferencing p. That memory location happens to be the first int element of the array a because p has been initialized with that element's address. Drumroll... Can you say "p points to the array a"? Not formally, but I cannot intuitively claim that it is completely wrong, either. I already used the term "divine knowledge" in some older post to describe the situation where we somehow "know" that there are other int neighbours after the first element. We know a[0] is only the first in a series of 10 contiguous ints. This information is undoubtedly there, but it is not coded into the pointer's type, and so is not available to the compiler or across function calls, etc. The first element is also somewhat special regarding the question. If p would point to any other element of a, I would be pressed to say it points to a. You could say it points into a. But the first element is special in that its address is the same as the address of the whole superobject it is a part of. On the other hand, you can only use the pointer to access one element at a time, and not the whole array at once. >>> If the discussion is about "pointer to T" then it is both inaccurate and >>> irresponsible to say that an int* points to an array. Only in the most casual >>> and general sense is this statement acceptable and only when the discussion is >>> not about "pointer to T". >>We certainly don't seem to agree on the level of casualness needed for >>the statement to be acceptable. But that is not the core point. Again, >>my quarrel is with the complete denial of any validity whatsoever of >>this POV. > Apparently we do not agree, and that is fine, but what I have expressed is that > when the discussion is already about T then T must remain constant. We are not > talking about T1 and T2. If the topic is about something other than "pointer > to T" then the POV is fine so long as it does not find itself to be the > foundation for other concepts that end up requiring specificity regarding T. > > ex. such as with the case of an educator explaining a function that takes a > pointer and the function is unaware that an array was allocated, further > bringing the class up to their first introduction to STL containers for example. Not all teachers teach you all the details from the start. Sometimes you learn the "what" and "how" first, and the "why" later. Also, knowing all the details about a tool is not always necessary to successfully use a tool. I agree though, that knowing the details is helpful, and often necessary for building upon it other knowledge. >>> Does case #2 from above hold up under this pointer defintion? >>No, and it does not have to under all circumstances. >> >> >>> From "The C++ Programming Language" >>> 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. >>> No. >>> >>> Is there any well-defined pointer definition that agrees with the assertion that >>> an int* points to an array? >>> None that I am aware. >>And there doesn't have to be... >> >>> I ask that if anybody knows of one to please feel free to add it to this >>> discussion. >>> >>> As my closing thought, I do not impose "lawyeresque verbiage" onto those that >>> choose loose terminology in general discussions. I do, however, make the very >>> important disctinction that there is a time to be "general" and a time to be >>> "technically precise". For the case of a C++ discussion about "pointer to T" >>> then the time is not to be general, but rather, and simply put, technically >>> precise. >>I'm happy to hear that we agree that there are times when technical >>correctness is not all that counts. > Of course. >> >>What Alf wanted to point out is, in my understanding, that his "3)" is >>something to be considered and not to be ignored, and nothing more. Too >>bad that some people did not see this and instead felt the need to raise >>their finger again, and be quick to dissect his post and insist on >>technical correctness, even though that completely misses the point. > I guess by "some people" you include me, which is fine. I own what I've said. > > He did not merely say that his "3)" was not to be ignored, and if he did, I > would not have responded. After reading again, I agree he didn't exactly. It was only my perceived intention of his post. > He did say, and I quote, "I've seen that some people think (3) is just > metaphorical. That to be technically correct one would need to insert > lawyeresque verbiage like "first element of". That seems silly to me, and except > for the trolling-threads here I've never heard anyone speaking that way, or read > anyone writing that way." I have to admit (and I'm not ashamed of that), that it's a bit exaggerated. I'm also of the opinion that you'd have to add something to be technically correct, and that in itself is not silly. I just disagree with the high level of casualness you demand to accept that phrase. But we've been there already. > So of course after such a statement I was inspired to cite 3 authoritative > sources that are written precisely in a way he claims to be silly and to not > have read. I respect your defense for Alf's POV. Do you respect mine as well? Yes. > Additionally, I emphatically disagree that it is at all "lawyeresque" to say > "first element of" in any context. It all amounts to the question of where you put the level of formality in the discussion at hand. This determines whether the words "lawyeresque", "nit-picky", "pedantic", "splitting hairs", etc. are likely to come into play or not. > But when the context specifically is regarding "pointer to T" and when T > matters, I then assert exactly the opposite of what Alf did, and that is "to be > technically correct one would need to insert first element of" since T is not a > loose abstraction, it is a type. I would like to point out again that he did not ignore the formality, but just added something to it. This is in accordance with my assertion that it's ok to become a little slack with the language as long as you keep in mind that it is formally not 100% correct. > My point is that context does matter every bit as much as the level of > formality. See above... > Further elaboration: > > Even if "points to" is an abstraction of an abstraction, which is really how I > perceive what Alf and SG have stated, the abstractions themselves must still > rely on some well-definition of pointer. Any such definition is always going to > include "stores the address of an object of type T". See "me on that topic" above. > And for any such definition where T* is declared, the address stored once > initialized, by well-definition, ( not casual conversation or subjectivity, or > opinion, ) MUST be the address of an object of type T. (no, we are not > explicitly naming polymorphic types here) Or else? > Once again, I do not discount the usefulness for easy language and loose > terminology. Even said, we probably do not agree on the proper time for > technical specificity which is ok with me. And everyone's happy. >>> >>> Charles >> >>Peter > > Charles > Thank you for your response. Thank you for a decent discussion without name calling, childish acting, or being offended easily and responding with troll accusations :) Peter
[toc] | [prev] | [next] | [standalone]
| From | cg_chas <cg_chas@hotmail.com> |
|---|---|
| Date | 2011-04-13 20:23 -0400 |
| Message-ID | <9ifcq65ob0gdpa8pj8htsjjl0nkeo3md5l@4ax.com> |
| In reply to | #3628 |
On Thu, 14 Apr 2011 02:12:41 +0200, Peter Remmers <p.remmers@expires-2011-04-30.arcornews.de> wrote: >Am 13.04.2011 21:35, schrieb cg_chas: >> On Wed, 13 Apr 2011 20:29:54 +0200, Peter Remmers >> <p.remmers@expires-2011-04-30.arcornews.de> wrote: >> >>>Am 13.04.2011 14:27, schrieb cg_chas: >>>> Needless to say, there is significant dissension regarding when, or even if, it >>>> is ever preferrable to use well-defined terminology instead of loose or casual >>>> but generally accepted terminology regarding pointers and arrays. >>>> >>>> Examples such as: >>>> int a[42]; >>>> int* p2 = a; >>>> apparently create huge debates about how to describe the above expressions. >>>> >>>> Similar examples include expressions like: >>>> int* p1 = new int[42]; >>>> >>>> I gleen two cases representing the major divisions of opinion in this matter and >>>> I happen to not agree entirely with either. >>>> >>>> 1) Nobody is actually saying that the int pointers p1 and p2 do not point to the >>>> initial element of an array, but more than one has expressed that it is silly to >>>> put it that way. >>> >>>If by "more than one" you refer to me agreeing with Alf, then I'm sorry, >>>but that's not what I said. At least not what I meant. I never denied >>>the necessity of precise language. I did not claim that p1 and p2 would >>>not point to the initial element of an array. I did not claim that it >>>would be silly to say so. >> Actually none of this post has referred to anything you've said, but I want you >> to know though, that before responding to you here, I have read all of your >> response and give it complete consideration in mine. >It is refreshing to see that I don't get a storm of hostility in response :) > >>>> 2) More than one has said that it is "generally acceptable" to say that the >>>> above expressions are both int pointers that point to arrays. >>> >>>My point was that although saying "p1 points to an array" is not >>>literally conforming to the definition in the standard, it is a valid >>>point of view because there is some amount of useful truth to it, and >>>that denying the validity and usefulness of this POV is impractical, and >>>therefore silly. >> It is a valid point of view in that it eases discussion. If the level of >> formality is suitable then its fine. Nothing I have said discounts the value of >> that. >Ok. > >> When the topic of discussion however is already about "pointer to T" then all >> bets are off. You are either acknowledging T is the type of the pointer that it >> was declared with or you are not. Only because the discussion is literally >> already about "pointer to T". I do not see any difficulty with this assertion. >I agree that once the topic of the discussion has shifted to the bottom >of the basics, i.e. what a pointer actually is, then the level of formal >definitions has been reached, which requires definition-grade precision >in the language.. >However, Alf did not ignore the formal definition (something that Paul >did - at least in the beginning), but instead expanded the view on the >pointer topic by adding a less formal way of thinking about them, and >saying that it cannot be completely wrong to do that. Even more so when >in practice this is by far the more common case (as opposed to a real >pointer-to-array type). >And I think that Alf's post was not meant to be yet another attempt at >giving a consistent definition of what a pointer is, and must therefore >not be rejected by pointing out the flaws in that non-attempt. "Me on >the subject" clearly introduces a personal view on the matter, just like >gwowen's excellent post about the reference/iterator view. > >>>> My thoughts are: >>>> >>>> In any C++ discussion about pointer to T, is it really ever silly to say that an >>>> int* points to the initial element of an array of int when it is well-defined to >>>> do so? >>>> No. >>>I did not claim that. >>> >>>> It is not silly because widely recognized C++ sources say it just that way. >>>> 1) The C++ Programming Language, Bjarne Stroustrup section 5.3 Pointers into >>>> Arrays >>>> 2) Accelerated C++, Andrew Koenig 10.1.3 Arrays (last paragraph, second >>>> sentence) >>>> 3) ISO/IEC 14882 5.3.4 New (paragraph 1, last two senctences) >>>> >>>> In any C++ discussion about pointer to T, is what is claimed to be "generally >>>> acceptable" (the statement that an int* points to an array) ever truly >>>> technically correct? >>>> No. >>>I did not claim that, either. But just because it is not 100% >>>technically correct, that does not mean that saying it must be avoided >>>at all cost. It is certainly useful to think about it this way in >>>practice, and it makes life easier when talking about code. If you don't >>>forget the fact that it is not 100% technically correct, I would say it >>>is perfectly "acceptable" as you put it. The appropriate level of >>>formality depends on the kind of discussion. >> Again, I did not have you in mind when writing this. I had my perspective in >> mind. I hold nobody's point of view hostage here. >> >> That being said, I don't think anybody is saying it must be avoided at all >> costs. The key point in my statement though, is if the discussion is already >> about "pointer to T" in other words "where T matters" and the discussion is >> about T, then the appropriate level of formality must be greater technical >> precision than to loosely state that int* p points to an array. T is not >> subjective. T is not gray area, and it is not up for debate. T is a specific >> type. A casual discussion using "points to" might be fine in whole gamut of >> topics, but not when the topic is litterally about "pointer to T". Does that >> clear it up a bit? >Yes. But I think the mistake here is that concentrating too much on the >definition of a pointer narrows the view too much to only one part of >the story. The object that is being pointed to is the other side. And in >the end it is about a combination of static types and dynamic values and >constellations of pointers and pointees. > >It's funny but I have to agree with Paul here, that the type of an >object that lives at a certain memory location is not affected by some >pointer that points to it (like, it's embarassing, and the color of the >object changes to red :) ). > >Hm, ok. Here's me on that topic: >A pointer is effectively like a pair of glasses that you see through >when you dereference it. Like, everything looks like a T when you look >at the memory through a T*... >The type is something that is determined at compile-time. I.e. it's >either a pair of green glasses or red glasses, and the color can't be >changed. >It is sort of an automatic reinterpret_cast, where the cast has been >done in advance (or was not necessary) during the assignment/initialization. >Pointers and pointees are orthogonal. Pointers can point to anything >(maybe by force, using a cast), and pointees can be pointed to by >anything (unaffected by them until actually accessed through one of >them). Some of the combinations are valid, some are UB. Ultimately, it's >the run-time act of actually dereferencing the pointer and accessing the >actual memory location that decides whether it's a crash or not (Note >that I intentionally used the more general word "crash" and not "UB" >here, even though it does not always have to end in a crash). That does >not mean this is the earliest opportunity for "formally UB" or >"implementation specific". It does not mean that some UB cannot be >proven at compile time. It also means that not all dereferences actually >access a memory location (e.g. for sizeof(*p), p does not have to point >to something valid). >The definition of a pointer defines how a pointer behaves when you use >it, and what you are formally allowed to do with it. > >Noah said: >> The important parts about pointers are that you can gain them in certain >> ways (like using &) and you can dereference them. Those two conceptual >> operations make a pointer what it is. >Perfectly clear up to here. > >> The type that you get when you >> dereference the pointer is what it points to. >That's the source for much of the recent discussion. >It's a compile-time centric view. It ignores the possibility that at >run-time, there may not actually be an object of that type at the >respective memory location. Sure, if you did not have to use a cast to >force it to point to something else, chances are that it actually points >to what its type says. But you don't even need to use a cast to create a >situation where it's different, and that is for example when you destroy >the object and create a new one at the same location but with different >type. > > >As for arrays... >They are tricky because they are composed of elements that have a type >while the whole array itself has another type. The whole discussion >about that is understandable... > >Let me introduce some old friends to talk about: >int a[10]; >int *p = a; > >Formally, p is of type "pointer to int", i.e. p points to a memory >location that is interpreted to be an int when accessed through p by >dereferencing p. That memory location happens to be the first int >element of the array a because p has been initialized with that >element's address. > >Drumroll... > >Can you say "p points to the array a"? >Not formally, but I cannot intuitively claim that it is completely >wrong, either. I already used the term "divine knowledge" in some older >post to describe the situation where we somehow "know" that there are >other int neighbours after the first element. We know a[0] is only the >first in a series of 10 contiguous ints. This information is undoubtedly >there, but it is not coded into the pointer's type, and so is not >available to the compiler or across function calls, etc. > >The first element is also somewhat special regarding the question. If p >would point to any other element of a, I would be pressed to say it >points to a. You could say it points into a. >But the first element is special in that its address is the same as the >address of the whole superobject it is a part of. > >On the other hand, you can only use the pointer to access one element at >a time, and not the whole array at once. > >>>> If the discussion is about "pointer to T" then it is both inaccurate and >>>> irresponsible to say that an int* points to an array. Only in the most casual >>>> and general sense is this statement acceptable and only when the discussion is >>>> not about "pointer to T". >>>We certainly don't seem to agree on the level of casualness needed for >>>the statement to be acceptable. But that is not the core point. Again, >>>my quarrel is with the complete denial of any validity whatsoever of >>>this POV. >> Apparently we do not agree, and that is fine, but what I have expressed is that >> when the discussion is already about T then T must remain constant. We are not >> talking about T1 and T2. If the topic is about something other than "pointer >> to T" then the POV is fine so long as it does not find itself to be the >> foundation for other concepts that end up requiring specificity regarding T. >> >> ex. such as with the case of an educator explaining a function that takes a >> pointer and the function is unaware that an array was allocated, further >> bringing the class up to their first introduction to STL containers for example. >Not all teachers teach you all the details from the start. Sometimes you >learn the "what" and "how" first, and the "why" later. >Also, knowing all the details about a tool is not always necessary to >successfully use a tool. >I agree though, that knowing the details is helpful, and often necessary >for building upon it other knowledge. > >>>> Does case #2 from above hold up under this pointer defintion? >>>No, and it does not have to under all circumstances. >>> >>> >>>> From "The C++ Programming Language" >>>> 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. >>>> No. >>>> >>>> Is there any well-defined pointer definition that agrees with the assertion that >>>> an int* points to an array? >>>> None that I am aware. >>>And there doesn't have to be... >>> >>>> I ask that if anybody knows of one to please feel free to add it to this >>>> discussion. >>>> >>>> As my closing thought, I do not impose "lawyeresque verbiage" onto those that >>>> choose loose terminology in general discussions. I do, however, make the very >>>> important disctinction that there is a time to be "general" and a time to be >>>> "technically precise". For the case of a C++ discussion about "pointer to T" >>>> then the time is not to be general, but rather, and simply put, technically >>>> precise. >>>I'm happy to hear that we agree that there are times when technical >>>correctness is not all that counts. >> Of course. >>> >>>What Alf wanted to point out is, in my understanding, that his "3)" is >>>something to be considered and not to be ignored, and nothing more. Too >>>bad that some people did not see this and instead felt the need to raise >>>their finger again, and be quick to dissect his post and insist on >>>technical correctness, even though that completely misses the point. >> I guess by "some people" you include me, which is fine. I own what I've said. >> >> He did not merely say that his "3)" was not to be ignored, and if he did, I >> would not have responded. >After reading again, I agree he didn't exactly. It was only my perceived >intention of his post. > >> He did say, and I quote, "I've seen that some people think (3) is just >> metaphorical. That to be technically correct one would need to insert >> lawyeresque verbiage like "first element of". That seems silly to me, and except >> for the trolling-threads here I've never heard anyone speaking that way, or read >> anyone writing that way." >I have to admit (and I'm not ashamed of that), that it's a bit >exaggerated. I'm also of the opinion that you'd have to add something to >be technically correct, and that in itself is not silly. >I just disagree with the high level of casualness you demand to accept >that phrase. But we've been there already. > >> So of course after such a statement I was inspired to cite 3 authoritative >> sources that are written precisely in a way he claims to be silly and to not >> have read. I respect your defense for Alf's POV. Do you respect mine as well? >Yes. > >> Additionally, I emphatically disagree that it is at all "lawyeresque" to say >> "first element of" in any context. >It all amounts to the question of where you put the level of formality >in the discussion at hand. This determines whether the words >"lawyeresque", "nit-picky", "pedantic", "splitting hairs", etc. are >likely to come into play or not. > >> But when the context specifically is regarding "pointer to T" and when T >> matters, I then assert exactly the opposite of what Alf did, and that is "to be >> technically correct one would need to insert first element of" since T is not a >> loose abstraction, it is a type. >I would like to point out again that he did not ignore the formality, >but just added something to it. >This is in accordance with my assertion that it's ok to become a little >slack with the language as long as you keep in mind that it is formally >not 100% correct. > >> My point is that context does matter every bit as much as the level of >> formality. >See above... > >> Further elaboration: >> >> Even if "points to" is an abstraction of an abstraction, which is really how I >> perceive what Alf and SG have stated, the abstractions themselves must still >> rely on some well-definition of pointer. Any such definition is always going to >> include "stores the address of an object of type T". >See "me on that topic" above. > >> And for any such definition where T* is declared, the address stored once >> initialized, by well-definition, ( not casual conversation or subjectivity, or >> opinion, ) MUST be the address of an object of type T. (no, we are not >> explicitly naming polymorphic types here) >Or else? > >> Once again, I do not discount the usefulness for easy language and loose >> terminology. Even said, we probably do not agree on the proper time for >> technical specificity which is ok with me. >And everyone's happy. > >>>> >>>> Charles >>> >>>Peter >> >> Charles >> Thank you for your response. > >Thank you for a decent discussion without name calling, childish acting, >or being offended easily and responding with troll accusations :) my pleasure > >Peter Charles
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2011-04-14 09:37 +1200 |
| Message-ID | <90mjc9FkbtU1@mid.individual.net> |
| In reply to | #3566 |
On 04/14/11 12:27 AM, cg_chas wrote: > Needless to say, there is significant dissension regarding when, or even if, it > is ever preferrable to use well-defined terminology instead of loose or casual > but generally accepted terminology regarding pointers and arrays. > > Examples such as: > int a[42]; > int* p2 = a; > apparently create huge debates about how to describe the above expressions. > > Similar examples include expressions like: > int* p1 = new int[42]; > > I gleen two cases representing the major divisions of opinion in this matter and > I happen to not agree entirely with either. > > 1) Nobody is actually saying that the int pointers p1 and p2 do not point to the > initial element of an array, but more than one has expressed that it is silly to > put it that way. > > 2) More than one has said that it is "generally acceptable" to say that the > above expressions are both int pointers that point to arrays. One point I don't think has been argued over: when is an array not an array? If after int* p1 = new int[42]; p pints to an array, what does ++p point to? Another array? If p is a pointer to an array, does incrementing p change it to something else? The standard is unambiguous as to what p is: 5.3.4/1: "If it is an array, the new-expression returns a pointer to the initial element of the array." and what p2 above is: 4.2/1: "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." > My thoughts are: > > In any C++ discussion about pointer to T, is it really ever silly to say that an > int* points to the initial element of an array of int when it is well-defined to > do so? > No. > > It is not silly because widely recognized C++ sources say it just that way. > 1) The C++ Programming Language, Bjarne Stroustrup section 5.3 Pointers into > Arrays > 2) Accelerated C++, Andrew Koenig 10.1.3 Arrays (last paragraph, second > sentence) > 3) ISO/IEC 14882 5.3.4 New (paragraph 1, last two senctences) > > In any C++ discussion about pointer to T, is what is claimed to be "generally > acceptable" (the statement that an int* points to an array) ever truly > technically correct? > No. > > If the discussion is about "pointer to T" then it is both inaccurate and > irresponsible to say that an int* points to an array. Only in the most casual > and general sense is this statement acceptable and only when the discussion is > not about "pointer to T". I agree. -- Ian Collins
[toc] | [prev] | [next] | [standalone]
| From | cg_chas <cg_chas@hotmail.com> |
|---|---|
| Date | 2011-04-13 17:41 -0400 |
| Message-ID | <iu5cq69sv7vr3l85seikmo9miiqmgo2jcc@4ax.com> |
| In reply to | #3597 |
On Thu, 14 Apr 2011 09:37:13 +1200, Ian Collins <ian-news@hotmail.com> wrote: >On 04/14/11 12:27 AM, cg_chas wrote: >> Needless to say, there is significant dissension regarding when, or even if, it >> is ever preferrable to use well-defined terminology instead of loose or casual >> but generally accepted terminology regarding pointers and arrays. >> >> Examples such as: >> int a[42]; >> int* p2 = a; >> apparently create huge debates about how to describe the above expressions. >> >> Similar examples include expressions like: >> int* p1 = new int[42]; >> >> I gleen two cases representing the major divisions of opinion in this matter and >> I happen to not agree entirely with either. >> >> 1) Nobody is actually saying that the int pointers p1 and p2 do not point to the >> initial element of an array, but more than one has expressed that it is silly to >> put it that way. >> >> 2) More than one has said that it is "generally acceptable" to say that the >> above expressions are both int pointers that point to arrays. > >One point I don't think has been argued over: when is an array not an >array? > >If after int* p1 = new int[42]; p pints to an array, what does ++p point >to? Another array? If p is a pointer to an array, does incrementing p >change it to something else? I am guessing Alf would say a "sub-object" or "sub-array". In either case, as soon as we start incrementing the pointer or the topic of discussion is about "pointer to T" which incrementing implies, then I would assert that "p points to an array" was technically imprecise and that p points to an element of an array now and before incrementing. > >The standard is unambiguous as to what p is: > >5.3.4/1: > >"If it is an array, the new-expression returns a pointer >to the initial element of the array." > >and what p2 above is: > >4.2/1: > >"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." > >> My thoughts are: >> >> In any C++ discussion about pointer to T, is it really ever silly to say that an >> int* points to the initial element of an array of int when it is well-defined to >> do so? >> No. >> >> It is not silly because widely recognized C++ sources say it just that way. >> 1) The C++ Programming Language, Bjarne Stroustrup section 5.3 Pointers into >> Arrays >> 2) Accelerated C++, Andrew Koenig 10.1.3 Arrays (last paragraph, second >> sentence) >> 3) ISO/IEC 14882 5.3.4 New (paragraph 1, last two senctences) >> >> In any C++ discussion about pointer to T, is what is claimed to be "generally >> acceptable" (the statement that an int* points to an array) ever truly >> technically correct? >> No. >> >> If the discussion is about "pointer to T" then it is both inaccurate and >> irresponsible to say that an int* points to an array. Only in the most casual >> and general sense is this statement acceptable and only when the discussion is >> not about "pointer to T". > >I agree.
[toc] | [prev] | [next] | [standalone]
| From | Noah Roberts <dont@email.me> |
|---|---|
| Date | 2011-04-13 17:01 -0700 |
| Message-ID | <4da63945$0$25115$cc2e38e6@news.uslec.net> |
| In reply to | #3600 |
On 4/13/2011 2:41 PM, cg_chas wrote: > On Thu, 14 Apr 2011 09:37:13 +1200, Ian Collins<ian-news@hotmail.com> wrote: > >> On 04/14/11 12:27 AM, cg_chas wrote: >>> Needless to say, there is significant dissension regarding when, or even if, it >>> is ever preferrable to use well-defined terminology instead of loose or casual >>> but generally accepted terminology regarding pointers and arrays. >>> >>> Examples such as: >>> int a[42]; >>> int* p2 = a; >>> apparently create huge debates about how to describe the above expressions. >>> >>> Similar examples include expressions like: >>> int* p1 = new int[42]; >>> >>> I gleen two cases representing the major divisions of opinion in this matter and >>> I happen to not agree entirely with either. >>> >>> 1) Nobody is actually saying that the int pointers p1 and p2 do not point to the >>> initial element of an array, but more than one has expressed that it is silly to >>> put it that way. >>> >>> 2) More than one has said that it is "generally acceptable" to say that the >>> above expressions are both int pointers that point to arrays. >> >> One point I don't think has been argued over: when is an array not an >> array? >> >> If after int* p1 = new int[42]; p pints to an array, what does ++p point >> to? Another array? If p is a pointer to an array, does incrementing p >> change it to something else? > I am guessing Alf would say a "sub-object" or "sub-array". > In either case, as soon as we start incrementing the pointer or the topic of > discussion is about "pointer to T" which incrementing implies, then I would > assert that "p points to an array" was technically imprecise and that p points > to an element of an array now and before incrementing. Hopefully not, because there's numerous problems with such a definition. For example, passing a pointer that "points to" (as they're defining it here) an array to "delete []" works...the same would NOT work with a "sub-array". At this point I believe its better to continue holding true to the concept of pointer as distinct to iterator. A pointer points at AN object. An iterator is a refinement of pointer that also allows iteration over a container (and in the subject of discussion that container is an array). Thus both p1 and p2 are pointers to elements in an array that are also iterators for that array. These terms are not interchangeable, one refines the other. -- http://crazycpp.wordpress.com
[toc] | [prev] | [next] | [standalone]
Page 1 of 7 [1] 2 3 4 5 6 7 Next page →
Back to top | Article view | comp.lang.c++
csiph-web