Sign in Join

Live chat for Free Pascal, Lazarus, Delphi and every Pascal programmer.

Mailing lists / fpc-devel / 2000-09

operator overloading problem

15 messages · 5 people · –

Reply by email Subscribe to this list Your subscription

Read-only archive. Use j and k to move between messages.

KO Myung-Hun

Hi.

I successed making RTL partially by modifing 'makefile' and OPT macro like that you told. Nevertheless, I don't think that this is fundamental way because FPC don't create .oo2 by itself in MAKE. By the way, FPC create .oo2 without MAKE. It's strange.

And I encountered another problem. That is operator overloading. When compiling ucomplex.pp, located in source/rtl/inc/, FPC print below msgs.

--------
ucomplex.pp(59,16) Error: Duplicate identifier PLUS
ucomplex.pp(59,16) Error: Duplicate identifier PLUS
ucomplex.pp(64,16) Error: Duplicate identifier PLUS
ucomplex.pp(64,16) Error: Duplicate identifier PLUS
ucomplex.pp(75,16) Error: Duplicate identifier MINUS
ucomplex.pp(75,16) Error: Duplicate identifier MINUS
ucomplex.pp(80,16) Error: Duplicate identifier MINUS
ucomplex.pp(80,16) Error: Duplicate identifier MINUS
ucomplex.pp(91,16) Error: Duplicate identifier STAR
ucomplex.pp(91,16) Error: Duplicate identifier STAR
ucomplex.pp(96,16) Error: Duplicate identifier STAR
ucomplex.pp(96,16) Error: Duplicate identifier STAR
ucomplex.pp(107,16) Error: Duplicate identifier SLASH
ucomplex.pp(107,16) Error: Duplicate identifier SLASH
ucomplex.pp(112,16) Error: Duplicate identifier SLASH
ucomplex.pp(112,16) Error: Duplicate identifier SLASH
ucomplex.pp(123,17) Error: Duplicate identifier STARSTAR
ucomplex.pp(123,17) Error: Duplicate identifier STARSTAR
ucomplex.pp(128,17) Error: Duplicate identifier STARSTAR
ucomplex.pp(128,17) Error: Duplicate identifier STARSTAR
ucomplex.pp(139,16) Error: Duplicate identifier EQUAL
ucomplex.pp(139,16) Error: Duplicate identifier EQUAL
ucomplex.pp(144,16) Error: Duplicate identifier EQUAL
ucomplex.pp(144,16) Error: Duplicate identifier EQUAL
ucomplex.pp(149,16) Error: Duplicate identifier MINUS
ucomplex.pp(149,16) Error: Duplicate identifier MINUS
----------

the part caused error is related to operator overloading. remarks of ucomplex.pp say FPC supports operator overloading. FPC supports only function overloading ? I know that FPC supports operator overloading as well as function overloading, incorrect ?

Finally, I have questions to development team. The RTL source package is different from that used by you ? If it's the same, I cannot understand why you succeed, but I fail. Also, I want to know how you make RTL.

For the better FPC !!!

from KO Myung-Hun...

Reply by email

Jonas Maebe
to KO Myung-Hun
KO Myung-Hun wrote
I successed making RTL partially by modifing 'makefile' and OPT macro like that you told. Nevertheless, I don't think that this is fundamental way because FPC don't create .oo2 by itself in MAKE. By the way, FPC create .oo2 without MAKE. It's strange.

I've fixed this bug in the fixes branch, I'll merge it in the main branch tomorrow.

And I encountered another problem. That is operator overloading. When compiling ucomplex.pp, located in source/rtl/inc/, FPC print below msgs.

[CUT]

I got the same problem, but only in the main branch. I believe some things were changed to operator overloading recently (for the variant support?). This is nothing OS/2 specific I think.

the part caused error is related to operator overloading. remarks of ucomplex.pp say FPC supports operator overloading. FPC supports only function overloading ? I know that FPC supports operator overloading as well as function overloading, incorrect ?

No, operator overloading is also supported. It's simply a bug in the current main branch compiler.

Finally, I have questions to development team. The RTL source package is different from that used by you ? If it's the same, I cannot understand why you succeed, but I fail. Also, I want to know how you make RTL.

Sometimes issues only show up under one operating system (like the problem with not assembling). Most developers use Dos/Windows/Linux, which is why sometimes problems go undetected longer on OS/2. However, since my windows HD died and I don't intend to reinstall WinXX anytime soon, as of now I will use OS/2 for FPC development in the weeends, which will hopefully bring the platform more up to date.

Lately, almost only Tomas Hajny was actively working on the OS/2 version and 1 person is too little to both maintain and improve compiler and RTL support for an OS I think (if only because then you have only one system on which everything is tested and you should be able to test on different configurations)

Jonas

Reply by email

Jonas Maebe
to Florian Klaempfl
Florian Klaempfl wrote 6 lines
> Finally, I have questions to development team. The RTL source package is > different from that used by you ? If it's the same, I cannot understand > why you succeed, but I fail. Also, I want to know how you make RTL. For example the go32v2 makefile doesn't contain the ucomplex unit. Is there any _real_ reason for that?

Forgotten to add it? :)

Jonas

Reply by email

Jonas Maebe
to Jonas Maebe: I've fixed this bug in the fixes branch, I'll merge it in the main branch tomorrow. [CUT]…
Jonas Maebe wrote 7 lines
> I successed making RTL partially by modifing 'makefile' and OPT macro > like that you told. Nevertheless, I don't think that this is fundamental > way because FPC don't create .oo2 by itself in MAKE. By the way, FPC > create .oo2 without MAKE. It's strange. I've fixed this bug in the fixes branch, I'll merge it in the main branch tomorrow.

