- Gpc - gnu.de

Re: Array intialization
by vanam srihari kumar 08 Nov '05

08 Nov '05

> > > 2) Do we have the standard library function in > gpc > > > which accomplishes the below functionality of > sun > > > library function. > > > open(file, pathname, > history, > > > error, buffer) > > > > > > open associates the permanent file file with a > file > > > variable for reading or writing. > > > open does not actually open the file; > > > > Maybe "Assign" is useful. > > Yes. I don't know what the latter 3 parameters do. > If they're > important, please explain. > please see the below link for clear desription of the open function. http://docs.sun.com/app/docs/doc/802-2944/6i6sg5q1e?a=view#06.Built-In_Proc… suppose if file is not found 'open' will set the error variable. But what exception/error code 'assign' will give if the file is not found. As lot of files in my project are using open function and based on the error variable value subsequent block of code will be executed. Regards Hari __________________________________ Start your day with Yahoo! - Make it your home page! http://www.yahoo.com/r/hs

1 0

linker problems
by vanam srihari kumar 07 Nov '05

07 Nov '05

Dear All I am compiling my code with gpc 2.1 version on solaris 8.0 platform and using the 'ld' linker. Below is the dump I am getting in linking stage linking ld: Software Generation Utilities - Solaris Link Editors: 5.8-1.285 Undefined first referenced symbol in file __ashrdi3 /usr/local/lib/gcc-lib/sparc-sun-solaris2.8/2.95.2/libgpc.a(sets.o) __floatdidf slaveac.o __ashldi3 /usr/local/lib/gcc-lib/sparc-sun-solaris2.8/2.95.2/libgpc.a(sets.o) __fixtfdi pasmath.o __floatditf /usr/local/lib/gcc-lib/sparc-sun-solaris2.8/2.95.2/libgpc.a(math.o) ld: fatal: Symbol referencing errors. No output written to Please suggest me as what to be done Regards Hari __________________________________ Yahoo! FareChase: Search multiple travel sites in one click. http://farechase.yahoo.com

3 2

Re: New gpc snapshot - OOP test resuls
by Waldek Hebisch 05 Nov '05

05 Nov '05

Prof A Olowofoyeku wrote: > I converted one small project from using OBJECTs to using CLASSes. > > The test program compiles and runs okay under Delphi, Virtual Pascal, > and FreePascal. > > The new GPC snapshot comes up with some compilation errors. You can see > the error log in the attached zip file. Also in the zip file are the > sources, and the test program's outputs when compiled with Delphi 7 > (d7.txt), FreePascal (fpc.txt), and Virtual Pascal (vp.txt). > : baseobj.pas:52: method `init', overrides parent method : baseobj.pas:253: method `init', overrides parent method The two errors above (and more in the following) are because GPC is more strict by default. You can write: CONSTRUCTOR init ( Owner : TClass ); override; or CONSTRUCTOR init ( Owner : TClass ); reintroduce; to specify the intent (to say the truth both mean the same for static methods). Or you may use `-fdelphi-method-shadowing' to silently accept your original code. : baseobj.pas: In constructor `TBaseList.init': : baseobj.pas:437: expression used as a statement : baseobj.pas: In destructor `TBaseList.done': : baseobj.pas:454: Delphi/OOE continuing destructor activation unsupported The patch below should fix those (with the patch I was able to compile your test program and got the same results as in enclsed output files) Index: p/objects.c =================================================================== RCS file: /mn/a8/cvsroot/gpc/p/objects.c,v retrieving revision 1.4 diff -u -r1.4 objects.c --- p/objects.c 4 Nov 2005 01:00:21 -0000 1.4 +++ p/objects.c 5 Nov 2005 18:01:27 -0000 @@ -145,11 +145,18 @@ if (TREE_CODE (obj) == TYPE_DECL) { tree cmeth = current_method (); - if (PASCAL_CONSTRUCTOR_METHOD (fun) - && PASCAL_TYPE_CLASS (TREE_TYPE (obj))) + int is_class = PASCAL_TYPE_CLASS (TREE_TYPE (obj)); + if (PASCAL_CONSTRUCTOR_METHOD (fun) && is_class) constructor_call = tree_cons (NULL_TREE, obj, tree_cons (NULL_TREE, cref, args)); + if (is_class && PASCAL_DESTRUCTOR_METHOD (fun) && + (!cmeth || !PASCAL_DESTRUCTOR_METHOD (cmeth))) + { + error("Delphi/OOE continuing destructor activation outside a destructor"); + return error_mark_node; + } + if (!cmeth) /* Somebody is looking for the address of this method. Give them the FUNCTION_DECL. */ { @@ -173,9 +180,10 @@ return error_mark_node; obj = build_indirect_ref (lookup_name (self_id), "`Self' reference"); is_virtual = 0; + is_destructor = 0; } - - is_destructor = PASCAL_DESTRUCTOR_METHOD (fun) + else + is_destructor = PASCAL_DESTRUCTOR_METHOD (fun) && TYPE_POINTER_TO (TREE_TYPE (obj)) && PASCAL_TYPE_CLASS (TYPE_POINTER_TO (TREE_TYPE (obj))); @@ -218,14 +226,8 @@ tree vobj; gcc_assert (TREE_CODE (obj) == INDIRECT_REF); vobj = TREE_OPERAND (obj, 0); - if (!cmeth || !PASCAL_DESTRUCTOR_METHOD (cmeth)) - return build_predef_call (p_Dispose, tree_cons (NULL_TREE, vobj, + return build_predef_call (p_Dispose, tree_cons (NULL_TREE, vobj, build_tree_list (NULL_TREE, fun))); - else - { - error("Delphi/OOE continuing destructor activation unsupported"); - return error_mark_node; - } } return fun; Index: p/statements.c =================================================================== RCS file: /mn/a8/cvsroot/gpc/p/statements.c,v retrieving revision 1.3 diff -u -r1.3 statements.c --- p/statements.c 28 Oct 2005 20:00:56 -0000 1.3 +++ p/statements.c 5 Nov 2005 17:33:00 -0000 @@ -1083,7 +1083,10 @@ function_called = 1; } if (TREE_CODE (t) == PASCAL_CONSTRUCTOR_CALL) - t = convert (void_type_node, TREE_OPERAND (t, 1)); + { + t = convert (void_type_node, TREE_OPERAND (t, 1)); + function_called = 1; + } if (!EM (t)) { if (PASCAL_TREE_IGNORABLE (t)) -- Waldek Hebisch hebisch(a)math.uni.wroc.pl

