I am keen on finding new conditional defines and keywords in the Delphi language which are undocumented.
Stuff like {$WARN GARBAGE ON}
http://qc.embarcadero.com/wc/qcmain.aspx?d=77686
I report such stuff in Quality Central but the issue got closed and "Promoted to Internal Database".
What does this mean? Should I expect an answer to this already year and half old question?
These two warnings are now documented.
GARBAGE: Turns on or off warnings produced when the presence of non-whitespace text is detected past the end of the final 'end.' in the program, unit, library or package
UNIT_EXPERIMENTAL: Turns on or off all warnings about the experimental directive applied to a unit declaration.
Presumably the report was marked as fixed once the documentation was added.
Related
I am working on the project where I found the warnings as
W1000 Symbol 'StrLComp' is deprecated: 'Moved to the AnsiStrings unit'
There are so many warnings in my code for many of the string functions defined in the System.SysUtils.
I am not able to use the AnsiStrings functions because it makes multiple occurrences.
Can anyone please tell me How I can remove these type of warnings?
I am working on Delphi 10 Seattle.
These warnings are dealt with quite readily by using the System.AnsiStrings unit, just as the warning instructs you. Use that unit, listing it after System.SysUtils in your uses clause, and the warning will no longer be produced.
If you include both System.SysUtils and System.AnsiStrings then you will encounter an ambiguous overload error when calling this function with an Ansi string as input. That will need to be resolved by qualifying the function name:
System.AnsiStrings.StrLComp(...)
or
AnsiStrings.StrLComp(...)
Depending on whether or not you use namespace aliases.
Before you go down this path, you might want to take a step back and consider if you really want to continue calling this ANSI function. Can you not use the Unicode version instead? If you can do so, this entire issue disappears.
This is a common question for other compilers (C#, VC++, GCC.) I would like to know the same thing for the Delphi compiler (any version; I'm currently using 2010 and XE2 and will use XE4 soon.)
I have a situation in high-performance code I'm writing where a condition has to be checked, but in most cases no action needs to be taken:
if UnlikelyCondition then
HandleUnlikelyCondition
else
HandleLikelyCondition
end;
Often nothing needs to be done for the likely case:
if UnlikelyCondition then
HandleUnlikelyCondition
else
Exit
end;
I would like to hint to the compiler that the second branch of the if statement is the one to optimize for. How can I do this in Delphi?
Current code
Currently, I have written my code assuming that the if statement's condition equalling true is the best thing to optimise for:
if LikelyCondition then
HandleLikelyCondition
else
HandleUnlikelyCondition
end;
or
if LikelyCondition then Exit;
HandleUnlikelyCondition;
In a test just now using the first of these two examples, I get a 50% extra performance boost restructuring my if statements like this, ie assuming the if statement's condition is true. Perhaps another way of phrasing the question is, is this the best I can do?
If you have not encountered branch misprediction before, this epic answer is an illuminating read.
There is nothing in the language or compiler that allows you to supply hints for branch prediction. And in any case, modern architectures would ignore those hints even if the compiler emitted object code that contained hints.
Everyone knows about hint directives. However from reviewing various modules, i learned what, for example, deprecated accepts string -literal- to be emitted in the same manner $MESSAGE does:
procedure StinkStr(S: string); deprecated 'You are unemployed now.';
However, documentation being modestly silent about that (highest version i have my hands on is D2010) and i hate guesswork in exact sciences - the questions are:
where this syntax is documented?
and, since which version it has been available?
Correction: accepts string literals only, refuses constants (a la external).
Current findings: D210 chokes on string literals accompanying any hint directive other than deprecated, also eats the hint if unit is marked with it.
It's documented here http://docwiki.embarcadero.com/RADStudio/en/Deprecated
As the comments mention above, it seems to have been introduced in Delphi 2009. Another reference is http://www.tindex.net/Language/deprecatedwithcomment.html
We have some ancient Delphi code (might have even originated as Turbo Pascal code) that uses {$I-}, aka {$IOCHECKS
OFF}, which makes the code use IOResult instead of exceptions for disk I/O errors.
I want to get rid of the {$I-} and bring this code forward into the 1990s, but to do that, I'd like to know what all is affected by {$IOCHECKS OFF}. Does this only affect the crufty old built-in I/O functions like AssignFile / Reset / Rewrite / Append / CloseFile? Or does it affect more modern things like TFileStream as well? More importantly, what else might be affected that I'm not thinking of? (Delphi Basics suggests that it also affects MkDir and RmDir. If it affects those, there have to be more.)
The Delphi 2007 Help topic "Input output checking (Delphi)" (ms-help://borland.bds5/devcommon/compdirsinput_outputchecking_xml.html) says that this affects "I/O procedure[s]", and that "I/O procedures are described in the Delphi Language Guide." This doesn't help much, since CodeGear has never shipped a Language Guide, and the last time Borland shipped one was Delphi 5.
Which functions and classes behave differently under {$I-}?
EDIT: The accepted answer gives some great background, but here's the quick summary in alphabetized list form: {$IOCHECKS OFF} only affects the following routines from the System unit.
Append
BlockRead
BlockWrite
ChDir
CloseFile
Eof
Eoln
Erase
FilePos
FileSize
Flush
MkDir
Read
Readln
Rename
Reset
Rewrite
RmDir
Seek
SeekEof
SeekEoln
SetLineBreakStyle
Truncate
Write
Writeln
Since $I is a compiler directive, it can only affect compiler-generated code, and it can only affect code that actually gets compiled.
For those two reasons, it cannot affect things like TFileStream. It's a class in Classes.pas, which is a unit you don't compile. Any code in it is not affected by the $I directive. Furthermore, the compiler doesn't treat that class specially in any way. It's just another ordinary class.
The $I directive affects the language built-in functions that you've mentioned. The compiler generates calls to those functions specially. It also affects calls to write, writeln, and readln. It should also affect BlockRead and BlockWrite.
You can check the source code. Anything that calls SetInOutRes is susceptible to $I. That includes functions that open files (Append, Reset, and Rewrite), as well as anything else that accepts a parameter of type file or TextFile (Flush, BlockRead, BlockWrite, Erase, FilePos, Seek, FileSize, Read, Readln, Write, Writeln, Rename, Eof, SeekEof, Eoln, SeekEol, Truncate, SetLineBreakStyle, and CloseFile). Also, anything that calls InOutError (ChDir, MkDir, amd RmDir).
Notably absent from the list is AssignFile. That function doesn't actually do any I/O. It just sets up the file record so that Append, Reset, and Rewrite will know what to do.
I should point out that looking at the source code is just inference. The $I directive controls whether the compiler will insert calls to the __IOTest function in your own code after you call certain other functions. That function checks the value of InOutRes, and if it's not zero, it raises a run-time error (which may yield an exception if SysUtils is included in your program). We can't check the source code to directly find out what functions are affected by $I (since it's only called in compiler-generated code), so we're really just looking for which functions set InOutRes, with the assumption that they wouldn't bother doing that if they didn't know the compiler would check for it afterward.
In CodeGear Delphi 2007, how can I turn specific warnings and hints off? I am attempting to turn off H2077 - Value assigned to 'varname' never used.
You are not able to disable specific hints like you can with warnings. Hints are those things that would not have any potential adverse affects on your runtime code. For instance, when you see the hint "Value assigned to 'varname' never used" it is merely a suggestion for something you should probably "clean up" in your code, but it won't cause any potential runtime errors (other than your own logic errors, of course :-). Hints are always best addressed by tweaking the code.
Warnings, on the other hand, are those things that could possibly cause unintended runtime behaviors and really should be addressed. For instance, using a variable before assigning a value to it is clearly a case of an uninitialized variable and that can lead to "bad things." In the vast majority of times, warnings should be addressed by "fixing" the code. Even then, in certain circumstances you may deem the warning as a "false positive" and are certain the code is functioning correctly. In those cases, you can disable a specific warning. Disabling all warnings is dangerous.
Hints? No specific.
You'll have to disable them all:
{$HINTS OFF}
Warnings?
{$WARN _name_of_warning_ OFF|ON|ERROR}
Check here for a full list
Why don't you instead change the code so the hint goes away? Those hints are usually pretty accurate. And if you really feel that the line of code (I'm guessing some variable initialization or other) is useful to the reader of your code even if it is irrelevant to the compiler, you can replace it with a comment.
What Lars said. Also, you can get the complete list of warnings and their current settings by pressing CTRL-O twice. It'll dump a list at the top of the current unit. You can look through there to find the one you need to change. Just remember to delete the list later, or people looking at the code later on will hate you. ;)
To remove a hint for a line of code that has the:
H2077 Value assigned to '%s' never used
You can wrap it in:
{$HINTS OFF}
//...
{$HINTS ON}
For example, from the buggy Vcl.ComCtrls.pas:
procedure TTrackBarStyleHook.Paint(Canvas: TCanvas);
//....
begin
if not StyleServices.Available then Exit;
{$HINTS OFF}
Thumb := ttbTrackBarDontCare; //value assigned to 'Thumb' never used
{$HINTS ON}
//...
end;
Note: Any code released into public domain. No attribution required.