If copying an object just create a new reference to the same object in memory then i don't understand why it is useful, because it only creates another name for the same object.
Copy, means for me, creating a clone of the object in another memory location.
Then i could manipulate 2 separate objects which are the same only at the moment of their copy but whom their live will be different.
I use C#.
Can someone explain me...
Thanks
John
Copying usually means actually creating a new object. However, the new object may be a shallow copy, so it may not actually hold references to new copy of the fields.
It's possible that the class you are looking at is Immutable, and the class designer decided that there was no need for the memory overhead.
Copying by reference is useful behaviour when you want to "pass around" an object to many components, either to allow many components to modify the state of the single object or to allow the functionality of the object to be used by multiple components.
Additionally, passing by reference avoids copying values, which can often produce a smaller memory footprint for an application.
If you wish, you can implement a Clone method on an object which will perform the behaviour you're asking for, allowing you to have a separate object to work with.
Lastly, if the behaviour of passing by reference doesn't seem natural for your object (for example your object is a fundamental value such as coordinate data), you can create a struct instead of a class. A struct or "structure" is copied by value, so when you pass it to a method, the entire object is copied and the copy passed to the method.
there are 3 kinds of copy
reference copy :giving another name to the object
shallow Copy : will create another copy of the object skeleton without the inner data
deep copy : will create another copy of the object and the data
you can read more about object copy in this link
http://en.wikipedia.org/wiki/Object_copy
You are right in your understanding that there are two, (actually three if you consider deep vs shallow copies) ways to reproduce a reference object.
You can copy the variables address into another variable (Same object on the Heap, now with another reference to it), or
You can create a new object on the heap and copy the values of the original objects properties and fields into the new object. This is generally called a Clone, and can be done in two ways Shallow or Deep.
Shallow Copy. Here you only copy primitives, and, where the object has properties which reference other reference types, only copy the reference, (i.e., the address), this is called a shallow copy, or,
Deep Copy. Here you copy primitives, and you can create new objects for each property which references another reference type.
You are right that copying creates a new object. I think the misconception comes from thinking of objects like primitives. Copying a primitive value and copying an object is done in different ways.
int x = 5;
int y = x;
y is a copy of x.
Object a = new object();
Object b = a;
b is a reference to a rather than a copy of a. To copy a you do need to write specific code to clone the object yourself.
I believe someone else will complain if Microsoft chooses implementing it in your way. It depends on the context that you using it to say which way is better. It's wise to take more efficient way as the default implementation.
Also, reference type is kind of like a pointer, so it makes sense to just copy the "pointer" itself in this case.
If you find this behavior is not what you desired, you can use your own implementation as well.
Related
With a dictionary with a nested class, for example: Dictionary<int, BankAccount>,
what's the difference between creating the class first as an object, then linking it to a new Dictionary, and creating the object directly into the Dictionary itself, for example:
dict.Add(1, new BankAccount());
var acc = new BankAccount();
dict.Add(1, acc);
Is there any benefit of using one over another?
The advantage of creating the object first, and adding it by reference is, that you hold the reference in the current method, and thus have full access to it.
If you create the object in line with the add method, you would have to fetch the object from the dictionary to gain access.
I do not see any other differences.
Creating the object first, could have code-maintainability benefits, when you find out later that the object needs to be modified.
The only real difference I could imagine is if you use the first option, the garbage collector doesn't have to hold onto a variable reference and can release the memory sooner. Other than that, it is more concise to choose the first option. Functionally, your options accomplish the same task.
My question concerns the use of objects in C#. I think I understand what's happening, but I want to understand why. For reasons I won't go into, I want to create a temporary copy of an object with its current data (current state). So I thought I could create a new object, assign it the original object, then change the original object. At that point I would have two objects in different states. But what happens is that the copied object ends up looking exactly like the first. Here is some code to illustrate:
Order o1 = new Order();
o1.property1 = "test 1";
Order o2 = new Order();
o2 = o1;
o1.property1 = "test 2";
But at the end of this code, both o1 and o2 have property1 set to "test 2". I think I realize that all objects are just pointers, so if you change one it changes another, but I can't understand why this is, or why it is useful. Is there some fundamental thing I'm missing here? Also, what would be the best way to accomplish what I want to do? Which is: store the state of the object, make changes, then revert if necessary. Hopefully this makes sense.
An object variable in C# is a reference (not a pointer) to a specific object in memory. When you declare
Order o2 = new Order();
you are creating a new Order object in the heap, and allocating a reference to that object to your o2 variable. When you then state
o2 = o1;
you are telling the compiler to make o2 a reference to o1. At this point, the reference to the original o2 object is lost, and the memory for that object will be removed during the next garbage collection sweep.
Henceforth, both o1 and o2 both reference the same object in memory. To copy information from one object to another, you will need to implement a procedure to instantiate a new destination object and copy all of the data from one object to the other. See the MSDN docs on ICloneable for more info.
What you are referring to is the difference between value types and reference types. Apparently your Order object is a reference type, I would assume it is a class.
Classes are reference types meaning they are "pointers". One of the reasons for this is performance as you do not want to copy huge amounts of data every time you assign a variable.
Structures are value types and would be copied in memory when you assign them.
You have 2 solutions :
Use a struct instead of class
Clone your object using either MemberwiseClone if it is very simple, or use your own method if you need to perform a deep clone.
This is by Design. If you want to clone and keep the clone independent i would recommend to Implement a "cloning" mechanism on your types. This can be ICloneable or even just a constructor that takes an instance and copies values from it.
Regarding your question
what would be the best way to accomplish what I want to do? Which is:
store the state of the object, make changes, then revert if necessary
A simple method is to simply serialize the object, e.g. using XMLSerializer. Then if you want to throw away your changes, just deserialize the original object and replace the modified object with the original version.
Use Structures to accomplish your task, Classes are reference type and Structs are Value type.
Classes are stored on memory heap
Structs are stored on stack.
for more info search Structs vs Classes and learn differences
Objects are, by definition, a 'pointer'; they hold a reference to your data, and not the actual data itself. You can assign it a value type though and it will give the appearance of holding the data.
As was mentioned above, understanding Value types vs. Reference types is key.
Java has no concept of any non-primitive data type other than an object reference; since almost anything one can do with an object reference involves acting upon the object referred to thereby, the . operator in Java . Although .net does have non-primitive value types, most .net languages maintain the convention (different from C and C++, which use -> to access a member of a pointed-to object and . to access a member of a structure) that the same . operator is used for both "dereference and access member" and "access value-type member".
Personally, I dislike Java's "everything is an object reference" design, and .net's decision to have value types and reference types use the same . operator to mean very different things doesn't help, but it is what it is.
I know when an assignment statement is made a new object is not made, a reference to the object is made instead. For instance I want to do the following:
word.start = newWordPos.First.Value;
word.end = newWordPos.Last.Value;
But every time the values of newWordPos.First.Value or newWordPos.Last.Value is updated, then word.start and word.end are updated as well. Is there any way I can get them to be assigned the actual value so that this does not occur?
Since your type is a class, you need to clone the object, not just assign a reference.
The type itself needs to provide some mechanism of creating a deep copy. The framework provides an interface (IClonable) which is for allowing a single Clone method - though it's not clear what form of cloning is being done (ie: full deep clone, etc).
I have in my program a struct type called Square which is used to represent the location (int Rank, int File) of a square on a chess board.
If I assign Square by new Square sq(); say and then I want to reassign it, is it better to do so by
sq = new Square(rank, file);
or by writing an internal Set method and calling Set thus
sq.Set(rank, file);
What I am asking is when you use new on a struct, does the runtime reallocate new memory and call the constructor or does it reuse the existing memory? If it does the former then it would be better to write a Set method to avoid overheads would it not? Cheers.
The traditional thinking these days is the value types should be immutable, so you would not want to have a Set method unless that is returning a new Square object and not mutating the original. As such,
sq = new Square(rank, file);
And
sq = sq.GenerateSquare(rank, file); // renamed Set method from original question to appease comments
Should ultimately perform the same operation.
But given this approach, GenerateSquare would also possibly be better as a static method of Square rather than something depending upon any given instance. (An instance method would be more useful if something about the existing instance was used in the creation of a new instance.)
Structures are value types, so a simple assignment will do the job:
Square sq = new Square(rank, file);
Square anotherSq = sq;
Worrying about the weight of garbage collection or memory use is something you should not be concerned with until you have profiled your application and know it will be an issue. A simple structure like this is not going be taking up much space and likely not the cause of problems if your program does hit a bottleneck.
For structs... space for new structs is created on the stack, (see NOTE), not the heap, and is not subject to garbage collection. If the assignment variable is an already existing copy of the struct, then it is overwritten. No additional memory is used.
NOTE: If you create a new struct and assign it to a variable that is a property of a reference type, then yes, the reference type is on the heap, but the memory slot the struct is copied to is the already existing memory slot for that already existing reference type, no new heap memory is allocated. And the struct is not independantly subject to garbage collection....
But others' comments about your design are correct, structs should generally only be used for immutable domain objects, things that are simple and easy to create (small footprint) and have no identity (i.e., one telephone number object set to (802) 123-4567 is equivilent to and can be used anywhere else you need a telephone number object set to (802) 123-4567
So in general, these objects should not have constrcutors or property setters, they should have static factory methods that create instances of them.
Can someone give an example of a situation where a shallow copy is needed?
Note that in some situations, shallow copy and deep copy are the same. This can happen when the object has no ownership over any of its subvariables; that is, all subvariables are aggregated. I'd like to see examples where the an object is composed from variables which it owns, and it still is desirable to copy them shallowly.
Remark: I don't care in which language the examples are given. I'm asking this question from a C++/Java/C# point of view, although I think copying is a language agnostic concept.
When the owned variables are immutable types, a shallow copy is sufficient. A deep copy is possible, but would only result in additional memory use.
One possible use case is when the composed objects can be derived from state information that is present in the shallow copy and you want, for instance, to serialize your object.
You can store the shallow copy and then rebuild the complete object from the state upon deserialization.
Coming from C++ POV, there would be one scenario that i will use shallow copy : when implementing copy-on-write mechanism.
class Element{
}
class Example {
private List<Element> elementList = new ArrayList<Element();
public List<Element> getElementList() {
return new ArrayList<Element>(this.elementList);
}
public void addElement(Element e) {
elementList.add(e);
}
public void removeElement(Element e) {
elementList.remove(e);
}
}
You want all modifications of Example.elementList to be done by object methods, but you want to expose elements stored in list. So you create getter which returns a shallow copy. Copy, because you don't want caller to modify object's list and shallow because you want to expose objects from list, not their copies.
If you look at the Gang of Four design patterns, there's a pattern called FlyWeight. Here's a quote from wikipedia:
A flyweight is an object that
minimizes memory use by sharing as
much data as possible with other
similar objects; it is a way to use
objects in large numbers when a simple
repeated representation would use an
unacceptable amount of memory.
This would be an acceptable use of a shallow copy.
As I pointed out in my answer to your related question, many languages don't really have the concept of shallow and deep copy. However, this class in C++, which prevents you from using a NULL pointer may be an example where a "shallow" copy is needed:
template <typename T>
struct NotNull {
T * p;
NotNull( T * t ) : p( t ) {}
T & operator *() {
if ( ! p ) {
throw "null!";
}
return * p;
}
};
The class does not own the thing pointed to, so no copy should be made.
My take on this is that the situations where you would use deep copy are different for C++ versus Java.
In C++, you might use deep copying to avoid difficult memory management issues, or to make it easier to implement a multi-threaded application.
In Java, deep copying is not necessary for those reasons. Since the languages are both garbage collected, it is not necessary to go through hoops to free data structures. So a deep copy is not necessary to simplify the problem. Similarly Java has built-in support for synchronizing access by multiple threads to shared data structures.
In most cases, deep copying is unnecessary in Java assuming that your application's data structures are well designed.
Shallow copies are quicker to make, which is often desirable for obvious reasons. The ultimate in shallow copying is obviously just a copy of a reference to the original object. If you're not mutating an object and can guarantee it won't get changed in other ways while you work with it then the more shallow the copy is, the better.
Remark: I don't care in which language the examples are given. I'm asking this question from a C++/Java/C# point of view, although I think copying is a language agnostic concept.
I think it depends quite a bit on the language.
In C++, copying plays a very different role than it does in Java/C#. In C++, I can't think of many cases where shallow copying makes sense. You'd usually just create references or pointers to an object instead. Copy constructors usually implement deep copies because in C++, an object takes ownership of its members, and is responsible for managing their lifetime. Because there's no GC, these ownership semantics become important, and you can't just have two objects pointing to a third without special care (do they use reference counting to keep the third alive? If not, which of the two objects owns it?)
I'd even say that the distinction between "deep" and "shallow" copies doesn't really make sense in C++. A copy creates all that is necessary for the newly created object to work. Sometimes, it shares a bit of data (typically data which isn't owned by either object), so it might not be a "true" deep copy", but it's not shallow either, because the bulk of the class typically is copied.