Note however that due to the shortstring's limitation of 255 chars, the directory containing your ppc386 executable has to be withinh the first 255 chars of your PATH for the fix to work.

Jonas

Reply by email

Florian Klaempfl
to Jonas Maebe
Show quoted text 14 lines
On Sun, 24 Sep 2000, Jonas Maebe wrote: > > I successed making RTL partially by modifing 'makefile' and OPT macro > > like that you told. Nevertheless, I don't think that this is fundamental > > way because FPC don't create .oo2 by itself in MAKE. By the way, FPC > > create .oo2 without MAKE. It's strange. > > I've fixed this bug in the fixes branch, I'll merge it in the main branch > tomorrow. Note however that due to the shortstring's limitation of 255 chars, the directory containing your ppc386 executable has to be withinh the first 255 chars of your PATH for the fix to work.

Because the 1.1 branch will require anyway FPC (or Delphi) we could change this by using ansistring.

Reply by email

Jonas Maebe
Show quoted text 6 lines
> Note however that due to the shortstring's limitation of 255 chars, the > directory containing your ppc386 executable has to be withinh the first > 255 chars of your PATH for the fix to work. Because the 1.1 branch will require anyway FPC (or Delphi) we could change this by using ansistring.

But then dos.getenv has to return an ansitring as well...

Jonas

Reply by email

Florian Klaempfl
to Jonas Maebe
Show quoted text 9 lines
>> Note however that due to the shortstring's limitation of 255 chars, the >> directory containing your ppc386 executable has to be withinh the first >> 255 chars of your PATH for the fix to work. > >Because the 1.1 branch will require anyway FPC (or Delphi) we could >change this by using ansistring. But then dos.getenv has to return an ansitring as well...

That's true, so what can we do?!
1. Using sysutils
2. Extend the DOS Unit in some way
...

Reply by email

Jonas Maebe
Show quoted text 5 lines
> But then dos.getenv has to return an ansitring as well... That's true, so what can we do?! 1. Using sysutils 2. Extend the DOS Unit in some way

Normally it shouldn't cause any compatibility problems, since ansistrings can be converted to shortstrings on the fly. OTOH, what happens if the calling program is compiled in TP mode?

Jonas

Reply by email

Florian Klaempfl
to Jonas Maebe
Show quoted text 10 lines
>> But then dos.getenv has to return an ansitring as well... > >That's true, so what can we do?! >1. Using sysutils >2. Extend the DOS Unit in some way Normally it shouldn't cause any compatibility problems, since ansistrings can be converted to shortstrings on the fly. OTOH, what happens if the calling program is compiled in TP mode?

For clean programs it shouldn't be a problem but ...

What about a getenvansistring in the DOS unit? It doesn't marking porting harder because
getenv will be a simple wrapper around getenvansistring. The parameter of getenvansistring
should be an ansistring as well, of course.

Reply by email

Marco van de Voort
to Florian Klaempfl
Show quoted text 15 lines
> >2. Extend the DOS Unit in some way > > Normally it shouldn't cause any compatibility problems, since ansistrings > can be converted to shortstrings on the fly. OTOH, what happens if the > calling program is compiled in TP mode? For clean programs it shouldn't be a problem but ... > What about a getenvansistring in the DOS unit? It doesn't marking porting harder because getenv will be a simple wrapper around getenvansistring. The parameter of getenvansistring should be an ansistring as well, of course.

Getpchar is better. Can be autoconverted too, and also can be used to get long env strings in plain tp mode.

Reply by email

Michael Van Canneyt
to Jonas Maebe: But then you have to take care of deallocating the memory reserved for returning the…
Jonas Maebe wrote 11 lines
>> What about a getenvansistring in the DOS unit? It doesn't marking >> porting harder because >> getenv will be a simple wrapper around getenvansistring. The parameter >> of getenvansistring >> should be an ansistring as well, of course. > >Getpchar is better. Can be autoconverted too, and also can be used to get >long env strings in plain tp mode. But then you have to take care of deallocating the memory reserved for returning the environment string in.

Yes. I don't think the pchar is a good idea; If you had this problem in TP then you had to think of a solution by yourself already, so trying to be TP compatible doesn't make sense for this, IMHO.

Michael.

Reply by email

Jonas Maebe
Show quoted text 8 lines
> What about a getenvansistring in the DOS unit? It doesn't marking > porting harder because > getenv will be a simple wrapper around getenvansistring. The parameter > of getenvansistring > should be an ansistring as well, of course. Getpchar is better. Can be autoconverted too, and also can be used to get long env strings in plain tp mode.

But then you have to take care of deallocating the memory reserved for returning the environment string in.

Jonas

Reply by email

Marco van de Voort
to Jonas Maebe
Show quoted text 11 lines
>> What about a getenvansistring in the DOS unit? It doesn't marking >> porting harder because >> getenv will be a simple wrapper around getenvansistring. The parameter >> of getenvansistring >> should be an ansistring as well, of course. > >Getpchar is better. Can be autoconverted too, and also can be used to get >long env strings in plain tp mode. But then you have to take care of deallocating the memory reserved for returning the environment string in.

You could return a pointer into the protected mode copy of the environment.

Reply by email

Jonas Maebe
> But then you have to take care of deallocating the memory reserved for > returning the environment string in. You could return a pointer into the protected mode copy of the environment.

No, because people may want to change the result.

Jonas

Reply by email