Indeed.
1 2 3 4 5 6 7 8
|
team::foo()
{
// what if the fightingTeam already points to an array here?
// the assignment below forgets (leaks) that array
// and all the gladiators pointed to by that array
fightingTeam = new gladiator*[teamSize];
// more code
}
|
Furthermore, I do suspect that at least the copy constructor, copy assignment, and destructor of
class team
might leak.
https://en.cppreference.com/w/cpp/language/rule_of_three
Edit:
1 2 3 4
|
team& team::operator+ ( int *add )
{
for ( int i = 0; i < teamSize ; ++i) {
switch ( add[i] ) {
|
That loop assumes that the
add
points to an array that has at least
teamSize
elements. Nothing checks or ensures that. This function has blind faith to the caller.
1 2 3 4 5 6 7 8
|
fightingTeam = new gladiator*[teamSize];
for (int i = 0; i < teamSize ; ++i) {
switch (add[i]){
default:
{
cout<<"Invalid gladiator type"<<endl;
}
}
|
The elements of the array are uninitialized. If any
add[k]
falls to the default, then the corresponding
fightingTeam[k]
will remain uninitialized.
I bet that the other team functions assume each fightingTeam to have a valid pointer.
marked correct by the auto marker |
Well, at least we now know not to trust it. At all.