Error 409

[Giuseppe Belziti]

I have done a program too large with a lot of things that are all usefulls and I cannot leave anything.

Now the compiler give me an 409 error: Sub/Function is too large

Sub/Function is too large - The number of lines of code Sub or Function is too long for the compiler to process. This can occur if the Sub or Function contains more than 12,000 lines of code. Break the Sub or Function down into two or more Subs or Functions.

Now I have attempt to move some code part in another Function but it don't operate. For example I have put a $INCLUDE in this second Function:
$INCLUDE"C:\PBCC\PRO\PAG\WDIPINC.BAS"
but it give me error.
How to use two or more Subs or Functions? Can you give me an example of their use?
Thanks

[Mel Bishop]

Just as a knee-jerk: When you created the new function, did you make sure your variables are visible to it? i.e.,

function TooLarge as string
local i, j, k as string
local a, b, c as long

...process
...process
This segment is moved to a new function
...process
...process
end function

function NewFunction
...process
...process
   end function

Now if i, j, k and a, b, c are defined as local in the TooLarge function, they won't be visible in the NewFunction, causing some problems.

[Walter Henn]

It's certainly disconcerting to learn that the compiler is not capable of handling functions that contain more than 12,000 lines of code. While I admit that functions of this size might reflect poor programming technique, it, nevertheless, does not appear to be a reasonable restriction. (Goto statements might reflect poor programming technique, but that's not a good reason to forbid them.)

I think that the next version of the compiler should address this restriction and permit virtually unlimited length functions.

[Knuth Konrad]

[...] more than 12,000 lines of code.

Rule of thumb: a procedure should be no more than maximum 2-3 screen pages long, so that one could scroll through it and understand the prodcedure's purpose with relative ease.

Coming from DOS, I tended to put everything in Main() in the beginning and change my coding style later on. I very much prefer the way I code now.

[Walter Henn]

While I admit that functions of this size might reflect poor programming technique, it, nevertheless, does not appear to be a reasonable restriction.

In my post, I clearly indicated that having functions of 12,000 lines or more might reflect poor programming technique. That said, the use of such functions should not be governed by the inability of the compiler to handle such functions, nor should it be governed by arbitrary rules of thumb.

[Michael Mattias]

I think that the next version of the compiler should address this restriction and permit virtually unlimited length functions

Granted we have entered the realm of the subjective, but to this writer it seems twelve thousand lines per procedure is already virtually unlimited.

the inability of the compiler to handle such [length] functions

But it did "handle" it, by giving an unambiguous compile-time message with an obvious solution.

When you think about it, you already deal with dozens of "restrictions" and "limitations" in the compiler; what is so special about this one?

e.g, can't have lines > 255 characters, DDT commands only valid in current code module, can't forward reference procedures, UDTs or equates, thread functions must be in same code module, etc, etc...

Seems to me if you can deal with these you can deal with this one, too.

All applications - including compilers - must make design-time tradeoffs among features, performance and cost. Successful products are those which make those tradeoffs skillfully. PowerBASIC Inc has been around about twenty years; in the world of computer software that is a very long time so IMNSHO they must be making those tradeoffs reasonably well.

[Fred Harris]

I'm pretty sure I ran into something like this years ago in Visual Basic 6.0. And I'm also pretty sure I had hit the limit somewhere considerably shy of twelve thousand lines.

[Walter Henn]

Granted we have entered the realm of the subjective, but to this writer it seems twelve thousand lines per procedure is already virtually unlimited.

Thank you for your opinion!

But it did "handle" it, by giving an unambiguous compile-time message with an obvious solution.

So, it handled more than 12,000 lines by generating an error message. What rubbish!

When you think about it, you already deal with dozens of "restrictions" and "limitations" in the compiler; what is so special about this one?
e.g, can't have lines > 255 characters, DDT commands only valid in current code module, can't forward reference procedures, UDTs or equates, thread functions must be in same code module, etc, etc...

All applications - including compilers - must make design-time tradeoffs among features, performance and cost. Successful products are those which make those tradeoffs skillfully. PowerBASIC Inc has been around about twenty years; in the world of computer software that is a very long time so IMNSHO they must be making those tradeoffs reasonably well.

Your argument that a limitation should be OK because there are all sorts of other limitations in the compiler is ridiculous at best. And the fact that PowerBasic has been in business about twenty-years does not mean that they always make the right decisions. PowerBasic made the choice to severely limit error handling in their more recent compilers, a poor decision in my opinion. If they were concerned about speed and size, they could have provided the programmer with the option of either having more extensive error trapping or not.

