Prim algorithm implementation for adjacency list represented graph
I try some review, although I don't know the Prim algorithm until now, so there are mostly general things here. Hope it is helpful nevertheless. The following points are in random order:



Regarding the language:


In your Vertex() {} class, you can omit the bVisited = false; as it is already initialized in the declaration. Otherwise, it's better to use an initializer list, Vertex() : bVisited(false) {}.
In C++11 (which you tagged) I would rather use the standard-library smart pointers and not the boost stuff. So, I would add an #include&lt;memory&gt; and replace all boost:: namespaces by std::.
Your function getMinEdge can be replaced by an single-line STL algorithm:

auto getMinEdge(const EdgeList&amp; edgeList) -&gt; boost::shared_ptr&lt;Edge&gt;
{
    return *std::min_element(edgeList.begin(),edgeList.end()
                           , [](boost::shared_ptr&lt;Edge&gt; const&amp; a
                              , boost::shared_ptr&lt;Edge&gt; const&amp; b)
                               { return a-&gt;cost &lt; b-&gt;cost; });
}

When using range-based for loops

 for(boost::shared_ptr&lt;Edge&gt; edge : dstVertexEdgeList) 


I would rather use auto instead of explicitly stating the type. Moreover, as copying a shared_ptr is not an unexpensive operation (as the memory manager must increase its reference count), here I would use auto&amp; or better auto const&amp; and pass the shared_ptr by reference.

The same holds for statements like boost::shared_ptr&lt;Edge&gt; minEdge = getMinEdge(potentialEdgeList); or EdgeList&amp; dstVertexEdgeList = (minEdge-&gt;dstVertex).lock()-&gt;edgeList;. Better use auto or auto&amp;, resp.




Regarding the design:


Regarding the storage scheme: The std::list&lt;std::shared_ptr&lt;Vertex&gt; &gt; you chose is probably the safest option, but probably also not the most performant. As an alternative you could for instance use std::shared_ptr&lt;std::list&lt;Vertex&gt; &gt;. It's rather fast and advantageous imo if vertices are more or less constant, such that you do not make changes in copies of the class -- because these would affect the original list. Further I would also consider whether a simple std::list&lt;Vertex&gt; is sufficient for you, as that is surely the easiest choice (--then you could then forget about all the smart-pointer stuff). Much here depends on the size of the pointed-to objects. The smaller they are, probably the less appropriate is the overhead of a shared_ptr.

The same holds for EdgeList. Here, you seem to make some copies and change these, such that std::shared_ptr&lt;std::list&lt;Edge&gt; &gt; doesn't make much sence (as you would change the original list). However, as edge is a rather small object, again a simple std::list could be more efficient. 

But these are fundamental design questions which affect "only" the performance. I leave them up to you and will go on with the implementation as it is.
Rather than a std::list, you can also consider using a std::set or a sorted std::vector (as you already using boost, the latter corresponds to a flat_set). This gives you better performance for the search (logarithmic vs. linear for a list) but an increased effort for insertion and deletion (logarithmic vs. constant for a list).
The weak_ptr in the Edge class is ok, though it might not exactly be what you want. At the moment it works like this: an Edge connects two vertices. If now one vertex is removed from the graph, the Edge remains, but when you want to go along it the shared_ptr from weak_ptr initialization will fail and implicitly tell you that it is a dead end. I don't know whether this is desired.

Instead, the graph object should know that it has to automatically remove this Edge once the Vertex is destroyed. This obviously would require some corresponding logic in the Graph class. As an alternative, you could also create a closer coupling between the two classes (e.g. maybe hold an EdgeList for each vertex).

Further, when you go for a weak_ptr and .lock() it, you must keep track that it still points to something which is alive. Otherwise, access to variables of the pointed-to class fails. If you not check for existence and simply rely on it due to your code, a raw pointer would be sufficient.




So, that's it for now, hope it helps. When I get to know the Prim algorithm itself, I'll maybe make an update.