Thread: Best way to avoid memory leak

I don't know the whole picture, but an assert checking that the pointer is NULL before assigning a new bigint, perhaps? That way you would know if you still have a pointer that isn't released. Unless, of course, you have circular references, in which case I don't think there would be an easy way except to use C++...

If you look at the interface provided by the GMP, you will find that they provide a third parameter to store the result. This approach could be better in that the add function will then have full control over how to assign the result.

One way would be to make the user responsible for allocation of the result as well [and thus, no hidden deallocation or other problems with "numbers getting overwritten".

Using a 3-argument add function would do the trick:

Code:

void add(bigint a, bigint b, bigint c)
{
    // a = b + c [or c = a + b]. 
}

However, you then need to accept calls like this:

Code:

bigint x = make_bigint();
bigint y = make_bigint();

add(x, x, y);
add(y, x, y);
add(x, x, x);

But it avoids the allocation of memory that isn't being freed because the pointer is being "lost" in the operation.

--
Mats

Originally Posted by laserlight

If you look at the interface provided by the GMP, you will find that they provide a third parameter to store the result. This approach could be better in that the add function will then have full control over how to assign the result.

Note: This is the same answer I came up with, but I didn't know that GMP uses that method - although it does of course make sense.

--
Mats

If its any consolation, I just spent the last couple of days on a prototype of my own variable-sized two's complement big-integer number class.
It's C++ though of course, and it's up on my website already, but I'm still working on it.
Is there any particular reason to only use C for this?

Originally Posted by mike_g

Funny you mention it; I was just thinking of converting it to C++. Garbage collection would be nice, and its one instance where operator overloading would make using the code much simpler. Might even be possible to template the chunk size, but thats getting ahead of myself. I had a look at the version on you site before, nicked a couple of ideas, some of just went over the top of my head. I'm still not all that used to C++.

C++ doesn't have garbage collection, under normal circumstances. There are GC add-ons that you can use in C++, with more or less likelihood of sucess.

But operator overloading is certainly an advantage.

--
Mats

So are smart pointers.

Originally Posted by mike_g

I had a look at the version on you site before, nicked a couple of ideas, some of just went over the top of my head. I'm still not all that used to C++.

You're welcome. If you'd like me to explain any of it, let me know.

For well known problems it is usually best not to have to deal with their solutions.
After some searching for my own needs i came up with this attractive open source
big integer implementation. It's written in ANSI C and there are also wrappers
that have inline assembler optimizations for x86 CPU's. I tested it and it is fairly fast,
and straightforward to use. There is no library file provided by the authors, but one
can be easily constructed.
It can be found here

For well known problems it is usually best not to have to deal with their solutions.

I think the point of this exercise is to learn how to create one's own bigint library, and hopefully learn a thing or two about mathematics and programming from it. I already posted a link to the GMP, so mike_g could have switched to using that yesterday, but would miss out on the exercise by doing so.