Pointers and Efficiency

This is a discussion on Pointers and Efficiency within the C++ Programming forums, part of the General Programming Boards category; I cherish the power they've given to developers to design with, but if they're designing a safe language, shouldn't they ...

  1. #31
    C++ Witch laserlight's Avatar
    Join Date
    Oct 2003
    Location
    Singapore
    Posts
    22,269
    I cherish the power they've given to developers to design with, but if they're designing a safe language, shouldn't they use a safe approach to copy? If you don't like it, you can, of course, override it.
    That is if you are looking at it from the point of view of someone who wants to use raw pointers as member variables. By storing an object, or a container of objects, there would be no need to explicitly perform deep copying. Likewise, the use of smart pointers would reduce, if not eliminate, the danger of not copying the objects pointed to.
    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

  2. #32
    C++まいる!Cをこわせ!
    Join Date
    Oct 2007
    Posts
    23,012
    Quote Originally Posted by laserlight View Post
    That is if you are looking at it from the point of view of someone who wants to use raw pointers as member variables. By storing an object, or a container of objects, there would be no need to explicitly perform deep copying. Likewise, the use of smart pointers would reduce, if not eliminate, the danger of not copying the objects pointed to.
    I use raw pointers as members as I know full well what I'm doing, but the copy constructor is something that's passed down by the compiler, not something I choose. I can't choose if I should have a simple or deep copy (unless I create one myself).

  3. #33
    C++ Witch laserlight's Avatar
    Join Date
    Oct 2003
    Location
    Singapore
    Posts
    22,269
    I use raw pointers as members as I know full well what I'm doing, but the copy constructor is something that's passed down by the compiler, not something I choose.
    Actually, since you want to program without making copies of such objects, it may be safer from a design point of view to make your copy constructors and copy assignment operators private. That way you can be sure that there is no copying and so sidestep this issue altogether.

    You may know full well what you are doing now, but there's no guarantee that you will always have that knowledge at your fingertips, much less for a maintenance programmer.
    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

  4. #34
    C++まいる!Cをこわせ!
    Join Date
    Oct 2007
    Posts
    23,012
    Quote Originally Posted by laserlight View Post
    Actually, since you want to program without making copies of such objects, it may be safer from a design point of view to make your copy constructors and copy assignment operators private. That way you can be sure that there is no copying and so sidestep this issue altogether.
    That only sidesteps the problem, it doesn't fix it If I wanted a safe copy, I would overload the copy constructor, if I see that it may be necessary.

    You may know full well what you are doing now, but there's no guarantee that you will always have that knowledge at your fingertips, much less for a maintenance programmer.
    Exactly! And that's wy behind-the-scenes operations (VB(tm)) should be done as safe as possible, lest I be given a choice!

  5. #35
    C++ Witch laserlight's Avatar
    Join Date
    Oct 2003
    Location
    Singapore
    Posts
    22,269
    And that's wy behind-the-scenes operations (VB(tm)) should be done as safe as possible, lest I be given a choice!
    Changing the default for copying may suit your programming style, but does not benefit the RAII programming style of modern C++. Effectively, you are forcing composition by default, but in some cases a weaker form of association may be required, so a shallow copying of pointers would be expected. Deep copying may even be the "unsafe" behaviour in this case.
    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

  6. #36
    C++まいる!Cをこわせ!
    Join Date
    Oct 2007
    Posts
    23,012
    Then perhaps we should be given a choice, to choose what method of copying we want. It sounds to me that we have to overlord the copy constructor all the time if we want the operation to be safe and without regrets.

  7. #37
    Cat without Hat CornedBee's Avatar
    Join Date
    Apr 2003
    Posts
    8,893
    I wouldn't be surprised if the committee had preferred not giving classes a default copy constructor and copy assignment operator at all. In fact, I know that several people have argued for this approach.
    But in the end, C compatibility necessitates generating default copy functions.

    Making the default copiers make deep copies is quite simply impossible. As I've pointed out before, pointers carry no semantic information. It's impossible to tell if a pointer points to a global object, a local object, a heap-allocated object or whatever. It's impossible to tell what the programmer's desired copy semantics are. (Thus the various smart pointers: scoped_ptr with noncopyable semantics, auto_ptr and its C++09 successor unique_ptr with move semantics, shared_ptr with object sharing (reference counting) semantics, the experimental clone ptr with deep copy semantics.) There's also not really a way to implement deep copying: you'd have to build a clone functionality in the language, as Java has. (Think polymorphism. Naive deep copying leads to object splicing.)



    You have to overload the copy constructor only for objects that don't have the copy semantics of their members defined, i.e. they use raw pointers for members.
    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

  8. #38
    C++まいる!Cをこわせ!
    Join Date
    Oct 2007
    Posts
    23,012
    Or something else the compiler can have no knowledge about, such as handles to different objects (like *cough* hwnd and hbitmap *cough*), which would usually become invalid or destroyed (since the class destructor would release them when done with them).

  9. #39
    Cat without Hat CornedBee's Avatar
    Join Date
    Apr 2003
    Posts
    8,893
    True, those make it even harder.
    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

  10. #40
    C++ Witch laserlight's Avatar
    Join Date
    Oct 2003
    Location
    Singapore
    Posts
    22,269
    Making the default copiers make deep copies is quite simply impossible. As I've pointed out before, pointers carry no semantic information. It's impossible to tell if a pointer points to a global object, a local object, a heap-allocated object or whatever.
    This could be changed, at the cost of otherwise unnecessary overhead and breaking compatibility with C. Effectively, all raw pointers would become a kind of smart pointer, and it would be the programmer's responsibility not to take as members pointers to objects on the stack (or on the heap without ownership of the object) and yet not overloading the copy constructor and assignment operator.

    It would be like the reverse of the current situation, but ignoring the benefits of RAII.
    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. #41
    Malum in se abachler's Avatar
    Join Date
    Apr 2007
    Posts
    3,189
    Quote Originally Posted by CornedBee View Post
    (you typically have about 1M of stack space, but 1G of heap)
    1M default, you can bump it in the project settings, and 2GB heap, bumpable to 3GB or 16 million TB if you go 64 bit. As for the rest fo the discussion, while it may make some exceedingly rare problems easier to solve, forcing the use of non-raw pointers presents serious performance isues as well as permanently removing functionality from teh language. One of the core concepts of C/C++ is 'assume the programmer knows what they are trying to accomplish'. If this isnt the case, then the programmer needs to rethink the problem. Trying to add too much functionality to the language will end up robbing it of its best assets, that is speed and versatility. Should we take out re-casting because some goof might forget the original type of the pointer and try to access a member variable of the wrong structure or class? Perhaps we shoudl take out run time memory allocation all together since someone might write sloppy code that causes a protection fault? At some point, you have to just trust that the people writing the code will know wtf they are doing. If you cant trust this, then perhaps you need to write teh code yourself, or just go back to using an abacus.

    Yes its would be nice if the compiler did all your thinking for you, but honestly, if you cant keep track of which member variables are pointing to what types and coordiante their proper construction and destruction, then you need to find some simpler approach.
    Last edited by abachler; 10-24-2007 at 04:06 PM.
    Until you can build a working general purpose reprogrammable computer out of basic components from radio shack, you are not fit to call yourself a programmer in my presence. This is cwhizard, signing off.

  12. #42
    and the hat of sweating
    Join Date
    Aug 2007
    Location
    Toronto, ON
    Posts
    3,545
    By using pointers & C functions everywhere instead of references & STL, you've effectively become a C+ programmer. Unfortunately my company is filled with C+ programmers, which makes my job a nightmare when I have to figure out what the code is doing and try to fix it.

    I'd highly recommend reading these 2 books:
    "C++ Coding Standards" by Herb Sutter & Andrei Alexandrescu
    and "Effective STL" by Scott Meyers.
    If they can't convince you to add another + to your C+ style, then I don't know what will.

  13. #43
    Cat without Hat CornedBee's Avatar
    Join Date
    Apr 2003
    Posts
    8,893
    Quote Originally Posted by abachler View Post
    1M default, you can bump it in the project settings,
    On Windows. On Unices, the stack may well be limited by the ulimit, and there's nothing a non-root can do about it.

    and 2GB heap,
    Only if you have enough RAM and swap to support that. (And you share those things with all other programs in the system.) Also, allocation overhead and heap fragmentation eventually lead to less being available. But my number was merely meant to illustrate that the heap is about 3 orders bigger than the stack.
    For example, I have 1 Gig of RAM and 2 Gigs of swap. Makes for 3 Gigs total. It's a 64-bit system, so in theory, every program has 2^48 bytes of virtual address space (~200 TB) - note that at least early Athlon64s only support 42 physical and 48 virtual address bits. But with everything, a program can actually use perhaps 2.8 Gigs, and it probably slows down to a crawl due to excessive swapping long before that.
    Given current typical amounts of RAM, and assuming that you don't want your program consume more memory than is physically available (swap is for inactive programs, IMO), 1 Gig is a good guideline. Currently sold systems usually vary between 512M and 2G.
    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. #44
    C++まいる!Cをこわせ!
    Join Date
    Oct 2007
    Posts
    23,012
    Quote Originally Posted by cpjust View Post
    By using pointers & C functions everywhere instead of references & STL, you've effectively become a C+ programmer. Unfortunately my company is filled with C+ programmers, which makes my job a nightmare when I have to figure out what the code is doing and try to fix it.
    I usually wrap the pointers in a memory handler and use MFC, not so much C.

  15. #45
    Registered User
    Join Date
    Nov 2006
    Posts
    519
    Quote Originally Posted by CornedBee View Post
    They make rather poor class members, but that is their only flaw.
    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?

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

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