Announcement

**Michael Mattias** · 7 Mar 2008, 08:16 AM

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:

 [B]CALL[/B] functionname (params) [b]TO Var[/b]
   or
 [B]CALL[/B] 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

**Richard Angell** · 7 Mar 2008, 08:22 AM

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

.

**Michael Mattias** · 7 Mar 2008, 08:26 AM

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.

**norbert doerre** · 7 Mar 2008, 01:35 PM

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.

**Richard Angell** · 7 Mar 2008, 05:12 PM

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

**Michael Mattias** · 7 Mar 2008, 05:26 PM

> 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

**norbert doerre** · 7 Mar 2008, 05:41 PM

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?"

**Richard Angell** · 7 Mar 2008, 05:55 PM

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.

**Cliff Nichols** · 7 Mar 2008, 05:59 PM

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

**norbert doerre** · 8 Mar 2008, 04:34 AM

@ 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.

**Egbert Zijlema** · 8 Mar 2008, 06:16 AM

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.

**Bob Zale** · 8 Mar 2008, 06:25 AM

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.

**jcfuller** · 8 Mar 2008, 07:22 AM

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

**Michael Mattias** · 8 Mar 2008, 09:00 AM

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

**norbert doerre** · 8 Mar 2008, 01:53 PM

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.

**Cliff Nichols** · 9 Mar 2008, 12:43 PM

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.

**norbert doerre** · 9 Mar 2008, 01:39 PM

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

**Barry Erick** · 10 Mar 2008, 05:55 AM

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.

**Ralph Brereton** · 17 Mar 2008, 10:32 AM

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.

Announcement

Struggeling with forward referencing

Struggeling with forward referencing

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment