FreeLists / openbeosnetteam / [openbeosnetteam] Re: NetDebug.h break BC

[Scott Mansfield <ThePhantom@xxxxxxx>]

On Wednesday 13 November 2002 09:02 am, Philippe Houdoin wrote:
> Quoting Scott Mansfield:
> > And so will NetAddress and NetDebug, and NetEndpoint (which I haven't
> > submitted to Philippe yet) be similarily broken.
>
> Hum, NetDebug.h seem to be BC. Short as this class is, it's a gift!
> ;-)

Doh!  You're right, my bad.

> Dunno yet about NetAddress.h, but yeah, I guess it break BC too.

Trust me, it will be.  :-/

> > > - the protected status_t m_init should be somewhere.
> > > I guess fInitialized make a good candidate to be replace by
> >
> > m_init...
> >
> > Yes, you are correct, I was following the opentracker coding standard as
> > suggested by the project pages.
>
> Yes, that unfortunate, but protected variables should keep their name.
> Mixed m_* and f* variables names. Glup.
> Bah.



> > My understanding is that private methods and data can be changed at will
> > without breaking binary compatibility.  Honestly, though, I don't
> > remember whether private virtual methods will show up in the
> > vtable or not.  I'll do a little digging when I get home tonight.
>
> Welcome onboard, I did know nothing about BC until last or two weeks ago!
> When Marcus tell me about NetBuffer.h broken BC.
> It's not like these classes are the most used and wanted.
> Many OBOS interface and app classes have broken BC too.
>
> The good news is: when BC issues raise, we're getting closer, that's for
> sure.
>
> > > - And what about the newly added protected variables fData,
> >
> > fDataSize,
> >
> > > fStackSize, fCapacity? No issue here?
> >
> > What I did was to add these variables and at the same time, decrease the
> > number of elements in the private member array (the name escapes me at
> > the moment).  The binary size of the class would remain the same.
>
> AFAIR, the size remains the same.
> But why making these 4 variables protected instead of private?
> Does your BNetEndpoint implementation exploit these protected members
> in some way?

No, BNetEndpoint doesn't.

I made these protected for convenience of implementation and inheritance -- 
should someone decide to extend this class with their own implementation and 
need access to the stack controllers.  Since, in the interest of binary 
compatibility, I couldn't write accessors and mutators for these member 
variables (which is, AFAIK, the generally accepted way to allow access to 
member data; please correct me if I'm wrong here) without breaking the class' 
signature, I made them protected.

If you want, I'll fix 'em.  After all, I'm the idiot that broke them in the 
first place...

> -Philippe "mailing-list awaker :-p" Houdoin

Scott "still workin' on my morning coffee" Mansfield