New to OSLib

Adam lists at snowstone.org.uk
Sat Oct 27 17:17:19 BST 2007


In message <dea15a384f.Jo at hobbes.bass-software.com>, John Tytgat wrote:

> In message <8bae55384f.admin at snowstone.org.uk>
>           Adam <lists at snowstone.org.uk> wrote:
> 
> > The os_error type clashes with the DeskLib definiton. Is there an
> > established way to resolve this?
> 
> Wildly guessing I think this used to work when oslib/os.h got included
> before DeskLib's Core.h as currently:
> 
> DeskLib's Core.h:
> --8<--
> /* Operating system errors (== _kernel_oserror).
>  * Conditional compilation to avoid clashes with EasyC's roslib and
>  * Acorn's "os.h".
>  */
> 
> #ifndef __roslib_h
>   #ifndef __os_h
>     typedef struct
>     {
>       int  errnum;
>       char errmess[252];
>     } os_error;
>   #endif
> #endif
> --8<--
> 
> The reason why this doesn't work today that, I believe, OSLib's
> multiple include protection __os_h got changed into os_H (the
> underscore starting #defines are not to be used by user headers).
> 
> So you could change DeskLib Core.h test __os_h -> os_H and make sure
> that in code using DeskLib and OSLib you're including OSLib's
> oslib/os.h before DeskLib's Core.h (well assuming that 'Acorn's
> "os.h"' is refering to OSLib or an early version).
> 
> Maybe we should consider doing the same in OSLib, i.e. checking on
> DeskLib's Core.h multiple include protection (which is currently
> __dl_core_h).

So presumably you'd suggest that __dl_core_h should be renamed to
dl_core_h also? (And the same for any other DeskLib macros starting with
"_" or "__".)


> Although I have a feeling that this is only the start of
> incompatibilities

Yes, I suspect so :(


> between those two library headers as both define TRUE, FALSE, ERROR,
> NULL etc and probably this first need to go through the bottom of this
> excercise and come up with a proposal for such changes.
> 
> You feel up doing that Adam ?

Um, well, I had proposed a while ago about completely changing the
DeskLib namespace so that every object begins with "dl_". Presumably
that would be sufficient to stop clashes between the libraries?

The main reason I haven't gone ahead with it is that I'm waiting for
Peter Naulls' feedback.


> BTW, when you're using a C compiler and settings that allows support
> for namespaces, you can set NAMESPACE_OSLIB in OSLib.

Oh, that's interesting, sounds like it would work to bodge the two
libraries together? A neater solution might be preferable though. ;)

Adam

-- 
Adam Richardson          Carpe Diem
http://www.snowstone.org.uk/riscos/



More information about the oslib-user mailing list