Yet another draft 'article' that I'll need to eventually flesh out? Why not!

Q: How is it implemented?

(from StackOverflow):

"It's implemented by using an underlying array. It's not possible to implement a std::vector with a linked list because the standard guarantees the elements in the list will be held in contiguous memory." (link)

Q: What does the underlying code look like?

(from the same page): "You can read one implementation for yourself at SGI (where STL was originally conceived)." here - very cool!

So, I wondered to myself, what if I wanted to extend vector (or a similar structure) to hold mixed types? Once again, StackOverflow to the rescue!

Q: How to store different data types in one list? (C++)

(from guess where):

class Property
    Property(const std::string& name)
      : m_name(name) {}
    virtual ~Property() {}
    std::string m_name;

template< typename T >
class TypedProperty : public Property
    TypedProperty (const std::string& name, const T& data)
      : Property(name), m_data(data);
    T m_data;

typedef std::vector< std::shared_ptr > property_list_type;

(full answer)

Neato! What the heck is this std::shared_ptr business, I wonder to myself? Later in his answer, he mentions it:

Bottom line: Never manage resources manually, always wrap them in objects of a class designed to handle exactly one instance of such a resource. For dynamically allocated objects, those handles are called "smart pointer", and the most used one is shared_ptr.

While is an unquestionably excellent resource, it is necessarily terse. Fortunately, Wikipedia's entry is a little easier to grok:

Misuse of pointers is a major source of bugs. Smart pointers prevent most situations of memory leaks by making the memory deallocation automatic. More generally, they make object destruction automatic: the object controlled by a smart pointer is automatically destroyed (finalized and then deallocated) when the last (or only) owner of the object is destroyed, for example because the owner is a local variable, and execution leaves the variable's scope. Smart pointers also eliminate dangling pointers by postponing destruction until the object is no longer in use.
(full article).

Ok, so you've sold me. Smart pointers help prevent memory leaks, and can help make your intentions known to anyone who has to read your code (including yourself). Great! So, the impulsive part of me thinks I should use them all the time now and so should you and your dog! Is this true?

No, it's not true. If a function needs a pointer and has nothing to do with ownership, then I strongly believe that a regular pointer should be passed for the following reasons: - No ownership, therefore you don't know what kind of a smart pointer to pass - If you pass a specific pointer, like shared_ptr, then you won't be able to pass, say, scoped_ptr The rule would be this - if you know that an entity must take a certain kind of ownership of the object, always use smart pointers - the one that gives you the kind of ownership you need. If there is no notion of ownership, never use smart pointers.
(his full answer)

Man, it's fun to dive head first into google/stackoverflow and see how much you can learn, and fast. It's less fun to see how quickly the clock seems to move during such escapades!