One very basic question

SkyManager · Post by **SkyManager** » Fri Mar 09, 2007 8:50 am

I have an include file which contains about 30 functions.
If I create an application which include this file but use only 3 functions, will the resulting exe include 30 functions or only 3 functions

Joakim Christiansen · Post by **Joakim Christiansen** » Fri Mar 09, 2007 9:07 am

If I remember correctly PureBasic 4 only included the functions you used.

Derek · Post by **Derek** » Fri Mar 09, 2007 10:10 am

Edit the include file to contain only the three functions you want, save it with a different name, compile two programs, one using the old include and one using the new include and then compare the size of the files.

This should show you conclusively what PB does.

Trond · Post by **Trond** » Fri Mar 09, 2007 11:30 am

It will include all called functions, including those which are called from uncalled functions:

Code: Select all

procedure Included()
endprocedure

procedure NotIncluded()
  Included()
endprocedure

procedure Included2()
endprocedure

Included2()

srod · Post by **srod** » Fri Mar 09, 2007 11:38 am

I think it will include all functions from an include file regardless.

With a compiled Purebasic user library, on the other hand, because the library is split (and basically has 1 object file per function), only the functions which are called get thrown into the final executable.

Trond · Post by **Trond** » Fri Mar 09, 2007 3:29 pm

> I think it will include all functions from an include file regardless.
It's like I described in my post above. If include files are handled differently than the main file, then there's a problem somewhere.

srod · Post by **srod** » Fri Mar 09, 2007 3:36 pm

Include files are handled exactly the same as the main source file in that all functions are placed into the exe regardless. As far as my understanding goes, only compiled PB user libraries offer the flexibility of being able to only include functions which are referenced (even if they're not actually used I guess).

Trond · Post by **Trond** » Fri Mar 09, 2007 4:32 pm

Why don't you just have a look at the generated assembly code to confirm that what I said is correct?

SkyManager · Post by **SkyManager** » Sat Mar 10, 2007 12:38 am

Yes, I can. But I suppose there will be an official answer from PB support. At least, you folks have already encountered this problem before.

Anyway, thank you all for the help.

hagibaba · Post by **hagibaba** » Sat Mar 10, 2007 12:47 am

what Trond said is correct.

If you don't call a procedure in your PB source code it won't be compiled to the executable (PB v4.02). It also makes no difference if the procedure is in an include file or not.

PB · Post by PB » Sat Mar 10, 2007 1:59 am

> If you don't call a procedure in your PB source code it won't be compiled

Not entirely true. Compile an exe with an uncalled procedure that has a string
in it, then search that exe with a hex editor for that string, and you'll find it.

Fred explained that strings are still included, but generally the procedures aren't.
I can't find his full explanation now, despite searching here for about 20 minutes.

srod · Post by **srod** » Sat Mar 10, 2007 11:05 am

Trond wrote:Why don't you just have a look at the generated assembly code to confirm that what I said is correct?

My apology Trond.

Everytime I looked at the generated assembly I saw the procedure code translated into asm even when it wasn't called. What I missed was the fact that it was embedded within a macro and the macro only utilised if the procedure was actually called. That's a nice way of doing it.

PB · Post by PB » Sat Mar 10, 2007 11:29 am

> compile two programs, one using the old include and one
> using the new include and then compare the size of the files.
> This should show you conclusively what PB does.

Not so. I just compiled the following two sources, and both create executables
of exactly 2.00 KB (2,048 bytes). This is due to Win32 executable sizes being
on a boundary of some kind -- I'm not very technical for the correct phrase.

Anyway, here's the conclusive proof: compile these two sources, then load each
in a hex editor. You'll see BOTH contain the DeleteFileA API in them, even though
the second one DOESN'T call the procedure that contains the DeleteFile command.

Code: Select all

; This one DOES call the procedure.

Procedure zzz(file$)
  DeleteFile_(file$)
EndProcedure

Sleep_(1)
zzz("c:\nosuchfile")

Code: Select all

; This one DOESN'T call the procedure,
; but the exe still has DeleteFileA!

Procedure zzz(file$)
  DeleteFile_(file$)
EndProcedure

Sleep_(1)

SkyManager · Post by **SkyManager** » Sat Mar 10, 2007 11:44 am

Actually, I have done some similar tests with similar results as yours.
Thank you for the help.

Derek · Post by **Derek** » Sat Mar 10, 2007 6:46 pm

I'm wrong again.