Source Code Limit Confusion

[Borje Hagsten]

Just a little notice, in case someone has missed this: Aside from
include files (.INC), it is also possible to break up a project in
a bunch of .BAS files.

I usually do this for sub-dialogs, so main code file can look like:

#COMPILE EXE
#RESOURCE "MYEDIT.PBR"
#INCLUDE "EDM32.INC"
#INCLUDE "FINDDLG.BAS"
#INCLUDE "ABOUT.BAS"

.. etc. And another tip: When I build these sub-dialogs, I usually start
doing them as "templates" - stand-alone .EXE's - each one placed in a
sub-folder in main project's folder. This makes it much faster/easier to
design the actual dialog - instead of having to compile entire project,
I get away with the dialog only, so re-arranging controls, etc. goes
much faster.

Usally no working code in these "templates", just the dialog and a callback
procedure. This way, I slowly build up a library of designed dialogs, so for
next project, I can often save a lot of time by re-using old ones.

When it's time to use any of these stand-alone dialogs, it's just a matter of
copying the .BAS file from the sub-folder to where-ever I need it, remove the
#COMPILE EXE statement, change WinMain/PBMAIN to something like "ShowFindDlg"
and change parent handle to become main dialog's..


------------------

[Lance Edmonds]

It's likely...

------------------
Lance
PowerBASIC Support
mailto:[email protected][email protected]</A>

Originally posted by Bern Ertl:
Lloyd,
It is possible to create your large app whether you hit any
limits or not. There are ways to work around all of them (ie.
breaking up code into .DLLs, .INC files, etc.).

Bern, I'm not sure if breaking your code up into .INC files is
necessarily a solution for programs that are too large to compile.
(Of course, if one of your source code files by itself were too
huge for the compiler to handle, in that case breaking up your
code into .INCs might save the day).

When my current project "hit the wall" a couple of weeks ago
(too big to compile), my first attempt to get around it was to
break the main .BAS file up into several smaller .INC files,
which had no effect. I simply have too much source code. I had
to break my program up into several separate .EXEs and a few
.DLLs to get the main module to compile again.

Putting part of your code into .DLLs or other .EXEs appear to
be the only solutions, other than writing more compact code, I'm
afraid. Let's hope the next PBDLL upgrade will permit
compilation of larger programs, which would make program design
much simpler.



------------------

[Bern Ertl]

Lloyd,

It is possible to create your large app whether you hit any
limits or not. There are ways to work around all of them (ie.
breaking up code into .DLLs, .INC files, etc.).



------------------
Bernard Ertl

[Michael Mattias]

In the email between yourself and Tech Support, the problem was identified as follows:

Well, that was ONE of the tech support problems I had submitted. The other, which involved PBDLL.EXE going GPF, was answered by yourself thus:

Thank you for your email. Your code does indeed highlight a problem with
the compiler.
...
Unfortunately, I'm not able to pinpoint which portion of the code that
triggers the problem, but R&D have confirmed that the issue has recently
become known to them...

The problem with %DEF and %PB_EXE was the error in the documentation.

MCM

I am sure code excluded by a #if..#EndIf block is not included/compiled by the compiler.
I use #if..#endif blocks for some comments because of a quirk in UltraEdit which causes it to sometimes begin
coloring a number of active code lines as though they are commented when scrolling.

#if 0!
  The rain in Spain is also wet.
#endif

[Lance Edmonds]

michael, if you are talking about your post in http://www.powerbasic.com/support/pb...ead.php?t=4022 that you did not post example code, rather you posted heresay.

in the email between yourself and tech support, the problem was identified as follows:

#if %def(%pb_exe)
  ' code
#end if

the result with that implementation is that the code inside the #if/#endif block was *always* included in the exe because the %pb_exe equate itself is always defined (which the %def() function evaluates *during* compilation), but the actual value of the %pb_exe equate itself will depend on whether the code is being compiled as an exe or as a dll.

the correct way to write target-specific (exe/dll) metastatement enclosed code is thus:

#if %pb_exe
  ' code for exe compilation
#else
  ' code for dll compilation
#end if

in summary, code that is excluded by #if/#endif is ignored by the compiler - i have not seen a single confirmed case to the contrary.

------------------
lance
powerbasic support
mailto:[email protected][email protected]</a>

[Michael Mattias]

What contributes to filling this [16Mb maximum compiler] space during compile is the symbol table, literal text strings, DATA, etc.

And as my example from two weeks ago demonstrated, "code between #IF 0...#ENDIF"

MCM

[Eric Pearson]

That would count as one line.

The IDE's editor is just working with "text". It doesn't care about colons, remarks, $IF blocks, or anything else. As far as it is concerned, it's all the same.

-- Eric


------------------
Perfect Sync Development Tools
Perfect Sync Web Site
Contact Us: mailto:[email protected][email protected]</A>

[Aldo Vitagliano]

Lance,

There is a 16,000 line limit PER FILE, IN THE current IDE

If a line is made up of n statements, separated by :
does it count as 1 line or as n lines ?




------------------
Aldo Vitagliano
mailto:[email protected][email protected]</A>

[Lance Edmonds]

Ok, lets put some of the misleading and inaccurate claims to bed:

1. There is a 16,000 line limit PER FILE, IN THE current IDE.

The compiler itself can handle much bigger files, no problem. Therefore, if your app code is going to occupy more than 16,000 lines, break it up into a .BAS and one or more .INC files (and use #INCLUDE).

Remember, if the compiler choked at a mere 16k lines (total) per app, how would anyone ever use the WIN32API.INC file (which is nearing 16K lines by itself)?


2. There is a (approx) 16,000,000 byte memory limit imposed on the compiler by Windows.

The current implementation of the compiler has to work in that space.

What contributes to filling this space during compile is the symbol table, literal text strings, DATA, etc.

For example, using lots of "very long" variable names will definitely impact on the synbol table size during compilation.

I've seen PB/DLL compile apps that are greater then 1Mb (disk size, excluding resources) - do you think your executable will be that large, Lloyd?


3. The "16K" memory limit you mention is actually a 16Mb limit. WinNT/2000 can provide 16Mb per 16-bit task, but Win95/98/ME are hybrid 16/32-bit O/S's and with those, all 16-bit processes share the same 16Mb. Therefore, you are likely to be able to compile larger programs under WinNT/2000 than 95/98/ME.]


4. Just because the compiler is 16-bit does not mean it is impossible to break through the 16Mb limits... it is quite likely future versions of the compiler will extend the limits significantly...


Ok?

The bottom line is this: don't panic. If you do manage to hit the current limits, you cna always create DLL's to cut the size of your main EXE.


------------------
Lance
PowerBASIC Support
mailto:[email protected][email protected]</A>

[Lloyd Snyder]

Ok, I was planning on starting a project that will be quite
large... Here recently, I've heard some talk about a 16k limit
on source code that PB can compile, and I had a few questions.

Question 1) PB doesn't actually compile constants into your
program, so would having a lot of constants still count against
the 16k limit???

Question 2) If I used #IF to remove code that isn't needed,
will that code still count against the limit???

Question 3) I am to understand that the limit is do to the fact
that the compiler is 16bit, and some versions of windows will
give each program a set amount of memory, others share the memory
among all 16bit programs currently running. How does Window ME
handle 16bit application's memory???

------------------


[This message has been edited by Lloyd Snyder (edited July 14, 2001).]