Topic: separation of pointer types
Author: cdiggins@videotron.ca ("christopher diggins")
Date: Mon, 11 Apr 2005 17:57:27 GMT Raw View
What is currently referred to as a pointer in C++ is in my opinion several
different types inappropriately amalgamated as one. Consider how there are
four very clear categories of pointers with entirely different interfaces:
1) the result of an address-of operation
- supports indirection
- supports comparison
- increment/decrement undefined
- delete undefined
- delete[] undefined
2) reference to an element of an array
- supports indirection
- supports comparison
- supports increment/decrement
- delete undefined
- delete[] undefined
3) reference to a dynamically allocated array
- supports indirection
- supports comparison
- supports delete[]
- delete undefined
4) reference to a dynamically allocated object
- supports indirection
- supports comparison
- delete[] undefined
- supports delete
I see no reason these four cases should not each have a separate type. Does
anyone else find the the hypothetical idea of separation of pointers into
different types to have some allure?
--
Christopher Diggins
Object Oriented Template Library (OOTL)
http://www.ootl.org
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]
Author: cdiggins@videotron.ca ("christopher diggins")
Date: Mon, 11 Apr 2005 23:23:38 GMT Raw View
What is currently referred to as a pointer in C++ is in my opinion several
different types inappropriately amalgamated as one. Consider how there are
four very clear categories of pointers with entirely different interfaces:
1) the result of an address-of operation
- supports indirection
- supports comparison
- increment/decrement undefined
- delete undefined
- delete[] undefined
2) reference to an element of an array
- supports indirection
- supports comparison
- supports increment/decrement
- delete undefined
- delete[] undefined
3) reference to a dynamically allocated array
- supports indirection
- supports comparison
- supports delete[]
- delete undefined
4) reference to a dynamically allocated object
- supports indirection
- supports comparison
- delete[] undefined
- supports delete
I see no reason these four cases should not each have a separate type. Does
anyone else find the the hypothetical idea of separation of pointers into
different types to have some allure?
--
Christopher Diggins
Object Oriented Template Library (OOTL)
http://www.ootl.org
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]
Author: Dave Thompson <david.thompson1@worldnet.att.net>
Date: Mon, 18 Apr 2005 11:49:00 CST Raw View
On Tue, 12 Apr 2005 09:50:32 GMT, nagle@animats.com (John Nagle)
wrote:
<snip>
> The array-as-pointer thing and the concept of pointer
> arithmetic are there mostly because they mapped well to
> PDP-11 hardware. Nobody has put that in a new language
> in a long time.
>
Actually they mapped better onto the word machines where BCPL was
first implemented, like PDP-10 and I think 709x. AIUI it was actually
the PDP-11's need for differing strides that drove _reintroduction_ of
types into C over B, but without dropping pointer arithmetic which has
since been such an opportunity for, ahem, infelicities.
Have there been any new SILs, but Oberon by Wirth who always goes for
safe? The entire category seems to have fallen out of favor.
- David.Thompson1 at worldnet.att.net
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]
Author: "Bob Bell" <belvis@pacbell.net>
Date: Mon, 18 Apr 2005 18:32:31 CST Raw View
"christopher diggins" wrote:
> "Marc Schoolderman" <squell@alumina.nl> wrote in message
> news:425E6DE0.7050206@alumina.nl...
> > So this isn't equivalent.
>
> I stand corrected.
>
> In the end, though I still stand by my thesis that four separate
pointer
> classes can and probably should be used to replace the four different
> categories of usage of regular pointers in most applications.
So what about Andrew's question: do I need to overload functions four
times four the four kinds of pointers?
Bob
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]
Author: nagle@animats.com (John Nagle)
Date: Tue, 12 Apr 2005 09:50:32 GMT Raw View
christopher diggins wrote:
> What is currently referred to as a pointer in C++ is in my opinion several
> different types inappropriately amalgamated as one.
I tend to agree, but it's one of those things that's too late
to fix in this language.
C++ has the needed concepts: arrays,
iterators, and references. But they're all convertable
to and from pointers, and most programmers don't see them
as distinct.
The array-as-pointer thing and the concept of pointer
arithmetic are there mostly because they mapped well to
PDP-11 hardware. Nobody has put that in a new language
in a long time.
John Nagle
Animats
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]
Author: maeder@glue.ch (Thomas Maeder)
Date: Tue, 12 Apr 2005 09:49:55 GMT Raw View
cdiggins@videotron.ca ("christopher diggins") writes:
> What is currently referred to as a pointer in C++ is in my opinion
> several different types inappropriately amalgamated as one. Consider
> how there are four very clear categories of pointers with entirely
> different interfaces:
>
> 1) the result of an address-of operation
> - supports indirection
> - supports comparison
> - increment/decrement undefined
> - delete undefined
> - delete[] undefined
>
> 2) reference to an element of an array
> - supports indirection
> - supports comparison
> - supports increment/decrement
> - delete undefined
> - delete[] undefined
>
> 3) reference to a dynamically allocated array
> - supports indirection
> - supports comparison
> - supports delete[]
> - delete undefined
>
> 4) reference to a dynamically allocated object
> - supports indirection
> - supports comparison
> - delete[] undefined
> - supports delete
>
> I see no reason these four cases should not each have a separate
> type.
Backward compatibility is a very strong reason.
> Does anyone else find the the hypothetical idea of separation of
> pointers into different types to have some allure?
Yes. Which is why we have a plethora of smart pointer and container
types that take care of cases 3) and 4).
The difference between 1) and 2) is blurry, by the way:
void f(int &i)
{
some_pointer_type pi(&i);
}
int main()
{
int i(0);
f(i);
int is[2] = { 0 };
f(is[1]);
}
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]
Author: ark@acm.org ("Andrew Koenig")
Date: Wed, 13 Apr 2005 05:53:28 GMT Raw View
""christopher diggins"" <cdiggins@videotron.ca> wrote in message
news:xiy6e.58852$wl6.549361@weber.videotron.net...
> I see no reason these four cases should not each have a separate type.
> Does
> anyone else find the the hypothetical idea of separation of pointers into
> different types to have some allure?
Does that mean that whenever I write a function that takes a pointer
argument, and that function does only things with the pointer that all four
of your desired categories support, that I must overload the function for
each category anyway?
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]
Author: kuyper@wizard.net
Date: Wed, 13 Apr 2005 00:52:48 CST Raw View
christopher diggins wrote:
> What is currently referred to as a pointer in C++ is in my opinion
several
> different types inappropriately amalgamated as one. Consider how
there are
> four very clear categories of pointers with entirely different
interfaces:
>
> 1) the result of an address-of operation
> - supports indirection
> - supports comparison
> - increment/decrement undefined
Incorrect; increment is allowed, decrement isn't.
> - delete undefined
> - delete[] undefined
>
> 2) reference to an element of an array
> - supports indirection
> - supports comparison
> - supports increment/decrement
Decrement is not allowed for a pointer to the first element of an
array.
> - delete undefined
> - delete[] undefined
>
> 3) reference to a dynamically allocated array
> - supports indirection
> - supports comparison
You left out:
- supports increment
> - supports delete[]
> - delete undefined
>
> 4) reference to a dynamically allocated object
> - supports indirection
> - supports comparison
You left out:
- supports increment
> - delete[] undefined
> - supports delete
Notice: the (corrected) differences with regard to increment and
decrement are all covered by one principle: a pointer to a single
object is treated as a pointer to the only element of a 1-element
array. It's never legal to decrement a pointer to the first element of
an array. It's always legal to increment a pointer to an element of an
array.
> I see no reason these four cases should not each have a separate
type. Does
> anyone else find the the hypothetical idea of separation of pointers
into
> different types to have some allure?
You'll have to identify the advantages. I don't see any.
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]
Author: cdiggins@videotron.ca ("christopher diggins")
Date: Thu, 14 Apr 2005 05:07:45 GMT Raw View
""Andrew Koenig"" <ark@acm.org> wrote in message
news:G9Q6e.564825$w62.517033@bgtnsc05-news.ops.worldnet.att.net...
> ""christopher diggins"" <cdiggins@videotron.ca> wrote in message
> news:xiy6e.58852$wl6.549361@weber.videotron.net...
>
>> I see no reason these four cases should not each have a separate type.
>> Does
>> anyone else find the the hypothetical idea of separation of pointers into
>> different types to have some allure?
>
> Does that mean that whenever I write a function that takes a pointer
> argument, and that function does only things with the pointer that all
> four of your desired categories support, that I must overload the function
> for each category anyway?
All four categories overlap only with regards to indirection. This means
that the appropirate type would be a reference.
--
Christopher Diggins
Object Oriented Template Library (OOTL)
http://www.ootl.org
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]
Author: kuyper@wizard.net
Date: 15 Apr 2005 04:50:14 GMT Raw View
"christopher diggins" wrote:
.
> All four categories overlap only with regards to indirection. This
means
> that the appropirate type would be a reference.
All four type support indirection, comparison, and increment.
References only support indirection.
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]
Author: v.Abazarov@comAcast.net (Victor Bazarov)
Date: Fri, 15 Apr 2005 04:47:08 GMT Raw View
christopher diggins wrote:
> ""Andrew Koenig"" <ark@acm.org> wrote in message
> news:G9Q6e.564825$w62.517033@bgtnsc05-news.ops.worldnet.att.net...
>
>>""christopher diggins"" <cdiggins@videotron.ca> wrote in message
>>news:xiy6e.58852$wl6.549361@weber.videotron.net...
>>
>>
>>>I see no reason these four cases should not each have a separate type.
>>>Does
>>>anyone else find the the hypothetical idea of separation of pointers into
>>>different types to have some allure?
>>
>>Does that mean that whenever I write a function that takes a pointer
>>argument, and that function does only things with the pointer that all
>>four of your desired categories support, that I must overload the function
>>for each category anyway?
>
>
>
> All four categories overlap only with regards to indirection. This means
> that the appropirate type would be a reference.
>
I don't see how this could coexist with a notion of 'null pointer value'
(a pointer that is valid yet does not point to any object).
V
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]
Author: squell@alumina.nl (Marc Schoolderman)
Date: Fri, 15 Apr 2005 04:46:57 GMT Raw View
christopher diggins wrote:
> All four categories overlap only with regards to indirection. This means
> that the appropirate type would be a reference.
No. As was debated over and over in a recent thread, a reference can't
be "null", whereas a pointer can. Also, a pointer can be changed inside
the function, whereas a reference can't. So this isn't equivalent.
A more fundamental problem has to do with the low-level nature of
pointers. IMHO, they're not supposed to be some "pure" error-proof
language construct for the things you're suggesting, they're "just above
the machine level" abstractions for addresses, and the things you use
addresses for in machine language. Having four different pointer types
for the same low-level construct would be extremely confusing.
~Marc
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]
Author: cdiggins@videotron.ca ("christopher diggins")
Date: Sat, 16 Apr 2005 22:30:38 GMT Raw View
"Marc Schoolderman" <squell@alumina.nl> wrote in message
news:425E6DE0.7050206@alumina.nl...
> christopher diggins wrote:
>
>> All four categories overlap only with regards to indirection. This means
>> that the appropirate type would be a reference.
>
> No. As was debated over and over in a recent thread, a reference can't be
> "null", whereas a pointer can.
You are correct. All four categories do support comparison to null.
> Also, a pointer can be changed inside the function, whereas a reference
> can't.
You are correct here as well.
> So this isn't equivalent.
I stand corrected.
In the end, though I still stand by my thesis that four separate pointer
classes can and probably should be used to replace the four different
categories of usage of regular pointers in most applications.
> A more fundamental problem has to do with the low-level nature of
> pointers. IMHO, they're not supposed to be some "pure" error-proof
> language construct for the things you're suggesting, they're "just above
> the machine level" abstractions for addresses,
Exactly! My point is programmers far too frequently just use pointers when
something more abstract would be more appropriate.
> and the things you use addresses for in machine language. Having four
> different pointer types for the same low-level construct would be
> extremely confusing.
So we agree using pointers is neccessary when we need the low-level
construct. I am simply saying that in most applications it is more
appropriate to use a more accurate abstraction instead.
> ~Marc
Christopher
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]