Re: 2-dimensional arrays and functions
From: Jumbo ((nospam)_at_12freeukisp.co.uk)
Date: 10/30/03
- Next message: Greg: "Re: C++ oddity in my code, or compiler?"
- Previous message: Fargo Holiday: "C++ oddity in my code, or compiler?"
- In reply to: Karl Heinz Buchegger: "Re: 2-dimensional arrays and functions"
- Next in thread: Gavin Deane: "Re: 2-dimensional arrays and functions"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Thu, 30 Oct 2003 18:07:09 -0000
"Karl Heinz Buchegger" <kbuchegg@gascad.at> wrote in message
news:3FA102EA.A5741B16@gascad.at...
>
>
> Jumbo wrote:
> >
> > I don't know how I can get it into your two thick skulls
> > look at this function Mike posted :
> >
> > int (*func(void))[DIM1][DIM2]
> > {
> > static int array[DIM1][DIM2] =
> > {
> > { 1, 2, 3, 4},
> > { 5, 6, 7, 8},
> > { 9, 10, 11, 12},
> > {13, 14, 15, 16},
> > };
> >
> > return &array;
> > }
> >
> > I suppose you think this is wrong too.
>
> That's a completly different situation.
>
> What the OP had and what the discussion turns around, is equivalent to:
>
> int* foo()
> {
> int j = 5;
> return &j;
> }
>
> And that clearly *is* a bug. The intoduction of arrays and dynamic
> memory allocations add more code, but the principle is still the
> same: the address of a local variable is returned.
>
> > Now if you search around enough you will find thousands of C++ functions
> > that return memory addresses.
>
> Yep. But they do it correctly:
>
> int* foo()
> {
> int* pA = new int [ som_number ];
>
> return pA;
> }
>
> But this is not what the OP had. He had
>
> return &pA;
>
> instead of
>
> return pA;
>
> Is that so hard to see?
>
> >
> > You obviously don't know the difference between a pointer and a memory
> > address.
>
> Oh, I do. But you seem to lack basic reading knowledge, if you can't
> see what the problem in the above is.
>
> > You seem to be confused by indirection
> > here's how it works:
> >
> > int*** return_Array(int dim1, int dim2){
> >
> > int** pArray = new int*[dim1];
> >
> > //new pointer to a pointer declared
> > //pArray is the pointer to the fist element of the array
> > //&pArray is the memory address of a pointer to the first element of the
> > array
> >
> > for(int i=0; i<dim1; i++){
> > pArray[i] = new int[dim2];
> > }
> > return &pArray;
>
> returning the address of a local variable.
> Bad idea.
>
> How many times do we have to repeat it:
> Don't return the address of a local variable!
> The variable is gone once the function has returned thus
> the caller ends up with an address which is useless for him.
>
> Indirection has nothing to do with that.
>
> >
> > // The memory address of a pointer to the first element of the array is
> > returned in EAX .
> > // This memory must be assigned to a suitable pointer by the caller
> > ,otherwise a memory leak is created
> > }
> >
> > The only pointer involved now is the one in main which is being
assigned
> > the return value.
> > The memory allocated by new is valid and persists until the program
exits ,
>
> Yep. But this is not what gets returned!!!!!!!!
> What gets returned is the address of the pointer variable, where the
> address of the dynamically allocated memory is stored. And that variable
> doesn't exist any longer after the function has returned.
>
> Seems it is you, who is confusing things.
>
> > or delete is called. Just because the pointer to it has gone out of
scope
> > does not make this memory invalid.
>
> Surely not. And if you read carefully, then we are not talking about
> this allocated memory. We are talking about the pointer variable, where
> this address is stored. That one doesn't exist after the function return.
>
> >
> > If you still cannot grasp this I suggest you try visual basic.
>
> Stop talking nonsense and actually try to read and understand what
> others write. Stop seeing things that simply are not there. No
> one is returning the address of the allocated memory in the posted
> example. But the example is returning the address of the variable
> where this addres is stored. And that one *is* a bug!
> Even if your C++ skills aren't high enough to see it.
>
> >
> > lol
> > Idiots
> > :-)
>
> The only one who makes a complete fool of himself is you.
>
> --
> Karl Heinz Buchegger
> kbuchegg@gascad.at
On the contrary it only strengthens my case.
Here it is shortened for you:
This is NOT the correct way to do it:
int** foo(){
int* pArray = new int;
return &pArray;
}
This is the correct way to do it:
void foo(int** ppArray){
int* pArray = new int;
*pArray = 5;
*ppArray = pArray;
}
int main(){
int* x;
foo(&x); //this is correct
int** y = foo(); //this is incorrect and can cause memory leaks
}
You are twisting the discussion to make out that I'm saying it's not a bug.
If you are trying to tell me there is a bug in the code above that I don't
know about then think again.
It was me who pointed it out as buggy in the first place!!!
It's very annoying when you pick out all the code I have already stated as
being crap and say ' that's buggy'.
:-s
So overall what are you trying to say ?
And do you have a reasonable comment on my code?
:-)
- Next message: Greg: "Re: C++ oddity in my code, or compiler?"
- Previous message: Fargo Holiday: "C++ oddity in my code, or compiler?"
- In reply to: Karl Heinz Buchegger: "Re: 2-dimensional arrays and functions"
- Next in thread: Gavin Deane: "Re: 2-dimensional arrays and functions"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
