TL;DR The inclusion of <boost/shared_ptr.hpp>
is required here. No (intelligent) way around it. MyType
itself can be forward-declared though.
Of course, you can just write #include <boost/shared_ptr.hpp>
at the top of your header so your users don't have to do it themselves. It's actually good practice to provide autonomous headers (ie headers that can be included first without errors).
The rules about forward compilation are slightly complicated. It is easier to understand the reason about them than to try and memorize all the cases.
There are two factors:
- semantics
- memory attributes (size & alignment)
Semantics: in order to access the objects' methods, attributes or base classes, you need to know about them. Seems obvious, of course, except that the constructors, assignment operators and destructors, even when automatically generated, are methods. It is easy to forget about them.
Memory attributes: unlike most languages, C++ tries to be as efficient as possible, which means that it will allocate memory for the object right there rather than allocate it somewhere and just use a pointer at the point of use, unless you instruct it to do so of course (by using either pointer or reference). In order to know how much to allocate, the compiler needs to see the guts of the object, ie what's underneath the hood. This means that even though the exact details are not accessible (private
/protected
stuff) they need be visible so it can see that 24 bytes aligned on a 8-bytes boundary are required (not relevant to shared_ptr
by the way).
In the Standard we say the object's definition is required for either of those two needs (methods and memory layout). If the definition is required, then it must be available obviously.
Okay, now that we know the reasons, we can check various things. Is a definition needed when:
- using an object as argument to
sizeof
or alignof
? yes (obviously, memory attributes required)
- using an object as attribute? yes (memory attributes required)
- using an object as static attribute? no (1)
- using a pointer or reference to an object as attribute? no (2)
- using an object as an argument in a function declaration? no (3)
- using an object as a return type in a function declaration? no (3)
- passing a pointer or reference to an object around? no (4)
- casting to base class? yes (semantic check of presence & accessibility of base class)
- converting to another type? depends (5)
(1) the declaration does not require anything, however the definition of the static attribute will require the object's definition.
(2) a pointer is either 32 bits or 64 bits large (depending on how you compile, ...) independently of the object. A reference has an implementation-defined representation.
(3) even if taken/returned by value! It may be required for the function definition (if used within) or the function call site though.
(4) of course, should you try to use it (p->foo()
or p.foo()
) then it's another story.
(5) if you need to use the object's conversion operators, then it's required obviously; otherwise if you use a constructor of the other type then the same rules as for functions apply (the other type definition is required though).
I hope things are clearer now.