NOTE: I've found the source of the error is not actually related to the shared_ptr, just cleverly disguised as such in the error message. Thus the below is basically nonsense (not the answers, they're fine)
--
I'm having some trouble using a shared_ptr
(boost's at the moment) where I need to simply forward a pointer to another function. Using native pointers the intervening function would not need to have access to the definition of the class, but using smart_ptr's it appears it does. Is there any way to avoid this?
For example, given a target function:
void func( shared_ptr<SomeClass> const & obj )
The const &
takes care of part of the problem, but say we have a getter class which obtains the object for some other class, like:
shared_ptr<SomeClass> someClassInstance();
And here is where I'd like to simply assemble arguments and forward to the target function:
func( someClassInstance() );
With a plain pointer this point in the code could simply use a forward declaration of SomeClass
, but with a smart_ptr
it needs to have the full definition (presumably as the smart_ptr might need to delete the class).
Now, if someClassInstance
were to return a const &
this problem would actually go away as the intervening code would not be copying any objects. However, the getter function must return the copy for thread-safety reasons.
Is there anyway I can achieve this type of smart pointer parameter forwarding without needing the class definition? That is, can I use smart pointers in the same fashion as I would a traditional pointer in this circumstance.
--
UPDATE: Writing a small test the answers are correct that a forward declaration is enough. Yet GCC is still complaining in one situation. I'm going to have to figure out exactly what is causing it to fail (in this particular situation).
Do I close this question for now, or what?