Take the 2-minute tour ×

I got my code working, but i feel as if there is a faster way to do this especially in my function copy. here is my code. can this be any faster? this is in C btw. Also when i return cpy from the function does it delete the dynamic memory since its out of scope? I don't want to have memory leaks :P

#include <stdio.h>
#include <stdlib.h>
double *copy(double a[], unsigned ele);
int main(){
    double arr[8], *ptr;
    unsigned i=0;
        scanf_s("%lf", &arr[i]);
    ptr=copy(arr, 8);
        printf("%f", ptr[i]);


double *copy(double a[], unsigned ele){
    double *cpy= malloc(sizeof(double)*ele);
    int i=0;
    for(;i<ele; i++)
    return cpy;
share|improve this question

3 Answers 3

up vote 5 down vote accepted

You can replace your for with a memcpy.

memcpy(cpy, a, ele * sizeof *cpy);

Other than that what you're doing it pretty okay: you're returning a pointer, thus the caller has a chance to free it.

Also I consider it good practice NOT to call free if you're going to exit - the OS will collect the memory anyway.

share|improve this answer
oh thats good to know thanks :). My professor however wants us to do it manually to see what's happening. Oh ok so i dont need to call free in this situation. –  Painguy May 14 '12 at 5:17
@NimaGanjehloo Well, the OS doesn't really care about malloc. It will take the memory back anyway. –  cnicutar May 14 '12 at 5:19
Seems we posted the same solution. :-) I am very curious about why you say its a good practice to NOT call free before an exit though Cnicutar. While obviously it doesn't matter in trivial programs like this in my business a good cleanup routine is important. If you don't cleanup its much harder to track bugs down in Valgrind. What's your reasoning behind this best practice? Perhaps I should post a question on this... –  David Mokon Bond May 14 '12 at 5:23
@DavidMokonBond Some time ago I read a post from R.. about this. The post detailed how the useless free can actually slow down things a lot. But yes, a "correct" malloc/free scenario is required for the sake of memory leak checkers. And it's not just trivial programs: if you're going to exit the free won't do anyone any good. –  cnicutar May 14 '12 at 5:26
I consider good practice exactly the opposite: always call explicit free! (just wrote it, otherwise it wouldn't be worth mentioning it). It is a good "memory exercise", and you won't be accustomed to leave it "since the program is going to exit"... If it slows the exit, I wonder if there are optimizers who are able to remove free when they recognize the only flow/path the program can go from there is an exit... However, it is worth mentioning the fact that not all OSs are able to free automatically the memory allocated by a program!! So, after all, it's good practice always to free memory. –  ShinTakezou May 14 '12 at 5:30

Use Memcpy. It might be able to take advantage of your underlying hardware etc... No need to reinvent the wheel. :-)


    size_t size = sizeof(double)*ele ;
    double *cpy= malloc(size);
    memcpy( cpy, a, size ) ;
    return cpy;
share|improve this answer
int size = sizeof(double)*ele You might want to change it to size_t. –  cnicutar May 14 '12 at 5:18

does it delete the dynamic memory since its out of scope

No, it doesn't: the only memory that goes out of scope is the one holding the pointer; you return the value of that pointer, and it's the only thing you need to access the memory you malloc-ed and which stays malloc-ed until you free it explicitly.

I don't want to have memory leaks

Memory leaks happen when you get memory that you won't release. Indeed, your code have a memory leak: you do not free the memory the pointer is returned by copy: free(ptr); at the end of your code. In this case, it does not matter too much, but it's a good practice to avoid to forget it.

Note also that if the memory would be freed automatically when a pointer to it goes out of scope, it would be freed from inside the copy function itself and you would return an invalid pointer; and then there would be a lot of double free and alike, each time a pointer goes out of scope! Fortunately this does not happen since memory you got using malloc must be explicitly freed with free.

share|improve this answer

Your Answer


