Returning int pointer ?

**Bartc** · Oct 18 '08, 06:55 PM

Re: Returning int pointer ?

"Mahendra" <imax@cc.gatech .eduwrote in message
news:gdd8n5$eg5 $1@news-int2.gatech.edu ...

>I have following code snippet -
>
int *createIncidenc eMatrix(int numEdges, int numVertices) {
int *p = (int *) calloc((numEdge s*numVertices), sizeof(int));
if(p == NULL) {
printf("Could not allocate memory");
exit(0);
}
return p;
}
>
>
void createIncidence PerView(int numEdges, int numVertices, int viewId) {
int *pnew = createIncidence Matrix(numEdges , numVertices);
}
>
This code compiles fine. I am trying to understand if this will run as
intended. Obviously, I tried running the code also. My question is -
>
When createIncidence Matrix() return p which is local variable, will p
get deallocated at return call ?

p is a pointer (to the memory you've allocated). The few bytes it takes up
/will/ be deallocated on return, but not before a copy of those bytes (the
value of the pointer variable p) has been made to return from the function.

--
Bartc

**Mahendra** · Oct 18 '08, 07:45 PM

Re: Returning int pointer ?

Bartc wrote:

>
"Mahendra" <imax@cc.gatech .eduwrote in message
news:gdd8n5$eg5 $1@news-int2.gatech.edu ...

>I have following code snippet -
>>
>int *createIncidenc eMatrix(int numEdges, int numVertices) {
> int *p = (int *) calloc((numEdge s*numVertices), sizeof(int));
> if(p == NULL) {
> printf("Could not allocate memory");
> exit(0);
> }
> return p;
>}
>>
>>
>void createIncidence PerView(int numEdges, int numVertices, int viewId) {
> int *pnew = createIncidence Matrix(numEdges , numVertices);
>}
>>
>This code compiles fine. I am trying to understand if this will run as
>intended. Obviously, I tried running the code also. My question is -
>>
>When createIncidence Matrix() return p which is local variable, will p
>get deallocated at return call ?

>
p is a pointer (to the memory you've allocated). The few bytes it takes
up /will/ be deallocated on return, but not before a copy of those bytes
(the value of the pointer variable p) has been made to return from the
function.
>

Will it copy the bytes - holding pointer variable or copy the bytes
holding the value of pointer variable ?

If it does the latter as described by you, where is this memory
allocated - heap ? Does this mean "return" call creates heap memory copy ?

Thanks
Mahendra

**Mahendra** · Oct 18 '08, 07:55 PM

Re: Returning int pointer ?

I got the response i was looking for from Andrey.

Thanks all
Mahendra

Mahendra wrote:

Bartc wrote:

>"Mahendra" <imax@cc.gatech .eduwrote in message
>news:gdd8n5$eg 5$1@news-int2.gatech.edu ...

>>I have following code snippet -
>>>
>>int *createIncidenc eMatrix(int numEdges, int numVertices) {
>> int *p = (int *) calloc((numEdge s*numVertices), sizeof(int));
>> if(p == NULL) {
>> printf("Could not allocate memory");
>> exit(0);
>> }
>> return p;
>>}
>>>
>>>
>>void createIncidence PerView(int numEdges, int numVertices, int viewId) {
>> int *pnew = createIncidence Matrix(numEdges , numVertices);
>>}
>>>
>>This code compiles fine. I am trying to understand if this will run as
>>intended. Obviously, I tried running the code also. My question is -
>>>
>>When createIncidence Matrix() return p which is local variable, will p
>>get deallocated at return call ?

>p is a pointer (to the memory you've allocated). The few bytes it takes
>up /will/ be deallocated on return, but not before a copy of those bytes
>(the value of the pointer variable p) has been made to return from the
>function.
>>

Will it copy the bytes - holding pointer variable or copy the bytes
holding the value of pointer variable ?
>
If it does the latter as described by you, where is this memory
allocated - heap ? Does this mean "return" call creates heap memory copy ?
>
Thanks
Mahendra

**blargg** · Oct 18 '08, 08:25 PM

Re: Returning int pointer ?

In article <48FA3CE4.10503 03@cc.gatech.ed u>, imax@cc.gatech. edu wrote:

Bartc wrote:

"Mahendra" <imax@cc.gatech .eduwrote in message
news:gdd8n5$eg5 $1@news-int2.gatech.edu ...

I have following code snippet -
>
int *createIncidenc eMatrix(int numEdges, int numVertices) {
int *p = (int *) calloc((numEdge s*numVertices), sizeof(int));
if(p == NULL) {
printf("Could not allocate memory");
exit(0);
}
return p;
}

[...]

p is a pointer (to the memory you've allocated). The few bytes it takes
up /will/ be deallocated on return, but not before a copy of those bytes
(the value of the pointer variable p) has been made to return from the
function.

>
Will it copy the bytes - holding pointer variable or copy the bytes
holding the value of pointer variable ?
>
If it does the latter as described by you, where is this memory
allocated - heap ? Does this mean "return" call creates heap memory copy ?

Pointers point to something. They're like having the address of a
building. If I crumple up or burn the piece of paper the address is
written on, nothing happens to the building at that address.

BTW, don't top-post as you did in another reply (look it up with Google if
you don't know what it means).

**s0suk3@gmail.com** · Oct 18 '08, 09:55 PM

Re: Returning int pointer ?

On Oct 18, 2:41 pm, Andrey Tarasevich <andreytarasevi ch@hotmail.com>
wrote:

Mahendra wrote:

I have following code snippet -

>

int *createIncidenc eMatrix(int numEdges, int numVertices) {
int *p = (int *) calloc((numEdge s*numVertices), sizeof(int));

>
Don't cast the results of memory allocation functions.

Why specifically memory allocation functions? That argument would
apply to any function that returns a void *. For example, you wouldn't
want to cast a memcpy() call either, simply because it's not
necessary. However, you're probably just saying it because of
comp.lang.c's old myth that malloc() shouldn't be cast (for whatever
reason).

Sebastian

**Richard Heathfield** · Oct 19 '08, 01:25 AM

Re: Returning int pointer ?

s0suk3@gmail.co m said:

On Oct 18, 2:41 pm, Andrey Tarasevich <andreytarasevi ch@hotmail.com>
wrote:

>Mahendra wrote:

I have following code snippet -

>>

int *createIncidenc eMatrix(int numEdges, int numVertices) {
int *p = (int *) calloc((numEdge s*numVertices), sizeof(int));

>>
>Don't cast the results of memory allocation functions.

>
Why specifically memory allocation functions? That argument would
apply to any function that returns a void *.

Absolutely right - it does.

For example, you wouldn't
want to cast a memcpy() call either, simply because it's not
necessary. However, you're probably just saying it because of
comp.lang.c's old myth that malloc() shouldn't be cast (for whatever
reason).

Hardly a myth. More like common sense. The idea of casting malloc is very
much like the law requiring cab drivers to keep a bale of hay in the boot
of the cab (for feeding the horses). Last I heard, this law was still on
the books but, unlike the great majority of C programmers, typical British
cabbies are bright enough to recognise an anachronism when they see one.

--
Richard Heathfield <http://www.cpax.org.uk >
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

**s0suk3@gmail.com** · Oct 19 '08, 04:35 AM

Re: Returning int pointer ?

On Oct 18, 7:37 pm, Richard Heathfield <rjh@see.sig.in validwrote:

s0suk3@gmail.co m said:

For example, you wouldn't
want to cast a memcpy() call either, simply because it's not
necessary. However, you're probably just saying it because of
comp.lang.c's old myth that malloc() shouldn't be cast (for whatever
reason).

>
Hardly a myth. More like common sense.

Well, lack of common sense isn't the reason people cast these
functions. AFAIK, there are three reasons: (1) It was required in
versions prior to C89 (I hear malloc() & friends used to return char
*), (2) it's shown that way in K&R2, and (3), it's required in C++
(stronger type checking). (2) is probably the main reason why so many
people still do this (K&R2 is still the primary C textbook). (1) is
probably less relevant nowadays. And (3) is the only justified one (in
case you need to write code that compiles as both C and C++).

Anyway, I think the whole argument against this cast is mostly style
flaming.

Sebastian

**Richard Heathfield** · Oct 19 '08, 05:15 AM

Re: Returning int pointer ?

s0suk3@gmail.co m said:

On Oct 18, 7:37 pm, Richard Heathfield <rjh@see.sig.in validwrote:

>s0suk3@gmail.co m said:

For example, you wouldn't
want to cast a memcpy() call either, simply because it's not
necessary. However, you're probably just saying it because of
comp.lang.c's old myth that malloc() shouldn't be cast (for whatever
reason).

>>
>Hardly a myth. More like common sense.

>
Well, lack of common sense isn't the reason people cast these
functions.

No, you're right (again); it's merely a failure to *apply* common sense.

AFAIK, there are three reasons: (1) It was required in
versions prior to C89 (I hear malloc() & friends used to return char
*),

Bales of hay.

(2) it's shown that way in K&R2,

Cargo cult programming.

and (3), it's required in C++

Almost irrelevant - this is C, not C++.

(stronger type checking). (2) is probably the main reason why so many
people still do this (K&R2 is still the primary C textbook). (1) is
probably less relevant nowadays. And (3) is the only justified one (in
case you need to write code that compiles as both C and C++).

The number of people who actually need to do that is vanishingly small - as
far as I know, only two people in this group (P J Plauger and Ian Collins)
have ever put forward a reason for writing such code that bears more than
ten seconds scrutiny, and even then not everyone is convinced that those
reasons are necessarily good ones. Of all the reasons I've ever heard, the
best is probably the reason K&R had - they wanted to be able to compile
programs containing the very latest ANSI-proposed features (e.g.
prototypes), but didn't have available a C compiler that supported them;
they did, however, have a C++ compiler that supported all the features
they needed. Nowadays, of course, finding a compiler that /doesn't/
support C89 in its entirety is quite a difficult exercise (although not
yet wholly impossible).

Anyway, I think the whole argument against this cast is mostly style
flaming.

I will treat that opinion, like your opinion on the "prevalence " of C99, to
a very large pinch of salt before attempting to sample it.

--
Richard Heathfield <http://www.cpax.org.uk >
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

**William Pursell** · Oct 19 '08, 07:35 AM

Re: Returning int pointer ?

On 19 Oct, 05:33, s0s...@gmail.co m wrote:

Well, lack of common sense isn't the reason people cast these
functions. AFAIK, there are three reasons: (1) It was required in
versions prior to C89 (I hear malloc() & friends used to return char
*), (2) it's shown that way in K&R2, and (3), it's required in C++
(stronger type checking). (2) is probably the main reason why so many
people still do this (K&R2 is still the primary C textbook). (1) is
probably less relevant nowadays. And (3) is the only justified one (in
case you need to write code that compiles as both C and C++).
>
Anyway, I think the whole argument against this cast is mostly style
flaming.

The only thing I disagree with here is the parenthetical statement
"stronger type checking". I would replace that with the phrase
"lack of void * type". Whether one implies the other is a
different matter altogether.

Also, I would add a 4th reason, which may be implied by the
3 reasons you cite: ignorance. Or maybe this is precisely
the same as reason 1. People think it is required. It has
little to do with 'common sense', and more to do with failure
to recognize that the language has evolved.

**Malcolm McLean** · Oct 19 '08, 08:25 AM

Re: Returning int pointer ?

"Richard Heathfield" <rjh@see.sig.in validwrote in message

>
The number of people who actually need to do that is vanishingly small -
as
far as I know, only two people in this group (P J Plauger and Ian Collins)
have ever put forward a reason for writing such code that bears more than
ten seconds scrutiny, and even then not everyone is convinced that those
reasons are necessarily good ones.
>

If you use both C and C++ it often useful to be able to snip and paste
functions between two source files.
I no longer use C++ so, to reduce visual clutter, my malloc()s are now
uncast.

--
Free games and programming goodies.

http://www.personal.leeds.ac.uk/~bgy1mm

**Harald van =?UTF-8?b?RMSzaw==?=** · Oct 19 '08, 09:15 AM

Re: Returning int pointer ?

On Sun, 19 Oct 2008 00:28:08 -0700, William Pursell wrote:

On 19 Oct, 05:33, s0s...@gmail.co m wrote:

>Well, lack of common sense isn't the reason people cast these
>functions. AFAIK, there are three reasons: [...]
>and (3), it's required in C++
>(stronger type checking).

>
The only thing I disagree with here is the parenthetical statement
"stronger type checking". I would replace that with the phrase "lack of
void * type".

But then it's simply untrue, because C++ does have a void * type.

**Richard Heathfield** · Oct 19 '08, 02:15 PM

Re: Returning int pointer ?

Malcolm McLean said:

>
"Richard Heathfield" <rjh@see.sig.in validwrote in message

>>
>The number of people who actually need to do that is vanishingly small -
>as
>far as I know, only two people in this group (P J Plauger and Ian
>Collins) have ever put forward a reason for writing such code that bears
>more than ten seconds scrutiny, and even then not everyone is convinced
>that those reasons are necessarily good ones.
>>

If you use both C and C++ it often useful to be able to snip and paste
functions between two source files.

It's more useful to compile your C functions with a C compiler, put them
into a C library, and link them to your C++ program in the canonical way.

I no longer use C++ so, to reduce visual clutter, my malloc()s are now
uncast.

Well, that's not a great reason, but it's not a *bad* reason! :-)

--
Richard Heathfield <http://www.cpax.org.uk >
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

**Malcolm McLean** · Oct 19 '08, 03:45 PM

Re: Returning int pointer ?

"Richard Heathfield" <rjh@see.sig.in validwrote in message

Malcolm McLean said:

>If you use both C and C++ it often useful to be able to snip and paste
>functions between two source files.

>
It's more useful to compile your C functions with a C compiler, put them
into a C library, and link them to your C++ program in the canonical way.
>

Often you want smallish functions to be static (file scope) to avoid
creating dependencies between files. Or you are writing a small one or two
file program in C++ and want to include a function for it. Or you might need
boilerplate code in which a few of the constants etc might need to be
dited - I'm thinking particularly of Windows programming where you need
repetitive code to register Window types, open dialogues, and the like, with
just a few of the parameters changed to meet your needs.

--
Free games and programming goodies.

http://www.personal.leeds.ac.uk/~bgy1mm

**Richard Heathfield** · Oct 19 '08, 04:05 PM

Re: Returning int pointer ?

Malcolm McLean said:

"Richard Heathfield" <rjh@see.sig.in validwrote in message

>Malcolm McLean said:

>>If you use both C and C++ it often useful to be able to snip and paste
>>functions between two source files.

>>
>It's more useful to compile your C functions with a C compiler, put them
>into a C library, and link them to your C++ program in the canonical
>way.
>>

Often you want smallish functions to be static (file scope) to avoid
creating dependencies between files.

At the expense of having code duplicated all over the shop. I'll take the
dependencies any day.

Or you are writing a small one or
two file program in C++ and want to include a function for it. Or you
might need boilerplate code in which a few of the constants etc might
need to be
dited

Edited? Well, that's why generality is so important.

- I'm thinking particularly of Windows programming where you need
repetitive code to register Window types, open dialogues, and the like,
with just a few of the parameters changed to meet your needs.

Functions rock. Parameterisatio n makes them rock even more.

--
Richard Heathfield <http://www.cpax.org.uk >
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

Returning int pointer ?

Returning int pointer ?

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment