Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c++ > #14092 > unrolled thread
| Started by | bintom <binoythomas1108@gmail.com> |
|---|---|
| First post | 2012-02-16 06:51 -0800 |
| Last post | 2012-02-17 15:13 +0000 |
| Articles | 20 on this page of 60 — 17 participants |
Back to article view | Back to comp.lang.c++
Pointer Problem bintom <binoythomas1108@gmail.com> - 2012-02-16 06:51 -0800
Re: Pointer Problem Juha Nieminen <nospam@thanks.invalid> - 2012-02-16 15:15 +0000
Re: Pointer Problem 88888 Dihedral <dihedral88888@googlemail.com> - 2012-02-16 07:17 -0800
Re: Pointer Problem Victor Bazarov <v.bazarov@comcast.invalid> - 2012-02-16 11:15 -0500
Re: Pointer Problem scott@slp53.sl.home (Scott Lurndal) - 2012-02-16 17:18 +0000
Re: Pointer Problem Victor Bazarov <v.bazarov@comcast.invalid> - 2012-02-16 13:46 -0500
Re: Pointer Problem Mike McCarty <mcmccarty@gmail.com> - 2012-02-16 12:41 -0800
Re: Pointer Problem scott@slp53.sl.home (Scott Lurndal) - 2012-02-16 20:45 +0000
Re: Pointer Problem Nick Keighley <nick_keighley_nospam@hotmail.com> - 2012-02-17 01:44 -0800
Re: Pointer Problem jt@toerring.de (Jens Thoms Toerring) - 2012-02-17 03:14 +0000
Re: Pointer Problem Juha Nieminen <nospam@thanks.invalid> - 2012-02-17 07:23 +0000
Re: Pointer Problem jt@toerring.de (Jens Thoms Toerring) - 2012-02-18 22:39 +0000
Re: Pointer Problem Peter Remmers <p.remmers@expires-2011-04-30.arcornews.de> - 2012-02-20 21:07 +0100
Re: Pointer Problem Paul <pchristor@yahoo.co.uk> - 2012-02-21 18:49 -0800
Re: Pointer Problem Paul <pchristor@yahoo.co.uk> - 2012-02-21 18:49 -0800
Re: Pointer Problem Juha Nieminen <nospam@thanks.invalid> - 2012-02-22 10:15 +0000
Re: Pointer Problem Paul <pchristor@yahoo.co.uk> - 2012-02-22 07:49 -0800
Re: Pointer Problem Leigh Johnston <leigh@i42.co.uk> - 2012-02-22 20:24 +0000
Re: Pointer Problem Juha Nieminen <nospam@thanks.invalid> - 2012-02-23 10:36 +0000
Re: Pointer Problem "Paul" <pchrist<nospam>or@yahoo.co.uk> - 2012-02-23 18:59 +0000
Re: Pointer Problem Leigh Johnston <leigh@i42.co.uk> - 2012-02-23 19:15 +0000
Re: Pointer Problem "Paul" <pchrist<nospam>or@yahoo.co.uk> - 2012-02-23 21:08 +0000
Re: Pointer Problem Leigh Johnston <leigh@i42.co.uk> - 2012-02-23 21:17 +0000
Re: Pointer Problem Leigh Johnston <leigh@i42.co.uk> - 2012-02-23 21:29 +0000
Re: Pointer Problem Joshua Maurice <joshuamaurice@gmail.com> - 2012-02-23 17:06 -0800
Re: Pointer Problem Paul <pchristor@yahoo.co.uk> - 2012-02-24 03:42 -0800
Re: Pointer Problem Leigh Johnston <leigh@i42.co.uk> - 2012-02-24 12:33 +0000
Re: Pointer Problem "Paul" <pchrist<nospam>or@yahoo.co.uk> - 2012-02-24 15:09 +0000
Re: Pointer Problem Jorgen Grahn <grahn+nntp@snipabacken.se> - 2012-02-23 20:53 +0000
Re: Pointer Problem Paul <pchristor@yahoo.co.uk> - 2012-02-24 04:11 -0800
Re: Pointer Problem Leigh Johnston <leigh@i42.co.uk> - 2012-02-24 12:36 +0000
Re: Pointer Problem Paul <pchristor@yahoo.co.uk> - 2012-02-24 06:07 -0800
Re: Pointer Problem Leigh Johnston <leigh@i42.co.uk> - 2012-02-24 14:11 +0000
Re: Pointer Problem "Paul" <pchrist<nospam>or@yahoo.co.uk> - 2012-02-24 15:49 +0000
Re: Pointer Problem Mike McCarty <mcmccarty@gmail.com> - 2012-02-24 08:50 -0800
Re: Pointer Problem "Paul" <pchrist<nospam>or@yahoo.co.uk> - 2012-02-24 18:47 +0000
Re: Pointer Problem Paul <pchristor@yahoo.co.uk> - 2012-02-24 13:44 -0800
Re: Pointer Problem Paul <pchristor@yahoo.co.uk> - 2012-02-26 12:41 -0800
Re: Pointer Problem Mike McCarty <mcmccarty@gmail.com> - 2012-02-26 21:30 -0800
Re: Pointer Problem Paul <pchristor@yahoo.co.uk> - 2012-02-27 06:07 -0800
Re: Pointer Problem Mike McCarty <mcmccarty@gmail.com> - 2012-02-27 07:25 -0800
Re: Pointer Problem Paul <pchristor@yahoo.co.uk> - 2012-02-27 08:17 -0800
Re: Pointer Problem Mike McCarty <mcmccarty@gmail.com> - 2012-02-27 08:51 -0800
Re: Pointer Problem Ian Collins <ian-news@hotmail.com> - 2012-02-28 07:18 +1300
Re: Pointer Problem Paul <pchristor@yahoo.co.uk> - 2012-02-27 11:32 -0800
Re: Pointer Problem Paul <pchristor@yahoo.co.uk> - 2012-02-27 11:32 -0800
Re: Pointer Problem Leigh Johnston <leigh@i42.co.uk> - 2012-02-27 19:17 +0000
Re: Pointer Problem Paul <pchristor@yahoo.co.uk> - 2012-02-27 11:49 -0800
Re: Pointer Problem Leigh Johnston <leigh@i42.co.uk> - 2012-02-27 20:04 +0000
Re: Pointer Problem Paul <pchristor@yahoo.co.uk> - 2012-02-27 12:55 -0800
Re: Pointer Problem Leigh Johnston <leigh@i42.co.uk> - 2012-02-27 21:15 +0000
Re: Pointer Problem Paul <pchristor@yahoo.co.uk> - 2012-02-27 14:26 -0800
Re: Pointer Problem Paul <pchristor@yahoo.co.uk> - 2012-02-27 11:21 -0800
Re: Pointer Problem SG <s.gesemann@gmail.com> - 2012-02-16 07:00 -0800
Re: Pointer Problem LR <lruss@superlink.net> - 2012-02-16 16:49 -0500
Re: Pointer Problem Juha Nieminen <nospam@thanks.invalid> - 2012-02-16 22:18 +0000
Re: Pointer Problem LR <lruss@superlink.net> - 2012-02-16 23:40 -0500
Re: Pointer Problem Juha Nieminen <nospam@thanks.invalid> - 2012-02-17 07:24 +0000
Re: Pointer Problem LR <lruss@superlink.net> - 2012-02-17 09:48 -0500
Re: Pointer Problem Juha Nieminen <nospam@thanks.invalid> - 2012-02-17 15:13 +0000
Page 3 of 3 — ← Prev page 1 2 [3]
| From | Mike McCarty <mcmccarty@gmail.com> |
|---|---|
| Date | 2012-02-27 07:25 -0800 |
| Message-ID | <4787762.9.1330356342660.JavaMail.geo-discussion-forums@vbbdh9> |
| In reply to | #14542 |
On Monday, February 27, 2012 8:07:58 AM UTC-6, Paul wrote: > A 1-dim array doesn't need a multiplier. A 2-dim array doesn't need > two multipliers it only needs one. This is not "loss of information" > as you have put it, the information is not there because it's not > required. I'm not talking about multipliers, I'm talking about knowing the bounds of the underlying array. It is lost information and it is required if you want to (robustly) treat the pointer as a reference to an array of objects. How do you sensibly increment a pointer without knowing the range of values the pointer can logically take? > > An example: > > > > > An example: > > > > int a[10]; > > int (&b)[9] = a[1]; > > > > The C++ language dictates that this is illegal syntax, despite the fact that simple analysis shows that it is perfectly reasonable and logically correct. This is the sort of 'context' you've been referring to but this 'context' is exactly what the language does not support. > > No I never brought references into the discussion., References *are* pointers... If you insist: int a[10]; int (*b)[9] = &a[1]; The argument still holds... > > Given only > > > > int* iptr = something(); > > I wish you wouldn't use this default object construction syntax(or > function syntax) when assigning to pointers, because more often than > not this will not return an objects' address. An objects' address is > assigned to a pointer, not an object. I'm not sure why you'd think it was an object constructor call -- it makes more syntactic sense as a simple function call. In any case, it's pseudo-code. The RHS of the assignment is not relevant which is why I did not work very hard at making it realistic. The point being: A _naked_ pointer cannot be (usefully) treated as an array reference. > A pointer doesn't only point to an object or null because it can also > point to objects(plural). It can point to an object allocated as part of an array, yes. Beyond that, you need external information. If you want to be pedantic about it, you could say that all allocations are array allocations just that many of them are arrays of size 1. Does it change what you can do with pointers? Nope. Does it change the meaning of pointers? Nope. > If you agree with Leighs argument , and disagree with Bjarne S, then I > think you have missed the point :) I'm not sure what you think Leigh's argument is at this point. I see nothing that contradicts anything Bjarne has ever said. I still contend you are in violent agreement.
[toc] | [prev] | [next] | [standalone]
| From | Paul <pchristor@yahoo.co.uk> |
|---|---|
| Date | 2012-02-27 08:17 -0800 |
| Message-ID | <0e88f34f-5881-4783-9ad7-48d1313221e0@i2g2000vbv.googlegroups.com> |
| In reply to | #14545 |
On Feb 27, 3:25 pm, Mike McCarty <mcmcca...@gmail.com> wrote: > On Monday, February 27, 2012 8:07:58 AM UTC-6, Paul wrote: > > A 1-dim array doesn't need a multiplier. A 2-dim array doesn't need > > two multipliers it only needs one. This is not "loss of information" > > as you have put it, the information is not there because it's not > > required. > > I'm not talking about multipliers, I'm talking about knowing the bounds of the underlying array. It is lost information and it is required if you want to (robustly) treat the pointer as a reference to an array of objects. How do you sensibly increment a pointer without knowing the range of values the pointer can logically take? > > > > An example: > > > > An example: > > > > int a[10]; > > > int (&b)[9] = a[1]; > > > > The C++ language dictates that this is illegal syntax, despite the fact that simple analysis shows that it is perfectly reasonable and logically correct. This is the sort of 'context' you've been referring to but this 'context' is exactly what the language does not support. > > > No I never brought references into the discussion., > > References *are* pointers... But you have said yourself that a pointer does not carry typeinfo. You are contradicting yourself by saying that a reference is a pointer, when it suits you. > > If you insist: > int a[10]; > int (*b)[9] = &a[1]; > > The argument still holds... > > > > Given only > > > > int* iptr = something(); > > > I wish you wouldn't use this default object construction syntax(or > > function syntax) when assigning to pointers, because more often than > > not this will not return an objects' address. An objects' address is > > assigned to a pointer, not an object. > > I'm not sure why you'd think it was an object constructor call -- it makes more syntactic sense as a simple function call. In any case, it's pseudo-code. The RHS of the assignment is not relevant which is why I did not work very hard at making it realistic. The point being: A _naked_ pointer cannot be (usefully) treated as an array reference. > > > A pointer doesn't only point to an object or null because it can also > > point to objects(plural). > > It can point to an object allocated as part of an array, yes. No , it can point to objects(plural) , that is what I said objectS (plural) , not a single object that is part of something. > Beyond that, you need external information. If you want to be pedantic about it, you could say that all allocations are array allocations just that many of them are arrays of size 1. Does it change what you can do with >pointers? Nope. Does it change the meaning of pointers? Nope. You don't always need information, its a well known fact that in C and C++ a pointer to an array does not carry size information. All allocations aren't arrays , because an array is a sequence of elements. Yes an array of size 1 is the same as a single object but then that's not really an array is it, its just a single object. And please don't bring arrays of size 0 into the discussion.. > > > If you agree with Leighs argument , and disagree with Bjarne S, then I > > think you have missed the point :) > > I'm not sure what you think Leigh's argument is at this point. I see nothing that contradicts anything Bjarne has ever said. I still contend you are in violent agreement. Leighs argument is that an int* can only point to a single int and cannot point to an array of ints. This contradicts what Bjarne says in his C++ glossary re: "char* - pointer to a char or an array of char" source: http://www2.research.att.com/~bs/glossary.html. This is why I am objecting to Juha and Leighs argument because they are confusing the pointers-type with what is pointed-to. The two are different contexts of "is a pointer -to" and not always related. If we have an object in memory that is an array, of any size: A pointer to it is a pointer to an array regardless of its's type, or to where it points within the array. They are incorrect to suggest that what is pointed to is defined by the pointers type, just look at a void pointer for an example of how wrong this is.
[toc] | [prev] | [next] | [standalone]
| From | Mike McCarty <mcmccarty@gmail.com> |
|---|---|
| Date | 2012-02-27 08:51 -0800 |
| Message-ID | <32554264.1181.1330361513198.JavaMail.geo-discussion-forums@ynil17> |
| In reply to | #14549 |
On Monday, February 27, 2012 10:17:36 AM UTC-6, Paul wrote: > > References *are* pointers... > > But you have said yourself that a pointer does not carry typeinfo. You > are contradicting yourself by saying that a reference is a pointer, > when it suits you. What??? A reference is a (immutable) pointer with a dose of syntactic sugar. Nothing more, nothing less. This does not contradict anything I've said by evidence of the rewritten example I followed up with: > > > > If you insist: > > int a[10]; > > int (*b)[9] = &a[1]; > > > > The argument still holds... I changed two characters, now it's a pointer instead of a reference, with exactly the same results. You seem to blithely ignore anything that you can't refute. > If we have an object in memory that is an array, of any size: A > pointer to it is a pointer to an array regardless of its's type, or to > where it points within the array. They are incorrect to suggest that > what is pointed to is defined by the pointers type, just look at a > void pointer for an example of how wrong this is. Well, here is where I get off the bus. If you have a point at all, you have been unable to sufficiently explain it to anybody and you certainly have not explained why it might be an important point for others to grasp. I would say we'll just agree to disagree but I'm not convinced there's actually a disagreement here, despite your protests. Good luck. Mike
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2012-02-28 07:18 +1300 |
| Message-ID | <9r1vnmF3nfU6@mid.individual.net> |
| In reply to | #14550 |
On 02/28/12 05:51 AM, Mike McCarty wrote: > > On Monday, February 27, 2012 10:17:36 AM UTC-6, Paul wrote: > > You seem to blithely ignore anything that you can't refute. Got it in one! -- Ian Collins
[toc] | [prev] | [next] | [standalone]
| From | Paul <pchristor@yahoo.co.uk> |
|---|---|
| Date | 2012-02-27 11:32 -0800 |
| Message-ID | <65098a52-ef98-4d66-b0ba-ee2b48014907@db5g2000vbb.googlegroups.com> |
| In reply to | #14555 |
On Feb 27, 6:18 pm, Ian Collins <ian-n...@hotmail.com> wrote: > On 02/28/12 05:51 AM, Mike McCarty wrote: > > > > > On Monday, February 27, 2012 10:17:36 AM UTC-6, Paul wrote: > > > You seem to blithely ignore anything that you can't refute. > > Got it in one! > > -- > Ian Collins *slap* Shush Ian.
[toc] | [prev] | [next] | [standalone]
| From | Paul <pchristor@yahoo.co.uk> |
|---|---|
| Date | 2012-02-27 11:32 -0800 |
| Message-ID | <4771752c-edbc-42fe-bc58-d7112c015bc5@w19g2000vbe.googlegroups.com> |
| In reply to | #14550 |
On Feb 27, 4:51 pm, Mike McCarty <mcmcca...@gmail.com> wrote: > On Monday, February 27, 2012 10:17:36 AM UTC-6, Paul wrote: > > > References *are* pointers... > > > But you have said yourself that a pointer does not carry typeinfo. You > > are contradicting yourself by saying that a reference is a pointer, > > when it suits you. > > What??? A reference is a (immutable) pointer with a dose of syntactic sugar. Nothing more, nothing less. This does not contradict anything I've said by evidence of the rewritten example I followed up with: > > > > > > If you insist: > > > int a[10]; > > > int (*b)[9] = &a[1]; > > > > The argument still holds... > > I changed two characters, now it's a pointer instead of a reference, with exactly the same results. You seem to blithely ignore anything that you can't refute. > > > If we have an object in memory that is an array, of any size: A > > pointer to it is a pointer to an array regardless of its's type, or to > > where it points within the array. They are incorrect to suggest that > > what is pointed to is defined by the pointers type, just look at a > > void pointer for an example of how wrong this is. > > Well, here is where I get off the bus. > > If you have a point at all, you have been unable to sufficiently explain it to anybody and you certainly have not explained why it might be an important point for others to grasp. > > I would say we'll just agree to disagree but I'm not convinced there's actually a disagreement here, despite your protests. > > Good luck. > > Mike I don't see what your point is you seem to be going of on a new tangent about pointers and references. I don't even know what your argument is , you seem to agree with Leigh and Juha when they state that an int* cannot point to an array of ints. My position is crystal clear and I have no qualms about disagreeing with them on this because I know that in C++ the int* is the correct type of pointer to point to a 1-dim array of ints. The situation is not that a pointers-type defines what is pointed-to as they describe as the only correct way.
[toc] | [prev] | [next] | [standalone]
| From | Leigh Johnston <leigh@i42.co.uk> |
|---|---|
| Date | 2012-02-27 19:17 +0000 |
| Message-ID | <55ednfOIZZBXS9bSnZ2dnUVZ8kqdnZ2d@giganews.com> |
| In reply to | #14549 |
On 27/02/2012 16:17, Paul wrote: > On Feb 27, 3:25 pm, Mike McCarty<mcmcca...@gmail.com> wrote: >> On Monday, February 27, 2012 8:07:58 AM UTC-6, Paul wrote: >>> A 1-dim array doesn't need a multiplier. A 2-dim array doesn't need >>> two multipliers it only needs one. This is not "loss of information" >>> as you have put it, the information is not there because it's not >>> required. >> >> I'm not talking about multipliers, I'm talking about knowing the bounds of the underlying array. It is lost information and it is required if you want to (robustly) treat the pointer as a reference to an array of objects. How do you sensibly increment a pointer without knowing the range of values the pointer can logically take? >> >>>> An example: >> >>>> An example: >> >>>> int a[10]; >>>> int (&b)[9] = a[1]; >> >>>> The C++ language dictates that this is illegal syntax, despite the fact that simple analysis shows that it is perfectly reasonable and logically correct. This is the sort of 'context' you've been referring to but this 'context' is exactly what the language does not support. >> >>> No I never brought references into the discussion., >> >> References *are* pointers... > > > But you have said yourself that a pointer does not carry typeinfo. You > are contradicting yourself by saying that a reference is a pointer, > when it suits you. >> >> If you insist: >> int a[10]; >> int (*b)[9] =&a[1]; >> >> The argument still holds... >> >>>> Given only >> >>>> int* iptr = something(); >> >>> I wish you wouldn't use this default object construction syntax(or >>> function syntax) when assigning to pointers, because more often than >>> not this will not return an objects' address. An objects' address is >>> assigned to a pointer, not an object. >> >> I'm not sure why you'd think it was an object constructor call -- it makes more syntactic sense as a simple function call. In any case, it's pseudo-code. The RHS of the assignment is not relevant which is why I did not work very hard at making it realistic. The point being: A _naked_ pointer cannot be (usefully) treated as an array reference. > > >> >>> A pointer doesn't only point to an object or null because it can also >>> point to objects(plural). >> >> It can point to an object allocated as part of an array, yes. > > No , it can point to objects(plural) , that is what I said objectS > (plural) , not a single object that is part of something. > >> Beyond that, you need external information. If you want to be pedantic about it, you could say that all allocations are array allocations just that many of them are arrays of size 1. Does it change what you can do with>pointers? Nope. Does it change the meaning of pointers? Nope. > > You don't always need information, its a well known fact that in C and > C++ a pointer to an array does not carry size information. > All allocations aren't arrays , because an array is a sequence of > elements. Yes an array of size 1 is the same as a single object but > then that's not really an array is it, its just a single object. And > please don't bring arrays of size 0 into the discussion.. >> >>> If you agree with Leighs argument , and disagree with Bjarne S, then I >>> think you have missed the point :) >> >> I'm not sure what you think Leigh's argument is at this point. I see nothing that contradicts anything Bjarne has ever said. I still contend you are in violent agreement. > > Leighs argument is that an int* can only point to a single int and > cannot point to an array of ints. This contradicts what Bjarne says in > his C++ glossary re: "char* - pointer to a char or an array of char" > source: http://www2.research.att.com/~bs/glossary.html. > > This is why I am objecting to Juha and Leighs argument because they > are confusing the pointers-type with what is pointed-to. The two are > different contexts of "is a pointer -to" and not always related. > > > If we have an object in memory that is an array, of any size: A > pointer to it is a pointer to an array regardless of its's type, or to > where it points within the array. They are incorrect to suggest that > what is pointed to is defined by the pointers type, just look at a > void pointer for an example of how wrong this is. Your void pointer argument is a straw man. It is really quite simple if you think in terms of objects: a void* pointer can point to an object of any type or nothing at all; an int* pointer can point to an object of type int or nothing at all. If an int* pointer points to an object of type int which is part of an array it is incidental that it is part of an array: it still points to the array element not the array. When talking about C++ types and objects are probably the most important things to consider. /Leigh
[toc] | [prev] | [next] | [standalone]
| From | Paul <pchristor@yahoo.co.uk> |
|---|---|
| Date | 2012-02-27 11:49 -0800 |
| Message-ID | <0ad57362-626a-4a9a-a6f2-849a6311419c@db5g2000vbb.googlegroups.com> |
| In reply to | #14557 |
On Feb 27, 7:17 pm, Leigh Johnston <le...@i42.co.uk> wrote: > On 27/02/2012 16:17, Paul wrote: > > > > > > > > > > > On Feb 27, 3:25 pm, Mike McCarty<mcmcca...@gmail.com> wrote: > >> On Monday, February 27, 2012 8:07:58 AM UTC-6, Paul wrote: > >>> A 1-dim array doesn't need a multiplier. A 2-dim array doesn't need > >>> two multipliers it only needs one. This is not "loss of information" > >>> as you have put it, the information is not there because it's not > >>> required. > > >> I'm not talking about multipliers, I'm talking about knowing the bounds of the underlying array. It is lost information and it is required if you want to (robustly) treat the pointer as a reference to an array of objects. How do you sensibly increment a pointer without knowing the range of values the pointer can logically take? > > >>>> An example: > > >>>> An example: > > >>>> int a[10]; > >>>> int (&b)[9] = a[1]; > > >>>> The C++ language dictates that this is illegal syntax, despite the fact that simple analysis shows that it is perfectly reasonable and logically correct. This is the sort of 'context' you've been referring to but this 'context' is exactly what the language does not support. > > >>> No I never brought references into the discussion., > > >> References *are* pointers... > > > But you have said yourself that a pointer does not carry typeinfo. You > > are contradicting yourself by saying that a reference is a pointer, > > when it suits you. > > >> If you insist: > >> int a[10]; > >> int (*b)[9] =&a[1]; > > >> The argument still holds... > > >>>> Given only > > >>>> int* iptr = something(); > > >>> I wish you wouldn't use this default object construction syntax(or > >>> function syntax) when assigning to pointers, because more often than > >>> not this will not return an objects' address. An objects' address is > >>> assigned to a pointer, not an object. > > >> I'm not sure why you'd think it was an object constructor call -- it makes more syntactic sense as a simple function call. In any case, it's pseudo-code. The RHS of the assignment is not relevant which is why I did not work very hard at making it realistic. The point being: A _naked_ pointer cannot be (usefully) treated as an array reference. > > >>> A pointer doesn't only point to an object or null because it can also > >>> point to objects(plural). > > >> It can point to an object allocated as part of an array, yes. > > > No , it can point to objects(plural) , that is what I said objectS > > (plural) , not a single object that is part of something. > > >> Beyond that, you need external information. If you want to be pedantic about it, you could say that all allocations are array allocations just that many of them are arrays of size 1. Does it change what you can do with>pointers? Nope. Does it change the meaning of pointers? Nope. > > > You don't always need information, its a well known fact that in C and > > C++ a pointer to an array does not carry size information. > > All allocations aren't arrays , because an array is a sequence of > > elements. Yes an array of size 1 is the same as a single object but > > then that's not really an array is it, its just a single object. And > > please don't bring arrays of size 0 into the discussion.. > > >>> If you agree with Leighs argument , and disagree with Bjarne S, then I > >>> think you have missed the point :) > > >> I'm not sure what you think Leigh's argument is at this point. I see nothing that contradicts anything Bjarne has ever said. I still contend you are in violent agreement. > > > Leighs argument is that an int* can only point to a single int and > > cannot point to an array of ints. This contradicts what Bjarne says in > > his C++ glossary re: "char* - pointer to a char or an array of char" > > source:http://www2.research.att.com/~bs/glossary.html. > > > This is why I am objecting to Juha and Leighs argument because they > > are confusing the pointers-type with what is pointed-to. The two are > > different contexts of "is a pointer -to" and not always related. > > > If we have an object in memory that is an array, of any size: A > > pointer to it is a pointer to an array regardless of its's type, or to > > where it points within the array. They are incorrect to suggest that > > what is pointed to is defined by the pointers type, just look at a > > void pointer for an example of how wrong this is. > > Your void pointer argument is a straw man. It is really quite simple if > you think in terms of objects: a void* pointer can point to an object of > any type or nothing at all; an int* pointer can point to an object of > type int or nothing at all. Nope, a pointer can point to an object, objects or nothing. > > If an int* pointer points to an object of type int which is part of an > array it is incidental that it is part of an array: it still points to > the array element not the array. This is plain narrow mindedness. The way to understand it is that the int* points to int objects(plural). > > When talking about C++ types and objects are probably the most important > things to consider. > The type of objects pointed to are int type objects, thus it's common sense that you'd use an int* to point to them. Why would you use a pointer of type(*)[10] to point to a 1-dim array of 10 ints? The extra [10] on this pointer type does nothing to affect the pointed-to array, it only affects the way its incremented and indexed. The main thing about this pointer type is that it has another level of indirection. You cannot index it without an addition dereference. You cannot increment it with first dereferencing it. It has an extra level of indirection that is completely unnecessary.
[toc] | [prev] | [next] | [standalone]
| From | Leigh Johnston <leigh@i42.co.uk> |
|---|---|
| Date | 2012-02-27 20:04 +0000 |
| Message-ID | <dt-dnVZiPtIgfNbSnZ2dnUVZ8n6dnZ2d@giganews.com> |
| In reply to | #14562 |
On 27/02/2012 19:49, Paul wrote: > On Feb 27, 7:17 pm, Leigh Johnston<le...@i42.co.uk> wrote: >> On 27/02/2012 16:17, Paul wrote: >> >> >> >> >> >> >> >> >> >>> On Feb 27, 3:25 pm, Mike McCarty<mcmcca...@gmail.com> wrote: >>>> On Monday, February 27, 2012 8:07:58 AM UTC-6, Paul wrote: >>>>> A 1-dim array doesn't need a multiplier. A 2-dim array doesn't need >>>>> two multipliers it only needs one. This is not "loss of information" >>>>> as you have put it, the information is not there because it's not >>>>> required. >> >>>> I'm not talking about multipliers, I'm talking about knowing the bounds of the underlying array. It is lost information and it is required if you want to (robustly) treat the pointer as a reference to an array of objects. How do you sensibly increment a pointer without knowing the range of values the pointer can logically take? >> >>>>>> An example: >> >>>>>> An example: >> >>>>>> int a[10]; >>>>>> int (&b)[9] = a[1]; >> >>>>>> The C++ language dictates that this is illegal syntax, despite the fact that simple analysis shows that it is perfectly reasonable and logically correct. This is the sort of 'context' you've been referring to but this 'context' is exactly what the language does not support. >> >>>>> No I never brought references into the discussion., >> >>>> References *are* pointers... >> >>> But you have said yourself that a pointer does not carry typeinfo. You >>> are contradicting yourself by saying that a reference is a pointer, >>> when it suits you. >> >>>> If you insist: >>>> int a[10]; >>>> int (*b)[9] =&a[1]; >> >>>> The argument still holds... >> >>>>>> Given only >> >>>>>> int* iptr = something(); >> >>>>> I wish you wouldn't use this default object construction syntax(or >>>>> function syntax) when assigning to pointers, because more often than >>>>> not this will not return an objects' address. An objects' address is >>>>> assigned to a pointer, not an object. >> >>>> I'm not sure why you'd think it was an object constructor call -- it makes more syntactic sense as a simple function call. In any case, it's pseudo-code. The RHS of the assignment is not relevant which is why I did not work very hard at making it realistic. The point being: A _naked_ pointer cannot be (usefully) treated as an array reference. >> >>>>> A pointer doesn't only point to an object or null because it can also >>>>> point to objects(plural). >> >>>> It can point to an object allocated as part of an array, yes. >> >>> No , it can point to objects(plural) , that is what I said objectS >>> (plural) , not a single object that is part of something. >> >>>> Beyond that, you need external information. If you want to be pedantic about it, you could say that all allocations are array allocations just that many of them are arrays of size 1. Does it change what you can do with>pointers? Nope. Does it change the meaning of pointers? Nope. >> >>> You don't always need information, its a well known fact that in C and >>> C++ a pointer to an array does not carry size information. >>> All allocations aren't arrays , because an array is a sequence of >>> elements. Yes an array of size 1 is the same as a single object but >>> then that's not really an array is it, its just a single object. And >>> please don't bring arrays of size 0 into the discussion.. >> >>>>> If you agree with Leighs argument , and disagree with Bjarne S, then I >>>>> think you have missed the point :) >> >>>> I'm not sure what you think Leigh's argument is at this point. I see nothing that contradicts anything Bjarne has ever said. I still contend you are in violent agreement. >> >>> Leighs argument is that an int* can only point to a single int and >>> cannot point to an array of ints. This contradicts what Bjarne says in >>> his C++ glossary re: "char* - pointer to a char or an array of char" >>> source:http://www2.research.att.com/~bs/glossary.html. >> >>> This is why I am objecting to Juha and Leighs argument because they >>> are confusing the pointers-type with what is pointed-to. The two are >>> different contexts of "is a pointer -to" and not always related. >> >>> If we have an object in memory that is an array, of any size: A >>> pointer to it is a pointer to an array regardless of its's type, or to >>> where it points within the array. They are incorrect to suggest that >>> what is pointed to is defined by the pointers type, just look at a >>> void pointer for an example of how wrong this is. >> >> Your void pointer argument is a straw man. It is really quite simple if >> you think in terms of objects: a void* pointer can point to an object of >> any type or nothing at all; an int* pointer can point to an object of >> type int or nothing at all. > > Nope, a pointer can point to an object, objects or nothing. > >> >> If an int* pointer points to an object of type int which is part of an >> array it is incidental that it is part of an array: it still points to >> the array element not the array. > > This is plain narrow mindedness. > The way to understand it is that the int* points to int > objects(plural). Wrong; a pointer can only ever point to one object at a time. If a int* pointer pointed to the middle element of an array you couldn't pass this pointer to delete[] to delete the array (you can only pass a pointer to the initial element of an array to delete[]) so it is wrong to say that this pointer points to an array and it is correct to say that this pointer points to an array element. > >> >> When talking about C++ types and objects are probably the most important >> things to consider. >> > The type of objects pointed to are int type objects, thus it's common > sense that you'd use an int* to point to them. Except an int* pointer can only point to one int object at a time. > > Why would you use a pointer of type(*)[10] to point to a 1-dim array > of 10 ints? The extra [10] on this pointer type does nothing to affect > the pointed-to array, it only affects the way its incremented and > indexed. The main thing about this pointer type is that it has another > level of indirection. You cannot index it without an addition > dereference. You cannot increment it with first dereferencing it. It > has an extra level of indirection that is completely unnecessary. You use the appropriate type for the job at hand. You can invoke array-to-pointer conversion to obtain a pointer to the first element of an array so talking about levels of indirection is mostly a smoke screen of your own making. /Leigh
[toc] | [prev] | [next] | [standalone]
| From | Paul <pchristor@yahoo.co.uk> |
|---|---|
| Date | 2012-02-27 12:55 -0800 |
| Message-ID | <67e9727a-7bd9-439d-8f54-0ce98e35d539@s7g2000vby.googlegroups.com> |
| In reply to | #14563 |
On Feb 27, 8:04 pm, Leigh Johnston <le...@i42.co.uk> wrote: > On 27/02/2012 19:49, Paul wrote: > > > > > > > > > > > On Feb 27, 7:17 pm, Leigh Johnston<le...@i42.co.uk> wrote: > >> On 27/02/2012 16:17, Paul wrote: > > >>> On Feb 27, 3:25 pm, Mike McCarty<mcmcca...@gmail.com> wrote: > >>>> On Monday, February 27, 2012 8:07:58 AM UTC-6, Paul wrote: > >>>>> A 1-dim array doesn't need a multiplier. A 2-dim array doesn't need > >>>>> two multipliers it only needs one. This is not "loss of information" > >>>>> as you have put it, the information is not there because it's not > >>>>> required. > > >>>> I'm not talking about multipliers, I'm talking about knowing the bounds of the underlying array. It is lost information and it is required if you want to (robustly) treat the pointer as a reference to an array of objects. How do you sensibly increment a pointer without knowing the range of values the pointer can logically take? > > >>>>>> An example: > > >>>>>> An example: > > >>>>>> int a[10]; > >>>>>> int (&b)[9] = a[1]; > > >>>>>> The C++ language dictates that this is illegal syntax, despite the fact that simple analysis shows that it is perfectly reasonable and logically correct. This is the sort of 'context' you've been referring to but this 'context' is exactly what the language does not support. > > >>>>> No I never brought references into the discussion., > > >>>> References *are* pointers... > > >>> But you have said yourself that a pointer does not carry typeinfo. You > >>> are contradicting yourself by saying that a reference is a pointer, > >>> when it suits you. > > >>>> If you insist: > >>>> int a[10]; > >>>> int (*b)[9] =&a[1]; > > >>>> The argument still holds... > > >>>>>> Given only > > >>>>>> int* iptr = something(); > > >>>>> I wish you wouldn't use this default object construction syntax(or > >>>>> function syntax) when assigning to pointers, because more often than > >>>>> not this will not return an objects' address. An objects' address is > >>>>> assigned to a pointer, not an object. > > >>>> I'm not sure why you'd think it was an object constructor call -- it makes more syntactic sense as a simple function call. In any case, it's pseudo-code. The RHS of the assignment is not relevant which is why I did not work very hard at making it realistic. The point being: A _naked_ pointer cannot be (usefully) treated as an array reference. > > >>>>> A pointer doesn't only point to an object or null because it can also > >>>>> point to objects(plural). > > >>>> It can point to an object allocated as part of an array, yes. > > >>> No , it can point to objects(plural) , that is what I said objectS > >>> (plural) , not a single object that is part of something. > > >>>> Beyond that, you need external information. If you want to be pedantic about it, you could say that all allocations are array allocations just that many of them are arrays of size 1. Does it change what you can do with>pointers? Nope. Does it change the meaning of pointers? Nope. > > >>> You don't always need information, its a well known fact that in C and > >>> C++ a pointer to an array does not carry size information. > >>> All allocations aren't arrays , because an array is a sequence of > >>> elements. Yes an array of size 1 is the same as a single object but > >>> then that's not really an array is it, its just a single object. And > >>> please don't bring arrays of size 0 into the discussion.. > > >>>>> If you agree with Leighs argument , and disagree with Bjarne S, then I > >>>>> think you have missed the point :) > > >>>> I'm not sure what you think Leigh's argument is at this point. I see nothing that contradicts anything Bjarne has ever said. I still contend you are in violent agreement. > > >>> Leighs argument is that an int* can only point to a single int and > >>> cannot point to an array of ints. This contradicts what Bjarne says in > >>> his C++ glossary re: "char* - pointer to a char or an array of char" > >>> source:http://www2.research.att.com/~bs/glossary.html. > > >>> This is why I am objecting to Juha and Leighs argument because they > >>> are confusing the pointers-type with what is pointed-to. The two are > >>> different contexts of "is a pointer -to" and not always related. > > >>> If we have an object in memory that is an array, of any size: A > >>> pointer to it is a pointer to an array regardless of its's type, or to > >>> where it points within the array. They are incorrect to suggest that > >>> what is pointed to is defined by the pointers type, just look at a > >>> void pointer for an example of how wrong this is. > > >> Your void pointer argument is a straw man. It is really quite simple if > >> you think in terms of objects: a void* pointer can point to an object of > >> any type or nothing at all; an int* pointer can point to an object of > >> type int or nothing at all. > > > Nope, a pointer can point to an object, objects or nothing. > > >> If an int* pointer points to an object of type int which is part of an > >> array it is incidental that it is part of an array: it still points to > >> the array element not the array. > > > This is plain narrow mindedness. > > The way to understand it is that the int* points to int > > objects(plural). > > Wrong; a pointer can only ever point to one object at a time. If a int* > pointer pointed to the middle element of an array you couldn't pass this > pointer to delete[] to delete the array (you can only pass a pointer to > the initial element of an array to delete[]) so it is wrong to say that > this pointer points to an array and it is correct to say that this > pointer points to an array element. > No this is where you are wrong. A pointer can point to one past the end of an array and thus it points to no individual objects. Delete requires a pointer that have the same value returned from the matching allocation by new. The allocation of a dynamic array returns a pointer to an array of objects, which also happens to be a pointer to the initial element. Saying that it's a pointer to the initial element but not a pointer to the array is complete nonsense. > > > >> When talking about C++ types and objects are probably the most important > >> things to consider. > > > The type of objects pointed to are int type objects, thus it's common > > sense that you'd use an int* to point to them. > > Except an int* pointer can only point to one int object at a time. > No this is rubbish an int* can point to an array of int objects. > > > > Why would you use a pointer of type(*)[10] to point to a 1-dim array > > of 10 ints? The extra [10] on this pointer type does nothing to affect > > the pointed-to array, it only affects the way its incremented and > > indexed. The main thing about this pointer type is that it has another > > level of indirection. You cannot index it without an addition > > dereference. You cannot increment it with first dereferencing it. It > > has an extra level of indirection that is completely unnecessary. > > You use the appropriate type for the job at hand. You can invoke > array-to-pointer conversion to obtain a pointer to the first element of > an array so talking about levels of indirection is mostly a smoke screen > of your own making. > It's not a smoke screen its a fact that the following pointers to arrays all increase in levels of indirection: int* int(*)[S] int(*)[S1][S2] int(*)[S1][S2][S3] All the above pointers can point to arrays of integer objects. The difference is in their level of indirection, which defines the number of dimensions in the pointed-to array. With the simple example of: int arr[10]; int* p1 = arr; int(*p2)[10] =&arr; If we dereference p1 we access the array because it is the directly pointed-to object: *p1 = 66; And we can increment the array to access the next element: p1++; *p1 = 77; With p2 we need to dereference twice to access the array: **p2 = 66; Incrementing this requires more dereferencing: *((*p2)+1)= 77; Another way to access the array is to use 2-dim array notation: p2[0][1] = 77; Thus it makes sense that p1 is more suitable as a pointer to a 1-dim array and p2 more suitable as a pointer to a 2-dim array. Both pointers are objects that hold exactly the same memory address, to suggest that they point to different objects is complete nonsense.
[toc] | [prev] | [next] | [standalone]
| From | Leigh Johnston <leigh@i42.co.uk> |
|---|---|
| Date | 2012-02-27 21:15 +0000 |
| Message-ID | <oumdnT445r7jb9bSnZ2dnUVZ8lydnZ2d@giganews.com> |
| In reply to | #14565 |
On 27/02/2012 20:55, Paul wrote: > On Feb 27, 8:04 pm, Leigh Johnston<le...@i42.co.uk> wrote: >> On 27/02/2012 19:49, Paul wrote: >> >> >> >> >> >> >> >> >> >>> On Feb 27, 7:17 pm, Leigh Johnston<le...@i42.co.uk> wrote: >>>> On 27/02/2012 16:17, Paul wrote: >> >>>>> On Feb 27, 3:25 pm, Mike McCarty<mcmcca...@gmail.com> wrote: >>>>>> On Monday, February 27, 2012 8:07:58 AM UTC-6, Paul wrote: >>>>>>> A 1-dim array doesn't need a multiplier. A 2-dim array doesn't need >>>>>>> two multipliers it only needs one. This is not "loss of information" >>>>>>> as you have put it, the information is not there because it's not >>>>>>> required. >> >>>>>> I'm not talking about multipliers, I'm talking about knowing the bounds of the underlying array. It is lost information and it is required if you want to (robustly) treat the pointer as a reference to an array of objects. How do you sensibly increment a pointer without knowing the range of values the pointer can logically take? >> >>>>>>>> An example: >> >>>>>>>> An example: >> >>>>>>>> int a[10]; >>>>>>>> int (&b)[9] = a[1]; >> >>>>>>>> The C++ language dictates that this is illegal syntax, despite the fact that simple analysis shows that it is perfectly reasonable and logically correct. This is the sort of 'context' you've been referring to but this 'context' is exactly what the language does not support. >> >>>>>>> No I never brought references into the discussion., >> >>>>>> References *are* pointers... >> >>>>> But you have said yourself that a pointer does not carry typeinfo. You >>>>> are contradicting yourself by saying that a reference is a pointer, >>>>> when it suits you. >> >>>>>> If you insist: >>>>>> int a[10]; >>>>>> int (*b)[9] =&a[1]; >> >>>>>> The argument still holds... >> >>>>>>>> Given only >> >>>>>>>> int* iptr = something(); >> >>>>>>> I wish you wouldn't use this default object construction syntax(or >>>>>>> function syntax) when assigning to pointers, because more often than >>>>>>> not this will not return an objects' address. An objects' address is >>>>>>> assigned to a pointer, not an object. >> >>>>>> I'm not sure why you'd think it was an object constructor call -- it makes more syntactic sense as a simple function call. In any case, it's pseudo-code. The RHS of the assignment is not relevant which is why I did not work very hard at making it realistic. The point being: A _naked_ pointer cannot be (usefully) treated as an array reference. >> >>>>>>> A pointer doesn't only point to an object or null because it can also >>>>>>> point to objects(plural). >> >>>>>> It can point to an object allocated as part of an array, yes. >> >>>>> No , it can point to objects(plural) , that is what I said objectS >>>>> (plural) , not a single object that is part of something. >> >>>>>> Beyond that, you need external information. If you want to be pedantic about it, you could say that all allocations are array allocations just that many of them are arrays of size 1. Does it change what you can do with>pointers? Nope. Does it change the meaning of pointers? Nope. >> >>>>> You don't always need information, its a well known fact that in C and >>>>> C++ a pointer to an array does not carry size information. >>>>> All allocations aren't arrays , because an array is a sequence of >>>>> elements. Yes an array of size 1 is the same as a single object but >>>>> then that's not really an array is it, its just a single object. And >>>>> please don't bring arrays of size 0 into the discussion.. >> >>>>>>> If you agree with Leighs argument , and disagree with Bjarne S, then I >>>>>>> think you have missed the point :) >> >>>>>> I'm not sure what you think Leigh's argument is at this point. I see nothing that contradicts anything Bjarne has ever said. I still contend you are in violent agreement. >> >>>>> Leighs argument is that an int* can only point to a single int and >>>>> cannot point to an array of ints. This contradicts what Bjarne says in >>>>> his C++ glossary re: "char* - pointer to a char or an array of char" >>>>> source:http://www2.research.att.com/~bs/glossary.html. >> >>>>> This is why I am objecting to Juha and Leighs argument because they >>>>> are confusing the pointers-type with what is pointed-to. The two are >>>>> different contexts of "is a pointer -to" and not always related. >> >>>>> If we have an object in memory that is an array, of any size: A >>>>> pointer to it is a pointer to an array regardless of its's type, or to >>>>> where it points within the array. They are incorrect to suggest that >>>>> what is pointed to is defined by the pointers type, just look at a >>>>> void pointer for an example of how wrong this is. >> >>>> Your void pointer argument is a straw man. It is really quite simple if >>>> you think in terms of objects: a void* pointer can point to an object of >>>> any type or nothing at all; an int* pointer can point to an object of >>>> type int or nothing at all. >> >>> Nope, a pointer can point to an object, objects or nothing. >> >>>> If an int* pointer points to an object of type int which is part of an >>>> array it is incidental that it is part of an array: it still points to >>>> the array element not the array. >> >>> This is plain narrow mindedness. >>> The way to understand it is that the int* points to int >>> objects(plural). >> >> Wrong; a pointer can only ever point to one object at a time. If a int* >> pointer pointed to the middle element of an array you couldn't pass this >> pointer to delete[] to delete the array (you can only pass a pointer to >> the initial element of an array to delete[]) so it is wrong to say that >> this pointer points to an array and it is correct to say that this >> pointer points to an array element. >> > No this is where you are wrong. A pointer can point to one past the > end of an array and thus it points to no individual objects. Yes a pointer can point to one past the end of an array and this does not contradict what I have said. > > Delete requires a pointer that have the same value returned from the > matching allocation by new. The allocation of a dynamic array returns > a pointer to an array of objects, which also happens to be a pointer > to the initial element. Saying that it's a pointer to the initial > element but not a pointer to the array is complete nonsense. The only time it is conceivably safe to say that a pointer points to an array is when that pointer does indeed point to the first element; if it points to any other part of an array (or one past the end) it is simply confusing to say that it points to an array. > >> >> >>>> When talking about C++ types and objects are probably the most important >>>> things to consider. >> >>> The type of objects pointed to are int type objects, thus it's common >>> sense that you'd use an int* to point to them. >> >> Except an int* pointer can only point to one int object at a time. >> > No this is rubbish an int* can point to an array of int objects. Obviously the idea that an int* pointer can point to more than one int object at a time is "rubbish". >> >> >>> Why would you use a pointer of type(*)[10] to point to a 1-dim array >>> of 10 ints? The extra [10] on this pointer type does nothing to affect >>> the pointed-to array, it only affects the way its incremented and >>> indexed. The main thing about this pointer type is that it has another >>> level of indirection. You cannot index it without an addition >>> dereference. You cannot increment it with first dereferencing it. It >>> has an extra level of indirection that is completely unnecessary. >> >> You use the appropriate type for the job at hand. You can invoke >> array-to-pointer conversion to obtain a pointer to the first element of >> an array so talking about levels of indirection is mostly a smoke screen >> of your own making. >> > It's not a smoke screen its a fact that the following pointers to > arrays all increase in levels of indirection: > int* > int(*)[S] > int(*)[S1][S2] > int(*)[S1][S2][S3] > All the above pointers can point to arrays of integer objects. The > difference is in their level of indirection, which defines the number > of dimensions in the pointed-to array. > > With the simple example of: > int arr[10]; > int* p1 = arr; > int(*p2)[10] =&arr; > > If we dereference p1 we access the array because it is the directly > pointed-to object: > *p1 = 66; > And we can increment the array to access the next element: > p1++; > *p1 = 77; > > With p2 we need to dereference twice to access the array: > **p2 = 66; > Incrementing this requires more dereferencing: > *((*p2)+1)= 77; > Another way to access the array is to use 2-dim array notation: > p2[0][1] = 77; > > Thus it makes sense that p1 is more suitable as a pointer to a 1-dim > array and p2 more suitable as a pointer to a 2-dim array. > Both pointers are objects that hold exactly the same memory address, > to suggest that they point to different objects is complete nonsense. Wrong again. Explain why sizeof(*p1) != sizeof(*p2). An array is an object and an array element is a sub-object. From n3337: "Objects can contain other objects, called subobjects. A subobject can be a member subobject (9.2), a base class subobject (Clause 10), or an array element. An object that is not a subobject of any other object is called a complete object." p1 points to an array element which is a sub-object of what p2 points to; the fact that they may have the same address is incidental to the semantics of pointers of specific types. HTH. /Leigh
[toc] | [prev] | [next] | [standalone]
| From | Paul <pchristor@yahoo.co.uk> |
|---|---|
| Date | 2012-02-27 14:26 -0800 |
| Message-ID | <518db63e-4cfd-499f-8249-963310134570@e27g2000vbu.googlegroups.com> |
| In reply to | #14567 |
<snip> > > >> Wrong; a pointer can only ever point to one object at a time. If a int* > >> pointer pointed to the middle element of an array you couldn't pass this > >> pointer to delete[] to delete the array (you can only pass a pointer to > >> the initial element of an array to delete[]) so it is wrong to say that > >> this pointer points to an array and it is correct to say that this > >> pointer points to an array element. > > > No this is where you are wrong. A pointer can point to one past the > > end of an array and thus it points to no individual objects. > > Yes a pointer can point to one past the end of an array and this does > not contradict what I have said. > So when you say "a pointer can only point to one object at a time". To which object does it point when it points to one past the end of an array? > > > > Delete requires a pointer that have the same value returned from the > > matching allocation by new. The allocation of a dynamic array returns > > a pointer to an array of objects, which also happens to be a pointer > > to the initial element. Saying that it's a pointer to the initial > > element but not a pointer to the array is complete nonsense. > > The only time it is conceivably safe to say that a pointer points to an > array is when that pointer does indeed point to the first element; if it > points to any other part of an array (or one past the end) it is simply > confusing to say that it points to an array. > I don't see why? If you passed a pointer into a function to iterate through an array or something. I wouldn't like to think that if the pointer was incremented it no longer points to the array. > > > >>>> When talking about C++ types and objects are probably the most important > >>>> things to consider. > > >>> The type of objects pointed to are int type objects, thus it's common > >>> sense that you'd use an int* to point to them. > > >> Except an int* pointer can only point to one int object at a time. > > > No this is rubbish an int* can point to an array of int objects. > > Obviously the idea that an int* pointer can point to more than one int > object at a time is "rubbish". > Why is it rubbish? You cannot point to one single banana , in a bunch , without also pointing at the bunch. It's purely contextual , are you pointing to a group of objects, at an individual object, or can both be correct. > > > > > > > > > > > >>> Why would you use a pointer of type(*)[10] to point to a 1-dim array > >>> of 10 ints? The extra [10] on this pointer type does nothing to affect > >>> the pointed-to array, it only affects the way its incremented and > >>> indexed. The main thing about this pointer type is that it has another > >>> level of indirection. You cannot index it without an addition > >>> dereference. You cannot increment it with first dereferencing it. It > >>> has an extra level of indirection that is completely unnecessary. > > >> You use the appropriate type for the job at hand. You can invoke > >> array-to-pointer conversion to obtain a pointer to the first element of > >> an array so talking about levels of indirection is mostly a smoke screen > >> of your own making. > > > It's not a smoke screen its a fact that the following pointers to > > arrays all increase in levels of indirection: > > int* > > int(*)[S] > > int(*)[S1][S2] > > int(*)[S1][S2][S3] > > All the above pointers can point to arrays of integer objects. The > > difference is in their level of indirection, which defines the number > > of dimensions in the pointed-to array. > > > With the simple example of: > > int arr[10]; > > int* p1 = arr; > > int(*p2)[10] =&arr; > > > If we dereference p1 we access the array because it is the directly > > pointed-to object: > > *p1 = 66; > > And we can increment the array to access the next element: > > p1++; > > *p1 = 77; > > > With p2 we need to dereference twice to access the array: > > **p2 = 66; > > Incrementing this requires more dereferencing: > > *((*p2)+1)= 77; > > Another way to access the array is to use 2-dim array notation: > > p2[0][1] = 77; > > > Thus it makes sense that p1 is more suitable as a pointer to a 1-dim > > array and p2 more suitable as a pointer to a 2-dim array. > > Both pointers are objects that hold exactly the same memory address, > > to suggest that they point to different objects is complete nonsense. > > Wrong again. Explain why sizeof(*p1) != sizeof(*p2). An array is an > object and an array element is a sub-object. From n3337: > What exactly are you trying to say is wrong here? Why compare sizeof(an array element) with sizeof(a reference), does this somehow disprove the fact that the pointers are different levels of indirection? > "Objects can contain other objects, called subobjects. A subobject can > be a member subobject (9.2), a base > class subobject (Clause 10), or an array element. An object that is not > a subobject of any other object is > called a complete object." > > p1 points to an array element which is a sub-object of what p2 points > to; the fact that they may have the same address is incidental to the > semantics of pointers of specific types. > This cannot happen in C++ because, although it supports OOP, its not a pure OOP language. An array object of type int[10] is not something that can be pointed to, as a whole. You can only ever point to element type objects. Dereferencing p2 yields a pointer, or a reference depending on usage. You can only access the array by dereferencing p2 twice, then you will only access one of the arrays elements.
[toc] | [prev] | [next] | [standalone]
| From | Paul <pchristor@yahoo.co.uk> |
|---|---|
| Date | 2012-02-27 11:21 -0800 |
| Message-ID | <e61a0f55-a818-4628-884a-4beff2ac8b30@gw9g2000vbb.googlegroups.com> |
| In reply to | #14545 |
On Feb 27, 3:25 pm, Mike McCarty <mcmcca...@gmail.com> wrote: > On Monday, February 27, 2012 8:07:58 AM UTC-6, Paul wrote: > > A 1-dim array doesn't need a multiplier. A 2-dim array doesn't need > > two multipliers it only needs one. This is not "loss of information" > > as you have put it, the information is not there because it's not > > required. > > I'm not talking about multipliers, I'm talking about knowing the bounds of the underlying array. It is lost information and it is required if you want to (robustly) treat the pointer as a reference to an array of objects. How do you sensibly increment a pointer without knowing the range of values the pointer can logically take? > That *multiplier* is the same thing that you are talking about. For example: int anarray[10][10]; int(*p)[10] = anarray; p[5][2] = 55; In the assignment here first index is an offset equal to 5 x mulitplier , where the multiplier is 10. So the indexed element will be the 50 + results of second index( which is just 2). So the element accessed is... index1 * multiplier + index2 This same value is used if the pointer is incremented i.e: p++; Here pointer to the array is incremented by 10*elements. Obviously there is no need for this multiplier with a 1-dim array, it would always be 1. Perhaps now you understand why a pointer to a 1-dim array is normally of type int* and we don't need added info for incrementing or indexing.
[toc] | [prev] | [next] | [standalone]
| From | SG <s.gesemann@gmail.com> |
|---|---|
| Date | 2012-02-16 07:00 -0800 |
| Message-ID | <5204fad6-8767-4b6d-98c7-221e16142a46@n12g2000yqb.googlegroups.com> |
| In reply to | #14092 |
On Feb 16, 3:51 pm, bintom <binoythomas1...@gmail.com> wrote: > What is the difference between the following declarations? > > int *ptr[10]; > > and > > int (*ptr)[10]; Ask http://cdecl.org It seems, cdecl doesn't like the name "ptr", though. Change it to something else.
[toc] | [prev] | [next] | [standalone]
| From | LR <lruss@superlink.net> |
|---|---|
| Date | 2012-02-16 16:49 -0500 |
| Message-ID | <4f3d7a55$0$22769$cc2e38e6@news.uslec.net> |
| In reply to | #14092 |
bintom wrote: > What is the difference between the following declarations? > > int *ptr[10]; > > and > > int (*ptr)[10]; You may want to read about the Right Left Rule. I looked around and found this, http://www.codeproject.com/Articles/7042/How-to-interpret-complex-C-C-declarations
[toc] | [prev] | [next] | [standalone]
| From | Juha Nieminen <nospam@thanks.invalid> |
|---|---|
| Date | 2012-02-16 22:18 +0000 |
| Message-ID | <4f3d80ac$0$2800$7b1e8fa0@news.nbl.fi> |
| In reply to | #14118 |
LR <lruss@superlink.net> wrote: > bintom wrote: >> What is the difference between the following declarations? >> >> int *ptr[10]; >> >> and >> >> int (*ptr)[10]; > > You may want to read about the Right Left Rule. Unfortunately that rule doesn't help here because the "(*)[]" syntax is special and has a particular meaning that isn't obvious. One just has to know what it means. (Incidentally, quite many even experienced C and C++ programmers don't know how to create a pointer to a multi-dimensional array, or even that it's possible. It's one of the more obscure features of C.)
[toc] | [prev] | [next] | [standalone]
| From | LR <lruss@superlink.net> |
|---|---|
| Date | 2012-02-16 23:40 -0500 |
| Message-ID | <4f3dda81$0$22764$cc2e38e6@news.uslec.net> |
| In reply to | #14121 |
Juha Nieminen wrote: > LR <lruss@superlink.net> wrote: >> bintom wrote: >>> What is the difference between the following declarations? >>> >>> int *ptr[10]; >>> >>> and >>> >>> int (*ptr)[10]; >> >> You may want to read about the Right Left Rule. > > Unfortunately that rule doesn't help here because the "(*)[]" > syntax is special and has a particular meaning that isn't obvious. > One just has to know what it means. I'm sorry, but I don't understand why the Right Left Rule does not apply to the second example above. Can you please explain why the rule doesn't help here and what is special about (*)[]?
[toc] | [prev] | [next] | [standalone]
| From | Juha Nieminen <nospam@thanks.invalid> |
|---|---|
| Date | 2012-02-17 07:24 +0000 |
| Message-ID | <4f3e0092$0$3078$7b1e8fa0@news.nbl.fi> |
| In reply to | #14126 |
LR <lruss@superlink.net> wrote: > Juha Nieminen wrote: >> LR <lruss@superlink.net> wrote: >>> bintom wrote: >>>> What is the difference between the following declarations? >>>> >>>> int *ptr[10]; >>>> >>>> and >>>> >>>> int (*ptr)[10]; >>> >>> You may want to read about the Right Left Rule. >> >> Unfortunately that rule doesn't help here because the "(*)[]" >> syntax is special and has a particular meaning that isn't obvious. >> One just has to know what it means. > > I'm sorry, but I don't understand why the Right Left Rule does not apply > to the second example above. I didn't say it doesn't apply. I said it doesn't help understanding what the syntax means.
[toc] | [prev] | [next] | [standalone]
| From | LR <lruss@superlink.net> |
|---|---|
| Date | 2012-02-17 09:48 -0500 |
| Message-ID | <4f3e690e$0$22778$cc2e38e6@news.uslec.net> |
| In reply to | #14137 |
Juha Nieminen wrote: > LR <lruss@superlink.net> wrote: >> Juha Nieminen wrote: >>> LR <lruss@superlink.net> wrote: >>>> bintom wrote: >>>>> What is the difference between the following declarations? >>>>> >>>>> int *ptr[10]; >>>>> >>>>> and >>>>> >>>>> int (*ptr)[10]; >>>> >>>> You may want to read about the Right Left Rule. >>> >>> Unfortunately that rule doesn't help here because the "(*)[]" >>> syntax is special and has a particular meaning that isn't obvious. >>> One just has to know what it means. >> >> I'm sorry, but I don't understand why the Right Left Rule does not apply >> to the second example above. > > I didn't say it doesn't apply. I said it doesn't help understanding > what the syntax means. I'm not sure I agree, but I can see your point about the RLR not leading to an understanding of the semantics. However, the OP asked about the difference between the two, and I think the RLR is very useful for that purpose.
[toc] | [prev] | [next] | [standalone]
| From | Juha Nieminen <nospam@thanks.invalid> |
|---|---|
| Date | 2012-02-17 15:13 +0000 |
| Message-ID | <4f3e6e98$0$3071$7b1e8fa0@news.nbl.fi> |
| In reply to | #14169 |
LR <lruss@superlink.net> wrote:
> However, the OP asked about the
> difference between the two, and I think the RLR is very useful for that
> purpose.
That would have been the case if he had asked something like what's
the difference between
const int* ptr;
and
int* const ptr;
However, in the case of "int *ptr[10]" vs. "int (*ptr)[10]" it's of
no help.
[toc] | [prev] | [standalone]
Page 3 of 3 — ← Prev page 1 2 [3]
Back to top | Article view | comp.lang.c++
csiph-web