method pointers

classic Classic list List threaded Threaded
29 messages Options
12
Reply | Threaded
Open this post in threaded view
|

method pointers

Wolfram Kläger
FPC can´t assign value to address, where Delphi can. For example:

TDomNode = class(TDomCustomNode);
  private
      ...
      FUserData : TUtilsWideStringList;
      FUserDataHandlers : TList;
      ...
 
destructor TDomNode.Destroy;
var
  I: Integer;
  UserDataEvent: TDomUserDataEvent;
begin
  // Call user data event handlers:
  if Assigned(FUserData) then
    with FUserData do
      for I := 0 to Pred(Count) do begin
        @UserDataEvent := pointer(FUserDataHandlers[I]);
        if Assigned(UserDataEvent) then
          UserDataEvent(OT_NODE_DESTROYED, WideStrings[I], Objects[I], nil, nil);
      end;
...

In Delphi, the line

        @UserDataEvent := pointer(FUserDataHandlers[I]);

is common practice. What is the difference to FPC and the appropriate workaround?

Thanks in advance
Wolfram
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: method pointers

Peter Vreman
> FPC can´t assign value to address, where Delphi can. For example:
>
> TDomNode = class(TDomCustomNode);
>   private
>       ...
>       FUserData : TUtilsWideStringList;
>       FUserDataHandlers : TList;
>       ...
>
> destructor TDomNode.Destroy;
> var
>   I: Integer;
>   UserDataEvent: TDomUserDataEvent;
> begin
>   // Call user data event handlers:
>   if Assigned(FUserData) then
>     with FUserData do
>       for I := 0 to Pred(Count) do begin
>         @UserDataEvent := pointer(FUserDataHandlers[I]);
>         if Assigned(UserDataEvent) then
>           UserDataEvent(OT_NODE_DESTROYED, WideStrings[I], Objects[I],
> nil, nil);
>       end;
> ...
>
> In Delphi, the line
>
>         @UserDataEvent := pointer(FUserDataHandlers[I]);
>
> is common practice. What is the difference to FPC and the appropriate
> workaround?

Did you use {$mode delphi} ? If it still fails to compile create a short
example that can be compiled and submit a bug report.





_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: method pointers

Matt Emson
>> In Delphi, the line
>>
>>         @UserDataEvent := pointer(FUserDataHandlers[I]);
>>
>> is common practice. What is the difference to FPC and the appropriate
>> workaround?

Forgive me for jumping in without reading the whole thread (Webmail is a
real PITA for this) but; No that is not completely correct. It does depend
on what you are doing. In Delphi, the _usual_ way to assign a method
pointer is as follows:

type TMyMethodPointer = procedure (const s; string) of object;

var
  mp: TMyMethodPointer;

...
  mp := AnInstance.CompatibleMethod;
...

However, for function pointers:

type TMyFuncPointer = procedure (const s; string);

var
  fp: TMyFuncPointer;

...
  fp := @CompatibleFunc;
...

The double dereference the poster uses above is not necessary. If
anything, the fact it works in Delphi is questionable.

M



_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: method pointers

Wolfram Kläger
In reply to this post by Wolfram Kläger


FPC-Pascal users discussions <[hidden email]> schrieb am 17.01.06 07:52:13:
>
> > FPC can´t assign value to address, where Delphi can. For example:

> Did you use {$mode delphi} ? ...


Thanks a lot, Peter. In my cfg file, I had OP extensions on. Switched to Delphi mode, and I have other problems again :-)

Wolfram
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

parameter names local, global, glocal

Wolfram Kläger
Hi, it´s me, the guy with this internal error recently, while porting
OpenXML to FP. Meanwhile, the compiler switch -B did help me out.
Apparently by compiling all units, regardless wether they have been changed
or not, this internal error is avoided. Now I believe this B stands for
Back to hell, since there are other surprises with duplicate identifiers,
where I never thought it could happen, see the following example.

unit xdom31;
uses
   ... xmltreeutils, ...
type
TDomNode = class (TDomCustomNode)
   private ...
   protected ...
   public ...
   property NamespaceURI: WideString read GetNamespaceURI; ...

