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

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

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 users discussions 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

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

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

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) ...

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

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

Micha

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

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

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.

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 -
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

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

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.

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

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

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

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

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

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.

Regarding EOL, you have to take into account the difference between Mac OS (classic) and Mac OS X.

Vincent

feeds and unix used #10 for line feeds, but I've heard that sometimes certain unix systems used #13. I've always wanted to clarify this.. And then there is the end of file delimiter which also came to mind.

Maybe it helps to trust in Delphi mode and makes porting to FP easier.

I've grown to like ObjFPC mode for understanding Pascal at a greater level but using Delphi mode is a good idea with code coming from Delphi. Many of the objfpc mode choices were made with Pascal philosophy in mind, whereas Delphi syntax is generally getting lazier for programmers, while making some code less clear but lazier to type on the keyboard. For example the whole lack of @procedure confuses me in Delphi - I find the @ helps jump out and let me know it's a procedure in the code and makes code easier to read anyway.

Mac OS 9 and below used #13. Mac OS X, with it's unix/bsd heritage, uses #10. I don't know of any *nix that uses #13?

I've always wanted to clarify this.. And then there is the end of file delimiter which also came to mind.

Afaik only Dos and OS/2 know that concept, other OS'es don't use an EOF delimiter.

Jonas

you wrote

I've grown to like ObjFPC mode for understanding Pascal at a greater level but using Delphi mode is a good idea with code coming from Delphi.

I agree completely. Delphi mode should support struggling with legacy code, but the idea of FP is (hopefuly) not to copy Delphi perfectly. Dotnet mode anybody? :-)

http://www.freepascal.org/faq.html#dotnet

06-01-19 13.05, skrev Jonas Maebe följande:

But one should be aware of that a mac user, using Mac OS X might run classic Mac OS programs, in the classic environmant, which produces #13 files.

Olle

Olle Raab wrote

But one should be aware of that a mac user, using Mac OS X might run classic Mac OS programs, in the classic environmant, which produces #13 files.

Actually, the standard Carbon stuff might also still use #13.

Jonas

Even when you work in Mac OS X native, there are situations where you end up with #13 files. E.g. when using BBEdit and the default is set at Mac files, or when you use an (s)ftp connection with automatic text translation (depending on preference settings). I get bitten by this too often.

Tom