1

How can i forward declare a class in a namespace. For example below is a header file of a library and user dont need to know about private myPtr so dont need to include boost headers when include below header file. So how can I forward declare the boost::shared_ptr to enable user code compilation?

MyClass.h

class MyClass
{

private:

  boost::shared_ptr<Mytype> myPtr;

}
6
  • @JaredC Not if he provides a pre-compiled library.
    – JBentley
    Commented Jan 12, 2013 at 17:44
  • @korhan I'm not sure I fully understand your question, but it sounds like it might be similar to one I asked recently - have a look at the answers here and see if any help: stackoverflow.com/questions/13978775/…
    – JBentley
    Commented Jan 12, 2013 at 17:45
  • You're trying to alleviate the consumer of this little gem from having to include the boost headers to get the definition of something you'd rather they didn't know about in the first place; does that about sum it up?
    – WhozCraig
    Commented Jan 12, 2013 at 17:49
  • @Jon thx for the replay , I just checked it, but my problem is with forward declaring a class within a namespace that consumer dont know about(or dont need to know aobut for me.)
    – kyy
    Commented Jan 12, 2013 at 17:55
  • @WhozCraig yes thats what i am try to do. By the way my library is a static library if it changes anything
    – kyy
    Commented Jan 12, 2013 at 17:57

1 Answer 1

2

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.

0

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.