Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

I've seen some posts on the StackExchange family of sites talking about std::vector implementations. They all seem to indicate that std::vector is implemented strictly as an array (in practice), and that C++ 2003 dictates contiguity of elements - pretty much closing non-array loopholes.

Now I thought that I had read once of a non-array implementation of std::vector - perhaps this predated the 2003 enforcement of contiguity? I believe it was something like a series of linked arrays with decreasing or increasing sizes under the hood but I can't remember the details. Does anyone know of std::vector implementations (or perhaps, more broadly, non-STL vector implementations) that use a non-array approach like this?

Edit: I'd like to clarify here that the emphasis is less on strict std::vector implementation for C++ and rather more on 1) historical STL implementations prior to C++ 2003 contiguous elements constraints or possibly even 2) "vector" implementations in other languages - that do not use the usual array-like structure. A VList implementation of a vector might be a potential example and I'm looking for others.

share|improve this question
1  
From stackoverflow.com/a/2096581: "It's not possible to implement a std::vector<T> with a linked list because the standard guarantees the elements in the list will be held in contiguous memory." –  Robert Harvey 2 days ago
    
Yes. I saw that post. If you look further down in the comments, it explicitly states that this was only as of C++ 2003 - which is why I added the caveat in my question. –  J Trana 2 days ago
    
I've been doing some digging to see if I could find it again and the closest thing to what I remember that I've seen so far is VLists - they have that linked array sort of structure. –  J Trana 2 days ago
3  
"A series of linked arrays" sounds a lot like the typical implementation of std::deque. –  Ixrec 2 days ago
    
Thanks @Ixrec, just took a look at deque implementations. Note quite what I was recalling (no increase/decrease in array size), but insightful nonetheless - and was highly useful if only to ask the question "why vector vs. deque" in a deeper way than I had before. –  J Trana yesterday

1 Answer 1

It's legally possible to implement std::vector<T> without using arrays (or data structures that use arrays under the hood). The only stipulation is that std::vector<T>::max_size() must return a value of 0 or 1.


Example:

// A standard's conforming sketch for (std::vector) that does not use arrays
// under the hood.
template <typename T>
class vector {
public:
    typedef T * iterator;

    vector () {}

    // This is provably guaranteed to be O(1) in the number of elements in the vector.
    void push_back (T const & x) {
        if (!ptr) {
            ptr = new T(x);
        }
        else {
            throw "You've been a bad boy. You've viloated this->max_size().";
        }
    }

    void pop_back () {
        assert(ptr);
        ptr.reset(nullptr);
    }

    size_t size () const {
        return ptr ? 1 : 0;
    }

    size_t max_size () const {
        return 1;
    }

    T * data () {
        return ptr;
    }

    iterator begin () {
        return ptr;
    }

    iterator end () {
        // Technically adding 1 to a non-array pointer is undefined (or at least
        // something to that effect). This problem can be mitigated by using a
        // proper iterator class instead of a typedef'ed pointer.
        return ptr ? ptr + 1 : ptr;
    }

private:
    std::unique_ptr<T> ptr;
};

The max_size() == 0 case is trivial. Left as an exercise for the reader.

share|improve this answer
1  
I believe the standard includes performance guarantees for vector that would be hard to implement with anything but a contiguous memory block. –  Steven Burnap 2 days ago
1  
Hrmmm, well, true - but I think @ThomasEding is referring to a sort of a degenerate implementation here for which this can happen. Technically quite accurate, but not really in the spirit of the question. –  J Trana yesterday
    
@StevenBurnap A fixed depth tree has the same asymptotic performance as a single block. Of course in practice the additional indirections will decrease performance. –  CodesInChaos yesterday
    
@CodesInChaos: But now you've broken contiguous memory guarantees. –  Thomas Eding yesterday
1  
@ThomasEding Of course. This was just a response to Steven's comment that the performance guarantees would be hard to implement without a contiguous memory block. –  CodesInChaos yesterday

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.