Thread: How objects are stored

  1. #31
    Registered User
    Join Date
    Aug 2009
    Posts
    198
    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?

  2. #32
    C++ Witch laserlight's Avatar
    Join Date
    Oct 2003
    Location
    Singapore
    Posts
    28,413
    Quote Originally Posted by MTK
    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 Bjarne Stroustrup (2000-10-14)
    I get maybe two dozen requests for help with some sort of programming or design problem every day. Most have more sense than to send me hundreds of lines of code. If they do, I ask them to find the smallest example that exhibits the problem and send me that. Mostly, they then find the error themselves. "Finding the smallest program that demonstrates the error" is a powerful debugging tool.
    Look up a C++ Reference and learn How To Ask Questions The Smart Way

  3. #33
    Registered User
    Join Date
    Aug 2009
    Posts
    198
    What when it doesn't really matter?

  4. #34
    C++ Witch laserlight's Avatar
    Join Date
    Oct 2003
    Location
    Singapore
    Posts
    28,413
    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 Bjarne Stroustrup (2000-10-14)
    I get maybe two dozen requests for help with some sort of programming or design problem every day. Most have more sense than to send me hundreds of lines of code. If they do, I ask them to find the smallest example that exhibits the problem and send me that. Mostly, they then find the error themselves. "Finding the smallest program that demonstrates the error" is a powerful debugging tool.
    Look up a C++ Reference and learn How To Ask Questions The Smart Way

  5. #35
    Registered User
    Join Date
    Aug 2009
    Posts
    198
    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.

  6. #36
    C++ Witch laserlight's Avatar
    Join Date
    Oct 2003
    Location
    Singapore
    Posts
    28,413
    Quote Originally Posted by MTK
    The objects I am dealing with are quite large, and often will be created in seperate functions.
    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
    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.
    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 Bjarne Stroustrup (2000-10-14)
    I get maybe two dozen requests for help with some sort of programming or design problem every day. Most have more sense than to send me hundreds of lines of code. If they do, I ask them to find the smallest example that exhibits the problem and send me that. Mostly, they then find the error themselves. "Finding the smallest program that demonstrates the error" is a powerful debugging tool.
    Look up a C++ Reference and learn How To Ask Questions The Smart Way

  7. #37
    Deprecated Dae's Avatar
    Join Date
    Oct 2004
    Location
    Canada
    Posts
    1,034
    Quote Originally Posted by MTK View Post
    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.
    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

  8. #38
    Registered User
    Join Date
    Apr 2006
    Posts
    2,149
    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.

  9. #39
    Registered User
    Join Date
    Aug 2009
    Posts
    198
    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?

  10. #40
    Officially An Architect brewbuck's Avatar
    Join Date
    Mar 2007
    Location
    Portland, OR
    Posts
    7,396
    Quote Originally Posted by MTK View Post
    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);
    //}

  11. #41
    Registered User
    Join Date
    Aug 2009
    Posts
    198
    Each widget contains a pointer to its parent, and the parent obviously will wave a pointer to the child.

    And what does DAG mean?

  12. #42
    Registered User
    Join Date
    Nov 2009
    Posts
    82
    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.

  13. #43
    Registered User
    Join Date
    Apr 2006
    Posts
    2,149
    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.

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. Vector of pointers to vector of objects
    By Litz in forum C++ Programming
    Replies: 10
    Last Post: 11-06-2009, 03:29 PM
  2. Objects as attributes of other objects.
    By kbro3 in forum C++ Programming
    Replies: 10
    Last Post: 08-15-2009, 03:46 PM
  3. Replies: 60
    Last Post: 12-20-2005, 11:36 PM
  4. chain of objects within pop framework help needed
    By Davey in forum C++ Programming
    Replies: 0
    Last Post: 04-15-2004, 10:01 AM
  5. array of objects?
    By *~*~*~* in forum C++ Programming
    Replies: 4
    Last Post: 05-31-2003, 05:57 PM