copy constructors with iterators

[jgscott]

I've been trawling around for an answer to this question and thought
I'd try here. I have a class Graph, which has a std::list<Node> as a
class member. Node it itself a class that makes extensive use of
pointers to represent various forms of data in the nodes of graphs,
along with pointers to neighboring nodes. This necessitates a deep
copy that iterators over the list. My copy constructor looks like:

DecomposableGraph:ecomposableGraph(const DecomposableGraph& G)
{
// Some stuff
// And now the iterator declaration:
std::list<Node, const Node&, const Node*>::iterator jt_i, jt_l, jt_m;
// use these iterators to do deep copy of G
}

The GNU compiler on my G4 Mac laptop does not object to this
declaration, which I cobbled together by trial and error message. The
code compiles, and the copy constructor works exactly as intended.
The GNU compiler on a Linux machine that I want to port this code to,
however, objects, claiming I can only have 1 member of the list
template declaration rather than 3. This leads me to believe I've
stumbled upon a peculiarity of the Mac implementation of the STL which
makes my declaration interpretable, albeit nonstandard. The problem,
as I understand it, is that I can't use a normal list<Node>::iterator
to iterator over class members of the const G the way I could over a
normal non-const function argument. But I don't know how to modify
the declaration in general to make such iteration possible.

Can anyone clue me in to the "standard" way to solve this problem, or
correct my understanding? Thanks for your time.

 

[Alf P. Steinbach]

* (e-mail address removed):

I've been trawling around for an answer to this question and thought
I'd try here. I have a class Graph, which has a std::list<Node> as a
class member. Node it itself a class that makes extensive use of
pointers to represent various forms of data in the nodes of graphs,
along with pointers to neighboring nodes. This necessitates a deep
copy that iterators over the list. My copy constructor looks like:

DecomposableGraph:ecomposableGraph(const DecomposableGraph& G)
{
// Some stuff
// And now the iterator declaration:
std::list<Node, const Node&, const Node*>::iterator jt_i, jt_l, jt_m;
// use these iterators to do deep copy of G
}

The GNU compiler on my G4 Mac laptop does not object to this
declaration, which I cobbled together by trial and error message. The
code compiles, and the copy constructor works exactly as intended.
The GNU compiler on a Linux machine that I want to port this code to,
however, objects, claiming I can only have 1 member of the list
template declaration rather than 3. This leads me to believe I've
stumbled upon a peculiarity of the Mac implementation of the STL which
makes my declaration interpretable, albeit nonstandard. The problem,
as I understand it, is that I can't use a normal list<Node>::iterator
to iterator over class members of the const G the way I could over a
normal non-const function argument. But I don't know how to modify
the declaration in general to make such iteration possible.

Can anyone clue me in to the "standard" way to solve this problem, or
correct my understanding? Thanks for your time.

If possible you should accept the default copy constructor for
DecomposableGraph, which then invokes the std::list copy constructor,
which invokes copy constructors for all Node instances in the list, and
here's where you need to deep copy so you should probably either provide
a custom copy constructor for Node or delegate even further, or, best of
all, see if use of e.g. shared_ptr can avoid the need for deep copying.

std::list has two template parameters: the node type T, and an allocator
type that defaults to std::allocator<T>.

Three actual parameters shouldn't compile.

Cheers, & hth.,

- Alf

 

[Jim Langston]

* (e-mail address removed):

If possible you should accept the default copy constructor for
DecomposableGraph, which then invokes the std::list copy constructor,
which invokes copy constructors for all Node instances in the list, and
here's where you need to deep copy so you should probably either provide a
custom copy constructor for Node or delegate even further, or, best of
all, see if use of e.g. shared_ptr can avoid the need for deep copying.

std::list has two template parameters: the node type T, and an allocator
type that defaults to std::allocator<T>.

Three actual parameters shouldn't compile.

Also, what is the actual declaration of your std::list in DecomposableGraph?

 

[Kai-Uwe Bux]

I've been trawling around for an answer to this question and thought
I'd try here. I have a class Graph, which has a std::list<Node> as a
class member. Node it itself a class that makes extensive use of
pointers to represent various forms of data in the nodes of graphs,
along with pointers to neighboring nodes. This necessitates a deep
copy that iterators over the list. My copy constructor looks like:

DecomposableGraph:ecomposableGraph(const DecomposableGraph& G)
{
// Some stuff
// And now the iterator declaration:
std::list<Node, const Node&, const Node*>::iterator jt_i, jt_l, jt_m;
// use these iterators to do deep copy of G

Huh? std::list<> usually takes two template parameters: the value type and a
user provided allocator (defaults to std::allocator< value_type >).
Implementations are allowed to add further parameters. Therefore, the above
might compile, however, it sure is weird to have a Node const & as an
allocator.

}

The GNU compiler on my G4 Mac laptop does not object to this
declaration, which I cobbled together by trial and error message. The
code compiles, and the copy constructor works exactly as intended.
The GNU compiler on a Linux machine that I want to port this code to,
however, objects, claiming I can only have 1 member of the list
template declaration rather than 3. This leads me to believe I've
stumbled upon a peculiarity of the Mac implementation of the STL which
makes my declaration interpretable, albeit nonstandard. The problem,
as I understand it, is that I can't use a normal list<Node>::iterator
to iterator over class members of the const G the way I could over a
normal non-const function argument. But I don't know how to modify
the declaration in general to make such iteration possible.

Can anyone clue me in to the "standard" way to solve this problem, or
correct my understanding? Thanks for your time.

Best

Kai-Uwe Bux

 

[Pete Becker]

std::list has two template parameters: the node type T, and an
allocator type that defaults to std::allocator<T>.

Three actual parameters shouldn't compile.

Implementations are allowed to use three actual parameters, provided
any parameters in addition to the required ones come after them and
have default values. The three actual parameters in the original code
don't meet that requirement, but that's a much narrower statement.

 

[jgscott]

Punting the deep-copy responsibility down to a lower level seems like
a good idea, and I will try that... thank you!

Also, what is the actual declaration of your std::list in DecomposableGraph?

class DecomposableGraph: public GGM
{
public:
// Lots of stuff

private:
//more stuff, and then
set<ushort> NodeSet;
list< JunctionTreeNode > JunctionForest;
}

class JunctionTreeNode
{
public:
//some stuff
// Here is where the deep copy is necessary...
list< list<JunctionTreeNode>::iterator > Neighbors;
//more stuff
};

So each node has data, and a list of pointers to other nodes (in a
list so iterators are stable) that say who the neighbors are. This is
probably not a great implementation, but I'm a statistician, not a
software guy, and this was the best way I could figure to do it for
the algorithms that happen over these graphical structures. Thanks
for your advice.

 

[jgscott]

Huh? std::list<> usually takes two template parameters: the value type and a
user provided allocator (defaults to std::allocator< value_type >).
Implementations are allowed to add further parameters. Therefore, the above
might compile, however, it sure is weird to have a Node const & as an
allocator.

I agree it looks strange, though I'm not au fait with the details of
the STL! I basically stumbled upon that declaration from the compiler
error message when I compiled using list<JunctionTreeNode>::iterator
as the declaration. After a little experimentation, the code then
compiled and works exactly as intended.