Jump to content

  • Log In with Google      Sign In   
  • Create Account


#ActualIcebone1000

Posted 24 March 2013 - 05:12 PM

Your cache class should own a shared_ptr, and it should hand out weak_ptrs.
shared_ptr implies ownership and access, weak_ptr implies access but not ownership. unique_ptr imples unique ownership and unique access.

You said, "and the data is really supposed to be shared around to avoid duplicates.", just incase you don't know, shared_ptr only shares the same variable when you tell it to.
If you do:

 

boost::shared_ptr<MyClass> ptrA = boost::make_shared<MyClass>(...);
boost::shared_ptr<MyClass> ptrB = boost::make_shared<MyClass>(...);
boost::shared_ptr<MyClass> ptrC = ptrA;

 

ptrA and ptrC point to the same MyClass. ptrB is an entirely different variable that points to a different MyClass.

You probably already know that, but I figured I'd mention it just incase.

You might also want to look into flyweight.

 

I also might be misunderstanding what you mean. Could you give an example of your problem? 'heap' memory means dynamic memory, IIRC. Shared pointers only operate on heap memory. Did you mean you have variables on the stack that you want to give shared access to? If so, use raw pointers (normal C or C++ pointers). Raw pointers aren't evil, they're just another tool in your toolbox. Not every use of pointers are supposed to be replaced by smart pointers.

I have a low level system who use shared pointers, this system by itself shares data trough shared pointers. But data isnt created by thys system, it comes from higher lvls systems who will be using it. What is bothering is that by doing that Im obligating heap allocation in the higher lvl module, otherwise I cant insert data to the low lvl module. Resuming..


#1Icebone1000

Posted 24 March 2013 - 05:11 PM

Your cache class should own a shared_ptr, and it should hand out weak_ptrs.
shared_ptr implies ownership and access, weak_ptr implies access but not ownership. unique_ptr imples unique ownership and unique access.

You said, "and the data is really supposed to be shared around to avoid duplicates.", just incase you don't know, shared_ptr only shares the same variable when you tell it to.
If you do:

 

boost::shared_ptr<MyClass> ptrA = boost::make_shared<MyClass>(...);
boost::shared_ptr<MyClass> ptrB = boost::make_shared<MyClass>(...);
boost::shared_ptr<MyClass> ptrC = ptrA;

 

ptrA and ptrC point to the same MyClass. ptrB is an entirely different variable that points to a different MyClass.

You probably already know that, but I figured I'd mention it just incase.

You might also want to look into flyweight.

 

I also might be misunderstanding what you mean. Could you give an example of your problem? 'heap' memory means dynamic memory, IIRC. Shared pointers only operate on heap memory. Did you mean you have variables on the stack that you want to give shared access to? If so, use raw pointers (normal C or C++ pointers). Raw pointers aren't evil, they're just another tool in your toolbox. Not every use of pointers are supposed to be replaced by smart pointers.

I have a low level system who use shared pointers, this system by itself shares data trough shared pointers. But data isnt created by thys system, it comes from higher lvls system who will be using it. What is bothering is that by doing that Im obligating heap allocation in the higher lvl module, otherwise I cant insert data to the low lvl module. Resuming..


PARTNERS