bugs, incompatibity, function attributes_(re)

Tue, 1 Jul 1997 12:13:03 +0100 (BST)


On Tue, 1 Jul 1997 01:15:36 +0100 (WET DST) Jan-Jaap van der Heijden 
 wrote:

[...]

>So:
>
>1. Are there any reasons not to change the "external" declaration, at
>   least for "borland" mode?

1. specifying DLL names;
With Borland, you need to specify the name of the DLL from which
you are importing a function. You need to do this with *every*
function. This is extremely tedious. Try doing that with the whole
Win32 API for example. Also, you would need to find some documentation
on which DLL holds which function. That is even more tedious. Thus, if we 
are going to support the Borland syntax, then using it should be optional. 
With GPC, you don't need to specify the DLL name - that is, I think, a 
*great* advantage over Borland.

2. not having to redeclare the entire function in the implementation section;
I think it is good to support this. With Borland, you can redeclare the whole
function, or you can just specify it's name. You are not forced to do it in
any particular way, and you can mix and match. It would be nice if GPC
supported this.

3. Delphi's "name" directive;
This is exactly the same as GPC's "asmname" directive. We can 
implement this simply by also allowing just the use of "name" in any place
where "asmname" would be allowed (i.e., we can dispense with the "asm"
part of the "asmname" directive). That way, we get the best of both worlds!

>2. Any objections against allowing (working, that is) function attributes
>   in the implementation part?

None that I can see - except if it makes things become more error-prone.

Best regards, The Chief 
Dr Abimbola A. Olowofoyeku (The African Chief, and the Great Elephant)
Author of:  Chief's Installer Pro v3.60 for Win16 and Win32.
Homepage:  http://ourworld.compuserve.com/homepages/African_Chief/
E-mail: laa12@cc.keele.ac.uk



The African Chief (laa12@cc.keele.ac.uk)

HTML conversion by Lluís de Yzaguirre i Maura
Institut de Lingüística Aplicada - Universitat "Pompeu Fabra"
e-mail: de_yza@upf.es