Am Dienstag, 2. Januar 2007 21:53 schrieb Giel van Schijndel: > Per Inge Mathisen schreef: > > On 1/1/07, Dennis Schridde <[EMAIL PROTECTED]> wrote: > >>> Although alGenSources() expects an ALuint. I think both this and > >>> similar OpenGL code that uses -1 for invalid value is just plain wrong > >>> - ~0 or -1 should be a perfectly valid value for both OpenGL textures > >>> and OpenAL sources. > >> > >> Could you explain what you mean with that? > >> Do you mean they should have used ~0 or (ALuint)(-1) instead? > > Bitwise ~0 and -1 is exactly the same thing, ~0 however doesn't require > to be treated as a signed value, whereas -1 does. So as far as assigning > goes, when you *do* want to assign that value to an unsigned variable ~0 > (or ~0U for the purist) is the cleaner way to go. > > >> Sorry, I don't get the point... > > > > What I try to say is, there is as far as I know no value of the second > > parameter to alGenSources() and glGenTextures() that is defined to be > > invalid, and we should not assume any value of this parameter to > > always be invalid. So if we want to check if we have initialized this > > variable, we should use another variable for this task instead. > > I agree that using a value which, as far as OpenAL is concerned, is > really a valid value as a defined invalid value. > > So as a solution you basically mean we should have two variables? One to > contain the value and another of say type BOOL (that is compiler > initialized to FALSE) which indicates whether the former is already > initialized and thus usable. > > I don't think this is a good way to go with at all honestly (although it > is better than the current implementation). I'd much rather prefer to > not even acquire the memory space for that variable when you don't have > the value to initialize it with (i.e. I prefer applying RAII, the AL > routines seem as good to me as any other to start with). So in essence I > mean there simply shouldn't be any variables that are > invalid/uninitialized, which would in turn result in cleaner code > because you don't need to check for invalid values. Oh well... Could someone please tell me what you are talking about??? What is the problem? What does that have to do with AL_INVALID? Actually I can't think of anything more sane than -1 for the value of AL_INVALID. Additionaly the value of AL_INVALID is out of our reach, it is defined by the OpenAL group. And the C standard doesn't have any value to represent "undefined" or "invalid", so it really can't be fixed...
I am totally confused... (And I guess I horribly misunderstood something...) --Dennis
pgpQleov8Y39Z.pgp
Description: PGP signature
_______________________________________________ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
