Message-ID: <39429582.139D50FE@cam.org> From: Uriel Weizmann 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> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit 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 > 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.