But, in the end, I always enjoy your posts, Michael, because they are so comical.

[Michael Mattias]

Comical?

I think not.

If you want to pay $1500 or more for a compiler without all the "ridiculous" restrictions (that was intended to be comical) in the PB compiler, be my guest.

Then again, it's not the paintbrush, it's the artist. Best wishes to you when you next paint. (Hint: 2 = Red.)

MCM

[Walter Henn]

Comical?

Then again, it's not the paintbrush, it's the artist. Best wishes to you when you next paint. (Hint: 2 = Red.)

MCM

Is your post supposed to be clever repartee? Sorry, Michael, it's just not in you!
:fight2:

[Bob Zale]

Hi Giuseppe--

I think you're misunderstanding the nature of the error message. You need to extract some of the code in your MAIN function, and break it up into smaller subroutines. This has nothing at all to do with INCLUDE files. Here is a small example of the technique on a very small scale:

FUNCTION PBMain()
PRINT 1
PRINT 2
PRINT 3
PRINT 4
PRINT 5
PRINT 6
PRINT 7
PRINT 8
END FUNCTION

Change this to a Function plus a Sub, such as:

FUNCTION PBMain()
PRINT 1
PRINT 2
Call Print3ToSix
PRINT 7
PRINT 8
END FUNCTION

SUB Print3ToSix()
PRINT 3
PRINT 4
PRINT 5
PRINT 6
END FUNCTION

Actually, if you break your code up into many such smaller modules, you'll find it's much easier to manage your program source code. Of course, there's an added benefit that many of these smaller Subs and Functions can probably be re-used many, many times just like you might re-use subroutines called by the GOSUB statement.

When you look into this further, I think you'll find that there is never a need to have a single Sub or Function with anywhere near 12,000 lines of source code. Ideally, each one should probably be limited to no more than a couple of hundred lines of code. When each Sub or Function is kept to a reasonable size by performing just one logical task, it's much easier to debug and maintain your program.

If you've read all the PowerBASIC documentation about using a Sub or Function, and you still have questions, please feel free to post them right here. You might also consider getting a good book on BASIC programming. One of the very best is "LEARNING BASIC", by Don Inman. It's no longer actively published, but you can always find used or even like new or new copies for sale on AMAZON.COM. Shouldn't cost more than just a few dollars.

Let us know how we can help?

Best regards,

Bob Zale
PowerBASIC Inc.

[Chris Holbrook]

...might reflect poor programming technique...

I'm not so sure about that. It is quite conceivable that someone may have learnt BASIC coding on an older interpreter, maybe even a long time ago, and is simply unfamiliar with SUBs and FUNCTIONs (probably misses line numbers too!). Under these circumstances, that person may have written some very good old-style BASIC, and while the advice to break up the code using SUBs and FUNCTIONs is appropriate, to even mention "poor programming technique" is, at best, to miss the point.

[Knuth Konrad]

I disagree, Chris.

A BASIC without Subs/Functions? That must be really a long time ago. Even QBasic back in the MS DOS 5 days already had procedures. And that is 20+ years ago. So even if your statement is true that one learned BASIC on an old interpreter, coming back after 20+ years and expect everything to be the same doesn't make sense, IMHO.

[Dale Yarker]

I wouldn't think increasing the limit should be a priority.

"Then again, it's not the paintbrush, it's the artist."

12,000 lines in one SUB/FUNCTION isn't art; it's a small nuclear explosion at a paint factory.

[Rodney Hicks]

I have to agree with Chris here. We don't know the level of experience. To assume that someone is familiar with the full potential of a product when they are just new to the product is a little presumptuous.
I suspect there may be a bit of a language barrier, and I don't know if the documentation is available in the poster's mother tongue.
I think guidance by example a la Bob Zale is the order of the day, rather than a rant on some rarely occurring feature.

Rod

[Bob Zale]

Hello Giuseppe!

I have to apologize to you for some of the things posted by our friends here. I'm sure they're mostly well-intentioned.

The truth is, we'd very much like to help you with your question. If you'd like some additional help, just ZIP your source files and send them to us at [email protected] -- Even though we can't normally write code for customers, I'd like to have one of our engineers show you some specific examples of how this can be easily accomplished, right in your own program.

Once you've used PowerBASIC a little more, this will become very straightforward for you. Please don't hesitate to ask any other questions, but it might be best to place them in a new thread to avoid all these other comments.

Thanks for posting, Giuseppe!

Best regards,

Bob Zale
PowerBASIC Inc.