Right. I agree with your points and will implement that.
Alex.
----- Original Message -----
From: "Christoph Reichenbach" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Sunday, December 02, 2001 10:39 PM
Subject: [freesci-develop] Re: Case -> if/else
> Hi,
>
>
> > I tried this in sound.h:
> >
> > const unsigned int SOUND_COMMAND_INIT_HANDLE =
> > (const)RegisterWindowMessage(UM_SOUND_COMMAND_INIT_HANDLE_MSG);
> >
> > and got the error:
> >
> > d:\src\freesci\src\include\sound.h(76) : error C2099: initializer is not
a
> > constant
> >
> > Even with both const's removed I still get the same error.
>
> It's a function call; function calls are not constant per definition (the
> set of constant C expressions is a strict subset of the set of expressions
> that can be evaluated at compile-time, and constant C expressions must not
> contain function calls, not even to functions typically handled internally
> by the compiler, such as 'toupper()', 'pow()', or 'strcmp()').
>
> Also, const values are just a typechecking feature (considering that the
> C type checker is pretty bland by design, this could be considered a
> good thing, if it wasn't customary to use preprocessor macros instead to
> allow the values to be inlined at the pre-processing stage) and not
> sufficient to qualify an identifier for use as a 'case' label in a
> 'switch' statement (just tried that)- the value there must evaluate to a
> constant expression without any identifier lookup.
>
> This means that hard numbers (possibly hidden behind preprocessor macros
> or derived from integer expressions) are the only things that can go
> there.
>
>
> > When trying to do a case statement with SOUND_COMMAND_xxx then, I get
this
> > error:
> >
> > d:\src\freesci\src\sound\sound.c(127) : error C2051: case expression not
> > constant
> >
> > That's why I had to ditch the case statements. Do you have any
suggestions?
>
> Even though it's considerable as an approach, I don't think that the case
> of sound commands not being constant should be considered as the default
> (which is the current, new way to handle them). It's a speciality of the
> Win32 event sound server implementation that the commands are mapped to
> integer values at run-time at all.
>
> Let's have a look at the current design of the sound server (this is from
> memory, please scream if anything is wrong there):
>
> A ----> B: A calls B
>
>
> Interpreter
> |
> |
> v
> sound.c interface code
> |
> |
> v
> Sound server implementation
> | |
> | |
> | |
> v v
> play_note(state) process_command(state, command)
>
> (I've excluded the status callbacks, such as the cue notifications, for
> since they're not relevant for this point).
>
> In this model, process_command() would contain the switch(){} statement
> that chooses the correct operation to process the command received. Since
> it is not part of the sound server implementation, it should not be
> subject to any of the quirks that implementation has to bypass in order to
> get its data transferred.
>
> This means that the mapping of FreeSCI sound commands to
> Win32-event-sound-server commands (and its inverse) will have to be
> implemented in the server. If possible, you might want to try the 'sbtree'
> implementation (static binary trees, see sbtree.h), which will only work
> with positive values (and zero), though. It is O(log(n)), though, unlike
> a O(n) "if..then..else if" implementation.
>
> Hope this helps,
>
> llap,
> Christoph
>
>
>
