Michael wrote: >> It seperates the external API from the internal support environment >> and marks what can and cannot be changed without breaking >> compatibility. >> All too often in the OBOS code I've seen, this distinction has become >> blurred. > > We have a wonderful guide to this - the BeBook. If BeBook was the documentation for all public (or should be public) API of BeOS, give me (us) *your* BeBook version right now! ;-) The fact is not all is documented by BeBook. No suprise. Beside that, new internal designs of OBOS kits could perfectly use or need to have exported symbols too. Modular way need this. Current net_kit stack is highly modular, for example. So, some symbols needs to be exported / are expected by design. But, if all are exported by default (stupid thing, let me say), how to find which are required, which are not, from the only OBOS net_kit documentation currently available: source code? So, we could have a better guide even: the source code itself. Remember that code is always most updated *documentation, and often the only one available. I'm pretty used (hey, it's be/BeBuild.h!) to see and add myself _EXPORT before any *symbol* that need to / should be public. I group them at top of source, so that the first, most public part of the code appear first. I think _EXPORT (or any other way that could tell me "this thing is exported, because it's a public entrypoint of the module, etc"... is part of autodocumentation feature too. A better one than his equivalent _declspec(dllexport), by the way. Not that I'll dislike a comment near any exported symbol telling his purpose in more details.. Oh, well, like all, in fact it'll end up to what OBOS committers will do... -Philippe -- Fortune Cookie Says: "I love Saturday morning cartoons, what classic humour! This is what entertainment is all about ... Idiots, explosives and falling anvils." -- Calvin and Hobbes, Bill Watterson