TDomCharacterData = class (TDomNode)
   private ...
   protected ...
   public ...
     function SubstringData(const Offset, Count: Integer): WideString; virtual;

     // FPC: identifier COUNT already defined in unit xmltreeutils at line 98

     procedure ReplaceData(const Offset, Count: Integer) ...

     // FPC: identifier COUNT already defined in unit xmltreeutils at line 98
...

TDomAttr = class (TDomNode)
   private  ...
   protected  ...
   public ...
     constructor CreateNS(
        const AOwner: TDomDocumentNS;
           const NamespaceURI ...

     // FPC: identifier NamespaceURI already defined at line 1192
...

unit xmltreeutils;
...
type
TCustomOwnedNode = class(TCustomOwnedObject)
   private ...
   protected ...
   property Count: Integer read GetCount;
   ...

Conclusion: never call any parameter of any procedure or function exactly
like any property of any class and its ancestors. So far I thought,
parameter names of functions and procedures are always local, i.e. valid
for this function or procedure block only. Is this a bug or feature of FPC
vs. Delphi?

Disclaimer: I love all FPC warnings and hints. Each may be an unknown error
less. In or in front of the machine.

Wolfram
--
Mosaikfabrik (r)  Bilder von Bildern  www.mosaikfabrik.de
MEMPHIS GmbH  HRB Kirchheim/Teck 1231  Geschäftsführer
Wolfram Kläger  Wrangellstrasse 11  D-70599 Stuttgart
Tel. (+49) 0711 31 944 39  Fax (+49) 012126 31 944 944

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: parameter names local, global, glocal

Jonas Maebe-2

On 18 Jan 2006, at 21:21, Wolfram Kläger wrote:

> Conclusion: never call any parameter of any procedure or function  
> exactly like any property of any class and its ancestors. So far I  
> thought, parameter names of functions and procedures are always  
> local, i.e. valid for this function or procedure block only. Is  
> this a bug or feature of FPC vs. Delphi?

It's a feature. The reason is that otherwise the property is masked  
by the parameter inside the method body, which may cause unintended  
effects. This error should not be reported if you switch to Delphi mode.


Jonas_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: parameter names local, global, glocal

L505
In reply to this post by Wolfram Kläger

> Conclusion: never call any parameter of any procedure or function exactly
> like any property of any class and its ancestors. So far I thought,
> parameter names of functions and procedures are always local, i.e. valid
> for this function or procedure block only. Is this a bug or feature of FPC
> vs. Delphi?


I've seen this before while doing ports from delphi to freepascal. What I did, just
to get it quickly working,  was use the underscore, although a bit messy looking:

  function SubstringData(const Offset, Count_: Integer): WideString; virtual;

  procedure ReplaceData(const Offset, Count_: Integer) ...

or

  function SubstringData(const Offset, _Count: Integer): WideString; virtual;

  procedure ReplaceData(const Offset, _Count: Integer) ...

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: parameter names local, global, glocal

Micha Nelissen
On Wed, 18 Jan 2006 13:39:21 -0700
L505 <[hidden email]> wrote:

> > Conclusion: never call any parameter of any procedure or function exactly
> > like any property of any class and its ancestors. So far I thought,
> > parameter names of functions and procedures are always local, i.e. valid
> > for this function or procedure block only. Is this a bug or feature of FPC
> > vs. Delphi?
>
>
> I've seen this before while doing ports from delphi to freepascal. What I did, just
> to get it quickly working,  was use the underscore, although a bit messy looking:
>
>   function SubstringData(const Offset, Count_: Integer): WideString; virtual;

Prefixing an 'A' seems to be an (un)official delphi naming convention:

function SubstringData(const AOffset, ACount: Integer): WideString; virtual;

Micha
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: parameter names local, global, glocal

Wolfram Kläger
In reply to this post by Wolfram Kläger


Jonas 18.01.06 21:30:58:

> ... This error should not be reported if you switch to Delphi mode.

Unfortunately no. This kind of errors ís reported by FPC, no matter which mode, while Delphi does not.

I understand your explanation, but don´t really understand that an anyproc.anyparam.name can eventually mask an anyclass.anyproperty.name. Even more, since several procedure or function declarations within a class or unit can share the same parameter names. In Delphi and FP as well.

Wolfram
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: parameter names local, global, glocal

Jeff Pohlmeyer
In reply to this post by Wolfram Kläger
> Prefixing an 'A' seems to be an (un)official delphi naming convention

Does this make it official?
  http://www.econos.de/delphi/cs.html#ObjectPascal_Procedures_Parameters

<QUOTE>
" The 'A' prefix is a convention to disambiguate when the parameter name
is the same as a property or field name in the class. "
</QUOTE>


- Jeff
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Re: parameter names local, global, glocal

L505

>> Prefixing an 'A' seems to be an (un)official delphi naming convention

> Does this make it official?
>  http://www.econos.de/delphi/cs.html#ObjectPascal_Procedures_Parameters

> <QUOTE>
> " The 'A' prefix is a convention to disambiguate when the parameter name
> is the same as a property or field name in the class. "
> </QUOTE>


Looks good, I'm not a fan of underscores in significant quantities, and should only
be used in special cases. In this case, I find the 'A' prefix is a neater solution
than the messy underscore hack.

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: parameter names local, global, glocal

L505
In reply to this post by Jonas Maebe-2
Is it possible the Apple/Mac line feed could be causing your name to be rammed into
the text below :-)

