CODEWITHSUNDEEP
c++arraysgenerics
Mike Tiger
Mike Tiger

Reputation: 29

C++ generic array implementation

I came lately across a C++ recruitment test. They are asking the 4 following questions.

  1. There are at least 4 different bugs in the implementation of the following Array class.
  2. Provide for at least 2 of them a test case for each bug.
  3. Propose a fix for each bug
  4. Assuming we have a bug-free implementation of Array class, do you think there are any design problems with it?
template <class T> class Array {
private:
    T *m_pData;
    unsigned int m_nSize;

public:

    Array(unsigned int nSize) : m_nSize( nSize)
    { 
        if ( m_nSize > 0)
            m_pData = new ( nothrow) T[ m_nSize];
    } 

    virtual ~Array() 
    { 
        if(m_pData != NULL)
            delete m_pData; 
    } 

    bool Set(unsigned int nPos, const T& Value) 
    {
        if(nPos < m_nSize) {
            m_pData[nPos] = Value;
            return true;
        }
        else 
            return false;
    }

    T Get(unsigned int nPos) {
        if(nPos < m_nSize) {
            return m_pData[nPos];
        }
        else 
            return T();
    }
};

The problem is I can see no bug. Yes, there are some weird code like:

But these are no bugs to me.

Upvotes: 2

Views: 4725

Answers (3)

Konrad Rudolph
Konrad Rudolph

Reputation: 545975

Here are the five bugs that I can find at a glance:

  1. Creating an instance with nSize == 0 will not initialise m_pData.
  2. If allocation fails, m_nSize is set to a wrong value, and subsequent access will fail.
  3. Copy constructor is missing.
  4. Assignment operator is missing.
  5. delete should be delete[] (and yes, the NULL check is redundant).

Those are all actual bugs, no argument possible. The other weaknesses (that I can see) are “merely” crippling design flaws.

Upvotes: 2

David Haim
David Haim

Reputation: 26506

General:
1. it is the best to put curly braces on each if-else , even for 1 line of code. - (arguable)
2. this if(m_pData != NULL) is redundand. C++ checks for null pointers in delete and delete[]
3. you should opt nullptr isntead of NULL.
4.Get could have been declared as const. not a bug per-se
5.does people still use the hungarian notation?

Bugs:
1. delete m_pData; should be delete[] m_pData;
according to the standard, deleting instead of deleting[] anything that was allocated with new[] has undefined behaviour.
2. in the Constructor : new doesn't throw exception in case of insufficiant memory, yet m_nSize is set to the given size anyway. that may lead to future bugs - if you try to allocate 10000 objects and you fails, Get and Set still going to excess *(m_pData + nPos) but this memory address is invalid. it should be actually : if( m_pData ) {m_nSize = nSize ;}
3. m_pData[nPos]; in Get and Set: again - the constructor doesn't throw an exception and m_pData may be null .you need to check if m_pData is not null.

Extended answer:
I do realize this is a test to check the person's understanding in memory management , obejct oriented and some template use. yet, the best answer will be "there is no need to reinvent the wheel, std::vector is smarter from any naive implementation we might think of." saying this as addition for the bugs above really raise your answer to a something that a professional C++ developer would say.

Upvotes: 0

mystic_coder
mystic_coder

Reputation: 472

Four Errors : 1. template class Array { private: T *m_pData; unsigned int m_nSize; It should be 

template <class T>
class Array 
{
    private: T *m_pData; unsigned int m_nSize;

2.In below code segment

Array(unsigned int nSize) : m_nSize( nSize)
{ 
    if ( m_nSize > 0)
        m_pData = new ( nothrow) T[ m_nSize];
}

if m_nSize is less then 0 , assigne m_pData to null;

3.In below cpode :

virtual ~Array() 
{ 
    if(m_pData != NULL)
        delete m_pData; 
}

Instead of delete , use delete[] m_pData , as m_pDatais array.

  1. in both get and set functions check whether m_pData is NULL or not null before accessing.

Upvotes: 0

Related Questions