Re: Globals in 4gl - feature or bug?

Feature, not bug! The code has always worked as you've discovered, and there is no reason why it should not continue to do so. What is critical is that you do not try to allocate memory for a global variable twice, particularly with the version 6 I4GL c-code compiler. This is because for the structured data types (DECIMAL, MONEY, DATETIME, INTERVAL and maybe blobs too), the ESQL/C compiler generates initializers when variables are defined (in C terms; that means that memory is allocated), and if two separate files both define a global variable x which has an initializer, your code no longer links. For a long time, no initializer was generated, and most systems were forgiving in these circumstances and simply provided one space for all definitions of a variable such as x. file1.4gl file2.4gl GLOBALS GLOBALS DEFINE x DATETIME YEAR TO SECOND DEFINE x DATETIME YEAR TO SECOND END GLOBALS END GLOBALS FUNCTION f1() FUNCTION f2() ... ... END FUNCTION END FUNCTION This code would compile on all systems (of course), and would link on most systems under version 4.1x compilers, and both references to x refer to the same variable. But with the 6.0x compilers, because both instances of x had an initializer specified (to ensure that the correct precision was recorded), the program would no longer link. There has never been any reason why you cannot use multiple globals files as long as no two globals files define the same symbol. And with the later releases of the product (4.13/6.01 or maybe 4.14/6.02), you should be able to use multiple GLOBALS "file.4gl" statements at the top of an I4GL source file. Check your release notes. There was a previous discussion of this in comp.databases.informix under the heading 'Do you cheat with GLOBALS' in 1994, probably in October. I initiated it... Yours, Jonathan Leffler (johnl@informix.com) #include <disclaimer.h> }Date: Mon, 25 Mar 96 13:56:09 PST }From: marco greco <marcog@ctonline.it> }X-Informix-List-Id: <list.9166> } }Quoted from the 4gl reference manual, volume 2: } }1. You may have at most one GLOBALS statement where global variables are } defined. This statement may be in a separate file or in the file } containing the main program block. } }For years I'va had this strange belief that in a multiple file application }you could only have one place where globals were defined, all other files }having to refer to that. On friday, with no apparent reason other than }the desire to acquire more knowledge, I tried the following: } }---- main.4gl ---- }main } call a() } call b() } call c() } call d() } call e() }end main } }---- a.4gl ---- }globals "ag.4gl" } }function a() } let a1=1 } display a1 at 1, 1 }end function } }---- b.4gl ---- }globals "ag.4gl" } }function b() } let a1=a1+1 } display a1 at 2, 2 }end function } }---- c.4gl ---- }globals "cg.4gl" } }function c() } display "3" at 3, 3 }end function } }---- d.4gl ---- }function d() } display "4" at 4, 4 }end function } }---- e.4gl ---- }globals } define e1 smallint }end globals } }function e() } display "5" at 5, 5 }end function } }---- ag.4gl ---- }globals } define a1 smallint }end globals } }---- cg.4gl ---- }globals } define c1 smallint }end globals } }it compiled with no complaints (c4gl 4.10UC1) and worked as expected! } }Hmmm.... surely the one globals limitation must have something to do with the p-code runner. I dug up the long lost i4gl (1.10.03) to give the code a try, and hear, hear, it compiled & worked too! } }It turns out that in every module you can have a global statement in which you can declare only the globals you need (with globals playing the role of "extern" as well), or reference a file that does. You can have multiple globals files, each defining the exact subset of globals a bunch of modules needs. } }Just to add to Kerry's rantings on reusable code, and more specifically to modular variables, this makes it possible to split a large module (to contain module size, to gain in readability or to utilize part of it in other contexts) and have multi-modular variables. } }Fglgo does even the job of catching globals defined in different ways by different modules (ld doesn't!). } }This redefines my concept of global variables. They appear to be less dangerous than I thought. } }I don't want to start a thread on the evil and good of global variables, }I only want to know: } }1) Is this a feature? - I suppose it is. } }2) if it is, is it generally known? (in other words, am I the only ignorant?) } }3) The reason of the single globals limitation. } }As a small aside, I would like to add to the "dates before Christ" thread by noting that many times the FM is not at all clear, and this seems to be one of those. } }cheers, }marco } }____________________________________________________________________________ }rem radioterapia, which I immeritately manage, seldom agrees with what I say } }marco greco (Catania, Italy) Work: }marcog@ctonline.it rem radioterapia 39 95 447828 fax 446558 }(was mar.greco@agora.stm.it) Achea 39 95 503117 }