Question

While learning C#, I found it fun to reimplement things like List or LinkedList just to understand how it works and potential problems you may have while implementing it.

While learning C++, since I have some experience in C#, I decided to challenge myself and attempt to implement more advanced code than what the end of chapter activities ask. So, I ended up trying to implement a non generic list in C++ to try it out, but ended up receiving a very weird seg fault.

A small disclaimer on the code, while trying to fix it I ended up refactoring it and removing stuff (none of it changed the error, though) so a function or two has no use but after a few hours trying to understand the problem, I don’t want to remove or change anything and accidently fix the problem. Anyway, here’s the code.

class List {
private:
int *ListData;
size_t ListSize;
size_t Pos;
std::stack<size_t> NullList;
size_t InternalNull();
inline size_t PosOnly();

void Check();
size_t (List::*NextNumber)();

public:
List(bool InternalNullHandle);
List(size_t DefaultSize, bool InternalNullHandle);
~List();
void Add(const int SalesRef);
int GetCopy(size_t Pos);
int Get();
};

List::List(bool InternalNullHandle) {
    NextNumber = (InternalNullHandle) ? &List::InternalNull : &List::PosOnly;
    ListSize = 32;
    ListData = new int[32];
    Pos = 0;
}

List::List(size_t DefaultSize, bool InternalNullHandle) {
    NextNumber = (InternalNullHandle) ? &List::InternalNull : &List::PosOnly;
    ListSize = DefaultSize;
    ListData = new int[DefaultSize];
    Pos = 0;
}

List::~List() {
    delete[] ListData;
}

void List::Check() {
    if (Pos >= ListSize) {
        size_t OldSize = ListSize;
        ListSize*=2;
        int *Buffer = new int[ListSize];
        memcpy(Buffer, ListData, sizeof(int)*OldSize);          
        if (ListData != NULL) {
            delete[] ListData; //POINT OF INTEREST ONE
            ListData = NULL;
        }
        else {
            std::cerr<<"ListData is null."<<std::endl;
        }
        ListData = Buffer;
    }
}

size_t List::InternalNull() {
    if (NullList.size() != 0) {
        size_t ToReturn = NullList.top();
            NullList.pop();
        return ToReturn;
}
return PosOnly();
 }

inline size_t List::PosOnly() {
    size_t Old = Pos;
    ++Pos;
    Check();
    return Old;
}

inline void List::Add(const int SalesRef) {
    //size_t Value = (this->*NextNumber) ();
//ListData[Value] = SalesRef;
//if the above code is utilised instead, everything works fine
    ListData[ (this->*NextNumber) () ] = SalesRef; //POINT OF INTEREST TWO
}

inline int List::GetCopy(size_t Pos) {
    return ListData[Pos];
}

I normally don’t post, but google extensively. I ended up installing and running valgrind, which gave read and write errors at Point of Interest One when Point of Interest Two was used. However, when Point of Interest Two was commented out and the commented lines were used, no problems were given.

The problem only arises after 128 iterations, meaning it doubles to 64 and 128 correctly as well as deleted the arrays correctly.

Also, as a note, the code ran perfectly fine on Windows compiled with g++.

I tried to reproduce the error using a separate class, but it worked perfectly fine.

Again, I know I should use the standard containers (and I will) but I like to understand everything and the fact that I can’t figure this out is extremely annoying. Coupled with the fact that I can’t even reproduce it and had to copy this incomplete and badly designed code just makes it worse. Thanks for the help in advance!

Minor edit, if it’s really hard to read I’ll add comments and try to clean the code up without breaking (well, fixing, rather) it. The OSes it was tested on was Windows 7 with mingw (which worked) and Debian with g++ (which only worked with the commented lines uncommented).

Answer 1

The problem with the statement

ListData[ (this->*NextNumber) () ] = SalesRef; //POINT OF INTEREST TWO

is that there’s no sequence point between fetching the value of the field ListData and calling the member function pointed at by NextNumber. So the compiler is perfectly happy doing that load before the function call and then doing the indexing off of it after the call. However, that call may result in reallocating ListData, so the pointer it got from before the call is now dangling (it points at the just deleted array) and bad things happen.

With the commented out code, you force the function call to occur before the fetch of ListData, so that fetch will always get the right value after the resize reallocation.