digitalmars.D.learn - Copying objects vs. primitive type
- muffles (1/1) Jun 30 2007 Ok, so since I'm in the process of learning D, I figured it could be hel...
- Jarrett Billingsley (40/41) Jun 30 2007 Do you necessarily need to? What if your list is a list of objects whic...
- Frits van Bommel (2/3) Jul 01 2007 Shouldn't that last bit be is(typeof(T.dup))?
- Jarrett Billingsley (4/7) Jul 01 2007 Yes, it probably should :D I always forget about the typeof, and then t...
Ok, so since I'm in the process of learning D, I figured it could be helpful to make a template linked list class. Since D works by treating instances of objects as references, it was suggested by people in #D that I create a dup() method when I want a copy of an object of a class I create, since using the assignment operator will just have the new reference point to the same object as the old one. So I started writing a dup() method for my linked list when I ran into problem. When I copy the data in a node from the old list to its corresponding place in the new list, I'll only be copying references if what the linked list is templated for a class (if my understanding is correct). If my linked list is of a primitive type, the assignment operator will do what I want and dup() will give what I want, a second linked list with node that contain data equivalent to the corresponding nodes in the original list. But if the linked list is of an object, I still get a new list, but the data is just references to the objects that are also being referenced to by the nodes in the original list. How should I go about accounting for this difference in behavior?
Jun 30 2007
"muffles" <sgtmuffles myrealbox.com> wrote in message news:f66tbd$14o1$1 digitalmars.com...How should I go about accounting for this difference in behavior?Do you necessarily need to? What if your list is a list of objects which can't really be duplicated, such as objects which represent open files? Or what if you want to be able to dup the list and have the new list reference the same class instances? If you want to be a bit more flexible, you could auto-detect if the element type has a .dup method, and use it if it does. Here's a possible example. // The AutoDup parameter can be set to false in order to override the // automatic discovery of .dup methods; if it's false, when duplicated // and the element is a reference type, the new list will reference the // same data. class LinkedList(T, bool AutoDup = true) { struct Node { T data; Node* next; } .... LinkedList!(T, AutoDup) dup() { auto ret = new LinkedList!(T, AutoDup); ... // This use of is() is checking to see if the element type // has a dup method. This'll work for arrays too. static if(AutoDup && is(T.dup)) { for(Node* n = mHead; n !is null; n = n.next) ret.addNode(n.data.dup); } else { // No dup-ing for(Node* n = mHead; n !is null; n = n.next) ret.addNode(n.data); } return ret; } }
Jun 30 2007
Jarrett Billingsley wrote:static if(AutoDup && is(T.dup))Shouldn't that last bit be is(typeof(T.dup))?
Jul 01 2007
"Frits van Bommel" <fvbommel REMwOVExCAPSs.nl> wrote in message news:f682fm$c47$1 digitalmars.com...Jarrett Billingsley wrote:Yes, it probably should :D I always forget about the typeof, and then the compiler whines and I put it in..static if(AutoDup && is(T.dup))Shouldn't that last bit be is(typeof(T.dup))?
Jul 01 2007