|
Exactly. That was my thinking too, resolution.
Regards,
Rob Philpott.
|
|
|
|
|
If you need a higher resolution, use timeGetTime. GetTickCount has a resolution of roughly 10ms, where the timeGetTime function is more accurate.
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
|
|
|
|
|
Had to debug a crash today where the 32 bit build of an application was crashing, but the 64 bit build wasn't. There was a method that takes a string (char * ) buffer as an in / out argument as follows.
void SomeClass::someMethod(char * arg1, )
{
arg1[i] = '\0';
return;
}
The caller was supposed to call it with a variable, but one caller was passing a string literal, so naturally it caused an access violation.
obj.someMethod("string_literal");
However the 64 bit build was working fine. After some fiddling around, I discovered that it was due to the project's optimization settings. The assignement apparently has no effect, so the compiler was removing it in the 64 bit build. Disabling optimization caused the 64 bit build to crash too.
Of course I had to come up with all kinds of crazy reasons first, thinking it was something to do with how 64 bit applications pass arguments, etc.
No more in/outs. const char * is much safer, and will keep you sane (until you cast away the const , of course).
|
|
|
|
|
The assignment arg1[i] = '\0'; wouldn't work with a const char * (at least it shouldn't).
Also, shouldn't a string literal be implicitely cont char * and create a compiler error when being passed to a function that expects a char * as parameter?
The good thing about pessimism is, that you are always either right or pleasently surprised.
|
|
|
|
|
It only works the other way, you can't put a non-const pointer in a const (without casting).
Ignore that, it is clearly incorrect, I'm the one who got it backwards. See below instead.
const char * const_ptr;
char * non_const_ptr;
const_ptr = non_const_ptr;
const_ptr = "literal";
non_const_ptr = "literal";
non_const_ptr = const_ptr;
modified 19-May-14 22:35pm.
|
|
|
|
|
That is really interesting and a great write-up. Very clear too.
It seems crazy to me, however, that the char * is "safer / saner" because it is somewhat more dangerous.
The in/out should force more control, like requiring the user to create a variable on the stack first, right?
Also, you said,
Indivara wrote: so the compiler was removing it in the 64 bit build
What do you mean "removing it"? Do you mean it actually just ignored the value sent in?
That could drive you crazy, when you're trying to figure out why it isn't working.
|
|
|
|
|
I meant using const char * arg1 would be a better choice in this case, not a generalization.
The compiler was removing the last assignment arg1[i] = '\0' because it had no effect. The thing was thrown together in a hurry and the assignment was 'insurance' against the caller forgetting to add it. Had the reverse effect ironically.
|
|
|
|
|
Ah, okay. I see what you mean now. Thanks for clarifying.
|
|
|
|
|
get
{
try
{
XTime.OL.UserObj myUserObj = (XTime.OL.UserObj)(HttpContext.Current.Session["UserObj"]);
if (myUserObj.USER_CODEID == 0) { }
return myUserObj;
}
catch
{
XTime.OL.UserObj myUserObj = new XTime.OL.UserObj();
if (HttpContext.Current.Session != null)
HttpContext.Current.Session["UserObj"] = myUserObj;
return myUserObj;
}
}
Go to catch is worse than using goto to go to catch.
|
|
|
|
|
Great idea! Instead of testing for myUserObj == null, he prefers to cause a NullReferenceException.
Bad only, if it was some different kind of exception...
Reminds me of the guy who reads beyond the end of a File, catches the exception (oh no, not "the", but any exception!) and in the catch block sets a flag that the end of the file was reached (and does not understand why that is bad coding...).
|
|
|
|
|
Brady Kelly wrote: Go to catch is worse than using goto to go to catch.
Yes, but unfortunately there are many "programmers" who liberally use exception handling mechanism to initialize object and to control code flow.
|
|
|
|
|
We have a lot of this where I work, I challenged it. Turns out the head honcho lives by this book[^], which is great, but Chapter 7 is all about how you define a normal flow and throw an exception if the normal flow is deviated from. Net result, a back-door goto mechanism implemented via try/catch/throw. It's the one chapter in the book that I disagree with (the rest is excellent) - the mechanism makes some sense if you have checked exceptions (as in Java - the language the book was written for) but then you are urged to switch the checked exceptions off. For some reason caking your calling code with try catch statements is better than caking it with checks on return value, and code-returning is the only alternative to the exception mechanism discussed.
|
|
|
|
|
Ehm, did you realize the extra gem?
if (myUserObj.USER_CODEID == 0) { }
He provokes a NullReferenceException instead of checking the returned value myUserObj for null (also that book says: do not return null...).
Of course, dealing with exceptions the Java style is very inconvenient for us .Net fans.
|
|
|
|
|
Shameel wrote: Yes, but unfortunately there are many "programmers" who liberally use exception
handling mechanism to initialize object and to control code flow.
I refer you to Sturgeon's Law: "90% of everything is crud, including this statement." This most definitely applies to programmers and to code.
"Seize the day" - Horace
"It's not what he doesn't know that scares me; it's what he knows for sure that just ain't so!" - Will Rogers, said by him about Herbert Hoover
|
|
|
|
|
err2go = " sErrDescr = ""Error "" & Err.Number & "" '"" & Err.Description & ""'"" & vbCrLf &_
"" occurred in " & fileName & " " & gErlRoutine & """ & _" & vbCrLf & _
" IIf(Erl <> 0, "" at line "" & cstr(Erl) & ""."", ""."")"
Print #fOut, err2go
This was a project that needed error handlers everywhere[1]. Using structured comments the source was preprocessed to automatically insert error handlers. Run time errors produced full stack traces with none of the bother of having to code an actual error handler manually. Sweet!
[1] Really. Trust me.
They will never have seen anything like us them there. - M. Spirito
|
|
|
|
|
switch (e.KeyCode)
{
case Keys.D1:
if (keyIsDown[Keys.D1]) return;
try
{
keyIsDown[Keys.D1] = true;
}
catch { }
break;
}
This is a question in StackOverFlow[^]
|
|
|
|
|
Meysam Tolouee wrote: This is a question in StackOverFlow[^]
Without answer
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
|
|
|
|
|
Why are you bothering us with it?
You'll never get very far if all you do is follow instructions.
|
|
|
|
|
The code makes perfect sense in its context. Were you looking at it through beer goggles?
"Seize the day" - Horace
"It's not what he doesn't know that scares me; it's what he knows for sure that just ain't so!" - Will Rogers, said by him about Herbert Hoover
|
|
|
|
|
I just came up with these two methods:
public static bool Implements(this Type t, Type interfaceType)
{
return t.GetInterfaces().Contains(interfaceType);
}
public static bool Implements<TInterface>(this Type t)
{
return t.Implements(typeof(TInterface));
}
They simply check if the Type t implements a specific interface.
I don't know of anything like this in the framework (I haven't checked).
What do you get when you cross a joke with a rhetorical question?
|
|
|
|
|
How about something like:
interfaceType.IsAssignableFrom ( t ) ;
(Untested, but I use IsAssignableFrom in similar cases.)
You'll never get very far if all you do is follow instructions.
|
|
|
|
|
I was going to suggest the same.
Basically, instead of writing someType.implements(interface) you write interface.IsAssignableFrom(someType) .
For some reason, when I encountered this method the first time, I thought that an "Implements" method would make more sense, even if they are basically the same.
|
|
|
|
|
Is it normally the case that you have a Type that you need to check vs. an actual instance?
For an instance there's:
if (foo is ISomething)
|
|
|
|
|
Reflecting over the types in an assembly, for instance (i.e. a basic plugin system).
What do you get when you cross a joke with a rhetorical question?
|
|
|
|
|
I guess since they're one-liners they weren't thought necessary. I don't think they exist in the framework so if they make things clearer then yes, they count as useful
|
|
|
|