I actually use unique_ptr with forward declarations a lot. Works great.
Ah, I see, so the definition has to be available at the point where I instanciate the class then. Thats only half-bad. Also explains why half my classes "mysteriously" worked with forward-declaration and the others didn't.
Your problem seems to be something causing std::unique_ptr to instantiate the destructor before Bar is defined. Pay close attention to the warning to see if it indicates another file in your compilation unit. This will usually happen if you have code in your header file that is trying to manipulate the unique_ptr, even if the manipulation is "invisible" (i.e. constructor, destructor, accessing, etc).
Unfortunately the warning at the end of the template-error only pointed to the member variable declaration itself, but maybe I missed something :/
Also, unique_ptr is not copyable, so anything that stores them can not be copied. This includes containers, which is why compilation failed with the auto-generated copy constructor and copy assignment operator. Since unique_ptr indicates single-ownership, this is desired, and you should delete the copy constructor and assignment operator as you did above. If you want to allow someone to move ownership, then supply your own move constructor and operator which should work just fine.
Yeah, I get that, but on the same time it appears inconsistent that having a reference or unique_ptr as member will implicitely disallow copying without any warning/errors (unless you try to copy, duh) but having it in a container will generate compile errors, even if I never try to compile the class. I also kind of disliked it because at first I thought using unique_ptr would remove a lot of unnecessary code... which it does in the cpp-files with all the deletes gone, and now that I know the cause for the undefined-type-warning I can get rid of all the empty dtors, but still I have to bloat the interface a little with all the default/delete-methods. But I quess you could argue that it was a fault for me not doing this before anyways, since being able to copy a class with dynamic memory with default copy-ctor sucks by itself.
I suspect all your problems would disappear if you used a pimpl. Hide your private parts.
That would indeed solve the issue, and speed up compile time by another factor, but I'm not quite willing to do that. I've already considered using pimpl, but I decided against in mostly due to performance concerns and additional development overhead, that currently stands in no relation to the gain. Regarding performance, I know its probably "premature optimization" in a way, but with all the talks about cache coherency & memory fregmentation, I'm certain that for most parts I'm better of without it. I just recently squished out about 0,1 ms by constructing my state machine statically instead of via new, so yeah...