Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c++ > #3440 > unrolled thread
| Started by | "Alf P. Steinbach /Usenet" <alf.p.steinbach+usenet@gmail.com> |
|---|---|
| First post | 2011-04-12 04:00 +0200 |
| Last post | 2011-04-12 09:36 -0700 |
| Articles | 7 on this page of 87 — 16 participants |
Back to article view | Back to comp.lang.c++
On generally accepted terminology for pointers and arrays "Alf P. Steinbach /Usenet" <alf.p.steinbach+usenet@gmail.com> - 2011-04-12 04:00 +0200
Re: On generally accepted terminology for pointers and arrays Pavel <pauldontspamtolk@removeyourself.dontspam.yahoo> - 2011-04-12 00:13 -0400
Re: On generally accepted terminology for pointers and arrays "Paul" <pchristor@yahoo.co.uk> - 2011-04-12 05:17 +0100
Re: On generally accepted terminology for pointers and arrays Leigh Johnston <leigh@i42.co.uk> - 2011-04-12 14:02 +0100
Re: On generally accepted terminology for pointers and arrays "Paul" <pchristor@yahoo.co.uk> - 2011-04-12 14:10 +0100
Re: On generally accepted terminology for pointers and arrays Leigh Johnston <leigh@i42.co.uk> - 2011-04-12 14:49 +0100
Re: On generally accepted terminology for pointers and arrays cg_chas <cg_chas@hotmail.com> - 2011-04-12 10:05 -0400
Re: On generally accepted terminology for pointers and arrays cg_chas <cg_chas@hotmail.com> - 2011-04-12 01:11 -0400
Re: On generally accepted terminology for pointers and arrays gwowen <gwowen@gmail.com> - 2011-04-11 23:24 -0700
Re: On generally accepted terminology for pointers and arrays gwowen <gwowen@gmail.com> - 2011-04-12 00:16 -0700
Re: On generally accepted terminology for pointers and arrays Leigh Johnston <leigh@i42.co.uk> - 2011-04-12 13:53 +0100
Re: On generally accepted terminology for pointers and arrays "Paul" <pchristor@yahoo.co.uk> - 2011-04-12 14:08 +0100
Re: On generally accepted terminology for pointers and arrays "Paul" <pchristor@yahoo.co.uk> - 2011-04-12 14:05 +0100
Re: On generally accepted terminology for pointers and arrays Leigh Johnston <leigh@i42.co.uk> - 2011-04-12 14:48 +0100
Re: On generally accepted terminology for pointers and arrays Ian Collins <ian-news@hotmail.com> - 2011-04-13 07:53 +1200
Re: On generally accepted terminology for pointers and arrays "Alf P. Steinbach /Usenet" <alf.p.steinbach+usenet@gmail.com> - 2011-04-12 22:14 +0200
Re: On generally accepted terminology for pointers and arrays Öö Tiib <ootiib@hot.ee> - 2011-04-12 15:39 -0700
Re: On generally accepted terminology for pointers and arrays Goran <goran.pusic@gmail.com> - 2011-04-12 01:39 -0700
Re: On generally accepted terminology for pointers and arrays Ian Collins <ian-news@hotmail.com> - 2011-04-12 20:51 +1200
Re: On generally accepted terminology for pointers and arrays Jorgen Grahn <grahn+nntp@snipabacken.se> - 2011-04-12 21:51 +0000
Re: On generally accepted terminology for pointers and arrays cpp4ever <n2xssvv.g02gfr12930@ntlworld.com> - 2011-04-12 09:59 +0100
Re: On generally accepted terminology for pointers and arrays "Alf P. Steinbach /Usenet" <alf.p.steinbach+usenet@gmail.com> - 2011-04-12 16:25 +0200
Re: On generally accepted terminology for pointers and arrays cpp4ever <n2xssvv.g02gfr12930@ntlworld.com> - 2011-04-12 16:07 +0100
Re: On generally accepted terminology for pointers and arrays "Alf P. Steinbach /Usenet" <alf.p.steinbach+usenet@gmail.com> - 2011-04-12 17:32 +0200
Re: On generally accepted terminology for pointers and arrays cpp4ever <n2xssvv.g02gfr12930@ntlworld.com> - 2011-04-12 16:53 +0100
Re: On generally accepted terminology for pointers and arrays "Alf P. Steinbach /Usenet" <alf.p.steinbach+usenet@gmail.com> - 2011-04-12 18:16 +0200
Re: On generally accepted terminology for pointers and arrays cpp4ever <n2xssvv.g02gfr12930@ntlworld.com> - 2011-04-12 17:39 +0100
Re: On generally accepted terminology for pointers and arrays "Alf P. Steinbach /Usenet" <alf.p.steinbach+usenet@gmail.com> - 2011-04-12 19:32 +0200
Re: DILLIGAF cpp4ever <n2xssvv.g02gfr12930@ntlworld.com> - 2011-04-12 19:05 +0100
Re: DILLIGAF Peter Remmers <p.remmers@expires-2011-04-30.arcornews.de> - 2011-04-12 20:36 +0200
Re: DILLIGAF cpp4ever <n2xssvv.g02gfr12930@ntlworld.com> - 2011-04-12 20:47 +0100
Re: DILLIGAF gwowen <gwowen@gmail.com> - 2011-04-12 14:48 -0700
Re: DILLIGAF Öö Tiib <ootiib@hot.ee> - 2011-04-12 15:16 -0700
Re: On generally accepted terminology for pointers and arrays "Paul" <pchristor@yahoo.co.uk> - 2011-04-12 17:48 +0100
Re: On generally accepted terminology for pointers and arrays Noah Roberts <dont@email.me> - 2011-04-12 09:37 -0700
Re: On generally accepted terminology for pointers and arrays "Paul" <pchristor@yahoo.co.uk> - 2011-04-12 18:34 +0100
Re: On generally accepted terminology for pointers and arrays "Alf P. Steinbach /Usenet" <alf.p.steinbach+usenet@gmail.com> - 2011-04-12 19:38 +0200
Re: On generally accepted terminology for pointers and arrays Noah Roberts <dont@email.me> - 2011-04-12 11:00 -0700
Re: On generally accepted terminology for pointers and arrays "Alf P. Steinbach /Usenet" <alf.p.steinbach+usenet@gmail.com> - 2011-04-12 20:03 +0200
Re: On generally accepted terminology for pointers and arrays Noah Roberts <dont@email.me> - 2011-04-12 11:06 -0700
Re: On generally accepted terminology for pointers and arrays Peter Remmers <p.remmers@expires-2011-04-30.arcornews.de> - 2011-04-12 20:26 +0200
Re: On generally accepted terminology for pointers and arrays Noah Roberts <dont@email.me> - 2011-04-12 11:33 -0700
Re: On generally accepted terminology for pointers and arrays Peter Remmers <p.remmers@expires-2011-04-30.arcornews.de> - 2011-04-12 20:55 +0200
Re: On generally accepted terminology for pointers and arrays "Paul" <pchristor@yahoo.co.uk> - 2011-04-12 20:14 +0100
Re: On generally accepted terminology for pointers and arrays Noah Roberts <dont@email.me> - 2011-04-12 12:47 -0700
Re: On generally accepted terminology for pointers and arrays Peter Remmers <p.remmers@expires-2011-04-30.arcornews.de> - 2011-04-12 22:40 +0200
Re: On generally accepted terminology for pointers and arrays cg_chas <cg_chas@hotmail.com> - 2011-04-12 14:15 -0400
Re: On generally accepted terminology for pointers and arrays "Alf P. Steinbach /Usenet" <alf.p.steinbach+usenet@gmail.com> - 2011-04-12 20:52 +0200
Re: On generally accepted terminology for pointers and arrays "Paul" <pchristor@yahoo.co.uk> - 2011-04-12 20:23 +0100
Re: On generally accepted terminology for pointers and arrays cg_chas <cg_chas@hotmail.com> - 2011-04-12 16:01 -0400
Re: On generally accepted terminology for pointers and arrays Noah Roberts <dont@email.me> - 2011-04-12 13:46 -0700
Re: On generally accepted terminology for pointers and arrays Öö Tiib <ootiib@hot.ee> - 2011-04-12 19:49 -0700
Re: On generally accepted terminology for pointers and arrays hanukas <jukka@liimatta.org> - 2011-04-13 00:06 -0700
Re: On generally accepted terminology for pointers and arrays cg_chas <cg_chas@hotmail.com> - 2011-04-13 04:14 -0400
Re: On generally accepted terminology for pointers and arrays Öö Tiib <ootiib@hot.ee> - 2011-04-13 07:53 -0700
Re: On generally accepted terminology for pointers and arrays "Paul" <pchristor@yahoo.co.uk> - 2011-04-13 09:52 +0100
Re: On generally accepted terminology for pointers and arrays cg_chas <cg_chas@hotmail.com> - 2011-04-13 05:20 -0400
Re: On generally accepted terminology for pointers and arrays "Paul" <pchristor@yahoo.co.uk> - 2011-04-13 10:31 +0100
Re: On generally accepted terminology for pointers and arrays cg_chas <cg_chas@hotmail.com> - 2011-04-13 07:04 -0400
Re: On generally accepted terminology for pointers and arrays "Paul" <pchristor@yahoo.co.uk> - 2011-04-13 12:35 +0100
Re: On generally accepted terminology for pointers and arrays cg_chas <cg_chas@hotmail.com> - 2011-04-13 07:41 -0400
Re: On generally accepted terminology for pointers and arrays Ian Collins <ian-news@hotmail.com> - 2011-04-14 07:47 +1200
Re: On generally accepted terminology for pointers and arrays "Paul" <pchristor@yahoo.co.uk> - 2011-04-14 11:44 +0100
Re: On generally accepted terminology for pointers and arrays "io_x" <a@b.c.invalid> - 2011-04-13 18:41 +0200
Re: On generally accepted terminology for pointers and arrays Noah Roberts <dont@email.me> - 2011-04-13 09:35 -0700
Re: On generally accepted terminology for pointers and arrays "Paul" <pchristor@yahoo.co.uk> - 2011-04-13 20:17 +0100
Re: On generally accepted terminology for pointers and arrays cg_chas <cg_chas@hotmail.com> - 2011-04-13 04:33 -0400
Re: On generally accepted terminology for pointers and arrays cg_chas <cg_chas@hotmail.com> - 2011-04-13 04:35 -0400
Re: On generally accepted terminology for pointers and arrays "Paul" <pchristor@yahoo.co.uk> - 2011-04-13 01:19 +0100
Re: On generally accepted terminology for pointers and arrays cg_chas <cg_chas@hotmail.com> - 2011-04-13 04:01 -0400
Re: On generally accepted terminology for pointers and arrays cg_chas <cg_chas@hotmail.com> - 2011-04-13 04:20 -0400
Re: On generally accepted terminology for pointers and arrays "Paul" <pchristor@yahoo.co.uk> - 2011-04-13 09:56 +0100
Re: On generally accepted terminology for pointers and arrays cg_chas <cg_chas@hotmail.com> - 2011-04-13 05:24 -0400
Re: On generally accepted terminology for pointers and arrays "Paul" <pchristor@yahoo.co.uk> - 2011-04-13 10:34 +0100
Re: On generally accepted terminology for pointers and arrays cg_chas <cg_chas@hotmail.com> - 2011-04-13 07:07 -0400
Re: On generally accepted terminology for pointers and arrays "Paul" <pchristor@yahoo.co.uk> - 2011-04-13 12:36 +0100
Re: On generally accepted terminology for pointers and arrays cg_chas <cg_chas@hotmail.com> - 2011-04-13 07:43 -0400
Re: On generally accepted terminology for pointers and arrays "Paul" <pchristor@yahoo.co.uk> - 2011-04-13 13:18 +0100
Re: On generally accepted terminology for pointers and arrays cg_chas <cg_chas@hotmail.com> - 2011-04-13 08:30 -0400
Re: On generally accepted terminology for pointers and arrays "Alf P. Steinbach /Usenet" <alf.p.steinbach+usenet@gmail.com> - 2011-04-13 15:57 +0200
Re: On generally accepted terminology for pointers and arrays Leigh Johnston <leigh@i42.co.uk> - 2011-04-13 15:10 +0100
Re: On generally accepted terminology for pointers and arrays cg_chas <cg_chas@hotmail.com> - 2011-04-13 11:09 -0400
Re: On generally accepted terminology for pointers and arrays cg_chas <cg_chas@hotmail.com> - 2011-04-13 12:04 -0400
Re: On generally accepted terminology for pointers and arrays Noah Roberts <dont@email.me> - 2011-04-13 09:56 -0700
Re: On generally accepted terminology for pointers and arrays cg_chas <cg_chas@hotmail.com> - 2011-04-13 14:11 -0400
Re: On generally accepted terminology for pointers and arrays "Paul" <pchristor@yahoo.co.uk> - 2011-04-12 19:29 +0100
Re: On generally accepted terminology for pointers and arrays Joshua Maurice <joshuamaurice@gmail.com> - 2011-04-12 09:36 -0700
Page 5 of 5 — ← Prev page 1 2 3 4 [5]
| From | Leigh Johnston <leigh@i42.co.uk> |
|---|---|
| Date | 2011-04-13 15:10 +0100 |
| Message-ID | <SZWdnc_0vs8hMzjQnZ2dnUVZ8vmdnZ2d@giganews.com> |
| In reply to | #3569 |
On 13/04/2011 14:57, Alf P. Steinbach /Usenet wrote: > * cg_chas, on 12.04.2011 22:01: >> On Tue, 12 Apr 2011 20:52:13 +0200, "Alf P. Steinbach /Usenet" >> <alf.p.steinbach+usenet@gmail.com> wrote: >>> >>> No, what Noah wrote, which is quoted in context above, was >>> >>> >>> "To claim that a pointer points at anything other than what you get >>> when you >>> dereference it flies in the face ofthe concept of "pointer". >> >> Yes I read and understood his statement expressely for the face value >> of every >> word in the sentence. Where we differ though is that I can see the >> greater >> value in his point regardless if he botched the wording or not. > > I'm sure that with enough empathy any self-contradictory statement can > be viewed as an attempted expression of some beautiful thought. > > But, you can't require utmost precision of others, and think your own > side is exempt from that requirement. > > At least if you want to be taken seriously. > > > > [snip] > >> Since I can see the logic in your rebuttle to Noah, I am convinced >> that you are >> not ignorant to the importance of technical correctness and well-defined >> terminology. > > Ah, good. > > >> So, let me ask you this directly. How does your logical assertion that >> an int* >> can "dynamically" point to an array fit into the pointer definition >> below? >> >> For a type T, T* is the type "pointer to T." That is, a variable of >> type T* can >> hold the address of an object of type T. > > For most of us there is no problem. > > Consider this function: > > void upcase( char* p ) > > If caller and implementor disagree on whether p points to single char > object, or to a zero-terminated string, or whatever, then result might > be core dump... > > Now I pass by your desk and see you struggling with this function. > Someone has noticed that too many core dumps seem to indicate that this > 'upcase' function is the culprit, and you are attempting to fix it. As I > pass you by you remark on the competentency (or lack thereof) of the > original programmer, "jeez, this call to toupper passes negative values, > he forgot to cast!". > > I glance at it, and remark "he he, and he also seems to have assumed > he's passed a pointer to a single char, instead of a pointer to a string!". > > You say, "pointer to string? that's technically meaningless! see, here, > it says 'char*" > > I think you're joking, and go on to whatever I was going to. > > Two days later I notice that you're STILL struggling with the 'upcase' > function. > > What's going on, I ask you. How come you're still working on that > trivial function? > > As it turns out, after fixing the cast issue (which caused UB in the > standard library) you thought you'd fixed it, but you got it back. No > more core dumps, OK, but it doesn't pass the unit tests anymore. And you > cannot figure out *why*. > > I look at it, and say, "hey, that p, it's surely a pointer to a string?". > If one wants to be both technically accurate and informal at the same time one could perhaps say: "hey, that p, it surely points to a string". "pointer to a foo" is different to "points to a foo"; subtle but true. It is incorrect to say "p is a pointer to a string" because the term "is a pointer to" is used to partially describe a *type*. The *type* of p is "pointer to a char" not a "pointer to a string". [...] /Leigh
[toc] | [prev] | [next] | [standalone]
| From | cg_chas <cg_chas@hotmail.com> |
|---|---|
| Date | 2011-04-13 11:09 -0400 |
| Message-ID | <i8bbq6lbr4h5glb23vm0t60ng7huircdjg@4ax.com> |
| In reply to | #3569 |
On Wed, 13 Apr 2011 15:57:19 +0200, "Alf P. Steinbach /Usenet" <alf.p.steinbach+usenet@gmail.com> wrote: >* cg_chas, on 12.04.2011 22:01: >> On Tue, 12 Apr 2011 20:52:13 +0200, "Alf P. Steinbach /Usenet" >> <alf.p.steinbach+usenet@gmail.com> wrote: >>> >>> No, what Noah wrote, which is quoted in context above, was >>> >>> >>> "To claim that a pointer points at anything other than what you get when you >>> dereference it flies in the face ofthe concept of "pointer". >> >> Yes I read and understood his statement expressely for the face value of every >> word in the sentence. Where we differ though is that I can see the greater >> value in his point regardless if he botched the wording or not. > >I'm sure that with enough empathy any self-contradictory statement can be viewed >as an attempted expression of some beautiful thought. > >But, you can't require utmost precision of others, and think your own side is >exempt from that requirement. > >At least if you want to be taken seriously. > > > >[snip] > >> Since I can see the logic in your rebuttle to Noah, I am convinced that you are >> not ignorant to the importance of technical correctness and well-defined >> terminology. > >Ah, good. > > >> So, let me ask you this directly. How does your logical assertion that an int* >> can "dynamically" point to an array fit into the pointer definition below? >> >> For a type T, T* is the type "pointer to T." That is, a variable of type T* can >> hold the address of an object of type T. > >For most of us there is no problem. > >Consider this function: > > void upcase( char* p ) > >If caller and implementor disagree on whether p points to single char object, or >to a zero-terminated string, or whatever, then result might be core dump... > >Now I pass by your desk and see you struggling with this function. Someone has >noticed that too many core dumps seem to indicate that this 'upcase' function is >the culprit, and you are attempting to fix it. As I pass you by you remark on >the competentency (or lack thereof) of the original programmer, "jeez, this call >to toupper passes negative values, he forgot to cast!". > >I glance at it, and remark "he he, and he also seems to have assumed he's passed >a pointer to a single char, instead of a pointer to a string!". > >You say, "pointer to string? that's technically meaningless! see, here, it says >'char*" > >I think you're joking, and go on to whatever I was going to. > >Two days later I notice that you're STILL struggling with the 'upcase' function. > >What's going on, I ask you. How come you're still working on that trivial function? > >As it turns out, after fixing the cast issue (which caused UB in the standard >library) you thought you'd fixed it, but you got it back. No more core dumps, >OK, but it doesn't pass the unit tests anymore. And you cannot figure out *why*. > >I look at it, and say, "hey, that p, it's surely a pointer to a string?". > >You just shake your head sadly, "Sorry Alf, that's meaningless, a 'char*' can't >point to a string, it can only point to a 'char', that's what the type is about. >But thanks for your attempt to help. Argh, this is really difficult: the code is >trivial, yet it doesn't pass unit tests; do you have any other idea?" > >I consider suggesting that you change the textual function declaration, like >'void upcase( char s[] )', but it doesn't take more than a milli-second of >reflection to see that you would not see the point of that. I could expect some >retort like "Alf, Alf, thanks, but that means exactly the same, so it would not >help with the unit test issue". And likewise for some other suggestions. > >So, I just fetch myself yet another cup of coffee, and leave you to it. > > >Cheers & hth., > >- Alf Ooh storybook fashion. I can dig it. :) Had to read it three times to experience the complete amusement of your story. I even got the impression that you were the one facing the core dumps and unit test failures from the perspective of the story's not-Alf character. It just sounded like you spoke from experience with the illustrious detail. I can appreciate that. I don't appreciate you not bringing me coffee while I was busting my ass with the core dumps though, but I guess that's because you're the teacher and I am the student. Fun aside and oddly enough, you chose to tell a story rather than respond to a rather direct question. Proper etiquette would have my thank you for any response, so thank you, but the reasonable expectation for a response to the question asked was not met. regarding your function example: void upcase( char* p ) Firstly a side note: this story and supporting example is the quintessential reason that an array is not a pointer. Which of course you stated yourself in your first case in initial post. The array that is a c-style string is very much a special case because the language defines that it is '\0' terminated. const char* c = "hello" c is a c-style string. c points to the address of 'h' void upcase(char* p) Which of course does not assert an agreement between the caller and the function would lead me to my project manager long before a core dump or trying to type any function that does not have a well-defined C++ object type that enforces an agreed upon interface. Using naked non-const c-style strings is not something you'll not typically see in any of my function arguments and if you do, the block in the function will be where the pointer is initialized, not the calling block. i do very much prefer: void upcase(std::string& s ) // const of course if we are only reading the string data or even: back to void upcase(std::vector<char>& v) Is it generally acceptable to say that c points to an array? Yes, and it is also correct to say that c "is" a c-style string, which forgoes the entire abstraction of a pointer, and replaces it with another abstraction. Is it technically correct to say that c points to an array? No, especially if the topic of discussion is "pointer to T." Consider the following: const char* c1 = "123"; const char c2[] = "123"; const char* pc1 = c1; const char* pc2 = c2; std::cout << "c1 type is : " << typeid(c1).name() << std::endl; std::cout << "c2 type is : " << typeid(c2).name() << std::endl; std::cout << "pc1 type is : " << typeid(pc1).name() << std::endl; std::cout << "pc2 type is : " << typeid(pc2).name() << std::endl; c1 is a c-style string or an object of type: char const * c2 is a c-style string as well, but has the type to prove it: char const[4] c1, pc1, and pc2 all technically point to a single char Through implicit conversion, only c2 points to an array. Regardless of whether or not the array is an array of char, the C language idiom that is a c-style string, pointer to element of an array does not break the well-defined pointer definition, it is in fact bound by it. 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. I'd re-ask for a direct answer to the direct question, but apparently that is asking too much.
[toc] | [prev] | [next] | [standalone]
| From | cg_chas <cg_chas@hotmail.com> |
|---|---|
| Date | 2011-04-13 12:04 -0400 |
| Message-ID | <qbibq6dfitk54ssi6vucee640ua3d311tv@4ax.com> |
| In reply to | #3576 |
On Wed, 13 Apr 2011 11:09:35 -0400, cg_chas <cg_chas@hotmail.com> wrote: >On Wed, 13 Apr 2011 15:57:19 +0200, "Alf P. Steinbach /Usenet" ><alf.p.steinbach+usenet@gmail.com> wrote: > >>* cg_chas, on 12.04.2011 22:01: >>> On Tue, 12 Apr 2011 20:52:13 +0200, "Alf P. Steinbach /Usenet" >>> <alf.p.steinbach+usenet@gmail.com> wrote: >>>> >>>> No, what Noah wrote, which is quoted in context above, was >>>> >>>> >>>> "To claim that a pointer points at anything other than what you get when you >>>> dereference it flies in the face ofthe concept of "pointer". >>> >>> Yes I read and understood his statement expressely for the face value of every >>> word in the sentence. Where we differ though is that I can see the greater >>> value in his point regardless if he botched the wording or not. >> >>I'm sure that with enough empathy any self-contradictory statement can be viewed >>as an attempted expression of some beautiful thought. >> >>But, you can't require utmost precision of others, and think your own side is >>exempt from that requirement. >> >>At least if you want to be taken seriously. >> >> >> >>[snip] >> >>> Since I can see the logic in your rebuttle to Noah, I am convinced that you are >>> not ignorant to the importance of technical correctness and well-defined >>> terminology. >> >>Ah, good. >> >> >>> So, let me ask you this directly. How does your logical assertion that an int* >>> can "dynamically" point to an array fit into the pointer definition below? >>> >>> For a type T, T* is the type "pointer to T." That is, a variable of type T* can >>> hold the address of an object of type T. >> >>For most of us there is no problem. >> >>Consider this function: >> >> void upcase( char* p ) >> >>If caller and implementor disagree on whether p points to single char object, or >>to a zero-terminated string, or whatever, then result might be core dump... >> >>Now I pass by your desk and see you struggling with this function. Someone has >>noticed that too many core dumps seem to indicate that this 'upcase' function is >>the culprit, and you are attempting to fix it. As I pass you by you remark on >>the competentency (or lack thereof) of the original programmer, "jeez, this call >>to toupper passes negative values, he forgot to cast!". >> >>I glance at it, and remark "he he, and he also seems to have assumed he's passed >>a pointer to a single char, instead of a pointer to a string!". >> >>You say, "pointer to string? that's technically meaningless! see, here, it says >>'char*" >> >>I think you're joking, and go on to whatever I was going to. >> >>Two days later I notice that you're STILL struggling with the 'upcase' function. >> >>What's going on, I ask you. How come you're still working on that trivial function? >> >>As it turns out, after fixing the cast issue (which caused UB in the standard >>library) you thought you'd fixed it, but you got it back. No more core dumps, >>OK, but it doesn't pass the unit tests anymore. And you cannot figure out *why*. >> >>I look at it, and say, "hey, that p, it's surely a pointer to a string?". >> >>You just shake your head sadly, "Sorry Alf, that's meaningless, a 'char*' can't >>point to a string, it can only point to a 'char', that's what the type is about. >>But thanks for your attempt to help. Argh, this is really difficult: the code is >>trivial, yet it doesn't pass unit tests; do you have any other idea?" >> >>I consider suggesting that you change the textual function declaration, like >>'void upcase( char s[] )', but it doesn't take more than a milli-second of >>reflection to see that you would not see the point of that. I could expect some >>retort like "Alf, Alf, thanks, but that means exactly the same, so it would not >>help with the unit test issue". And likewise for some other suggestions. >> >>So, I just fetch myself yet another cup of coffee, and leave you to it. >> >> >>Cheers & hth., >> >>- Alf >Ooh storybook fashion. I can dig it. :) > >Had to read it three times to experience the complete amusement of your story. >I even got the impression that you were the one facing the core dumps and unit >test failures from the perspective of the story's not-Alf character. It just >sounded like you spoke from experience with the illustrious detail. I can >appreciate that. I don't appreciate you not bringing me coffee while I was >busting my ass with the core dumps though, but I guess that's because you're the >teacher and I am the student. > >Fun aside and oddly enough, you chose to tell a story rather than respond to a >rather direct question. Proper etiquette would have my thank you for any >response, so thank you, but the reasonable expectation for a response to the >question asked was not met. > >regarding your function example: >void upcase( char* p ) > >Firstly a side note: this story and supporting example is the quintessential >reason that an array is not a pointer. Which of course you stated yourself in >your first case in initial post. > >The array that is a c-style string is very much a special case because the >language defines that it is '\0' terminated. > >const char* c = "hello" > >c is a c-style string. >c points to the address of 'h' edit: c holds the address of 'h' > >void upcase(char* p) > >Which of course does not assert an agreement between the caller and the function >would lead me to my project manager long before a core dump or trying to type >any function that does not have a well-defined C++ object type that enforces an >agreed upon interface. > >Using naked non-const c-style strings is not something you'll not typically see >in any of my function arguments and if you do, the block in the function will be >where the pointer is initialized, not the calling block. > >i do very much prefer: >void upcase(std::string& s ) // const of course if we are only reading the >string data >or even: > >back to void upcase(std::vector<char>& v) > >Is it generally acceptable to say that c points to an array? >Yes, and it is also correct to say that c "is" a c-style string, which forgoes >the entire abstraction of a pointer, and replaces it with another abstraction. > >Is it technically correct to say that c points to an array? >No, especially if the topic of discussion is "pointer to T." > >Consider the following: > >const char* c1 = "123"; >const char c2[] = "123"; >const char* pc1 = c1; >const char* pc2 = c2; > >std::cout << "c1 type is : " << typeid(c1).name() << std::endl; >std::cout << "c2 type is : " << typeid(c2).name() << std::endl; >std::cout << "pc1 type is : " << typeid(pc1).name() << std::endl; >std::cout << "pc2 type is : " << typeid(pc2).name() << std::endl; > >c1 is a c-style string or an object of type: char const * >c2 is a c-style string as well, but has the type to prove it: char const[4] >c1, pc1, and pc2 all technically point to a single char >Through implicit conversion, only c2 points to an array. > >Regardless of whether or not the array is an array of char, the C language idiom >that is a c-style string, pointer to element of an array does not break the >well-defined pointer definition, it is in fact bound by it. > >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. > >I'd re-ask for a direct answer to the direct question, but apparently that is >asking too much.
[toc] | [prev] | [next] | [standalone]
| From | Noah Roberts <dont@email.me> |
|---|---|
| Date | 2011-04-13 09:56 -0700 |
| Message-ID | <4da5d5cc$0$10335$cc2e38e6@news.uslec.net> |
| In reply to | #3521 |
On 4/12/2011 1:01 PM, cg_chas wrote: >> No, what Noah wrote, which is quoted in context above, was >> >> >> "To claim that a pointer points at anything other than what you get when you >> dereference it flies in the face ofthe concept of "pointer". > > Yes I read and understood his statement expressely for the face value of every > word in the sentence. Where we differ though is that I can see the greater > value in his point regardless if he botched the wording or not. This also was not botched. There are several ways to look at why this statement is true: 1) void f(int * ptr); <- the only useful thing that can be said of ptr is that it points at int. If that is true here, it is true everywhere else we no longer have a consistent language about pointers. 2) double * ptr = &int_var; <- Though is some hypothetical languages this might be possible, a strongly typed one like C++ does not allow this. You have to cast one or the other. In other words you can't assign the wrong variable type and what ptr points at defines what that is (by both language and concept). 3) double * ptr; decltype(*ptr) <- returns double, regardless of any casting you've done to bypass types. C++ allows you to cast types into other things. This does not mean that a double pointer is going to point at an int if you've casted the address of that int to double*. The simple truth is that from a conceptual/semantic (and in C++, syntatic) viewpoint, deref(ptr)->T means that ptr points at a T; to claim anything else is unsupportable. -- http://crazycpp.wordpress.com
[toc] | [prev] | [next] | [standalone]
| From | cg_chas <cg_chas@hotmail.com> |
|---|---|
| Date | 2011-04-13 14:11 -0400 |
| Message-ID | <q8pbq6duksc95ufjfj3qo89cbdkeori5kg@4ax.com> |
| In reply to | #3586 |
On Wed, 13 Apr 2011 09:56:45 -0700, Noah Roberts <dont@email.me> wrote: >On 4/12/2011 1:01 PM, cg_chas wrote: > >>> No, what Noah wrote, which is quoted in context above, was >>> >>> >>> "To claim that a pointer points at anything other than what you get when you >>> dereference it flies in the face ofthe concept of "pointer". >> >> Yes I read and understood his statement expressely for the face value of every >> word in the sentence. Where we differ though is that I can see the greater >> value in his point regardless if he botched the wording or not. > >This also was not botched. There are several ways to look at why this >statement is true: Being honest, I do not feel your statement was botched. I merely suggested that even if it was that I saw the greater point. Think of it as diplomatic way to suggest that even if the wording was not immutable law, the meaning was very clear and in my opinion valid. > >1) void f(int * ptr); <- the only useful thing that can be said of ptr >is that it points at int. If that is true here, it is true everywhere >else we no longer have a consistent language about pointers. > >2) double * ptr = &int_var; <- Though is some hypothetical languages >this might be possible, a strongly typed one like C++ does not allow >this. You have to cast one or the other. In other words you can't >assign the wrong variable type and what ptr points at defines what that >is (by both language and concept). > >3) double * ptr; decltype(*ptr) <- returns double, regardless of any >casting you've done to bypass types. > >C++ allows you to cast types into other things. This does not mean that >a double pointer is going to point at an int if you've casted the >address of that int to double*. The simple truth is that from a >conceptual/semantic (and in C++, syntatic) viewpoint, deref(ptr)->T >means that ptr points at a T; to claim anything else is unsupportable. Precisely why I said to him, "We could also cast the pointer to an infinite number of types and expect infinitely different types of yielded values."
[toc] | [prev] | [next] | [standalone]
| From | "Paul" <pchristor@yahoo.co.uk> |
|---|---|
| Date | 2011-04-12 19:29 +0100 |
| Message-ID | <OS0pp.1513$6W.761@newsfe21.ams2> |
| In reply to | #3499 |
"Alf P. Steinbach /Usenet" <alf.p.steinbach+usenet@gmail.com> wrote in message news:io22nf$fm4$1@dont-email.me... >* Noah Roberts, on 12.04.2011 18:37: >> On 4/11/2011 7:00 PM, Alf P. Steinbach /Usenet wrote: > [snip] >> >>> The second way in which a pointer can point to an array, is the answer >>> to question 3, namely >>> >>> int a[42]; >>> int* p2 = a; // OK, p2 is a pointer to an array (dynamically). >>> >> >> No. > > That's silly (see below). > > >> The p2 variable is a pointer to int because an int is what you get when >> you >> dereference it. > > Yes. > Wrong there is an exception in rhe C++ standards for pointers to arrays. See the section on Arrays. When dereferenced, a pointer to an array does not yield what it points to but a (n-1) dimensional array.
[toc] | [prev] | [next] | [standalone]
| From | Joshua Maurice <joshuamaurice@gmail.com> |
|---|---|
| Date | 2011-04-12 09:36 -0700 |
| Message-ID | <e97f4f8a-b839-4c2c-8705-a8d71b70325a@e9g2000vbk.googlegroups.com> |
| In reply to | #3440 |
On Apr 11, 7:00 pm, "Alf P. Steinbach /Usenet" <alf.p.steinbach +use...@gmail.com> wrote: > Since my killfile works I only see one side of the numerous debates here about > pointers and arrays. > > But it does seem to be pretty confrontational. > > So, herewith, me on the subject of how to talk about pointers & arrays. > > When I wrote my (peer reviewed) pointers tutorial I discovered that even the > acknowledged international experts did not agree on the meaning of "pointer". > Happily the disagreements were mainly of the single kind exemplified by > > Hey, you can't call THAT a pointer (because I don't)! > > Some objected to calling variables pointers, others objected to calling pointer > values pointers, and yet others objected to calling pointer types pointers, even > though the Holy Standard does. In case the latter is difficult to grok: I'm > talking about utterances like "it's a pointer" and "it's a car", instead of > spelling it out more literally like "it's a something of pointer type" and "it's > an object that conforms to the requirements of the 'car' type of vehicle". I > never understood the point of making such subtle distinctions, but apparently > some who are smarter and/or more knowledgable than me, do. And what about smart > pointers? If they are accepted as pointers, then a pointer needs not necessarily > be a pointer of the kind that the language supports directly. So what we have is > a word that becomes more vague the larger the context is. > > Happily, that means that as one narrows the context, one also narrows down the > possible meanings of "pointer". Narrowing it down to the pointers directly > supported by the C++ language, the RAW POINTERS of C++, there is almost no > ambiguity. In this very limited context the term is well-defined. > > Now, three questions that I have seen mentioned often in the debates, are > > 1) Is an array a pointer? > > 2) Can a pointer point to an array? > > 3) Can a pointer of type T* be said to point to an array of T? > > Regarding question (1), is an array a pointer?, the answer is NO. > > Some newbies think the answer is yes because lots of things are very much the > same for pointers and arrays. But the crucial thing is not how operationally > similar they are. Instead, the crucial thing is how they differ, for example > that an array can occupy an arbitrary amount of storage, while the size of a > pointer -- e.g. as reported by the sizeof operator -- is pretty small. > > Regarding question (2), can a pointer point to an array? > > Here the answer is YES, and, /in two different ways/. > > First, a pointer can point to an array in the Pascal sense, where the pointer is > of type "pointer to array" and points to some array (or else is null), like > > int a[42]; > int (*p1)[42] = &a; // OK, p1 is a pointer to array (type-wise). > > It would be wrong to omit the "42" in the pointer declaration, because p1 is > very very strictly a pointer to an array *of a given size*. You would not be > able to e.g. "++" increment the pointer if the pointee type was of some unknown > size. And although you can have pointers to incomplete types (types of unknown > size (uh, I mean, types whose instances are of unknown size (or, more > pedantically, types whose instances, if they could exist, would be of unknown > size (hm, ok, I direct you to the Holy Standard for absolute precision)))), in > this specific case the language does not permit it -- I don't know why. > > So, in the case above we have a pointer variable that points to an array, *and* > that is of type pointer to array. > > The second way in which a pointer can point to an array, is the answer to > question 3, namely > > int a[42]; > int* p2 = a; // OK, p2 is a pointer to an array (dynamically). > > In this case, however, the type of the pointer is not a pointer to array, but > pointer to ElementType. It's only the dynamic situation that right after the > above declaration, p2 points to array a. Still, this is the most common > situation (the p1 thing is extremely rare!), and it would be silly to talk about > "points, at this point in the program execution, to the first element of an > array", sort of like a lawyer, instead of just saying "points to an array". > > So, the answer to question (3) is also YES. > > Summing up: > > 1) A pointer is not an array. An array is not a pointer. They can be > differentiated in many ways (e.g. sizeof, typeid, template tricks, > not to mention formal arguments of reference type). > > 2) A pointer can, however, point to an array. > > 3) And a pointer of type T* be said to point to an array of T, but only > in the dynamic sense, like "right now it points to an array". > > 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. > > Cheers & hth., > > - Alf Sure. I fully agree. I also remember stating a lot of this a while back as well... lol.
[toc] | [prev] | [standalone]
Page 5 of 5 — ← Prev page 1 2 3 4 [5]
Back to top | Article view | comp.lang.c++
csiph-web