setter and getter vs. public members

Quote:

---

Originally Posted by YourSurrogateGod

Graham, I've read your entire post, but I still have some questions.

When you talk about the pimpl idiom, do you mean something like having 2 classes, one for implementation and one that uses the implementation class but prevents the modification of this class?

---

Herb Sutter, in Exceptional C++, has an excellent article about the pimpl idiom (also known as "Compiler Firewall"). Basically, the idea is that you present an "interface class" to the rest of the world (note: I don't mean a class that only has pure virtual functions; I mean one that only has public - and possibly protected - functions, plus the private pointer-to-implementation). You separate the implementation of that public interface into another class: this one is completely hidden from the rest of the program.

So, yes, that about sums it up, except that I'm not sure what you mean by "prevents the modification of this class". The implementation class is hidden away, the external (interface) class, uses it.

Quote:

---

Originally Posted by Graham

Herb Sutter, in Exceptional C++, has an excellent article about the pimpl idiom (also known as "Compiler Firewall"). Basically, the idea is that you present an "interface class" to the rest of the world (note: I don't mean a class that only has pure virtual functions; I mean one that only has public - and possibly protected - functions, plus the private pointer-to-implementation). You separate the implementation of that public interface into another class: this one is completely hidden from the rest of the program.

So, yes, that about sums it up, except that I'm not sure what you mean by "prevents the modification of this class". The implementation class is hidden away, the external (interface) class, uses it.

---

When I made that particular statement, I was refering to the implementation class, the fact that it's hidden and such.

Quote:

---

Originally Posted by YourSurrogateGod

When you talk about the pimpl idiom, do you mean something like having 2 classes, one for implementation and one that uses the implementation class but prevents the modification of this class?

---

And to provide a small example...

Code:

---

class CDllImpl;            // Forward declaration of implementation class

class CDll
{
public:
  void Function();
  // all your functions etc.

private:
  CDllImpl *m_pImpl;
};

// dll.cpp
#include <dll.hpp>
#include <dllimpl.hpp>

CDll::CDll()
{
  m_pImpl = new CDllImpl;
}

CDll::~CDll()
{
  delete m_pImpl;
}

void CDll::Function()
{
  m_pImpl->Function();
}

// dllimpl.hpp
#include <SomeHeader>;          // Here you can put all your needed headers

class CDllImpl
{
public:
  void Function();
  ...
};

// dllimpl.cpp
void CDllImpl::Function()
{
  // Do some processing
}

---

Just one thing to be careful about there:

- Default copy constructor. Yikes! and operator=

You can handle this in several ways:

- use boost::scoped_ptr< Impl >
Impl can still be incomplete. Will automatically make your class non-copyable and non-assignable and you won't have to worry about the delete

- put in private declarations (no definitions required) for copy constructor and operator=

- derive privately from boost::noncopyable

- implement a deep copy

You could also use boost::shared_ptr but then you'd find your two copies were actually simply different references to the real impl. If that's what you want then do it, but beware of this among other things:

Code:

---

void DoSomething( const MyClass & rMyClass )
{
 // you think I can't modify the MyClass but I can, without const-casting, thus

  MyClass myClassCopy( rMyClass );
  myClassCopy->nonConstFunction(); // haha!
}

---

Because both instances of MyClass share their implementation, you are modifying both of them when you call the nonConstFunction.

Of course, the interface of the implementation class doesn't have to mirror the interface of the outer class. For example Outer::function() could call two or more functions of the pimpl class. This comes from another possibility raised by the pimpl idiom: one carefully designed pimpl class could actually provide the implementation for two or more outer classes, who use the (probably much more low-level) functions of the pimpl in different orders or at different times.

It often does mirror it though. I've often thought about doing the below but never actually have done it:

Code:

---

class Impl1 : public SomeInterface
{
public:
  // all the methods

private:
  boost::scoped_ptr< Impl2 > m_pImpl;
};

class Impl2 : public SomeInterface
{
// everything
};

---

That would lead to the prospect of actually doing this:

Code:

---

class Impl1 : public SomeInterface
{
private:
  boost::scoped_ptr< SomeInterface > m_pImpl;

public:
  // these methods are virtual in SomeInterface

  virtual void Method1() { m_pImpl->Method1(); }

  virtual int Method2( const std::string & s ) const
    { return m_pImpl->Method2( s ); }

 // etc

// in .cxx file

Impl1::Impl1()
 : m_pImpl( new Impl2 )
{
}

---

Here you have a base class (probably abstract), an implementation which is a fully blown implementation (Impl2) and an implementation by proxy (Impl1). Impl1 is a concrete class and you can construct members of it.

I'd be interested to know, by the way, has anyone ever written an automatic code generator for pImpl.

Quote:

---

Originally Posted by Andreas Masur

And to provide a small example...

Code:

---

class CDllImpl;            // Forward declaration of implementation class

class CDll
{
public:
  void Function();
  // all your functions etc.

private:
  CDllImpl *m_pImpl;
};

// dll.cpp
#include <dll.hpp>
#include <dllimpl.hpp>

CDll::CDll()
{
  m_pImpl = new CDllImpl;
}

CDll::~CDll()
{
  delete m_pImpl;
}

void CDll::Function()
{
  m_pImpl->Function();
}

// dllimpl.hpp
#include <SomeHeader>;          // Here you can put all your needed headers

class CDllImpl
{
public:
  void Function();
  ...
};

// dllimpl.cpp
void CDllImpl::Function()
{
  // Do some processing
}

---

---

Thanks, I think I'll play around with this subject a little bit more when I get home.

The closest I got once was to write a Rational Rose macro that made a pimpl from a given class. That is, if I created a class foo in my Rose model, I selected it, then chose the pimpl macro, and it created a foo_impl class and added the appropriate aggregation dependency.

I've just read all your answers, very interesing, very interesting. That book by Herb Sutter, I think I'll give it a shot. I still find myself being unhappy with my class design too often. It's a serious challenge in C++. :/