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?
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.Originally Posted by MTK
Look up a C++ Reference and learn How To Ask Questions The Smart WayOriginally Posted by Bjarne Stroustrup (2000-10-14)
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.Originally Posted by MTK
Look up a C++ Reference and learn How To Ask Questions The Smart WayOriginally Posted by Bjarne Stroustrup (2000-10-14)
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.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.Originally Posted by MTK
Look up a C++ Reference and learn How To Ask Questions The Smart WayOriginally Posted by Bjarne Stroustrup (2000-10-14)
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.
Warning: Have doubt in anything I post.
GCC 4.5, Boost 1.40, Code::Blocks 8.02, Ubuntu 9.10 010001000110000101100101
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.
Last edited by King Mir; 11-30-2009 at 10:30 PM.
It is too clear and so it is hard to see.
A dunce once searched for fire with a lighted lantern.
Had he known what fire was,
He could have cooked his rice much sooner.
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.
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.
Code://try //{ if (a) do { f( b); } while(1); else do { f(!b); } while(1); //}
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).
Last edited by since; 12-01-2009 at 04:42 PM.
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++.
It is too clear and so it is hard to see.
A dunce once searched for fire with a lighted lantern.
Had he known what fire was,
He could have cooked his rice much sooner.