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
