On Wed, May 23, 2001 at 11:35:31AM -0400, Bruce Momjian wrote:
> > > > > We have added more const-ness to libpq++ for 7.2.
> > > > 
> > > > Breaking link compatibility without bumping the major version number
> > > > on the library seems to me serious no-no.
> > > > 
> > > > To const-ify member functions without breaking link compatibility,
> > > > you have to add another, overloaded member that is const, and turn
> > > > the non-const function into a wrapper.  For example:
> > > > 
> > > >   void Foo::bar() { ... }   // existing interface
> > > > 
> > > > becomes
> > > > 
> > > >   void Foo::bar() { ((const Foo*)this)->bar(); }   
> > > >   void Foo::bar() const { ... }   
> > > 
> > > Thanks.  That was my problem, not knowing when I break link compatiblity
> > > in C++.  Major updated.
> > 
> > Wouldn't it be better to add the forwarding function and keep
> > the same major number?  It's quite disruptive to change the
> > major number for what are really very minor changes.  Otherwise
> > you accumulate lots of near-copies of almost-identical libraries
> > to be able to run old binaries.
> > 
> > A major-number bump should usually be something planned for
> > and scheduled.
> 
> That const was just one of many const's added, and I am sure there will
> be more stuff happening to C++.  I changed a function returning short
> for tuple length to int.  Not worth mucking it up.
> 
> If it was just that one it would be OK.

I'll bet lots of people would like to see more careful planning about 
breaking link compatibility.  Other changes that break link compatibility 
include changing a struct or class referred to from inline functions, and 
adding a virtual function in a base class.

It's possible to make a lot of improvements without breaking link
compatibility, but it does take more care than in C.  If you wonder
whether a change would break link compatibility, please ask on the list.

Nathan Myers
ncm@zembu.com

Wed, 23 May 2001 14:36:50 -0700
ncm@zembu.com (Nathan Myers)
Re: C++ Headers
> > If it was just that one it would be OK.
> 
> I'll bet lots of people would like to see more careful planning about 
> breaking link compatibility.  Other changes that break link compatibility 
> include changing a struct or class referred to from inline functions, and 
> adding a virtual function in a base class.
> 
> It's possible to make a lot of improvements without breaking link
> compatibility, but it does take more care than in C.  If you wonder
> whether a change would break link compatibility, please ask on the list.

Our C++ interface needs serious work, and I don't want to burden a
maintainer with adding muck for backward compatibility.

We do update libpq occasionally and don't keep link compatibility. We do
keep interface compatibility with the backend.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

Wed, 23 May 2001 18:57:52 -0400 (EDT)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: C++ Headers