Per Inge Mathisen schreef: > On 1/2/07, Dennis Schridde <[EMAIL PROTECTED]> wrote: >>> 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. > Works for me. >>> 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. > Now you lost me. How do you implement RAII with C? I mean this specifically for variables like ints etc. For example instead of declaring a variable `int i;' at the beginning of a function, move it downwards where the first assignment takes place so you can do something like `int i=returnValueOfRandomFunction();'.
As for a more serious implementation of RAII C++ would indeed be required. >> 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... > Well, I do not really understand what AL_INVALID was supposed to do, > and now it is deprecated (in OpenAL 1.1). The problem is that > AL_INVALID / -1 is a signed value, and alGenSources takes an unsigned > value, making the compiler complain. Making the compiler happy is > (nearly) always a good idea ;-) If AL_INVALID is deprecated I'd say flush it through the toilet right away! And making the compiler happy is indeed a very good idea. Although I would in this particular case not be satisfied by simply casting AL_INVALID or redefining it as ~0. This because (as you pointed) ~0 is a perfectly legal argument to the OpenAL library functions. @Dennis: if I'm still being to fuzzy about this subject just say so or ask a specific question -- Giel
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
