Re: Compile speed: Pascal(Delphi) vs C++

Chavoux wrote:


> I am not familiar at all with the internals of the compilers of these
> languages, but I would like to know why this is the case? I have heard
> a few times that C (and C++?) programs tend to be very fast at
> runtime, but to compile slowly.


There are a number of variables involved, including type of compiler,
how it was written, target, etc.


> [DELETED] (I.o.w. maybe the Pascal is a real one-time pass
> compiler, whereas C compromised on this somewhere along the line?)


Most Pascal compilers are in fact, true one pass compilers for the
simple reason that they can be. Since everything is pre declared, you
have no unknown forward references, the compiler can include stub
references for things that have been defined but not yet referenced
(that is, you know that an item will exist at some point later on in
the code but you don't know where it will be) then come back and do
fixups for those unknown forward pointers. Much, much faster than
having to keep bookkeeping of both undeclared and forward declared
items (in hope that they will be declared later) which is required for
C and C++.


Not to raise any language wars here, but C++ is simply a much more
complicated language with a lot more ways to do things in it than
Object Pascal and thus it is going to take more work to compile.
Also, Pascal is a rigidly defined language which it is much easier to
syntax check than C or any of its derivatives (C++, Java etc.), thus
Pascal compilers can be smaller and faster.


It is quite possible to build a 'state machine' for Pascal in which,
in any particular construct of the language, there are a limited
number of legal states that you can transition to, and in fact, that
is exactly the way most Pascal compilers are written. (Having read
the source code to some 9 different Pascal compilers written for 6
different systems, I believe I am qualified to offer such an opinion.)


Such a capacity is impossible for C and C++. That makes compilers for
those languages much more complicated, bigger and slower.


> AFAIK static linking is always needed on programmes written for
> Windows because you can't assume that the C libraries will be
> available on the user's PC.


Actually, that is not true on both points. Most Microsoft Windows
applications use dynamic linking and you usually CAN assume the
libraries you need will be available on the user's PC. I'll explain
why.


If you write a program using anything that is referring to Microsoft
Visual C/C++, those libraries are included as standard components of
Microsoft Windows (because some parts of Windows are written using
Microsoft's C compiler, natch). Now, when you create an application
you're supposed to build an install for it that includes all necessary
components. Most Microsoft Windows-based compilers that I am aware of
(Visual Basic, Visual C, Delphi, etc.) do include either a rudimentary
installer that will at least set up the application and include
appropriate files, register necessary components include needed
registry keys and libraries, or they include a stripped-down version
of a third-party installer.


Visual Basic's default installer is itself written in Visual Basic
except for a small stub-loader written in Visual C to load some
libraries needed by the installer. Visual C's installer is, of
course, written in Visual C. Delphi uses a 'light' or 'personal'
version of Installshield. Those at least, are the ones I know of.


You may also purchase a number of third-party installers
(InstallShield, Wise) or obtain open source third-party installers
(Inno Setup) that will do the job and are essentially programmable
tools in their own right, sometimes requiring a degree in rocket
science to use them properly. The installers are supposed to check
for the presence of libraries and components on the system where the
application is to be installed, and to install missing ones as well as
upgrade older libraries as needed.


Most Microsoft Windows applications that use components or libraries
therefore are in fact dynamically bound to them at run time because of
the 'usual and customary practice' of installing the 'latest and
greatest' files when a program is installed.


This is one of the reasons why to install an application you can't
simply copy files over to a Windows 9x/2000/Me/NT/Xp system like you
could with DOS and Windows 3.1 applications, because of the use of
dynamically bound libraries. (Plus possibly registry keys and
application settings, another matter altogether.)


--
Paul Robinson "Above all else... We shall go on..."
"...And continue!"

Return to the comp.compilers page.
Search the comp.compilers archives again.