Suggestions

[Ainsley Pereira]

In message <200004242010.NAA17446 at purple.trimedia.sv.sc.philips.com> you wrote:

>  | Firstly, I'm a bit uncomfortable about this use of |bool| in any 
> case.
>  | Wouldn't a better way be to typedef our own boolean operator, e.g.
>  | |typedef int BOOL| and then use that throughout the library code. 
> 
>    Hold on, hold on!
> 
>    |bool| **is** "our own boolean operator"!

No it's not, it's a C++ keyword. We cannot unconditionally define it, as
that makes as much sense as typedef int void; :) My vote is for:

typedef int osbool;

with ostrue defined as 1 and osfalse defined as 0 (optionally in
uppercase, I don't care).

There should already be implicit conversion between osbool and C++'s
bool if it's defined like that.

Compatability with existing code is a simple matter of a (C
specific) typedef and a #define or two.

>    I don't want to see a situation where we end up with 
> "OSLibBoolean_Type", as well as "OSLibInclude$Path"!

:)

>    If other libraries use "bool", we have to come up with some 
> solution to enable us to work together, but I think this is best done 
> in a case-by-case basis. 

It's not other libraries, but the languages that's the problem.

>  | Secondly, I'm also a bit uncomfortable about the use of the
>  | (undocumented) macro __swi, which is only applicable to a single
>  | compiler, itself no longer maintained, and probably no longer the
>  | mainstream compiler for the platform. How much real benefit does it
>  | bestow on the library code?
> 
>    This is what it says in the readme:
> 
>  | * (*Experimental*) Use inline SWIs where possible: 252 out of 2429
>  | SWI veneers happen to be A P C S-conforming, and may be replaced
>  | by single SWI instructions in the caller. Only supported by
>  | Norcroft C release 5, but enabled by default: IF YOU ARE NOT USING
>  | NORCROFT C RELEASE 5 OR LATER, you must disable the feature by
>  | using the -D__swi option on the compiler command line (e g, 
>  |
>  |       cc -D__swi c.progfile

Shouldn't this be -D__swi(x) or something? Anyway, wouldn't it be easier
to do this once in a header, given that it can be detected with
appropriate #ifdefs. IMHO it's not tidy to require extra stuff of people
NOT using a certain compiler.
I've no objections to retaining the actual __swi things in the code
though. (Who knows? Maybe that nice Nick chap will add support for it to
GCC...)

~Ainsley

-- 
 -----------------------------------------------------------
   / Ainsley Pereira       /   aka Marble on Snowplains   /
  /                       / telnet://snowplains.org:3456 /
 ------------------------------------------------------------