Announcement

Collapse
No announcement yet.

Error 409

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • Error 409

    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
    mailto:info@softplus.it
    From Italy.

  • #2
    Just as a knee-jerk: When you created the new function, did you make sure your variables are visible to it? i.e.,
    Code:
    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.
    There are no atheists in a fox hole or the morning of a math test.
    If my flag offends you, I'll help you pack.

    Comment


    • #3
      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.

      Comment


      • #4
        [...] 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.

        Comment


        • #5
          Originally posted by Walter Henn View Post
          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.

          Comment


          • #6
            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.

            Comment


            • #7
              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.
              Fred
              "fharris"+Chr$(64)+"evenlink"+Chr$(46)+"com"

              Comment


              • #8
                Originally posted by Michael Mattias View Post
                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!

                Originally posted by Michael Mattias View Post
                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!

                Originally posted by Michael Mattias View Post
                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. :laugh:

                Comment


                • #9
                  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

                  Comment


                  • #10
                    Originally posted by Michael Mattias View Post
                    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:

                    Comment


                    • #11
                      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.

                      Comment


                      • #12
                        Originally posted by Walter Henn View Post
                        ...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.

                        Comment


                        • #13
                          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.

                          Comment


                          • #14
                            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.
                            Dale

                            Comment


                            • #15
                              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
                              Rod
                              "To every unsung hero in the universe
                              To those who roam the skies and those who roam the earth
                              To all good men of reason may they never thirst " - from "Heaven Help the Devil" by G. Lightfoot

                              Comment


                              • #16
                                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 support@powerbasic.com -- 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.

                                Comment

                                Working...
                                X