No big deal, I just wondered from an academic perspective, whether the line feed on
the Mac would cause this issue on a PC, or whether it was for other reasons.

Lars

-------------------------------------------------------

Jonas_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: parameter names local, global, glocal

Wolfram Kläger
In reply to this post by Wolfram Kläger


L505 18.01.06 21:33:48:
> ... use the underscore, although a bit messy looking:
>
>   function SubstringData(const Offset, Count_: Integer): WideString; virtual;
> ...

Thanks. Matches to the habit of the guy, who has written the Delphi code, that I am working on. He usually begins each private class item name with an underscore. Meanwhile this habit seems appropriate to me. Now I will probably change my habit, concerning parameter names as well, by ending with an underscore, as you proposed.

Wolfram
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: parameter names local, global, glocal

L505
> > ... use the underscore, although a bit messy looking:
> >
> >   function SubstringData(const Offset, Count_: Integer): WideString; virtual;
> > ...
>
> Thanks. Matches to the habit of the guy, who has written
> the Delphi code, that I am working on. He usually begins
> each private class item name with an underscore. Meanwhile
> is habit seems appropriate to me. Now I will probably
> change my habit, concerning parameter names as well, by
> ending with >an underscore, as you proposed.

I dunno it is a religious thing, read the other messages too :)

I guess too many underscores in the code I find messy so I've fallen for the 'A'
prefix now. I use underscores only where there is really a need, and have found that
too many of them in code causes messiness and hard to read code. Either solution is
okay, but since there is lots of existing Pascal code out there that uses the A
prefix, it's probably best to use it. I'm not stubborn and am willing to change for
the better.

I do prefer underscores in very special special cases, such as when you have a very
similar function but it does something special in addition to the other function:

Parse   (input: string);
Parse_SF(input: string);

SF stands for secure and fast implementation, whereas

ParseFastAndSecureImplementation() is way too long, and you cannot tell whether it is
 Parse Fast, the secure implementation or
 Parse the Fast, Secure, implementation  or
 Parse, and please do it securely and fast

Also
 ParseFastAndSecureImplementation() looks extremely different than
 Parse() whereas
 Parse_SF looks extremely similar to
 Parse() so you know that Parse_SF() and Parse() are two similar functions, with one
just being special.

So the underscore helps suffix and separate function and keep the code logical
without being extremely verbose. This is the sacrifice I've made for making
underscores useful in some areas - some prefer to skip underscores altogether for
religious reasons, I prefer to include underscores in code when they have some
extreme advantage.