2 1

Re: Mac objects and Delphi classes
by Waldek Hebisch 03 Nov '05

03 Nov '05

Thorsten Glaser wrote: > Waldek Hebisch dixit: > > >Adriaan van Os wrote: > [...] > >> >> -fborland-objects > >> >> -fmac-objects > >> >> -fooe-objects > >> >> -fgnu-objects > > >> Or maybe (since they are mutually exclusive) -fobject-model=xx, where > >> xx is bp,delphi,mac,ooe or default. The default model links to the > >> dialect setting. > > > >I have already implemented the -fxxx-objects version. -fobject-model=xx > >requires more work... > > But it does look more logical, compared with all the other recent > changes (such as -march= instead of e.g. -mpentium), and less bloated. > We do not want to have many objects models. So the bloat is limited. But if -fobject-model=xx is considerd better we can have it in the future. > By the way, I just digged out my old TP 6.01 manual and started > throwing some random OOP code at gpc (20050217), and to my (but > not too big) surprise everything worked as I remember from long > ago. What, exactly, does "gnu objects" differently than borland > (turbo pascal) as long as I use the object keyword? > The goal is to have no difference (be backwards compatible). There is small difference in new functionality (and it is likely to grow once new features get implemented). -- Waldek Hebisch hebisch(a)math.uni.wroc.pl

2 1

linker name in gpc 2.1
by vanam srihari kumar 03 Nov '05

03 Nov '05

How to call the linker explicitly in gpc 2.1 version. Regards Hari __________________________________ Yahoo! Mail - PC Magazine Editors' Choice 2005 http://mail.yahoo.com

3 3

Mac objects and Delphi classes
by Waldek Hebisch 03 Nov '05

03 Nov '05

