Home Articles Books Download FAQs Tips

General IDE:
Watch for out of date #pragma link commands that cause code bloat

Before you read this tip, check out the tip on your project's directory settings. That tip is related to this one.

When you place a control onto a form, the C++Builder IDE automatically inserts a #pragma link statement for that control's compiled OBJ. To view the #pragma link command, create a new project and place a third party control or sample control (BCB 1.0 only) on the form. Now look the the form's CPP file. You should see something like this:

#include "Unit1.h"
//---------------------------------------------------------------------------
#pragma package(smart_init)
#pragma link "xgauge"
#pragma link "piereg"
#pragma resource "*.dfm"

In the previous example, I added the BCB 3 Pie control and my own XGauge control to a form. The #pragma link commands essentially add the OBJ's for the Pie control and XGauge control to the project. The linker will then know that it should link these OBJ's in to the EXE.

A problem crops up when you start removing controls from a form. C++Builder doesn't seem to delete the #pragma link commands. The result is that OBJ's are linked that don't need to be. This can slow down the linker and can sometimes cause unecessary code bloat (since newer versions of BCB use packages, the bloat is sometimes not readily apparent). To prevent this problem, look at your source files periodically and verify that every #pragma link command is still needed. You can simply comment out suspicious commands. The linker will holler at you if you remove one that it still needs.

In conjunction with looking for extraneous #pragma link commands, keep an eye out for old control declarations in the header files for your forms. Delete declarations for controls that you absolutely know have been removed from the form (if you're unsure, leave the declarations alone). These declarations can force the linker to keep an OBJ that contains the code for that control. The linker is usually smart enough to ignore OBJ's that don't seem to be used anywhere, but unecessary declarations can force it to pack an OBJ into the EXE.

Another thing to look out for is #include statements for controls that have been removed. This will usually show up in a unit's header file. Here's what the unit header file looked like for this example after I removed the components:

#include <Classes.hpp>
#include <Controls.hpp>
#include <StdCtrls.hpp>
#include <Forms.hpp >
#include "piereg.h"
#include "xgauge.h"

The IDE didn't remove the #include statements even though the pie and gauge controls were deleted. Usually, header files alone don't cause code bloat, but it's a good idea to keep your code as clean as possible.



Copyright © 1997-2001 by Harold Howe.
All rights reserved.