delorie.com/archives/browse.cgi | search |
Message-ID: | <39429582.139D50FE@cam.org> |
From: | Uriel Weizmann <uw1 AT cam DOT org> |
X-Mailer: | Mozilla 4.7 [en] (Win98; I) |
X-Accept-Language: | en |
MIME-Version: | 1.0 |
Newsgroups: | comp.os.msdos.djgpp |
Subject: | Re: error flaging I can't reason with.. |
References: | <3941DA42 DOT 1DEE7B3E AT cam DOT org> <3941f7b4 DOT 30496790 AT news DOT cis DOT dfn DOT de> |
X-Forwarded: | by - (CAM) |
Lines: | 103 |
Date: | Sat, 10 Jun 2000 12:22:42 -0700 |
NNTP-Posting-Host: | 198.168.100.7 |
X-Complaints-To: | abuse AT videotron DOT net |
X-Trace: | wagner.videotron.net 960653721 198.168.100.7 (Sat, 10 Jun 2000 12:15:21 EDT) |
NNTP-Posting-Date: | Sat, 10 Jun 2000 12:15:21 EDT |
To: | djgpp AT delorie DOT com |
DJ-Gateway: | from newsgroup comp.os.msdos.djgpp |
Reply-To: | djgpp AT delorie DOT com |
Horst Kraemer wrote: > On Fri, 09 Jun 2000 23:03:46 -0700, Uriel Weizmann <uw1 AT cam DOT org> > wrote: > > > The present is a c++ source program containing two lines commented > > respectively CASE1 and CASE2. > > > Until this moment I can't find an explanation why CASE1 does not work. > > I thing that POINTR1 and ARRAY1 are exactly the same type variables with > > the same data. > > > The puzzle even grows by the fact that if we eliminate the & from the > > parameter ARRAY in the prototype of FILLARRAY (changing ARRAY from > > POINTER REFERENCE to the older style POINTER TO INTEGER, CASE1 works > > fine. > > Yes. That's what you should do if you want to use your function for > true arrays and for pointers pointing to the initial element of some > array. Your declaration makes it unusable for entities declared as > arrays. > > The parameter declaration > > > void fillarray (int* &array) > > expects a reference to a non-const int*. Now you are calling > > int arr[10]; > int *ptr = arr; > > f(ptr); > f(arr); > > In the first case ptr is a variable of type (non-const) int*. This > matches exactly a reference to a non-const int*. In the second case > arr is converted implicitly to a pointer to int pointing to the > initial element of the array arr. Lets call this temporary pointer > parr. The difference is that ptr is a variable of type int* and aptr > is only a _value_ - like a number - and not a variable. > > According to the C++ Standard a reference to a non-const 'foo' is > expecting a non-const variable of type 'foo' may not be initialized > with a simple value if type 'foo'. Values of type 'foo' are treated in > this context as if they where const variables of type 'foo'. > > If you change your declaration to > > void fillarray (int* & const array) > > it will be compiled because the type of the parameter is now > > reference to const (int*) > > which matches a _value_ of type int* _and_ a variable of type int*, > too. But there is no point in declaring it > > void fillarray (int* & const array) > > because there is no practical difference to > > void fillarray (int* array) > > On the contrary. The compiler may create more code for the reference > definition because it may create a pointer variable of its own where > it stores the temporary pointer. The only theoretical difference is > that you cannot change array itself like > > array = 0; > > _in_ the function which you would never to anyway. And still you could > achieve this by a simple > > void fillarray (int* const array) > > in order to protect yourself against an accidental change of 'array' > itself in the function. Thus there is no point in using the reference > version at all. > > Regards > Horst Thanx Horst for the good explanation. Not having a real concept what the compiler does with a pointer reference I still suspect that assigning it a pointer comes down to assign it an address of a pointer rather than the content of a pointer, which makes it in this program (implicitly) a pointer to a pointer. This must be as you said an overhead compile and runtime wise. Thanks again Uri Thanx again Uri.
webmaster | delorie software privacy |
Copyright © 2019 by DJ Delorie | Updated Jul 2019 |