Pointers and Efficiency

This is a discussion on Pointers and Efficiency within the C++ Programming forums, part of the General Programming Boards category; And just a thought by me too: when it comes to classes, it's more efficient for functions to take pointers ...

  1. #1
    C++まいる!Cをこわせ! Elysia's Avatar
    Join Date
    Oct 2007
    Posts
    22,788

    Pointers and Efficiency

    And just a thought by me too: when it comes to classes, it's more efficient for functions to take pointers to them and create the objects on the heap to avoid hugging valueble stack space and to avoid all copying of objects forth and back, wasting precious resources and cpu time.
    Last edited by laserlight; 10-24-2007 at 01:16 PM. Reason: First line from earlier discussion.

  2. #2
    C++ Witch laserlight's Avatar
    Join Date
    Oct 2003
    Location
    Singapore
    Posts
    21,935
    And just a thought by me too: when it comes to classes, it's more efficient for functions to take pointers to them and create the objects on the heap to avoid hugging valueble stack space and to avoid all copying of objects forth and back, wasting precious resources and cpu time.
    In C++, this is not the only option: one could use pass by (const) reference instead of passing pointers.
    C + C++ Compiler: MinGW port of GCC
    Version Control System: Bazaar

    Look up a C++ Reference and learn How To Ask Questions The Smart Way

  3. #3
    Registered User
    Join Date
    Jan 2005
    Posts
    7,340
    >> it's more efficient for functions to take pointers to them and create the objects on the heap to
    >> avoid hugging valueble stack space and to avoid all copying of objects forth and back, wasting
    >> precious resources and cpu time.

    I disagree. Creating variables on the heap can be more expensive for small objects, it almost always leads to more bugs in your code (which is "expensive" itself) and in most cases you wouldn't notice a difference anyway. Use stack based objects unless you have a specific reason not to. In this case, one reason not to would be to keep objects around longer than the lifetime of the scope that created them, but as shown that isn't necessary and the alternative is perfectly appropriate.

  4. #4
    C++まいる!Cをこわせ! Elysia's Avatar
    Join Date
    Oct 2007
    Posts
    22,788
    Quote Originally Posted by laserlight View Post
    In C++, this is not the only option: one could use pass by (const) reference instead of passing pointers.
    But the thing is that the classes would need to be created on the heap, and then there's no real point in passing by reference. If the functions would take references only, the objects would go out of scope.
    If you have a pointer, why not just pass it along? Or am I missing something here?

  5. #5
    Registered User
    Join Date
    Jan 2005
    Posts
    7,340
    >> Or am I missing something here?
    Are you talking about a specific example in this thread? Which class and which example? (Actually, it's a bit off topic so a separate thread might be appropriate).

    In general you should prefer local automatic objects over dynamically allocated ones. If you see a specific case where that general rule doesn't apply can you point it out.

  6. #6
    C++ Witch laserlight's Avatar
    Join Date
    Oct 2003
    Location
    Singapore
    Posts
    21,935
    But the thing is that the classes would need to be created on the heap, and then there's no real point in passing by reference. If the functions would take references only, the objects would go out of scope.
    Ah, but the issues are separate: avoiding copying is not a valid reason to use dynamic memory allocation.
    C + C++ Compiler: MinGW port of GCC
    Version Control System: Bazaar

    Look up a C++ Reference and learn How To Ask Questions The Smart Way

  7. #7
    C++まいる!Cをこわせ! Elysia's Avatar
    Join Date
    Oct 2007
    Posts
    22,788
    I find it better and more efficient to make a function that takes a pointer, like the register:
    Code:
    void Register::RegisterCar(Car* pCar)
    And creating a new Car object and passing it along:
    Code:
    Register.RegisterCar( new Car(...) );
    It doesn't hug stack space, it doesn't do a lot of copying and I'm sure there are other benefits as well.
    The register could simply be responsible for cleaning up all the cars when it destructs.
    And it looks more object-oriented to me, as well, though that could just be me.

  8. #8
    Cat without Hat CornedBee's Avatar
    Join Date
    Apr 2003
    Posts
    8,893
    Yuck! That's a memory leak waiting to happen. (Depending on what RegisterCar does, of course.)

    And it's just you. Heap and stack have absolutely nothing to do with object-orientedness.

    Using new is a matter of size (you typically have about 1M of stack space, but 1G of heap), lifetime (if the object must survive past the end of the function) and binding (if you decide at runtime which kind of object you create).
    All the buzzt!
    CornedBee

    "There is not now, nor has there ever been, nor will there ever be, any programming language in which it is the least bit difficult to write bad code."
    - Flon's Law

  9. #9
    C++まいる!Cをこわせ! Elysia's Avatar
    Join Date
    Oct 2007
    Posts
    22,788
    Quote Originally Posted by CornedBee View Post
    Yuck! That's a memory leak waiting to happen. (Depending on what RegisterCar does, of course.)
    That it is not. The register creates records and should be responsible for cleaning them up as well. This is a usual approach I typically always use and which almost never results in memory leaks (usually they come from some screw-up elsewhere :P). You can also use a memory manager or smart pointer.
    Of course, this approach can also be used to avoid bugs with the duplication of objects and if you usally do not want your object to be duplicated.

    Anyway, carry on.

  10. #10
    C++ Witch laserlight's Avatar
    Join Date
    Oct 2003
    Location
    Singapore
    Posts
    21,935
    I find it better and more efficient to make a function that takes a pointer, like the register:
    Better and more efficient than what?

    That it is not. The register creates records and should be responsible for cleaning them up as well. This is a usual approach I typically always use and which almost never results in memory leaks (usually they come from some screw-up elsewhere :P). You can also use a memory manager or smart pointer.
    I agree, though CornedBee did qualify with "depending on what RegisterCar does, of course".
    C + C++ Compiler: MinGW port of GCC
    Version Control System: Bazaar

    Look up a C++ Reference and learn How To Ask Questions The Smart Way

  11. #11
    C++まいる!Cをこわせ! Elysia's Avatar
    Join Date
    Oct 2007
    Posts
    22,788
    Quote Originally Posted by laserlight View Post
    Better and more efficient than what?
    Than passing by value and copying the class at least 3 times (or twice).

  12. #12
    C++ Witch laserlight's Avatar
    Join Date
    Oct 2003
    Location
    Singapore
    Posts
    21,935
    Than passing by value and copying the class at least 3 times (or twice).
    I agree. On the other hand, I have noted that pass by reference is an option. It really depends on the situation.

    Even if one returns an object by value instead, in some cases return value optimisation may mean that extra copying will be eliminated.
    Last edited by laserlight; 10-24-2007 at 12:55 AM.
    C + C++ Compiler: MinGW port of GCC
    Version Control System: Bazaar

    Look up a C++ Reference and learn How To Ask Questions The Smart Way

  13. #13
    C++まいる!Cをこわせ! Elysia's Avatar
    Join Date
    Oct 2007
    Posts
    22,788
    Quote Originally Posted by laserlight View Post
    I agree. On the other hand, I have noted that pass by reference is an option. It really depends on the situation.
    Yes, but then you would at least attempt one copy of the class and if you keep using just references, the objects would go out of scope. References are useless things in modern C++, they're almost of no use.

    Code:
    class Register
    {
    private:
    Car* m_pCar;
    public:
    void RegisterCar(Car* pCar) { m_pCar = pCar; } // OK, no copying whatsoever.
    };
    Code:
    class Register
    {
    private:
    Car& m_rCar; // Will require initialization in constructor.
    };
    But this is a register, right? So we should be able to add objects and remove them at will, making this useless.

    Code:
    class Register
    {
    private:
    Car m_Car; // Oops, constructor will be called
    public:
    void RegisterCar(Car& rCar) { m_Car = rCar; } // Oops, copy constructor will be called
    };
    Not to mention that any resources used by m_Car will be allocated and you may have to overlord or specify your own copy constructor to release any resources that Car might use before copying the new object which will probably require memory copy.

    Code:
    class Register
    {
    private:
    Car* m_pCar;
    public:
    void RegisterCar(Car& rCar) { m_pCar = &rCar; } // BAD!
    };
    Useless, since references are just like pointers - compiler will pass the address to the object and it adds more complexity, having to do &rCar too, since we can't put a reference member unless it's initialized.

  14. #14
    Cat without Hat CornedBee's Avatar
    Join Date
    Apr 2003
    Posts
    8,893
    Quote Originally Posted by Elysia View Post
    That it is not. The register creates records and should be responsible for cleaning them up as well.
    And how do I, as a maintenance programmer, know that? How do I know, from looking at the code, that RegisterCar takes responsibility for the pointer?

    Pointers are awful low-level constructs. They're good for implementing high-level constructs, and should be avoided everywhere else.

    If the function does not take responsibility for the object, make the argument a reference. If it takes responsibility for the object and wants to take the object away from you, make the argument an auto_ptr. If it wants to keep the object indefinitely, make it a shared_ptr. If it wants to keep a reference to the object indefinitely without taking responsibility, make it a weak_ptr.
    Under no circumstances make it a raw pointer.

    References are useless things in modern C++, they're almost of no use.


    References are not the right tool for the use case at hand, but that doesn't mmake them useless. The idea that references are useless in modern C++ will get you laughed at by practitioners of modern C++.
    All the buzzt!
    CornedBee

    "There is not now, nor has there ever been, nor will there ever be, any programming language in which it is the least bit difficult to write bad code."
    - Flon's Law

  15. #15
    C++まいる!Cをこわせ! Elysia's Avatar
    Join Date
    Oct 2007
    Posts
    22,788
    Quote Originally Posted by CornedBee View Post
    And how do I, as a maintenance programmer, know that? How do I know, from looking at the code, that RegisterCar takes responsibility for the pointer?
    One should always take implemtation into mind. Decide who takes responsibility for the pointers.

    Pointers are awful low-level constructs. They're good for implementing high-level constructs, and should be avoided everywhere else.
    But there are no good alternatives to pointers. References are near uselss. auto_ptr, etc, are you pointer handling classes to my knowledge.

    If the function does not take responsibility for the object, make the argument a reference. If it takes responsibility for the object and wants to take the object away from you, make the argument an auto_ptr. If it wants to keep the object indefinitely, make it a shared_ptr. If it wants to keep a reference to the object indefinitely without taking responsibility, make it a weak_ptr.
    Under no circumstances make it a raw pointer.
    That makes absolutely no sense to me at all. Wrap all memory pointers in memory handling classes such as auto_ptr and be done with it. I don't really have much insight into auto_ptr, shared_ptr and weak_ptr, but again, I tend to handle everything myself. Any class that gets rids of memory when no longer in use is okay by me.



    References are not the right tool for the use case at hand, but that doesn't mmake them useless. The idea that references are useless in modern C++ will get you laughed at by practitioners of modern C++.
    Near useless. They're incredibly static, not dynamic. Must be initialized, and that is almost THE biggest flaw of them. I only use references when a function works with local variables and does not intend to store them in any way (and assuming it's not a thread, and the arguments are not pointers to begin with).

    Anyway, I take effciency before pass by value any day.

Page 1 of 6 123456 LastLast
Popular pages Recent additions subscribe to a feed

Similar Threads

  1. Improving the efficiency..
    By aaronljx in forum C Programming
    Replies: 11
    Last Post: 12-01-2008, 09:09 AM
  2. trouble with file pointers...
    By quasigreat in forum C Programming
    Replies: 4
    Last Post: 05-19-2008, 08:12 AM
  3. Function Pointers in C
    By Gobinath in forum C Programming
    Replies: 7
    Last Post: 03-10-2005, 10:54 AM
  4. Request for comments
    By Prelude in forum A Brief History of Cprogramming.com
    Replies: 15
    Last Post: 01-02-2004, 09:33 AM
  5. Question about efficiency... structures and stuff
    By rmullen3 in forum C++ Programming
    Replies: 2
    Last Post: 01-05-2002, 12:00 PM

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21