In this question (link) it was said that the line below (in each unit) would remove as much RTTI as possible:
{$RTTI EXPLICIT METHODS([]) PROPERTIES([]) FIELDS([])}
The posting didn't mention what Delphi version it works with, but I assume D2010. However, when I include the line above, I get this error:
DCC Fatal Error: E2158 System unit out of date or corrupted:
missing TVisibilityClasses.
I'm using a "stock" version of D2010 and have never done anything that I'm aware of that would change the default installation or the libraries.
Any suggestions? TIA
Related question: link.
Make sure you put the "{$RTTI" line below the "unit unit1;" line.
Note that as of XE5 and newer, this directive needs to be in each individual unit for which you want to disable RTTI. Before that (as in comments, which applies only to XE4 and below) it could be in the DPR file and would apply to all units in the project.
The new RTTI is for Delphi 2010 and up.
It can be removed, but then lots of things will have limited functionality (like JSON conversion, part of DataSnap and many of the newer 3rd party libraries that do ORM or other mappings).
Things depending on TValue are gone anyway.
"old style" RTTI (which was introduced in Delphi 1 and is still present in Delphi 2010) cannot be removed.
So: it is recommended to remove RTTI only from your own units, and not from the RTL and VCL.
--jeroen
Related
In compiling a Delphi 2007 project, I receive the following error:
E203: Undeclared identifier: TChangeLink
This appears to belong to the Vcl > ImgList library.
My limited understanding is that Vcl is part of the native Delphi libraries. How do I verify that it is correctly referenced?
It's because ImgList isn't in your uses clause. Based on information you provided in a comment,
uses contains this line:
Clipbrd{$IFDEF DELPHI4}, ImgList {$ENDIF}, dxCommon{$IFDEF DELPHI6}, Variants{$ENDIF}
It's because the {$IFDEF DELPHI4} is excluding it, presumably because DELPHI4 isn't defined. This is typically caused by using code that is in open-source or commercial component sets that use those version defines to support multiple Delphi versions with the same source. (This is usually done in a .INC file of some sort; Jedi uses JEDI.INC, for instance, for all of the version defines for various compiler and IDE related differences.)
The best solution (to maintain cross-version compatibility) would be to update the definitions to include Delphi 2007, but I can't offer advice on how to do so because I don't know where the define is located. The other alternative is to just remove the {$IFDEF DELPHI4} from the uses clause, if you don't need to worry about earlier versions of the IDE/compiler.
I am trying to port some Delphi XE code to XE2, it uses a unit called InvRules.pas, which according to the XE2 docs, has no namespace prefix.
It also isn't in the soap folder where I expect it:
C:\Program Files (x86)\Embarcadero\RAD Studio\9.0\source\soap
The simplest answer is that it's been removed (accidentally or on purpose) from XE2.
Has anyone figured out what's up? This unit contains functions like GetStackTypeSize, and RetOnStack, which are used sometimes in custom TRIOHelper type classes.
This unit is no longer used by the soap runtime so it's not being shipped anymore. In previous releases, it was part of the soaprtl runtime package. There were some significant changes made to the soap runtime for the XE2 release to make the code portable to x64 and less reliant on BASM code that was essentially duplicated in the RTTI support units. The change log entry associated with the commit states:
Refactor out InvRules, use RTTI to get type sizes.
Remove InvRules, PrivateHeap from soap package.
If you have code which relies on the helper routines in this unit you should be fine using the source from a previous release. You may also want to diff the Invoker.pas, InvokeRegistry.pas, OPToSOAPDomConv.pas and Rio.pas units between XE and XE2 to see how the code changed so it no longer relies on the InvRules.pas unit.
i have use delphi xe recently but exe size is very big because of rtti(i think)
howto remove rtti , and can i make my application size as small as delphi 2009 application(490 kb) without comprssion; and what is the use of rtti
In short (full story provided by links in the splash's answer):
{$RTTI EXPLICIT METHODS([]) PROPERTIES([]) FIELDS([])}
Note that as of XE6 and newer, this needs to be in each individual unit for which you want to disable RTTI. Before that (XE5 and below) it could be in the DPR file and would apply to all units in the project.
Read the Online Help for Delphi ...
Working with RTTI
RTTI directive
... and search Stack Overflow:
Why should I care about RTTI in Delphi?
Practical usage for Delphi's new RTTI
Keep in mind that the $RTTI directive has to be included in every unit where it should take effect. See How can I set the $RTTI directive for the entire project?
Your problem is not related to RTTI. If you are talking about relatively small increase (100-200K), this is due to extra functions in RTL (added for Unicode support etc). If you get 500-700K increase or so, then check whether you link VCL UI units (Forms, Controls etc). If you get 3Mb increase, then you've turned on extra debug symbols.
It's because some generics functionality has been added to sys units.
Generics were added in 2009 but in systems units some classes were rewritten with generics in xe and xe2. imho
Add this flags to reduce the size in dpr file (Project > view source) to each individual unit (as of XE5)*.
{$SETPEFlAGS IMAGE_FILE_DEBUG_STRIPPED or IMAGE_FILE_LINE_NUMS_STRIPPED or
IMAGE_FILE_LOCAL_SYMS_STRIPPED OR IMAGE_FILE_RELOCS_STRIPPED}
{$WEAKLINKRTTI ON}
{$RTTI EXPLICIT METHODS([]) PROPERTIES([]) FIELDS([])}
(*) Note that as of XE5 and newer, this needs to be in each individual unit for which you want to disable RTTI. Before that (XE4 and below) it could be in the DPR file and would apply to all units in the project.
I do not think it is RTTI what adds so much size overhead to your application. How do you know it is?
I'm working on migrating an old project from Delphi 2007 to Delphi 2010. One thing I've found is that the resulting executable has more than doubled in size, and the original was already quite big. (Over 50 MB.) I suspect that a lot of it has to do with extended RTTI.
Since the project predates Delphi 2010, it doesn't use extended RTTI anywhere, and I'd like to be conservative about including it. Is there any way to use the Project Options dialog to globally set {$RTTI EXPLICIT METHODS([]) PROPERTIES([]) FIELDS([])} as the default? I'd have expected there to be an option for this (and for $WEAKLINKRTTI) somewhere, but I don't see them.
Does anyone know if this can be done from the "Additional options to pass to the compiler" field, or some other way? I'd really prefer not to have to add an include file to every single unit in the project, as there are a few thousand of them...
The behavior of the $RTTI directive has been changed since XE6 because actually it was a bug because it was supposed to be local to the current unit (and it was actually documented as that since Delphi 2010).
Also it could have fatal affects using the directive at all even in one unit because due to the bug it basically switched a global flag affecting the following units (as in the order of compilation).
You can try with the dcc32 –$weaklinkrtti command-line option. (like {$WEAKLINKRTTI ON}).
But that has not the impact of {$RTTI EXPLICIT METHODS([]) PROPERTIES([]) FIELDS([])} in each unit.
Your best bet would be to have it at the top of each unit in an include file.
But then it wouldn't do it for the VCL/RTL which would still be inflated....
Update: Also make sure you compare what's comparable. For instance verify if you don't include debug information in the Linker Options in the new D2010 project where you may not have it in the D2007 one...
In a comment on Mason's own blog, in response to a comment of mine, Mason answered this question.
Try putting these two lines at the top
of your DPR, before the USES clause:
{$WEAKLINKRTTI ON}
{$RTTI EXPLICIT METHODS([]) PROPERTIES([]) FIELDS([])}
This will make sure that no RTTI gets
generated for your own code or any
third-party libraries you use, unless
they’re in a unit where RTTI
generation is explicitly enabled. You
can’t turn it off for the RTL or VCL,
but that shouldn’t add very much to
your size anyway.
Are you certain this is caused by the new RTTI info? While it's a lot of data it shouldn't really double the size of your application.
Check that it's not including debug info in the release build executable.
(Project options -> Delphi Compiler -> Debug information should be False)
As for the question, I use {$WEAKLINKRTTI ON} before the uses clause in the dpr file and it seems to work fine.
I don't know of such an option, but I still would use an include file.
I wont be a problem for any experienced Delphi programmer to write a small program to add an {$i ProjectIncludeFile.inc} to any unit in your folders (immediatly after the unit line).
And that way you can use it for whatever purpose you like.
I myself use if f.i. to set a WriteTempFiles compiler directive (which I use f.i. to save stringlist contents at various places when developing the program), that way I can disable it in one place when the program is ready for deployment.
Since most of my projects involve multiple executables and/or dll's, this is the easiest way to accomplish this globaly for the whole project.
It is possible to work with a Delphi 5 project in the Delphi 2009 IDE by referencing the Delphi 5 version of dcc32?
If so are there any issues to watch out for concerning the way that project settings (search paths, conditional defines etc.) are implemented in 2009?
Edit: Just to clarify I am also upgrading the project to Unicode but will still need to debug and run releases in the old configuration
It depends on what you're trying to accomplish and what limitations you are willing to accept.
As far as I know, you can't use the Delphi 2009 IDE to maintain Delphi 5 projects directly. For example, even if you stick to functionality that's common between the two, some properties that are not supported in Delphi 5 are written to your DFMs, causing an error at run time.
I've maintained projects and library code that were written in Delphi 2005/2006/2007 that was also being used in Delphi 6/7. I usually edited and debugged these using the latest IDE. I had separate project files for each target version and made sure they all used the same memory manager. Finally, I had an automated build process and unit tests that would strip incompatible properties out of the DFMs (my own DFM Scrubber), make sure all of the targets always compile and run unit tests, which are also recompiled for each target.
All in all, it's more effort and I wouldn't recommend it unless you have a specific requirement to do so.
No. That said, it is still Delphi, and assuming you have source or D2009 versions of any custom components it can be modified to compile in Delphi 2009. The layout of the VCL has changed quite a bit since D5, so expect to have to modify your uses clauses and probably rewrite some small chunks here and there, but it is doable.
You either port your code to Delphi 2009/2010 level (Unicode), or you may as well not install the product.
I suggest you open the project and see where it fails, close the project (without saving anything), find the component versions you need and install them, and once the project opens up in design mode (all components are installed) you can start porting.
Read the Unicode Delphi migration (porting) information available at the website.
Ask your self each time you see PChar, and Char, if it needs to be PAnsiChar, or AnsiChar instead? If you are reading bytes from a disk, a com port, or a network connection, you will need to change from Char to AnsiChar, from PChar to PAnsiChar, otherwise, you might just leave the Char and PChar as they are and they will become Unicode. Always be aware that Char is not a Byte, anymore.
You also must replace explicit references to narrow Win32 API calls with versions without the A (ansi) suffix. Example: CreateFileA might need to become just CreateFile.
W