Re: [AD] Allegro 4.2 todos

[ Thread Index | Date Index | More lists.liballeg.org/allegro-developers Archives ]


> I don't see an easy solution without rearranging a lot of things. Probably
> this is better left as is then since we're going for a change in
> architecture in (distant) future Allegro releases.

I'm afraid you're right.

> 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).

> Why are we too late? AllegroGL has been out for a while so it's already
> somewhat stable enough (or am I wrong?). Integrating it within Allegro
> shouldn't cause much problems as I see it... And we're still 6 months
> ahead of the 4.2 release (if we want to give it for the end of the year)
> so there'e plenty of time to fix any possible thing.

Maybe.

> 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.

> I have a problem: if I declare it as private inside internal.h, we'll have
> to include this header manually also in many files (test.c, demo.c,
> ex12bit, ex3buf and others that all use rand()), which is not nice IMO.
> Otherwise I could declare it in some basic Allegro header, but then which
> one? Noone seems to be the right place for such a function...

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.

-- 
Eric Botcazou




Mail converted by MHonArc 2.6.19+ http://listengine.tuxfamily.org/