Re: Pimpl idiom without dynamic memory allocation
On Oct 17, 10:36 pm, "Daniel T." <danie...@earthlink.net> wrote:
Daniel Lidstr=F6m <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 (=A712.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=E9e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34