D pointers

[Koos Vriezen]

On Saturday 01 October 2005 14:39, Stephan Kulow wrote:
> OK, let me post a conclusion: 
>  - inline is bad as it removes all kind of BC flexibility we have
>  - without inline, the price of d pointers are: one more malloc 
>      (can only be spared in KDE 4.0 and is likely to return, so 
>      it's a little price and there is no guarantee to be kept - so we
>      better optimize _with_ it already included) and the extra 
>      indirection that a d pointer brings (this->member becomes
>      this->d->member). The latter is the real problem

Ah, then I withdraw my remarks about accessors issues. This is about
privates that stay private, because what I thought was about:
  class KPublicFoo {
    Foo * m_foo;
  public:
    Foo * foo () const { return m_foo; }
    void setFoo (Foo * f) { m_foo = f; }
  };

Would be done as
  class KPublicFoo {
    KPublicFooPrivate *d;
  public:
    Foo * foo () const;
    void setFoo (Foo * f);
  }
  // in some .cpp
  Foo * KPublicFoo::foo () const { return d->foo; }
  void KPublicFoo::setFoo (Foo * f) { d->foo = f; }

These accessors are public.
Because in this case coolo's list should also add an extra function call
and two extra exported symbol as price for using d-pointers.

Thanks for clearing this,

Koos