Pointers and Efficiency

This is a discussion on Pointers and Efficiency within the C++ Programming forums, part of the General Programming Boards category; Originally Posted by pheres Hm, what'd be wrong with Code: class World; class Entity { const World& mr_world; public: Entity(const ...

  1. #46
    C++まいる!Cをこわせ! Elysia's Avatar
    Join Date
    Oct 2007
    Posts
    22,606
    Quote Originally Posted by pheres View Post
    Hm, what'd be wrong with

    Code:
    class World;
    
    class Entity
    {
        const World& mr_world;
    
    public:
       Entity(const World& _world)
       :mr_world(_world)
       {}
    };
    I'm using such construcs all the time for keeping associations to parent classes. I find raw pointers meaningless and every other programmer would be confused about it's semantic, as you pointed out. But whats wrong with this reference as class member?
    That's their biggest flaw:
    They need to be initialized. Therefore, it's impossible to dynamically add or assign to these members after the object has been created. And that's a very, very, very handy concept that it very used.
    If you can't assign your class members at will, your class is almost useless.

  2. #47
    Registered User
    Join Date
    Nov 2006
    Posts
    519
    Why should, using the abstraction of a universe as we observe it with our limited human senses, an entity ever switch to another world?

  3. #48
    and the hat of sweating
    Join Date
    Aug 2007
    Location
    Toronto, ON
    Posts
    3,545
    Quote Originally Posted by Elysia View Post
    That's their biggest flaw:
    They need to be initialized. Therefore, it's impossible to dynamically add or assign to these members after the object has been created. And that's a very, very, very handy concept that it very used.
    If you can't assign your class members at will, your class is almost useless.
    That's only for specific types of classes that share data (like your Register class). For other classes that keep their own data separate from other classes, references or copies are better. I haven't needed to use your kind of classes much. Most of my classes don't need to use shared data.

    What kind of code do you work on that requires so much data sharing? Is it Windows GUI code?

  4. #49
    C++まいる!Cをこわせ! Elysia's Avatar
    Join Date
    Oct 2007
    Posts
    22,606
    That's hard to say. It's not that much related to GUI, but more to internal processing of the application.

  5. #50
    Registered User
    Join Date
    Jan 2005
    Posts
    7,318
    >> I usually wrap the pointers in a memory handler and use MFC, not so much C.
    Would you say your memory handler is more like a garbage collector or a smart pointer?

  6. #51
    C++まいる!Cをこわせ! Elysia's Avatar
    Join Date
    Oct 2007
    Posts
    22,606
    That depends on what a "smart pointer" is. I could see it as a safe garbage collector, too. It uses a reference count to keep track of the lifetime of an object and works strictly on the design that it strictly owns the memory you want to create and will not allow you to assign a new pointer to it.
    It can also take ownership of memory by attaching a pointer, though it requires you to manually set the reference count (since it can't do that) and it also requires a pointer to a pointer, setting your original pointer to NULL to indiciate that it owns the memory now. You are not allowed to manipulate the memory outside the class.

  7. #52
    Registered User
    Join Date
    Jan 2005
    Posts
    7,318
    I guess I'm asking whether it is a class that wraps the pointer, so that you have to pass around instances of the class rather than the raw pointer itself, or whether you overload new and delete to handle the memory and you just pass around raw pointers in your program.

  8. #53
    C++まいる!Cをこわせ! Elysia's Avatar
    Join Date
    Oct 2007
    Posts
    22,606
    Quote Originally Posted by Daved View Post
    I guess I'm asking whether it is a class that wraps the pointer, so that you have to pass around instances of the class rather than the raw pointer itself...
    Yes, you have to pass around the container. The container will not accept a raw pointer (neither through the constructor or operator =), though there is an Attach function, as I explained, that takes ownership of memory.
    You have to pass around the container since otherwise it can't keep track of the reference count and it would be very unsafe to let go of the memory that the class owns.
    What it is not for is generic pointers that you can use for shortcuts or walking through memory blocks or such. In other words, pointers where you do not allocate memory.

    ...or whether you overload new and delete to handle the memory and you just pass around raw pointers in your program.
    No, that is not what I do.

    The goal is simple: a safe and easy class that destroys objects when no longer in use, but provides easy access to the memory pointer by the pointer.

  9. #54
    Registered User
    Join Date
    Jan 2005
    Posts
    7,318
    So you use a smart pointer. That sounds exactly like what shared_ptr does (the almost standard reference counting smart pointer).

    In your post (#7 in this thread) you give an example using raw pointers. That's generally a bad idea. (Although I do that all the time in my MFC app because I want to follow the coding style of the code around me, raw pointers are not something to be advised.) If you use your smart pointer for that, then it's fine.

    In the end, there are reasons to use pointers to dynamic memory. Those cases include large/expensive to copy objects, or objects that must live beyond the lifetime of the scope in which they are created. In those instances, though, the pointer should always be wrapped in a smart pointer which is then passed around by value. I think you agree with this, right?

    So I'm wondering where the disagreement is. Perhaps your definition of "large or expensive to copy" is broader than others? Or maybe in your experience it is so common that you think that should be the default solution?

    My viewpoint is that the default solution should be the simplest one that works. In most cases (including the case of esmeco's code that started this conversation), the objects are small enough that containing them directly as objects rather than pointers will likely have no noticeable effect on performance. Therefore, doing so should be preferred because it is simpler than using dynamic memory and a smart pointer.

  10. #55
    C++まいる!Cをこわせ! Elysia's Avatar
    Join Date
    Oct 2007
    Posts
    22,606
    Quote Originally Posted by Daved View Post
    In the end, there are reasons to use pointers to dynamic memory. Those cases include large/expensive to copy objects, or objects that must live beyond the lifetime of the scope in which they are created. In those instances, though, the pointer should always be wrapped in a smart pointer which is then passed around by value. I think you agree with this, right?
    Yes. There's no use (and a bad idea) to pass such a smart pointer around by reference. I wonder if it's possible to restrict that.

    So I'm wondering where the disagreement is. Perhaps your definition of "large or expensive to copy" is broader than others? Or maybe in your experience it is so common that you think that should be the default solution?
    In my view, classes should not be passed by value. Either reference or by a pointer, the later is usually the most used solution.

    My viewpoint is that the default solution should be the simplest one that works. In most cases (including the case of esmeco's code that started this conversation), the objects are small enough that containing them directly as objects rather than pointers will likely have no noticeable effect on performance. Therefore, doing so should be preferred because it is simpler than using dynamic memory and a smart pointer.
    Here's where I disagree. Classes should be passed around by pointers or references. Using a smart pointer is not such a trivial task at all. You can work with it like usual, though using -> instead of ".". The smart pointer will take care of deleting the object for you as well.
    I don't know exactly why, but having classes as members (some_class m_class; some_class* m_pclass is okay) is just not something that agrees with me. Maybe it's just more flexible? I tend to choose flexibility before simplicity.
    But passing pointers also has the advantage of not having to worry about a copy constructor.

  11. #56
    Registered User
    Join Date
    Jan 2005
    Posts
    7,318
    C++ is designed to allow you flexibility if you desire it. There are tradeoffs, though. Code clarity and robustness are two areas that are hindered when you try to take advantage of the flexibility. If you choose to do that in your application, fine, but most C++ experts agree that one should tend more towards the simplicity to gain the advantages doing so provides. In this case we are advising others on what we think is the best practices to learn for their coding.

    There are a lot of cases where using a smart pointer makes sense more sense than a plain object, but there are almost always alternatives to raw pointers. So I won't have any issue with you giving your opinion that objects should always be held in smart pointers (even if I disagree), but please be careful about advising others to use raw pointers over plain objects, especially for C++ beginners.

    >> But passing pointers also has the advantage of not having to worry about a copy constructor.
    And storing (raw) pointers in the class has the disadvantage of making you worry about writing your own copy constructor.

    I think you are worrying too much about the cost of copying objects and not enough about easy to read, easy to maintain, and more robust code. Sure it annoys me when I see other developers in my project passing around CString by value when a reference to const would work as well. However, even when I "fix" all those places, it has no noticeable effect on performance.

  12. #57
    C++まいる!Cをこわせ! Elysia's Avatar
    Join Date
    Oct 2007
    Posts
    22,606
    I guess it's all up to your own style, huh? I will keep in mind about being careful when suggesting pointers to beginners.

  13. #58
    Cat without Hat CornedBee's Avatar
    Join Date
    Apr 2003
    Posts
    8,893
    Quote Originally Posted by pheres View Post
    Code:
    class World;
    
    class Entity
    {
        const World& mr_world;
    
    public:
       Entity(const World& _world)
       :mr_world(_world)
       {}
    };
    Nothing, really. You just have to remember that, once you have a reference member, several things happen. First, you don't get a generated copy assignment operator. Second, the class is no longer a POD, even if it would have been otherwise. Third, if the reference can refer to different objects in different instances, you cannot implement a reliable assignment operator or a reliable swap, because the functions would have to fail for objects coming - in your example - from different worlds. Built-in xenophobia

    So when I said that references make poor class members, I was referring to the fact that having a reference member affects the design of the class.
    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

  14. #59
    Captain Crash brewbuck's Avatar
    Join Date
    Mar 2007
    Location
    Portland, OR
    Posts
    7,239
    Quote Originally Posted by Elysia View Post
    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).
    What a crock. I've written several programs larger than 10,000 lines without ever using a pointer except in "char **argv."

    Anyway, I take effciency before pass by value any day.
    Pointer-free code is both easier to understand and often more efficient. You just can't seem to imagine how it looks.

  15. #60
    C++まいる!Cをこわせ! Elysia's Avatar
    Join Date
    Oct 2007
    Posts
    22,606
    Quote Originally Posted by brewbuck View Post
    What a crock. I've written several programs larger than 10,000 lines without ever using a pointer except in "char **argv."
    I have written programs with lots of lines where I didn't need a single reference.
    And it actually worked.

    Pointer-free code is both easier to understand and often more efficient. You just can't seem to imagine how it looks.
    Not really. Pointers look natural to me. References look unnatural for the most because of their static nature.

Page 4 of 6 FirstFirst 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