Re: [AD] Allegro 4.2 todos

[Angelo Mottola <a.mottola@xxxxxxxxxx>]

>> Hug. Never bothered to read that file, and now I see I should have done
>> it... Still, I hate all those "deprecated" warning messages.
> 
> You wrote some BeOS related lines in it though. And there is
> -Wno-deprecated-declarations (you could even write a preventive FAQ entry for
> that, as I wrote the preventive FAQ entry for USE_CONSOLE on Darwin).

Yes, but either it didn't include explicit references to 4.2 when I
contributed to it, either I completely forgot about it...

>> What about an install_thread() function, that fails if no threading
>> support is available? (in which case also mutexes would not work). This
>> would leave the decision on safely using thread/mutexes up to the
>> programmer...
> 
> The problem is, a synchronisation scheme based on mutexes basically doesn't
> work when they are no mutexes. And vice versa. So users would have to cope
> with two different behaviours depending on the platform their code is
> compiled on, and this would go against Allegro's mantra of (nearly) out of
> the box portability.

This is the case when we have to take a choice. Personally I'd prefer to let
the user choose if to code his program supporting threads/mutexes, and fail
to execute at startup by checking if install_threads() fails. Coders working
with threads and mutexes are likely not to be interested in porting to DOS
anyway...
Kinda like install_mouse(). Many programs require mouse to run, but not to
compile; supporting threads would be similar in that the programs will
compile even if no proper threading support is available, but if properly
written the programs will abort at startup (ok, this wasn't the best
example, but you got the idea).

> I think we shoud make a distinction between the library and the programs. In
> the library, we use a private lazy RNG. In the programs, we use whatever
> linear function of rand() gives good results on most platforms.

Humm, already commited a patch that makes the lib and all the
programs/examples to use a private _al_rand()/_al_srand() interface. Seems
the best solution to me and also gives pretty good results here.

-- 
Angelo Mottola
a.mottola@xxxxxxxxxx