Nick Ioffe wrote:
I declare public variables in module interface and then try to use them.
The problem is that while integer variables work perfectly all other kinds of variables (at least files and strings) don't work at all.
May somebody explain me what is going on? Why integer is defined ok, but string has problem?
It's a known problem:
: the capacity of strings declared in interfaces of modules is not : initialized (daj3.pas, sven14c.pas, nick1.pas)
Actually, it affects those types that require some automatic initialization which are schemata (including strings), files and objects.
It only happens with modules, not with units. I'll try to fix it when I get to it, but it's not trivial and will require some other cleaning up of the module mechanism ...
Frank
Hi! Thank you for all your responses. I'm sorry for bringing back the known problem.
Here're 2 more strange behaviours with interface vs. implementation global variables definitions. May be they will help you to find out what is wrong in modules initialization.
Problem I:
I slightly change the previous expample - declare my_str_var in both mod1 module interface and implementation, in mod2 implementation and in my_main global var definitions block.
What happens is that although each variable should be local for the module (at least that is what the common sense tells me) all the variables behave like there're the same variable. I've checked it with debugger and it points to the same address in all modules.
the source is as follows: ---------------mod1.pas------------------- module mod1 interface; export mod1 = all; Type mystr = string(7); Var my_str_var : mystr; procedure mSet (str_arg : mystr);
end.
module mod1 implementation;
Var my_str_var : mystr;
procedure mSet (str_arg : mystr); begin writeln ('mod1 mset str_arg:',str_arg,'.'); my_str_var := str_arg; writeln ('mod1 mset my_str_var:',my_str_var,'.'); end;
end.
---------------mod2.pas-------------------- module mod2 interface export mod2 = all; import mod1;
procedure sSet (str_arg : mystr); function sGet : mystr; end.
module mod2 implementation; import mod1
Var my_str_var : mystr;
procedure sSet (str_arg : mystr); begin writeln ('mod2 sset str_arg:',str_arg,'.'); my_str_var := str_arg; writeln ('mod2 sset my_str_var:',my_str_var,'.'); end;
function sGet : mystr; begin sGet := my_str_var; end;
end. -----------------------my_main.pas------------------- program my_main (input,output); import mod1; import mod2;
Var another_str : mystr := '7654321'; my_str_var : mystr;
begin sSet ('0123456'); writeln ('1. my_main another_str:',another_str,'.'); another_str := sGet; writeln ('2. my_main another_str:',another_str,'.');
my_Str_var := 'abcdefg'; another_str := sGet; writeln ('2. my_main another_str:',another_str,'.');
mSet ('nick io'); another_str := sGet; writeln ('2. my_main another_str:',another_str,'.'); end. -------------------------------------------------------- The run results are: mod2 sset str_arg:0123456. mod2 sset my_str_var:0123456. 1. my_main another_str:7654321. 2. my_main another_str:0123456. 3. my_main another_str:abcdefg. mod2 sset str_arg:nick io. mod2 sset my_str_var:nick io. 4. my_main another_str:nick io.
============================================================= Problem II. As we've seen in problem I repeating the declaration in module implementation solves the problem of accessing the strings. Now I need to declare the array of string: -----------------mod3_1.pas------------------------- module mod3 interface; export mod3 = all; Var my_buff : array [1..10] of String(80);
procedure pBuff;
end.
module mod3 implementation;
Var my_buff : array [1..10] of String(80);
procedure pbuff; var int ii; begin for ii:=1 to 10 do writeln (my_buff[ii]); end; end. ------------------------------------------------ When I compile it I get the following errors: mod3.pas:15: redeclaration of 'My_buff' mod3.pas:10: previous declaration of 'Mybuff'
then I change the source as follows: -----------------mod3_2.pas------------------------- module mod3 interface; export mod3 = all; Type my_buff_type = array [1..10] of String(80); Var my_buff : my_buff_type;
procedure pBuff;
end.
module mod3 implementation;
Var my_buff : my_buff_type;
procedure pbuff; var int ii; begin for ii:=1 to 10 do writeln (my_buff[ii]); end; end. ------------------------------------------------ Now everything compiles good.
Why? What is the difference?
Sincerely, Nick
Nick Ioffe wrote:
Here're 2 more strange behaviours with interface vs. implementation global variables definitions. May be they will help you to find out what is wrong in modules initialization.
Thanks, but actually I know what is wrong. It will just take some effort to fix it. ;-)
Problem I:
I slightly change the previous expample - declare my_str_var in both mod1 module interface and implementation, in mod2 implementation and in my_main global var definitions block.
What happens is that although each variable should be local for the module (at least that is what the common sense tells me) all the variables behave like there're the same variable. I've checked it with debugger and it points to the same address in all modules.
Problem II. As we've seen in problem I repeating the declaration in module implementation solves the problem of accessing the strings. Now I need to declare the array of string:
[...]
When I compile it I get the following errors: mod3.pas:15: redeclaration of 'My_buff' mod3.pas:10: previous declaration of 'Mybuff'
then I change the source as follows:
[...]
Now everything compiles good.
Why? What is the difference?
I think both problems are because GPC ignores duplicate declarations of the same type (equivalent array declarations are not the same type in Pascal, but a common `type' definition is).
In part that's a relic from the C compiler. However, when I tried to fix it, I was told that some people apparently use GPC in such strange ways (i.e., using include files like in C instead of modules or units, so the same variable is declared externally and normally in the same file). I guess sometime we have to break this, anyway, and they'll have to rewrite their code ...
(These problems are unrelated to the problem of missing initializations.)
Frank