Compiler Warning and Notices like unused variables etc.
I just wanted to say I LOVE the fact that the compiler warns you of these
Personally, I don't consider my application at a good stopping point unless
I can make all the warnings go away. Sometimes I even will put in (hopefully
a low overhead thing when I do it) a meaningless command to remove
"variable not initialized" warnings... when I KNOW I'm doing something to
init the variable that the compiler can't (nor is expected to) know I'm
Var MyVariable: ansistring;
MyVariable:=MyVariable; // this is a workaround in rare cases.
CallAReferenceProcedure(MyVariable); // This is warning material.
Note: I know it MAY create a few assembly instructions - but I think I'll
take a couple of them to hush the compiler.
It seems like a "CLEAN" thing to do... I mean, it raises doubt (speaking for
myself) when I compile something and there are warnings being displayed. It
makes me think the programmer has not addressed everything or my environment
might be the cause of said application to maybe not work as designed.
Re: Compiler Warning and Notices like unused variables etc.
> MyVariable:=MyVariable; // this is a workaround in rare cases.
Can anybody that knowns the internals of FPC confirm if this will
create extra work/code for the compiler? I have been trying for a
long time to figure out a clean way of getting rid of some compiler
Depending on the view point and application it might be negligible. It's
probably not a good idea to do that inside a tight loop, but in most
other cases those couple of bytes won't hurt.
Although, well ... I wouldn't depend on that behaviour, because the
variable still *is* as uninitialized as before, because the right hand
side of the expression assigned to it is. So if someone cares to write
code for a more stricter data flow analysis, the warning may at some
So this is no clean way to do it I'd say.
What is needed is a way to tell the compiler: "Trust me. I know what I'm