Hi Folks.

Moving some units from Delphi to FPC-Lazarus, the FPC compiler tells me something I do not understand:
Platform is Linux_x64, Lazarus 1.0.8 FPC 2.6.2, gtk2 Project options have been set to Obj Pascal (mdelphi removed)

interface
     uses ...
[324]    function OpenLongFileName(const ALongFileName: String; const
SharingMode: Integer): THandle;
implementation
uses ...
function OpenLongFileName(const ALongFileName: String; const
SharingMode: Integer): THandle;
begin
   if not FileExists(ALongFileName) then begin
     with TStringList.Create do try
       Clear;
       SaveToFile(ALongFileName);
     finally
       Free
     end;
   end;
   Result := FileCreate(ALongFileName, fmOpenReadWrite, SharingMode);
end;

compiler says:

clamav3.pas(324,12) Error: Forward declaration not solved
"OpenLongFileName(const AnsiString,const LongInt):QWord;"

Any comment ?

Thanks,

Antonio.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20130809/25feed26/attachment.html>

Maybe there is a unit in your implementation uses section that redefines THandle.

Mattias

Le 09/08/2013 10:22, Mattias Gaertner a ?crit :

On the declaration (following Ctrl + mouse left click) leads to QWord: THandle --> PtrUInt (LCLType) --> QWord (systemh.inc) on the implementaion: THnadle --> System.THandle (sysutilf.inc) --> THandle --> LongInt (sysosh.inc)

Well done. In the interface units uses declares:   LCLIntf, LCLType,
LMessages,  FileUtil;
In the implemantaion uses declares   Classes,  sysutils;
OK. It is a Delphi conversion and I didn't pay enough attention to it

But the isn't there some ambiguity between LCL declarations and FPC declarations for what is obviously the same type ? Thanks Mattias,

Antonio.

Might be related to the fact that the LCL often uses the THandle to store a pointer on non-Windows widgetsets. On e.g. Linux x86_64 THandle is defined as a longint because of file operations... There might not be a solution with which anyone can live :/

Regards,
Sven

Le 09/08/2013 11:29, Sven Barth a ?crit :

OK, I think I can live with this. But I think it would be preferable to use a distinct type name. As I can understand that the system unit is quite close to the OS definitions it should not be superseded by Lazarus. Anyway, thanks for the explantion Sven.

Antonio.

The problem is that Windows has one handle type for everything, while other OS have different types of handles.
?

Mattias

I have been proponent of this idea since many years :-)

Michael.

What type do you want to rename?

Mattias

LCLType.THandle.

Regars,
Sven

THandle. I suspect you have it in lcltypes or so.

IMHO there should be TFileHandle, TWindowHandle etc. Probably on windows they will all end up referencing windows.THandle, but on other platforms they may be wildly different.

That's one of the reasons dynlibs introduced TLibHandle.

Michael.

Le 09/08/2013 13:39, Michael Van Canneyt a ?crit :

For a developer as me, this is probably the best solution indeed. I do manipulate lots of handles in my applications and do not really want to take care of which basic type they are. I'd be more than happy to re-engineer my applications diversifying handle types which means to get rid of all this ambiguity when addressing OS objects. My problem then would be to use the right handle type where needed

Antonio.

That is exactly why I am a proponent of this mechanism.

Michael.

Le 09/08/2013 15:02, Michael Van Canneyt a ?crit :

Just tell me how to push forward with you 8-)

Antonio.

Simple:
We kidnap Mattias, lock him in the casemates in Luxemburg city, and don't let him out till he did the work ;)

Michael.

Le 09/08/2013 15:21, Michael Van Canneyt a ?crit :

Looks so simple. OK Michael, look for the chains and the cuffs and I'll take care for a machine gun. Who's gonna take the car ? Maybe a bicycle would do it ? :-P

Antonio.

El 09/08/2013 11:15, Antonio Fortuny escribi?:

In delphi, exists sysutils.abort and windows.abort. I don't know how long it took me to find the bug: Just because "windows" was used after "sysutils". In this case the compiler didn't complain, and the errors where very weird.

Other languages, like Ada, raise a compiler error. IMHO, the FPC should not allow such ambiguity and raise an error, asking to qualify the identifier. I suppose it would break backward compatibility, a directive {$Check_Ambiguity+} would be fine for me ;-)

When you work with big programs, you are going to face with identifier collisions. The solution is not to change identifier, probably each unit programmer chose such name for good reasons, but using namespaces, that object pascal already has. The current solution, relying in the order of units to guess which one will pick, is a prone of errors, and sometimes very difficult to find, because most of us aren't aware of this most time, and don't code with this concept in mind. With hundreds of third party libraries and components, I am sure many people have hit this error and gone nuts for a while.

The reason why things like this don't happen more often is because units usually contain objects and we use things encapsulated in object more often than global identifiers. But that is not an excuse, relying in "uses" order is a poor decision from old times that could be improved.

Sure it's a FPC topic, but I couldn't help... it's just a rant ;-)

+1

Namespaces was discussed many times on FPC list and many ideas were said, however no idea was good enough for FPC team, unfortunately.

Regards,
Marcos Douglas

Some more people would like something like that. The compiler developers most probably won't, because it would slow down compilation.

As a compromise a directive $RequireQualification could be added, forcing error messages with *all* unqualified identifiers in the unit. This in fact could speed up compilation, because searching the Uses lists is not required any more. But before using such an switch a tool or feature would be required to qualify all unambiguous identifiers, and to offer choices for the ambiguous ones.

A global directive won't work, because the FCL, LCL and all other library writers most probably won't update their code, only to please some users. And I wouldn't like that, too, because it adds so many qualifiers to the code, that it will become almost unreadable to me (and other coders).

Sure it's a FPC topic, but I couldn't help... it's just a rant ;-)

Ask again in FPC-devel, or create an feature request.

Or write your own tool for finding ambiguous declarations, and the whole world will praise you ;-)

DoDi

Do casemates have power and internet?

Mattias