[Scummvm-devel] Re: [Scummvm-cvs-logs] CVS: scummvm/backends/dc dcmain.cpp,1.11,1.12

[Max Horn]

Am Sonntag, 06.07.03 um 19:38 Uhr schrieb Marcus Comstedt:

>
> Max Horn <max at quendi.de> writes:
>
>> Not a good way to fix it. The correct fix probably is to use:
>>
>> OSystem::MutexRef OSystem_Dreamcast::create_mutex()
>>
>> If that doesn't work, tell me the error and I can suggest another fix.
>
> Seems to work.  I wonder why it is necessary here, but not in the
> definitions of lock_mutex() et al.
If you look, I actually did the same in the implementation 
sdl-common.cpp

there is actually a logic behind it: There is no type MutexRef, only 
OSystem::MutexRef, since MutexRef was declared in the scope of the 
OSystem declaration.

The fact that you can write MutexRef instead of OSystem::MutexRef *at 
all* is the exception, not that C++ forces you to write the full name 
in some places. For example, inside OSystem, you can refer to MutexRef, 
since it's unambiguous from the context that this particular type is 
meant. Likewise for subclasses. In addition, this one is unambiguous, 
too:

OSystemSubclass::lock_mutex(MutexRef ref) {
...
}
Why? Because from the context it is clear that this lock_mutex is 
declared inside an OSystem subclass, so it is clear that MutexRef is 
really to OSystem:: MutexRef. But this one is not unambiguous:

MutexRef OSystemSubclass::create_mutex() {
...
}
It is not, because MutexRef is used *outside* any OSystem / 
OSystem-subclass scope. It comes before we enter that scope. Hence it 
can not be assumed to be the particular OSystem::MutexRef.


>  C++ should be taken out and shot
> at dawn, preferably earlier...
>
Hehe. Yeah, scope rules in C++ can drive you crazy :-)

Max