does adding new member function into d pointer class break binary compatibility?

Question

Will adding new member function into d pointer class definition break binary compatibility?

For example, will the new definition below break binary compatibility compared to the original? (side question, is there a tool that will tell me if a new .so breaks binary compatibility compared to the old .so? If not, how do I check manually?)

Original:

#ifndef __TESTBC_H__
#define __TESTBC_H__
class APrivate;

class A
{
  public:
   int get() { d->update(); return _d->get(); }

private:
   APrivate *_d;

};

class APrivate
{
  public:
   int get() { return _val; }
   void update() { _val = 1; }

  private:
   int _val;
};
#endif

New:

#ifndef __TESTBC_H__
#define __TESTBC_H__
class APrivate;

class A
{
  public:
   int get() { _d->update(); return _d->get(); }

private:
   APrivate *_d;

};

class APrivate
{
  public:
   int get() { return _val; }
   void update() { _val = 1; multiply(); }
   void multiply() { _val = _val * 10; }

  private:
   int _val;
};
#endif

FYI: I understand d pointer class should be specified in the cc file instead of header. above example is contrived to focus on binary compatibility issue.

Answer 1

No it does not.

You should understand how C++ builds its objects.

In your case it is just almost "POD" class with non-virtual member functions. These functions do not affet the representation of object in memory. Thus new version is binary compatible with old.

More then that, if you do not expose your "APrivate" class to user. (Not giving a header just forward declaration), you would not brake an API even if you do much bigger changes.

Meaning:

#ifndef YOUR_PUBLIC_API
#define YOUR_PUBLIC_API
class bar;
class foo {
public:
    // member functions using bar
private:
    bar *bar_;
};
#endif

You do not even expose bar so you may change it in any way you wish. it is the best way to make C++ libraries ABI compatible.