And the brackets? Yes I know it is a sin in Pascal to use Procedure() and only Java
programmers do that, I was just using the brackets in this text so that the text was
easier to read, i.e. distinguish Pascal procedure from English text.

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: parameter names local, global, glocal

Jonas Maebe-2
In reply to this post by L505

On 19 jan 2006, at 00:49, L505 wrote:

> Is it possible the Apple/Mac line feed could be causing your name  
> to be rammed into
> the text below :-)

No. Mac OS X uses the same line feed as every other *nix out there.

> No big deal, I just wondered from an academic perspective, whether  
> the line feed on
> the Mac would cause this issue on a PC, or whether it was for other  
> reasons.

I don't know what causes it. Maybe my mailer doesn't automatically  
add some extra linefeeds at the end of mails, while others do.


Jonas
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: parameter names local, global, glocal

Jonas Maebe-2
In reply to this post by Wolfram Kläger

On 19 jan 2006, at 00:18, Wolfram Kläger wrote:

>> ... This error should not be reported if you switch to Delphi mode.
>
> Unfortunately no. This kind of errors ís reported by FPC, no matter  
> which mode, while Delphi does not.
>
> I understand your explanation, but don´t really understand that an  
> anyproc.anyparam.name can eventually mask an  
> anyclass.anyproperty.name.

 From your example I understood you were talking about  
childclass.method.param.name masking parentcalls.property.name. That  
is perfectly possible.

> Even more, since several procedure or function declarations within  
> a class or unit can share the same parameter names. In Delphi and  
> FP as well.

The reason this is not a problem, is that you cannot access the  
parameters of one procedure in another anyway. But you can access a  
property of a parent class in the method of a child class.


Jonas_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: parameter names local, global, glocal

Wolfram Kläger
In reply to this post by L505
At 19.01.2006 01:46, L505 wrote:

>I dunno it is a religious thing, read the other messages too :)

Of course, the whole pascal thing is religion. And maillists like this are
kind of praying, at least when you have urgent questions :-)

Wolfram
--
Mosaikfabrik (r)  Bilder von Bildern  www.mosaikfabrik.de
MEMPHIS GmbH  HRB Kirchheim/Teck 1231  Geschäftsführer
Wolfram Kläger  Wrangellstrasse 11  D-70599 Stuttgart
Tel. (+49) 0711 31 944 39  Fax (+49) 012126 31 944 944

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: parameter names local, global, glocal

Wolfram Kläger
In reply to this post by Jonas Maebe-2
At 19.01.2006 10:02, Jonas wrote:

>The reason this is not a problem, is that you cannot access the
>parameters of one procedure in another anyway. But you can access a
>property of a parent class in the method of a child class.

Thanks. This seems exactly to be the point. Now I know better, where to be
careful. Let´s keep the difference to Delphi for religious purposes.

Wolfram
--
Mosaikfabrik (r)  Bilder von Bildern  www.mosaikfabrik.de
MEMPHIS GmbH  HRB Kirchheim/Teck 1231  Geschäftsführer
Wolfram Kläger  Wrangellstrasse 11  D-70599 Stuttgart
Tel. (+49) 0711 31 944 39  Fax (+49) 012126 31 944 944

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: parameter names local, global, glocal

Jonas Maebe-2

On 19 jan 2006, at 11:00, Wolfram Kläger wrote:

> Thanks. This seems exactly to be the point. Now I know better,  
> where to be careful. Let´s keep the difference to Delphi for  
> religious purposes.

I think the use of "religious" is inappropriate in this case since  
religion is based on faith, and this is based on simple reasoning.  
Anyway, in Delphi mode we should compile everything also compilable  
by Delphi, so if that's not the case please submit a bug.


Jonas_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: parameter names local, global, glocal

Wolfram Kläger
At 19.01.2006 11:08, Jonas wrote:
...
>Anyway, in Delphi mode we should compile everything also compilable
>by Delphi, so if that's not the case please submit a bug.

Ok. I will check it again and do so. Maybe it helps to trust in Delphi mode
and makes porting to FP easier.


--
Wolfram Kläger
[hidden email]

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
12