Announcement

Collapse
No announcement yet.

Struggeling with forward referencing

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

  • Struggeling with forward referencing

    I have a general question about best organizing code with .inc files:

    Using at least eight main .inc files not containing forward referencing is simple with PB. But what is if a new additional .inc file cannot be placed in the correct order in the DECLARE section because whereelse I place it, it always is forward referencing to at least one of the other .inc files while the .inc file contains code used by the following .inc files.
    This makes programming very much frustrating sometimes and also leaves back source code in the .inc files by which I repaired 'bugs' caused by forward referencing. So, whenever I reuse a 'repaired' .inc file after some time with new code, I'm getting new bugs caused by the repairs I hardly can find when the .inc files became multi referencing.
    Shure, using a DLL instead of .inc source code would be possible, but this would increase the number of DLLs at least twice. On the other hand, I'm always slightly updating the .inc sources while programming, and it would not be a good idea to recompile them each time before compiling my current source code. My current source for example consists of one .bas file and 14 .inc files.

    So, what would YOU prefer as a constructive solution in such cases?
    Norbert Doerre

  • #2
    The constructive solution is to send a New Feature Suggestion to [email protected] requesting the compilers support forward referencing.

    You will get the much-coveted "checkmark" because I have had that suggestion in for some time.

    As a workaround, the way to get around this restriction for procedures is to eschew the formats:
    Code:
      Var = FunctionName (params)
       or 
      SubName  param, param.....
    .. in favor of
    Code:
     CALL functionname (params) TO Var
       or
     CALL subname (param, param...)
    When the explicit CALL verb is used, the compiler handles forward procedure references just fine.

    No, this does not address the forward reference limitation for User-Defined Types and Unions or equates, but it's a start.

    MCM
    Michael Mattias
    Tal Systems (retired)
    Port Washington WI USA
    [email protected]
    http://www.talsystems.com

    Comment


    • #3
      DECLARE can occur in the main .bas file, before the #INCLUDE. However if you are using any TYPEs, UNIONs, equates and/or globals ... in the .inc's you may need to place those in the main module before the DECLARE function statements. If there are lots of TYPE's , UNIONs, equates and/or globals, you could also place these in a .inc that is included before the declares.

      Writing convoluted code is easy, straightening it out can take effort ... as you are finding.
      Rick Angell

      Comment


      • #4
        The one I really wanted to do but was unable to was a hierarchical linked list...

        Code:
        TYPE ParentType
           members 
           pChild     AS   ChildType PTR 
           members
        END TYPE
        
        TYPE ChildType
           members 
           pParent    AS  ParentType PTR 
           members
        END TYPE
        Oops.


        Strangely enough, you can reference a type before it's completely defined just fine...

        Code:
        TYPE NodeType
           members 
           pParent  [ or pChild]  AS  Nodetype PTR 
           members
        END TYPE
        You can use the "NodeType PTR" even though "nodetype" is not yet completely defined at the point of use.

        But that may be only because the size of a PTR data type is always the same and in context the compiler can never need to know "what" is being pointed to at the time the SIZEOF the named type is needed.
        Last edited by Michael Mattias; 7 Mar 2008, 09:32 AM.
        Michael Mattias
        Tal Systems (retired)
        Port Washington WI USA
        [email protected]
        http://www.talsystems.com

        Comment


        • #5
          Growing technical problems need forward referencing

          I currently prefer Richard's method, and I have been already using it because it offers the best overview to the whole large code with comments in the .bas file.
          But I also consent to Michael's suggestion to finally change the compiler to forward referencing. My personal problem for example is that my English is not good enough to tell the PB developers all the reasons and my real intention in plain words. This is because my English has nearly the same problems as PB with the lack of forward referencing because I always have to ship around words I can't find. This means: My English is not complete, and so is the PB compiler, too. Anyway, I never found a perfect software or - above all - perfect people, myself included.
          But in times of fast growing code with faster growing technical problems the next PB version should really have this deficit solved.
          Norbert Doerre

          Comment


          • #6
            Norbert,

            I do a little English tutoring to professionals and students here in Mexico. Your English is alive and well, better than some of my students who were supposed to have had 3 or 4 years in regular English classes. I ask them to bring several of their English e-mails to clients and suppliers, most are not as good as your and other non-native English spearker PB'ers posts Since we are an international community here and English is the stated language for posting, many of us get used to reading the intent of the words, rather than the perfection of the grammar. If we still don't get it, keep trying.

            See 'ya
            Rick Angell

            Comment


            • #7
              > English is the stated language for posting,

              It is?

              I know we've had people post in other languages .. and get responses in same.

              True, your 'audience' is greatly reduced, but if ONE person can understand your problem if posted in <non-English>, that beats the ZERO people who will understand it if you post in English. (or try to post in English).

              MCM
              Michael Mattias
              Tal Systems (retired)
              Port Washington WI USA
              [email protected]
              http://www.talsystems.com

              Comment


              • #8
                Richard, Your opinion is my English were 'well'.
                My opinion is that it is not, an I compared it with even PB beeing not perfect, too.
                Murfey's law seems to be the winner again:
                I ask myself: "Why for God sake isn't in consequence PB as good as my English?" ;-)
                Norbert Doerre

                Comment


                • #9
                  In the past some administrator(s) indicated English should be used, and if one posted in another language, then a translation in English was requested to accompany the other language. I believe it was stated somewhere, in the previous forum.
                  Rick Angell

                  Comment


                  • #10
                    Excuse my confusion, but by "Forward Referencing" do you mean something like the following?

                    Code:
                    #INCLUDE WIN32API.INC
                    #INCLUDE MYDIALOG.INC
                    #INCLUDE MYFUNCTIONS.INC
                    But lets say you have a variable called "MyVariable" and it is declared in the MYFUNCTIONS.INC file but used in the MYDIALOG.INC file that the compile would fail?

                    I have 2 solutions (work-arounds) if this is the case. Each has its pluses and minuses but would boil down to your programming style and how huge (or number of files) you need to keep track of "Where the heck did I declare that??" concept, when you need to debug long after you wrote the code
                    Engineer's Motto: If it aint broke take it apart and fix it

                    "If at 1st you don't succeed... call it version 1.0"

                    "Half of Programming is coding"....."The other 90% is DEBUGGING"

                    "Document my code????" .... "WHYYY??? do you think they call it CODE? "

                    Comment


                    • #11
                      @ Cliff: Some more info with .inc file organization

                      Cliff, the forwarding problem is not with variables, because I normally use only local variables. There exist only a few exceptions, which are always declared in the .bas file.
                      The problem comes up with interoperating functions defined in separated .inc files with the intention to beware best flexibility for reusing the code. I wrote about 1000 functions separated in about 100 .inc files depending from their functionality. PB does not offer something like a projekt file. So, a size limited .inc file with defined content is much easier to handle manually.
                      Forwarding appears as soon as the number of used .inc files provocates interoperability the way that backward declaration is no more sufficient. Depending from the ranking in the .bas file declaration list it then reaveals that I cannot use a function whereever the .inc file declaration is placed in the list, because there exists always a forewarding conflict. In the past I tried to reorganize the .inc files during the coding process, but I won't alter their organization depending from their optimized functional content, for instance for algebraic functions, matrix functions, trigonometrical functions, file functions, menu functions and so on.
                      The current average size of the resulting DLL file (~60 KB) is just as large as I think that it's functionality corresponds relatively to it's size. This means I don't like a one and only huge function package pool which can hardly be handled by an old programmer like me. For me it is a horror vision of programming style to know that a PB DLL is tending to contain as much bloat as that produced with an MS compiler. Just this should be one of the arguments to implement forwarding declarations in PB.
                      Norbert Doerre

                      Comment


                      • #12
                        What about a general declare file APPNAME.INC?

                        I've been struggling for quite a while with this issue, due to the fact that parts of my declarations (or is it declares? ) reside in "their own" INC-file, which means: the file that also contains the functions and procedures.

                        This is my "solution": I simply copy and paste those declarations to a file named APPNAME.INC. In the main module this is the first one to be #INCLUDEd.

                        Egbert Zijlema, journalist and programmer (zijlema at basicguru dot eu)
                        http://zijlema.basicguru.eu
                        *** Opinions expressed here are not necessarily untrue ***

                        Comment


                        • #13
                          Originally posted by norbert doerre View Post
                          ...programming style to know that a PB DLL is tending to contain as much bloat as that produced with an MS compiler. Just this should be one of the arguments to implement forwarding declarations in PB.
                          Sadly, I'm afraid you're mistaken. There is absolutely no correlation between forward recognition of function declarations (or lack of it) and your concept of "bloat". DECLARE statements, regardless of number or position, add nothing to the size of the compiled executable or DLL.

                          I'm surprised you didn't try it before complaining about a non-issue with such "heat".

                          Now, it may be that forward recognition of Declares is a good idea. If you believe that, I'd suggest you forward your suggestion to support at [email protected] as was mentioned to you much earlier. Please include the specific reason(s) you think it's a good idea, so they can accumulate this information for their managers.

                          Best regards,

                          Bob Zale
                          PowerBASIC Inc.

                          Comment


                          • #14
                            I keep all my utilities in one file and use conditional statements to maintain granularity.
                            James


                            Code:
                            'Cut the following out and paste in source
                            'Uncomment to use function
                            '------------------------------------------------------------------------------
                            'Conditional Compile Equates for PBLIB.BAS"
                            '------------------------------------------------------------------------------
                            '  %USE_ALLPBLIB = 1
                            '  %USE_ScreenToClientRect  = 1
                            '  %USE_ClientToScreenRect = 1
                              %USE_RectWidth = 1
                            '  %USE_RectHeight = 1
                            '  %USE_FileExists = 1
                            '  %USE_FileDateTimeSize = 1
                            '  %USE_BrowseForFolder = 1
                            '  %USE_GetFilePath = 1
                            
                            
                            #IF DEF%(%USE_RectWidth)
                            FUNCTION _
                              RectWidth ( _
                                tRect AS RECT _
                              )  AS LONG
                              FUNCTION = tRect.nRight - tRect.nLeft
                            END FUNCTION
                            #ENDIF

                            Comment


                            • #15
                              FWIW, if the problem is just DECLAREs, I know there are at least two programs in the source code forum to "generate DECLARE statements for all procedures in this file."

                              (Hey, wouldn't that be a cool addition to the IDE feature list? "File[or maybe "Edit" menu]/Generate DECLARE File?" I gotta send that one in for sure!!!)

                              MCM
                              Michael Mattias
                              Tal Systems (retired)
                              Port Washington WI USA
                              [email protected]
                              http://www.talsystems.com

                              Comment


                              • #16
                                Compromise found

                                Thanks for all Your hints.
                                Until now, my intention was always to keep declarations and functions together in one file for each special function group, just to keep the control. Bob, the problems of increasing code are not the declarations but would be interacting functions with source code in one huge single .inc file. This is the alternative horror scenario I tried to describe.
                                The method Egbert proposes seems currently to be the best one in my case, but in fact not the most straight and comfortable one. The best would really be introducing forward declarations to the compiler. This would solve much redeclaration and copy/paste trouble and thus would save a lot of time.
                                Norbert Doerre

                                Comment


                                • #17
                                  Personally I have used 2 ways to solve the problem. The first was when using Global Variables, I would put my globals and Declares in a *.h file, and then reference all my *.h files files before referencing a *.inc file (which holds the function code)

                                  My 2nd way (and more preferable) now that I am working back to no globals is to wrap each of my *.inc files with #IF NOT DEF%

                                  This way if I have functions Dependant on other functions (either at writing time, or functions added later) All I have to do is declare the dependency

                                  One other thing I do (maybe a little un-orthodox) but helps me keep functionality in groups, is to put my *.inc files in folders based on the grouping of what it does. (Dialogs/Functions/WindowsApi....etc) and then relative base my *.inc files like
                                  #INCLUDE "./WINDOWSAPI/WIN32API.INC" 'Define Windows OS variables and functions
                                  It sure helps when working on larger projects and trying to locate code I may have wrote months ago and not sure where I put it.
                                  Engineer's Motto: If it aint broke take it apart and fix it

                                  "If at 1st you don't succeed... call it version 1.0"

                                  "Half of Programming is coding"....."The other 90% is DEBUGGING"

                                  "Document my code????" .... "WHYYY??? do you think they call it CODE? "

                                  Comment


                                  • #18
                                    All is running very well

                                    Cliff, I tried out already Your second method. But it leads currently into trouble because my .inc files are too many, and I'm just resorting them by dependencies to each other instead of their strict content. The dependencies from each other are not static because they are still dynamically changed and updated during coding. I learnt that when I try to limit them by adding additional dependencies with conditional compiling I'm getting more trouble than ever. This could be done perhaps when the biggest part of them will be ready.
                                    Nevertheless, the biggest part of my program is running fine because PB compiler is marvellous and stable like a railway.
                                    I hope that 'railway' doesn't sound critical because they are not everywhere in the world as stable as here in Germany ;-)
                                    Norbert Doerre

                                    Comment


                                    • #19
                                      Cliff's second method is the one I use, but you have to do this before things get out of hand, else you whave to wrap more than just the include file; you'll have to wrap many individual decalres/functions/macros that might be in other includes and with the same names for the constant that #IF %DEF tests for.
                                      Barry

                                      Comment


                                      • #20
                                        Norbert Doerre is not alone. I too am struggling with this problem of "forward referencing" (if that is what it is.) For me it arose when converting a project from VB6 to PB. This is what I am doing. Does it seem OK to you more experienced guys ?

                                        My Function PBMain is in a main.bas file
                                        This file has near the beginning lots of #INCLUDE "something.inc"
                                        The first INCLUDE is for win32api.
                                        The second INCLUDE contains User Defined Types and Globals (few of those).
                                        The third INCLUDE contains DECLARE statements for every Function, even those in main.bas.
                                        The remaining INCLUDES contain Function statements with appropriate code.
                                        After the INCLUDES in main.bas there are many constants like %IDC_something.
                                        So far I have not tried to accumulate these constants into another INCLUDE.
                                        Perhaps I should.


                                        If that's OK my only grumble is that having to repeat function definitions inside a DECLARE inside an INCLUDE must surely open many possibilities for error. Like when you alter the Function but forget to go and alter the DECLARE. But then, nothing in life is perfect, especially not me.

                                        Comment

                                        Working...
                                        X