Mysterious Moving Pointers

IMHO this is another case where C++'s hidden layers of complexity hides bugs that would've been obvious in plain C. In fact for this particular use-case I'd probably use indices instead of pointers.

Storing a pointer to memory that you did not explicitly allocate is always a red flag, I think. You really need to understand how everything works, and be very careful.<p>I would default to just using std::unique_ptr&lt;Node&gt; in a situation like this, especially since using std::list suggests performance isn&#x27;t critical here, so the additional indirection probably doesn&#x27;t matter.

This is a great reminder of the pox that was Microsoft of the early part of the millennium. Besides an allergy to investing in web standards, they were woefully behind in their language support. Their non-adoption of modern C++ standards held client security back for a decade, and arguable held language standards development back.

I must be misunderstanding something from this article. With:<p>struct Node {<p><pre><code> std::vector&lt;Connection&gt; connections; </code></pre> };<p>struct Connection {<p><pre><code> Node* from, to; </code></pre> };<p>Does this mean that to create the vector of connections, Nodes are created, and references are taken to store in the Connections? And then the Nodes are stored in the list, with std::move()?<p>I don&#x27;t understand why you would want to go down that road. Intuitively, I would assume that you are not safe from an object copy somewhere down the line and your graph then comes crashing down like a house of cards. Wouldn&#x27;t it make more sense to store the nodes as pointers? If you like to live dangerously, something like:<p>struct Graph {<p><pre><code> std::vector&lt;std::list&lt;Node\*&gt;&gt; nodes; </code></pre> };<p>Or better:<p>struct Graph {<p><pre><code> std::vector&lt;std::list&lt;std::unique_ptr&lt;Node&gt;&gt;&gt; nodes; </code></pre> };<p>The later will give you plenty of warnings if you do not copy Nodes around with std::move().<p>Or less performant, but maybe safer, std::shared_ptr&lt;Node&gt;, together with:<p>struct Connection {<p><pre><code> std::weak_ptr&lt;Node&gt; from, to; </code></pre> };<p>so that you have some check guarantees before access?

This is a noob mistake, not a huge mystery. It&#x27;s not always wrong to store raw pointers to STL container elements, but if you do then you must take care of reallocations.<p>If you find storing pointers to elements too perilous, you should probably just make a container of pointers instead.

There is a lesser known cousin to std::vector that doesn&#x27;t have to move nor copy its elements when adding new elements, and that is std::deque.

I know C++ the language but not the STL (the overwhelming abundance of UB and total lack of safety make it an anathema), so my question is why the STL allows&#x2F;requires non-move here copying here dependent on whether an object has a no throw move constructor?<p>Note I’m not asking about move constructor vs memmove&#x2F;cpy but rather the use of copy constructor vs move depending on exception behavior? Is it something like prefer no throw copy constructor over “throwing” move?

This is another nice reminder to people who build systems where there is only one language implementation. Implementations always change.

Don&#x27;t assume! The basic mantra of software development.