[bigint] BigInteger library

Matt McCutchen <matt at mattmccutchen.net>
Fri Apr 10 21:51:16 PDT 2009


On Fri, 2009-04-10 at 19:35 -0400, mark at trouvist.com wrote:
> I read that you are more familiar with Java than C++, which might  
> explain some bugs in your BigInteger library.

I didn't say that exactly.  I do understand C++; I just tend to make
careless mistakes.

> It is recommended that  
> you use the virtual keyword for any functions which should/could be  
> overridden in a base class.

I didn't really expect clients to inherit from the BigUnsigned/Integer
classes, so I saw no reason to make the functions virtual and pay for
the dynamic dispatch.  Are you planning to inherit from them?

> Additionally, the virtual keyword is  
> absolutely imperative on the destructor in a base class in order to  
> guarantee that it will be called when inherited classes are  
> destructed.  Currently, whenever a BigInteger or BigUnsigned is  
> deleted/destructed, NumberLikeArray's destructor isnt being called,  
> hence the memory is not being freed.

I think you're mistaken here.  C++ automatically inserts calls to
base-class destructors in a derived-class destructor.  The purpose of
"virtual" on a destructor is just like on any other method: to perform a
dynamic dispatch based on the object's runtime type, even if the call is
made through a pointer whose static type is the base class.  The
situation in which this would be needed is the following:

BigInteger *bi = new BigInteger();
NumberlikeArray *na = bi;
// compute compute compute
delete na;

But that shouldn't happen because the inheritance from NumberlikeArray
is nonpublic.

So, do you have concrete evidence of a memory leak?  When I run the
testsuite under valgrind, I get "All heap blocks were freed -- no leaks
are possible."

> Other than that, so far BigInteger looks infinitely usable! Thanks :)

You're welcome, and good luck with whatever you're doing with it.

-- 
Matt




More information about the bigint mailing list