[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