2

Sometimes, you want to provide a class declaration, which is not merely an opaque forward declaration but has the public functionality exposed - yet you don't want to commit to your private, or implementation-specific, fields and methods. One solution for this is the pimpl idiom - using a pointer to an inner class, housing the implementation of the class exposed publicly.

I don't really like using pimpl and wish the language would allow you to have really-private members - so that code using the class does not 'see' their declaration (and thus probably doesn't need to be recompiled when the implementation details change). Also, recently, I've noticed C++ has been evolving much faster - a 3-year tick-tock pattern in standard updates. So... is there a proposal to add such functionality to C++? Do some compilers currently support it perhaps?

einpoklum
  • 118,144
  • 57
  • 340
  • 684
  • Modules along the lines of what you're looking for? Lots of work being done on those. – chris May 23 '15 at 21:26
  • According to [this summary](https://stackoverflow.com/questions/3596147/modules-in-c11) here on SO, modules do not coincide with classes. i.e. it doesn't seem you can make some methods belong to a module and others not. Or am I wrong? – einpoklum May 23 '15 at 21:34
  • 1
    I doubt there will be a proposal on something as vague as "obviating the pimpl". – juanchopanza May 23 '15 at 21:35
  • Why would you need an evolution of the standard tom implement such an obvious thing that it would be difficult to obviate it more ? – Christophe May 23 '15 at 21:51
  • With strong compile time reflection (both writing and reading), an interface->pimpl forwarder might be doable. Remove boilerplate. Unlikely in C++17, reflection is going for baby steps. – Yakk - Adam Nevraumont May 24 '15 at 01:14

1 Answers1

1

Yes, such a proposal exists. There were even several previous versions, the most current one is from last year:

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4173.pdf

The proposal would allow operator. to be overloaded, listing several use-cases:

  • Smart references
  • Smart pointer work-alikes
  • Proxies
  • Interface refinement
  • Pimpl
  • Handles

You can read the linked proposal for more information. Of course, this will not necessarily be accepted and, even if it is accepted, it will probably not make it into C++17.

Jonathan Leffler
  • 730,956
  • 141
  • 904
  • 1,278
Daniel Frey
  • 55,810
  • 13
  • 122
  • 180
  • Oh, that's quite an interesting approach... it doesn't quite obviate pimpl, but it makes its use less fugly. – einpoklum May 24 '15 at 16:28