Printable View
I was wondering about this:
In Java (which is the OO programming language I am used to), this would cause both variables to point to the same object in memory, and cause obj2 to be garbage collected.Code:MyObject obj1;
MyObject obj2;
obj1 = obj2;
A don't know if in C++ it will do what Java does or make obj2 an independent duplicate of obj1? And if so, how do you make two variables point to the same object?
Assuming that MyObject has normal copying semantics, that would cause obj1 to be a copy of obj2. They are nonetheless different objects.
So, for example, if MyObject had a field "x", then continuing from my above example setting obj1.x = 5 would not make obj2.x == 5, right?
Right. It's copy constructed. If you wanted that behavior, you'd have to explicitly state it with a reference (&) or pointer (*) or something. Also given these are normal objects they will be destroyed at the end of the scope, freeing the memory. If you allocated the memory with malloc or new then you'd have to worry about collecting your own garbage (or use a smart pointer, etc). You get the idea.Quote:
Originally Posted by MTK
In this case copy assignment, not copy construction, is used.Quote:
Originally Posted by Dae
And in a case where I need the Java-like behavior, I guess should use pointers.
To get closer to Java you probably want reference-counted smart-pointers, like shared_ptr.Quote:
Originally Posted by MTK
Depends. You should prefer references to pointers where possible. References have the limitation that they cannot be reassigned to refer to something else.Quote:
Originally Posted by MTK
I read about references, and it says that once the scope of the originally declared variable runs out, all references will be invalid. Is there a way to avoid this?
How is that different from a pointer? A reference is just a pointer with different, sometimes-nicer-to-use language semantics.Quote:
Originally Posted by MTK
If you pass a pointer to a local variable to a function that runs in another thread, and original function finishes execution, the local variable will be destroyed and what the pointer in the thread then contains is undefined.
Same thing with references.
Is that not what you're referring to?
I'm just very strongly used to Java's way where all objects are actually references, and the object is destroyed only when all references are gone, not when the original reference went out of scope.
That is exactly what smart pointers do.
I find Java's references to be a real pain and a mess. They act like some reference-pointer hybrid.
C++ is the real deal, I would say, since using the == operator can actually compare the objects instead of the pointers (comparing two references compares the two objects).
You can also choose whether to check the pointers for equality or the objects themselves.
Doesn't Java's way use less CPU and memory because it doesn't do all that copying?
Oh lord. All it does is copy a 4 byte pointer. That's nothing compared to what Java does behind the scenes. C++ is quick, as in very quick. You don't really need to second guess the compiler very often.Quote:
Originally Posted by MTK
I thought C++ copies the whole object, not just a pointer.
In the case of
The object is copied.Code:Object obj1;
Object obj2;
obj1 = obj2;
However in the case of
p_obj2 is assigned the address of obj, thus it points to that object.Code:Object obj;
Object *p_obj2 = &obj;
However, you have to realize that java uses something called reference counting. It will automatically release memory for you when it goes out of scope.
ie in Java
When you call method() a new Integer object is created and x is made to point to it. Then x is made to point to a different Integer object which hold the value of 2. Since the old Integer object is no longer referenced it can never be recovered, thus the JVM garbage collector will delete and re-use the memory where the Integer object that has a 1 is located.Code:public void method() {
Integer x = new Integer(1);
x = new Integer(2);
}
However, in C/C++ when you make a pointer point to another object you are expected to handle the old object. This can be an annoyance at first, but it's a bit of an advantage (performance wise) when you can decide when to delete the memory which was previously taken up by the object. In java there is no guarantee of when the garbage collector is going to be called.
In java everything is pass by reference (except for primitives, which is pass by copy). In c++ everything is pass by copy. So when you don't want to copy an entire object, you just pass a copy of it's address (which is a pointer).
We could go on and on about this all day.
However, whenever I have a problem I go to .... no not google, but wikipedia and search it. Google is always second.
Wikipedia has a great comparison of Java and C++. It's much more in depth than anyone here will feel like writing.
cs_student
Unless you pass a pointer. That's the whole point. You can pass an object, making a copy of it. You could pass a pointer or a reference to the object. Either, as it suits the situation. So you have all the same choices you'd have in Java and then some.Quote:
Originally Posted by MTK
QFE!Quote:
Originally Posted by iMalc
King Mir is also correct though, you don't necessarily need to be exactly like Java in most cases. Use the best tools that the language provides you. Often that will be references, rather than any kind of pointer or smart-pointer.
On the contrary, in Java there is only pass by value (i.e., copy), but in C++ one has the choice of pass by value or pass by reference. However, variables of class type in Java are actually reference variables, whereas in C++ they really are object variables.Quote:
Originally Posted by cs_student
Sure, but it is also prone to blunders by editors who do not really know what they are talking about. For example, you presumably stated that "In java everything is pass by reference (except for primitives, which is pass by copy)" after reading that article's statement that in Java "Primitive data types always passed by value. Objects passed by reference." However, that very statement has a reference to another article, which actually contradicts this conclusion in favour of what I stated: Java is Pass-by-Value, Dammit! So much for citing references in Wikipedia, eh?Quote:
Originally Posted by cs_student
I'm going to call it pass-pointer-by-value, haha.
Everything is pass-by-value in Java, and the fact that primitive types aren't really objects, thus does not use references makes the whole damn thing just worse. Of course, then Java have to provide wrapper types that are Objects to the primitive types. Again, what's the point of both?
So pass a primitive type to a function - it is copied. Pass an object to a function - its reference, the reference you actually pass, is copied.
Then there's the fact that you can't actually make a reference to a reference in Java...
But it is possible to make a pointer to a pointer or reference to a pointer in C++.
Oh yes, don't forget that there is a difference.
Sometimes you WANT to make a copy of an object. In Java, this is tricky or annoying. Usually, constructing a new object and passing the old one in the constructor or using a clone member function.
This works OK when you need polymorphism, but not for being able to copy objects in a simple way. It's way less tedious in C++.
So Java's way isn't "better," because there are times when you want a copy of the actual object.
A true pass by reference is
and when the function ends, a == 100Code:void foo(ojb a)
{
a= 100;
}
In C++ this is not done. The type isn't "obj a". It is "obj& a". So a reference is passed by value. It is like C, except that C would use * rather than &. Their difference is
That is a syntax difference.Code:foo(a); //C++
foo(&a); //C
Java and C# compine two different meaning in one thing. Pointer and object becomes a reference and that causes the confusion. But there is confusion only because you think in a C++ way when you use Java. In Java you are not supposed to think references as pointers, but as objects, even though they are actually pointers.
So concluding, if you think everything in Java as an object then objects are passed by reference. If you think that references are pointers, then they are passed by value. The only exception is when you assign null. Then the "passing an object by reference" scheme doesn't work, but that is the only exception.
I believe Java is indented to use the "passing objects by reference". It fits it more.
That could very well be pass by name (or call by name, if you prefer). I posit that your example does not adequately express this "true pass by reference".Quote:
Originally Posted by C_ntua
The problem with saying that "a reference is passed by value" is that it is not. The reference is an alias, and that is at the heart of call by reference. As such, C++ references really do implement call by reference.Quote:
Originally Posted by C_ntua
I'd say that the syntax difference is important. One reason why it is important to note that a pointer is passed by value, even though passing a pointer gives call by reference semantics, is that it is possible to change the value of the pointer itself. It is not possible to change the value of a reference itself, and thus a reference is completely an alias.Quote:
Originally Posted by C_ntua
EDIT:
I suggest that you read the article that I linked to. As for references and pointers: pointers implement a reference mechanism; valid non-null pointers refer to something.Quote:
Originally Posted by C_ntua
if you say:Quote:
Originally Posted by MTK
then yes, it copies the entire object.Code:object obj1;
object obj2 = obj1;
but if you do the following:
then all it does is copy a 4-byte (or whatever the default size is for a pointer on your platform) pointer, and the second object IS the first object like in java.Code:object obj1;
object& obj2 = obj1;
OR
object* obj2 = &obj1;
This is what I'm talking about:
Code:int main() {
MyObject *o;
o = createObject();
cout << o->number << "\n"; //Is pointer o still valid, of did the o created by createObject() go out of scope, causing a segfault?
return 0;
}
MyObject *createObject() {
MyObject o;
o.number = 4;
return &o;
}
And this is what iMalc is talking about:Quote:
Originally Posted by MTK
Code:// ...
int main() {
std::tr1::<MyObject> o;
o = createObject();
cout << o->number << "\n";
return 0;
}
std::tr1::shared_ptr<MyObject> createObject() {
std::tr1::shared_ptr<MyObject> o(new MyObject);
o->number = 4;
return o;
}
The pointer is invalid since the local object that it points to has been destroyed. The behaviour is undefined.Quote:
Originally Posted by MTK
So is there a way to create a function that returns a valid pointer to an object that it created?
I know it can be done with malloc(), but it there a better "C++ Way"?
Yes. I have shown you one way. You could use an ordinary pointer too, except that you would have to care of memory management. (But you could use a smart pointer in the caller to immediately take ownership of the object pointed to by the pointer returned.)Quote:
Originally Posted by MTK
Code:// ...
int main() {
std::tr1::<MyObject> o;
o = createObject();
cout << o->number << "\n";
return 0;
}
std::tr1::shared_ptr<MyObject> createObject() {
std::tr1::shared_ptr<MyObject> o(new MyObject);
o->number = 4;
return o;
}
So this is the way you do it?
That depends on what I am trying to do, and what I can do. If I had the choice, I would write:Quote:
Originally Posted by MTK
Code:// ...
int main() {
MyObject o(4);
cout << o << "\n";
return 0;
}
So the best practice is to use pass-by-copy where possible, and pointers where you really need it to be the same object, not a copy of it, right?
The best practice is to do what is most appropriate for the situation. If you need a copy, copy, if you don't, don't.Quote:
Originally Posted by MTK
What when it doesn't really matter?
If it does not matter, that means that you do not need to copy, so you should not copy. That said, this is with respect to objects of class types that might be expensive to copy. For objects of built-in types, or for objects of class types that are specifically intended to be cheap to copy, then you would not need to use pass by (const) reference to avoid copying.Quote:
Originally Posted by MTK
The objects I am dealing with are quite large, and often will be created in seperate functions. If you are supposed to use pointers for big objects, this brings back the problem of them going out of scope when the object-creating function returns.
You might want to know that in some situations, return value optimisation can be performed. For example, if your function creates a local variable, maybe does some computation with it, and then returns the object by value, and then in the caller the return value is used to copy construct an object of the same type, it may be possible for the compiler to make it such that the copy construction does not happen, i.e., the object in the function and the object in the caller are treated as the same object.Quote:
Originally Posted by MTK
That is only a problem if you are trying to return a pointer or reference to a local variable, or otherwise use a local variable that has been destroyed in the caller. Avoiding this problem introduces the problem of having to do manual memory management, but this is where containers and smart pointers come in.Quote:
Originally Posted by MTK
When the object-creating function returns, the memory dynamically allocated by new will only be deallocated manually. So it works fine, you just need to handle memory management yourself. If for instance you didn't call delete, your program would probably still work, but with a lot of memory leaks. Instead of a pointer, use a smart pointer, and you can use it the same way as Java without any issues (object = create_object()). Most people will recommend you instead allocate an object, and pass it by reference to the object-creating function for initialization (create_object(object)). You get the same result, without pointers, and the function user can handle memory themselves. You can then omit the return value, or use a status value.Quote:
Originally Posted by MTK
In general, you should try to create objects in the function that uses them.
You can have factory methods, that return a pointer to a heap variable (a variable created by new). These can be plain pointers or smart pointers. Smart pointers are convenient in that they automatically provide exception safety, and that they automatically handle deletion for you. On the other hand you would be coupling object construction with memory management; you would force the particular type of smart pointer you chose. Factory methods add complexity, so don't use them unless you need them.
EDIT:
Regarding "object = create_object()" vs. "create_object(object)", It's a bit of a contested issue, and I would say that the second is better so long as there is something that could conceivably be done between creating the object and calling the method. If every creating of the object is followed by a call to the same method, then you're splitting object construction into two methods when it should be one. There should be no such thing a partially constructed object.
So for example I am creating my GUI toolkit project and the widgets must have pointers to each other, and all the functions that set/get them must also use pointers.
What do you recommend here, pointers, references, or smart pointers?
None of the above. The relationships between GUI widgets are so complex that no single answer could be correct. The problem is determining ownership and lifetime of the widgets. Ideally, you'd want a widget to go away when no other widget references it, which would suggest a smart pointer. But that doesn't help if two widgets reference each other in a cycle (either directly or indirectly), and it's not inconceivable that this could happen in a GUI framework.Quote:
Originally Posted by MTK
If you require that widgets always be organized in a DAG such that there are no cycles, then smart pointers can work. But better, in my opinion, is to designate a clear owner of every widget, and have that owner be responsible for destruction of the widget.
This means you need to have a way of allowing widgets to point at each other, with the understanding that the pointed-to widget could disappear at any moment (because its parent goes away). So you need some kind of weak pointer concept.
Each widget contains a pointer to its parent, and the parent obviously will wave a pointer to the child.
And what does DAG mean?
Sounds like you want to better understand the general design behind MVC to understand what mechanisms to employ to allow the features and functionality you want to have. It's all been done before. ^_^
Model–view–controller - Wikipedia, the free encyclopedia
Create an event based system to hand conditions for all existing windows, core MVC logic can manage states of various windows and update other nodes referencing it, etc.
The best choice to go with entirely deals with each mechanism and the general design of the system. The technical aspects of the programming should be made clear in your abstraction as you plan everything out in more detail. There's plenty of resources out there to help more, entire communities dedicated to designing UI systems.
I don't really know a whole lot personally about MVC design in detail but I know these design patterns exist and there are no standardized instructions for implementation (as far as I know).
So the key point here is that in C++ every object has at least one owner, either a function or another object, that controls it's life span. Smart pointers and scoped objects enforce ownership constraints, while raw pointers and references don't. (Generally when objects are passed by raw pointer or reference to a function then the object is guaranteed by the caller to remain alive for as long as the function needs it.) When planning your classes, this needs to be taken into consideration. This is tied to the difference between aggregation and composition in object oriented design, and it must be given special consideration in C++.