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
Related
Except for constants RTLVersion and CompilerVersion is there any way how to get version symbol like VER320 instead of following code?
'VER' + IntToStr(Trunc(CompilerVersion * 10))
The simple answer to the question is no. There is no mechanism for code to enumerate conditional symbols.
Your current approach is probably the best you can do, subject to there being no guarantee that future release of the compiler will follow the current VERxxx convention.
Of course, you may as well simply report the compiler version directly.
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.
In the documentation it says, 'source' can be either str or AST object
When trying to compile my ast root:
dl = compile(newRoot, '<string>', 'eval')
I get this Exception:
expected str, got Module
I am using the last version of IronPython.
Is there an idea why this does not work? all the examples I found seem to do it this way with no issues.
Is there a workaround to compile an AST object?
Thanks!!!!
PD: I found this issue but seems to have no activity: http://ironpython.codeplex.com/workitem/32526
First off, IronPython does not support this.
It's actually quite hard to support in IronPython (and I didn't know it needed to be supported until today). IronPython's _ast module is a wrapper around its own AST, and currently only implements conversion from IronPython AST => CPython AST, but not the reverse. It's a fair bit of (honestly, quite tedious) work, so I'm not sure when it will get fixed.
If there's a popular program or library that's broken because of this that moves it up the priority list, and patches are always welcome.
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.
Is it possible to unmangle names like these in Delphi?
If so, where do I get more information?
Example of an error message where it cannot find a certain entry in the dbrtl100.bpl
I want to know which exact function it cannot find (unit, class, name, parameters, etc).
---------------------------
myApp.exe - Entry Point Not Found
---------------------------
The procedure entry point #Dbcommon#GetTableNameFromSQLEx$qqrx17System#WideString25Dbcommon#IDENTIFIEROption could not be located in the dynamic link library dbrtl100.bpl.
---------------------------
OK
---------------------------
I know it is the method GetTableNameFromSQLEx in the Dbcommon unit (I have Delphi with the RTL/VCL sources), but sometimes I bump into apps where not all code is available for (yes, clients should always buy all the source code for 3rd party stuff, but sometimes they don't).
But say this is an example for which I do not have the code, or only the interface files (BDE.INT anyone?)
What parameters does it have (i.e. which potential overload)?
What return type does it have?
Is this mangling the same for any Delphi version?
--jeroen
Edit 1:
Thanks to Rob Kennedy: tdump -e dbrtl100.bpl does the trick. No need for -um at all:
C:\WINDOWS\system32>tdump -e dbrtl100.bpl | grep GetTableNameFromSQLEx
File STDIN:
00026050 1385 04AC __fastcall Dbcommon::GetTableNameFromSQLEx(const System::WideString, Dbcommon::IDENTIFIEROption)
Edit 2:
Thanks to TOndrej who found this German EDN article (English Google Translation).
That article describes the format pretty accurately, and it should be possible to create some Delphi code to unmangle this.
Pitty that the website the author mentions (and the email) are now dead, but good to know this info.
--jeroen
There is no function provided with Delphi that will unmangle function names, and I'm not aware of it being documented anywhere. Delphi in a Nutshell mentions that the "tdump" utility has a -um switch to make it unmangle symbols it finds. I've never tried it.
tdump -um -e dbrtl100.bpl
If that doesn't work, then it doesn't look like a very complicated scheme to unmangle yourself. Evidently, the name starts with "#" and is followed by the unit name and function name, separated by another "#" sign. That function name is followed by "$qqrx" and then the parameter types.
The parameter types are encoded using the character count of the type name followed by the same "#"-delimited format from before.
The "$" is necessary to mark the end of the function name and the start of the parameter types. The remaining mystery is the "qqrx" part. That's revealed by the article Tondrej found. The "qqr" indicates the calling convention, which in this case is register, a.k.a. fastcall. The "x" applies to the parameter and means that it's constant.
The return type doesn't need to be encoded in the mangled function name because overloading doesn't consider return types anyway.
Also see this article (in German).
I guess the mangling is probably backward-compatible, and new mangling schemes are introduced in later Delphi versions for new language features.
If you have C++Builder, check out $(BDS)\source\cpprtl\Source\misc\unmangle.c - it contains the source code for the unmangling mechanism used by TDUMP, the debugger and the linker. (C++Builder and Delphi use the same mangling scheme.)
From the Delphi 2007 source files:
function GetTableNameFromSQLEx(const SQL: WideString; IdOption: IDENTIFIEROption): WideString;
This seems to be the same version, since I also have the same .BPL in my Windows\System32 folder.
Source can be found in [Program Files folders]\CodeGear\RAD Studio\5.0\source\Win32\db
Borland/Codegear/Embarcadero has used this encoding for a while now and never gave many details about the .BPL format. I've never been very interested in them since I hate using runtime libraries in my projects. I prefer to compile them into my projects, although this will result in much bigger executables.