On Oct 17, 10:36 pm, "Daniel T." <danie...@earthlink.net> wrote:
> Daniel Lidström <someb...@microsoft.com> wrote:
> > // In the header of your class called Line

> > #include <string>

> > class Line
> > {
> > public:
> > Line(const std::string& name);
> > const std::string& GetName() const;
> > void SetName(const std::string& s);

> > private:
> > // Private implementation idiom:
> > // all member variables are hidden in this class
> > class LineImpl;
> > const LineImpl& m_pimpl; // normally a non-const pointer
> > };

> > // and in your implementation file:

> > #include "Line.h"

> > // Here we define the class with the member variables
> > class Line::LineImpl
> > {
> > public:
> > LineImpl(const std::string& s) : m_s(s) {}
> > // all methods need to be const here
> > const std::string& GetName() const { return m_s; }
> > void SetName(const std::string& s) const { m_s = s; }
> > private:
> > mutable std::string m_s; // the trick! all members are mutable
> > };

> > // create the pimpl instance without using new
> > Line::Line(const std::string& s) : m_pimpl(LineImpl(s)) {}

> Where would the memory for the LineImpl object be placed? It
> isn't embedded in the object, nor is it in the heap, and it
> can't be placed on the stack (and still survive the call to
> the c_tor.)

>From the standard (§12.2/5): "A temporary bound to a reference
member in a constructor's ctor-initializer persists until the
constructor exits." In colloquial terms: the temporary is
created on the stack, and destructed before returning from the
constructor.

> Doesn't sound like a good idea to me.

It isn't, unless you like undefined behavior and hard to find
bugs.

--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34