Custom Query (545 matches)

The [9c8efad5f587] patch fixes the problem.

The [79643f6e8c52] fixes the problem.

The idea is that the copy constructor and operator=() of a ListGraph::NodeMap<> &Co. would not effectively copy the map but instead it would use the container array of the source map. The storage would be deallocated when there are no maps pointing to it.

Moreover, the default maps would have a copy() member function, which would effectively copy the contents, i.e.:

  ListDigraph::NodeMap<int> a(g);
  ListDigraph::NodeMap<int> b(a); /// a and b use the same storage
  a[e]=5   /// this also sets b[e] to 5.
  ...
  b.copy() /// b now have a separate storage
  a[e]=7   /// the value of b[e] does not change

The advantage of this approach is that

• a function could create return a map. Currently it is impossible, the caller must allocate the map and pass it as a reference.
• we could assume that the copy/assignment of a map of the same type are cheap therefore we don't have to differentiate e.g. between the default maps and the map adaptors.

However this approach is not fully compatible with the current implementation, therefore we must follow one of the tree approaches below.

• Declare that this is a basically bad idea and therefore we will never introduce it. I would not be happy with a decision like this.
• We like the idea so much that we implement it right now. Though it is not a trivial task, I guess.
• We postpone this to the next release. If we want to do this, we must forbid temporarily the usage of operator= and the copy constructor of the default maps, for a late introduction of a cheap copy would break the API compatibility.

P.S: It can also be a nice thing to do something similar with the graphs themselves. Fortunately, graph have no copy constructors and assignment operators, therefore in case of graphs the introduction of "cheap copy" is a clear enhancement and does not break the API compatibility.