I would like to slightly update Mac objects and Delphi classes support. In particular I ma thinking about options names. AFAICS there five major axes which differentiate dialects that we would like to support: 1) Value versus reference model: BP - value model (objects are values) OOE, Delphi, Mac - pointer model (object are pointer to values) 2) Static versus virtual methods: OOE, Mac - mehods are always virtual BP, Delphi - there are static methods 3) Keywords used: BP, Mac - use "object" as a keyword (but with different semantics) OOE, Delphi - use "class" keyword 4) Method redefinition: BP - silent overriding Delphi - silent shadowing, override needs "override" OOE, Mac - explicit "override" needed 5) Base object: BP, Mac - no base object, multiple roots OOE - "Root" is the root of inheritance tree Delphi - "TObject" is the root of inheritance tree There is also question if constructors are mandatory for objects with virtual methods. ATM I think that we may tie this to object model: in value model (BP) make them mandatory, in reference mode make them optional. Namely, Mac objects have no constructors while OOE and Delphi will get them without any explicit declaration. I propose to have the following options: -fobjects-are-references -- choose reference model even if the declaration uses "object" keyword, on for Mac Pascal, off otherwise -fmethods-always-virtual -- leave it as is -fobjects-require-override -- to require "override" even for objects declared using "object" keyword (classes will always require "override") -fdelphi-method-shadowing -- redefinition without override will shadow (hide) old definition. By default to hide old definition one would have to use OOE "view" or Delphi "reintroduce" directive -fbase-object= -- to add default parent to object without an explicit parent the last option will require some effort to implement. Additionally, we may have -fmac-objects directive, which would be equivalent to sum of -fobjects-require-override, -fmethods-always-virtual and -fobjects-are-references. Comments? -- Waldek Hebisch hebisch(a)math.uni.wroc.pl

6 16

importing module problem
by vanam srihari kumar 02 Nov '05

02 Nov '05

Dear All I am using gpc 2.1 version. Is there any way to work out below code without changing the make file? please help me out as this is urgent to me. ******************************************************* 1)MakeFile PC=gpc PFLAGS= -DSOLARIS -I/home/kvsspl DemoMod3.o :DemoMod3.pas $(PC) -c $(PFLAGS) DemoMod3.pas ModDemo3.o :ModDemo3.pas $(PC) -c $(PFLAGS) ModDemo3.pas ModDemo3 :ModDemo3.o DemoMod3.o $(PC) -o ModDemo3 DemoMod3.o ModDemo3.o --object-path=/home/kvsspl ******************************************************* ******************************************************* 2)ModDemo3.pas program ModDemo3 (Output); import DemoMod3; begin xtra; end. ******************************************************* ******************************************************* 3)DemoMod3.pas module DemoMod3; export DemoMod3 = all; procedure xtra; end; procedure xtra; begin writeln('DemoMod3 function'); end; end. ******************************************************* Regards Hari __________________________________ Yahoo! Mail - PC Magazine Editors' Choice 2005 http://mail.yahoo.com

2 1

External CString
by Eike Lange 31 Oct '05

31 Oct '05

Hi Folks! In a C wrapper file, I have the declaration /* xmlc.c */ const char* _c_CXML_DEFAULT_VERSION = XML_DEFAULT_VERSION; Now, I would like to use it in pascal. { xml.pas, Unit } unit XML; interface var C_HELPER_XML_DEFAULT_VERSION: CString; external name '_c_CXML_DEFAULT_VERSION'; attribute (const); XML_DEFAULT_VERSION: TString = CString2String (C_HELPER_XML_DEFAULT_VERSION); implementation {$L xmlc.c} end. Using this unit results in an error: "cannot evaluate this expression from a global declaration" "Error initial value is of wrong type". How can I use my string constant in GPC? Eike

2 2

protected var parameters and operators
by Adriaan van Os 28 Oct '05

28 Oct '05

Consider the following test program. program test; type Str255 = record sLength: Byte; sChars: packed array[1..255] of Char end; operator + ( protected var s1, s2: Str255 ) = theResult : Str255; var len1, len2: Integer; begin len1 := s1.sLength; len2 := Min( 255 - len1, s2.sLength); theResult.sLength := len1 + len2; if len1 > 0 then theResult.sChars[1..len1] := s1.sChars[1..len1]; if len2 > 0 then theResult.sChars[len1+1..len1+len2] := s2.sChars[1..len2]; end; var s1: Str255 value ( sLength: 1, sChars: 'A'); s2: Str255 value ( sLength: 1, sChars: 'B'); s3: Str255 value ( sLength: 1, sChars: 'C'); s4: Str255; begin s4:=s1+s2+s3 { Error: reference expected, value given }; writeln( s4.sChars[ 1..s4.sLength]) end. The program triggers an error for s1+s2+s3. The error doesn't occur when the expression has only one + operator (e.g. s1+s2). The problem disappears when using const parameters. It looks like the internal representation of an intermediate result is triggering the compiler error ! Regards, Adriaan van Os

3 2

gcc-4.0.2
by Russell Whitaker 27 Oct '05

27 Oct '05

hi Now that gcc-4.0.2 is out, is there a patch file for it? (tried 3.4.3, dosen't work) russ

4 4