[openbeosnetteam] Re: NetDebug.h break BC
- From: Philippe Houdoin <philippe.houdoin@xxxxxxx>
- To: openbeosnetteam@xxxxxxxxxxxxx
- Date: Wed, 13 Nov 2002 18:02:43 +0100 (CET)
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!
;-)
Dunno yet about NetAddress.h, but yeah, I guess it break BC too.
>
> > - 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?
-Philippe "mailing-list awaker :-p" Houdoin
- Follow-Ups:
- [openbeosnetteam] Re: NetDebug.h break BC
- From: Scott Mansfield
- References:
- [openbeosnetteam] One small step for net team, but... but one small step forward?
- From: Philippe Houdoin
- [openbeosnetteam] Re: One small step for net team, but... but one small step forward?
- From: Matthijs Hollemans
- [openbeosnetteam] NetDebug.h break BC
- From: Philippe Houdoin
- [openbeosnetteam] Re: NetDebug.h break BC
- From: Scott Mansfield
Other related posts:
- » [openbeosnetteam] NetDebug.h break BC
- » [openbeosnetteam] NetDebug.h break BC
- » [openbeosnetteam] Re: NetDebug.h break BC
- » [openbeosnetteam] Re: NetDebug.h break BC
- » [openbeosnetteam] Re: NetDebug.h break BC
- » [openbeosnetteam] Re: NetDebug.h break BC
- » [openbeosnetteam] Re: NetDebug.h break BC
- » [openbeosnetteam] Re: NetDebug.h break BC
- » [openbeosnetteam] Re: NetDebug.h break BC
- » [openbeosnetteam] Re: NetDebug.h break BC
- » [openbeosnetteam] Re: NetDebug.h break BC
- [openbeosnetteam] Re: NetDebug.h break BC
- From: Scott Mansfield
- [openbeosnetteam] One small step for net team, but... but one small step forward?
- From: Philippe Houdoin
- [openbeosnetteam] Re: One small step for net team, but... but one small step forward?
- From: Matthijs Hollemans
- [openbeosnetteam] NetDebug.h break BC
- From: Philippe Houdoin
- [openbeosnetteam] Re: NetDebug.h break BC
- From: Scott Mansfield