Ban pointers or references on classes?

This is a discussion on Ban pointers or references on classes? within the C++ Programming forums, part of the General Programming Boards category; Maybe I should just split this into a new topic and call it "Designing my smart pointer"...

  1. #76
    C++まいる!Cをこわせ! Elysia's Avatar
    Join Date
    Oct 2007
    Posts
    22,172
    Maybe I should just split this into a new topic and call it "Designing my smart pointer"

  2. #77
    Cat without Hat CornedBee's Avatar
    Join Date
    Apr 2003
    Posts
    8,892
    Or you could just use Boost's shared_ptr.

    Coming as std::tr1::shared_ptr to a compiler near you.
    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

  3. #78
    C++まいる!Cをこわせ! Elysia's Avatar
    Join Date
    Oct 2007
    Posts
    22,172
    Why toss away such a huge amount of work on something so great?
    Oh, and does Boost's shared_ptr allow you to do this?
    Code:
    int main()
    {
    	ppnew<int> p = 0; // Ref count == 1
    	int* test = p;
    	pp<int> p2 = test; // Ref count == 2
    	...
    }
    I store all pointers handled by the class in a map so it will never forget the ref count, even if you strip it from the class and attach it somewhere else.

  4. #79
    Cat without Hat CornedBee's Avatar
    Join Date
    Apr 2003
    Posts
    8,892
    No, it doesn't. But then, I consider this scenario quite contrived and useless. I also predict huge performance and/or correctness problems for you when you go multi-threaded.
    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

  5. #80
    C++まいる!Cをこわせ! Elysia's Avatar
    Join Date
    Oct 2007
    Posts
    22,172
    Not so useless when passing a raw pointer to a thread and then attaching it to a local smart pointer class.

  6. #81
    Cat without Hat CornedBee's Avatar
    Join Date
    Apr 2003
    Posts
    8,892
    Ah, but that's why the copy constructor in my thread affinity example didn't have a thread affinity check: because you're actually supposed to pass a (const!) reference/pointer to an existing smart pointer and create a copy there immediately, and only then signaling the creating thread that initialization is complete.
    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

  7. #82
    C++まいる!Cをこわせ! Elysia's Avatar
    Join Date
    Oct 2007
    Posts
    22,172
    Eh, two sides of a coin, two ways to do it, the same result. And it's more secure this way. Don't forget your pointers.
    Plus it will only check if you assign or attach (although it will store a pointer every time you make a new one).

  8. #83
    Cat without Hat CornedBee's Avatar
    Join Date
    Apr 2003
    Posts
    8,892
    And it's more secure this way. Don't forget your pointers.
    I quite disagree. I see hardly any security advantage at all. You can't ever forget your pointers if they're locked in smart pointers. And it raises the question (again!) of why you're passing around raw pointers in the first place.

    Also, have you considered the threading implications? Are your map accesses properly thread-safe? What's the effect of locking an application-wide mutex for every pointer destruction operation? (Especially since you seem to prefer passing the smart pointer by value to subroutines.)
    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. #84
    C++まいる!Cをこわせ! Elysia's Avatar
    Join Date
    Oct 2007
    Posts
    22,172
    Quote Originally Posted by CornedBee View Post
    Also, have you considered the threading implications? Are your map accesses properly thread-safe? What's the effect of locking an application-wide mutex for every pointer destruction operation? (Especially since you seem to prefer passing the smart pointer by value to subroutines.)
    Dunno.
    And if you're really worried about performance, don't use smart pointers.
    Going to have to use a profiler for performance questions.

  10. #85
    Cat without Hat CornedBee's Avatar
    Join Date
    Apr 2003
    Posts
    8,892
    Quote Originally Posted by Elysia View Post
    And if you're really worried about performance, don't use smart pointers.
    Oh, no, I don't think so at all. The work done by a smart pointer has to be done anyway. The smart pointer doesn't add overhead per se.

    It's your particular implementation that I'm concerned about. Let's just say that I highly distrust global data structures.
    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

  11. #86
    C++まいる!Cをこわせ! Elysia's Avatar
    Join Date
    Oct 2007
    Posts
    22,172
    Well... I think I can locate AMD's profiler and give it a try.
    The current amount of time spent in the memory manager class (with thread safety ON) is... 0.00&#37;!
    Last edited by Elysia; 10-29-2007 at 01:10 PM.

  12. #87
    Algorithm Dissector iMalc's Avatar
    Join Date
    Dec 2005
    Location
    New Zealand
    Posts
    6,264
    Quote Originally Posted by Elysia View Post
    Why toss away such a huge amount of work on something so great?
    Oh, and does Boost's shared_ptr allow you to do this?
    Code:
    int main()
    {
    	ppnew<int> p = 0; // Ref count == 1
    	int* test = p;
    	pp<int> p2 = test; // Ref count == 2
    	...
    }
    I store all pointers handled by the class in a map so it will never forget the ref count, even if you strip it from the class and attach it somewhere else.
    I've never heard of someone doing that before. What it does though is decouple the pointer value from the ownership semantics of the refcounting. Sure, that enables you to pass it around as a raw pointer, but that isn't particularly safe. The whole point of a smart pointer is that you wont have the class it points to getting deleted whilst anyone has a pointer to it, and it will be deleted as soon as there is nothing pointing to it. Dangling pointers lead to very nasty bugs!
    So again, just because you can do it, doesn't mean you should.

    The other thing is certainly efficiency. A global map of reference counts requires locking for every refcount change. This might work okay for a few pointers being accessed by just a few threads. However it would be a killer for an app I've worked on that may have 200 threads under normal operation. It just doesn't scale well. As a minimum you'd want to use an unordered_map (hash_map), or lock-free data structures, but even then it is an awful lot of bother for something that essentially does something we don't really want it to do.

    The profiling benchmark you mentioned is fairly meaningless. You could write a loop that uses your smart pointer 1000 times and then have a Sleep or GetMessage in there and you'd get the same result. In other words, it took 1/10000th the amount of time of what?
    My homepage
    Advice: Take only as directed - If symptoms persist, please see your debugger

    Linus Torvalds: "But it clearly is the only right way. The fact that everybody else does it some other way only means that they are wrong"

  13. #88
    C++まいる!Cをこわせ! Elysia's Avatar
    Join Date
    Oct 2007
    Posts
    22,172
    Yes, it's a big hit when time critical, but then I can always add functionality to disable it.

  14. #89
    Cat without Hat CornedBee's Avatar
    Join Date
    Apr 2003
    Posts
    8,892
    And then you remember for which pointers you disabled this functionality at runtime and don't try this trick? I don't believe it.

    I have the same opinion about your runtime decision for thread safety, by the way. It's just way too brittle.
    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. #90
    C++まいる!Cをこわせ! Elysia's Avatar
    Join Date
    Oct 2007
    Posts
    22,172
    Quote Originally Posted by CornedBee View Post
    And then you remember for which pointers you disabled this functionality at runtime and don't try this trick? I don't believe it.
    No. Wouldn't work very feasible.

    I have the same opinion about your runtime decision for thread safety, by the way. It's just way too brittle.
    Well, shrug. Nothing ventured, nothing gained.

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

Similar Threads

  1. Pointers v References
    By m37h0d in forum C++ Programming
    Replies: 28
    Last Post: 06-30-2008, 01:29 PM
  2. Replies: 12
    Last Post: 12-31-2007, 05:59 AM
  3. Pointers, Classes, and Errors o my!
    By Scottc1988 in forum C++ Programming
    Replies: 12
    Last Post: 03-13-2003, 09:14 PM
  4. Pointers to derived classes.
    By sean in forum C++ Programming
    Replies: 3
    Last Post: 11-13-2001, 07:19 PM
  5. Pointers to inherited classes
    By sean in forum C++ Programming
    Replies: 1
    Last Post: 11-03-2001, 02:04 PM

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