Re: Bug in my C++ program seems really strange. (Update on debugging
progress)
* mike3:
Hi.
I seem to have made some progress on finding that bug in my program. I
deactivated everything in the bignum package that was used except for
the returning of BigFloat objects. I even crippled all the
constructors. So now all the operations and constructors that were
used do is just return BigFloats but no memory is actually accessed at
any point, nor is any allocated. However, when I reenable those parts
of the constructor that allocate memory, and _then_ enable the part of
the _de_structor that _frees_ the memory, the bug appears. It only
seems when I go to allocate the "digits" buffer with (in constructor)
digits = new DIGIT32[length];
and free with (in destructor)
delete digits;
or:
(allocate in constructor) digits = (DIGIT32
*)malloc(length*sizeof(DIGIT32));
(free in destructor) free(digits);
When I don't call free or delete, though, the crash does not appear.
But it does not seem to be something needing the memory and then
accessing it as I tried it with none allocated in the first place and
"digits" set to a dummy pointer, and there was no bug nor any attempt
to access the memory as that would crash the program. It only happens
when you allocate memory in the constructor and free it in the
destructor. Freeing it immediately after allocation, in the
constructor, does not result in the crash bug.
What gives, anyway?
This seems to be a classic case of violation of the rule of three. Rule
of three: if you have a destructor or an assignment operator or a copy
constructor, then you should in general have all three.
What happens with an RO3 violation is that an object is copied including
its pointers, in the raw, and then two or more objects all deallocate
via the same pointer values, so that something is multiply deallocated.
From another point of view an RO3 violation is most often a classic
case of evil premature optimization, usually going down to the lowest
possible level of abstraction instead of more sensibly using the highest
level available (like the standard C++ library), which provides the
required safe copying functionality automatically.
If I understand it correctly, what you have is C level code, let's call
that level 0, like
typedef ... DIGIT32; // Note: reserve all uppercase for macros!
struct MyClass
{
DIGIT32* myDigits;
int myLength;
MyClass( int aLength )
{
myLength = aLength;
digits = (DIGIT32)(malloc(...);
}
~MyClass()
{
free( myDigits );
}
};
There are number of abstraction levels between that hazardious C style
code and proper C++ code.
I'll discuss this in order, how to move from C style to C++.
Level 1, simply packaging that code using C++ constructs. A kind of
word for word translation from C to C++. This does not fix the RO3
violation, but paves the way for fixing it:
typedef ... Digit32;
class MyClass
{
private:
Digit32* myDigits;
int myLength;
public:
MyClass( int aLength )
: myLength( aLength )
, myDigits( new Digit32[aLength] )
{}
~MyClass() { delete[] myDigits; }
};
This does the same as the C-style code, but without casts and generally
in a bit more safe way, although as mentioned not fixing RO3 violation.
Level 2, implementing proper copying, that is, fixing that violation:
typedef ... Digit32;
class MyClass
{
private:
Digit32* myDigits;
int myLength;
public:
MyClass( int aLength )
: myLength( aLength )
, myDigits( new Digit32[aLength] )
{}
MyClass( MyClass const& other )
: myLength( other.myLength )
, myDigits( new Digit32[other.myLength] )
{
Digit32 const* const srcDigits = other.myDigits;
std::copy( srcDigits, srcDigits+myLength, myDigits );
}
~MyClass() { delete[] myDigits; }
void swap( MyClass& other )
{
std::swap( myDigits, other.myDigits );
std::swap( myLength, other.myLength );
}
MyClass& operator=( MyClass other )
{
swap( other );
return *this;
}
};
Now that became slightly complicated, so on to level 3, using standard
containers that implement the copying for you:
typedef ... Digit32;
class MyClass
{
private:
std::vector<Digit32> myDigits;
public:
MyClass( int aLength ): myDigits( aLength ) {}
};
Simple, yes?
Cheers, & hth.,
- Alf
--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?