Additionally in the DllMain docs, in order to make an initialization routine that is only called once, their suggestion is "the initialization routine can create a file with an ACL
that restricts access, and each routine in the DLL would call the
initialization routine if the file does not exist." Is there really no better way to do this? No say global variable you can create?
Talchas
@Talchas
Best posts made by Talchas
Latest posts made by Talchas
-
RE: Windows WTF
-
RE: Geico's Gecko GETs It All
Of course it will be saved in the address bar + history, so if anyone ever uses that computer...
-
RE: A simple WTF metric
@Lingerance said:
@Talchas said:
Well, you could legitimately have typedefed something to be int64
Interestingly enough that regexp doesn't trigger for int64 (afaik) although it will trigger for int8 (which SDL uses).
It should - it matches int and then [0-9]+, which should do it. -
RE: A simple WTF metric
Well, you could legitimately have typedefed something to be int64, which wouldn't really be a wtf. If its variable names though....
-
RE: Multilanguage Truth
@yoz-y said:
#define TRUE (1 == 1) <= ow my eyes
#define boolean int <= what ?Actually, this isn't that bad (in C) - the best you can do for a boolean is some sort of integer type, and (1==1) is the best way to define true if you need to do so, because the value of (1==1) is only guaranteed to be nonzero (I think). So if you want "return TRUE" to be consistent with true-false generated by the comparison ops, this is a good way to do it.
now in my college they took a different approach :
(found in a C source file we had to work on on C classes)typedef enum{FAUX=0, Faux=0, faux=0, FALSE=0, False=0, false=0,
VRAI=1, Vrai=1, vrai=1, TRUE=1, True=1, true=1} Booleen;Not only they managed to handle the personal preferences of everybody. They also happened to provide both French and English wordings.
I find this a bit odd since they only defined Booleen and no Boolean. (not even speaking about BOOLEAN, booleen ...)
Now thats just WTF.
-
RE: This should never happen.
@seaturnip said:
I never said to ignore them permanently; when they appear they should be fixed as early as convenient. But in the event that it so happens a build is given to QA that causes a harmless assert when bringing up a certain dialog box, say, the testers should still be able to test the contents of that dialog box. It's also convenient for developers to be able to skip over assertions at runtime to be able to verify what are the consequences of going past the assertion without needing to comment out the assertion and recompile.
I guess my point was that there should never be a harmless assert, but if someone screws up, then yeah, it would be good to be able to just skip it.
-
RE: This should never happen.
Assertions are for internal consistency failures or maybe for failures of method preconditions. In either case they represent a bug somewhere that needs to be fixed. Just ignoring them and getting silent data corruption isn't the right answer. If you can verify that everything will work the way it should even if the assert fails, then that assert shouldn't be there. Also in the "assert(x); if(!x) throw ..." example, if you have exceptions why isn't your assertions library using them? Alternatively, why is the assert there at all if you are going to go and do the check anyway. (or not you but whoever wrote that)
-
RE: See your network's product keys!
They could be fake...
But that seems unlikely.
-
RE: UT3
Yeah, for some reason UT3 defaults to only rendering at 1/2 the resolution or so and then upsampling. On top of that it defaulted to 640x480 or so on my computer - it looked horrible. Once I put some sane config setting in there, it looked ok.