Re: [Boost-users] [Container] Forward declaration of movable types

Subject: Re: [Boost-users] [Container] Forward declaration of movable types
From: Szymon Gatner (szymon.gatner_at_[hidden])
Date: 2011-08-16 13:05:45

2011/8/16 Ion Gaztañaga <igaztanaga_at_[hidden]>:

[snip]
>
> You always need the include, just like you needed it when MyMovable was
> copyable, move is an optimization it does not offer type erasure.

Yeah I get that that. I probably wasn't clear, I only meant that no
include was needed
if instances were kept by (smart) pointer and not by value.

> If you
> need to break dependencies, use pimpl idiom for all your members (Warning: I
> haven't compiled it):
>

[snip]

So there is no really a way around it, is there? Either:

1) objects in container have to be kept by pointer to break dependency
but then they
have to be allocated on the heap so there is little or no benefit in
making them movable
(as smart pointer will provide necessary copy/move/ownership semantics)

2) whole container has to be pimpled so that hidden implementation may then take
advantage of all move goodies like container emplacing

I feel like 2nd option is the one that gives real benefits. Is that right?

Also, I often write code like:

class Widget
{
public:
  typedef std::vector<shared_ptr<MyMovable> > MyMovables;

  const MyMovables& movables() const;

private:

  MyMovables movables_;
}

so that clients can later do:

BOOST_FOREACH(MyMovable& m, indirect(widget->movables())
{
   // do something with m
}

how to design Widget's class API in similar way if MyMovables is
hidden behind pimpl?

I mean:

class Widget
{
public:

  ??? movables() const // what return type here?

private:

class Internals;
Internals* pimpl_;
}

or maybe an API is just broken altogether?

PS. I just compiled such a code:

//widget.hpp

class Movable; // only forward declared

class Widget
{
  boost::container::vector<Movable> movables_;
}

and widget.cpp properly adds Movable instances by moving them to movable_.

Why does this work? If this is normal then I have no problem at all ;)

Best regards and thanks for such a great libraries,
Simon