On 2012-09-27 19:16, Florian Klämpfl wrote:
>
> You care about Delphi compatibility?
:) I was waiting for that. I care about coding not having IFDEF yes - so
it stays readable. tiOPF is the only project I work on that is a shared
code base.
Graeme.
__
Am 26.09.2012 13:27, schrieb Graeme Geldenhuys:
> On 2012-09-26 11:40, Marco van de Voort wrote:
>>
>> It means the interface will always be constref, and thus no ifdefing
>> in FPC
>> (if you don't support <2.6.0) will be necessary.
>
> For fpGUI, I only support the latest stable release of FPC,
In our previous episode, Sven Barth said:
> > I don't know what XE3 improves in that regard. But since FPC encountered
> > this problem only after going multiarchitecture, I don't expect Embarcadero
> > to deal with that until the new Delphi compiler lands.
>
> The question is whether Embarcadero
Am 26.09.2012 12:37, schrieb michael.vancann...@wisa.be:
My suggestions (if we do indeed enable it):
intfconst for constref/const
intfdecl for stdcall/cdecl {I would not use extdecl so that there
are no
potential conflicts}
libcall was already mentioned. It also helps in a lot of other
places,
Am 26.09.2012 13:43, schrieb Marco van de Voort:
After all, it seems Delphi doesn't have a constref correct?
I don't know what XE3 improves in that regard. But since FPC encountered
this problem only after going multiarchitecture, I don't expect Embarcadero
to deal with that until the new Delph
Am 26.09.2012 13:27, schrieb Graeme Geldenhuys:
On 2012-09-26 11:40, Marco van de Voort wrote:
It means the interface will always be constref, and thus no ifdefing
in FPC
(if you don't support <2.6.0) will be necessary.
For fpGUI, I only support the latest stable release of FPC, so that
would
In our previous episode, Graeme Geldenhuys said:
> >
> > It means the interface will always be constref, and thus no ifdefing in FPC
> > (if you don't support <2.6.0) will be necessary.
>
> For fpGUI, I only support the latest stable release of FPC, so that
> would be 2.6.0. So I should be fine w
On 2012-09-26 11:40, Marco van de Voort wrote:
It means the interface will always be constref, and thus no ifdefing in FPC
(if you don't support <2.6.0) will be necessary.
For fpGUI, I only support the latest stable release of FPC, so that
would be 2.6.0. So I should be fine with removing tha
In our previous episode, Graeme Geldenhuys said:
> > You are right! I forgot about that. 2.6.0 already supports constref so
> > we can indeed remove the FPC_HAS_CONSTREF part from trunk.
>
> Awesome! So I guess that could be back ported to 2.6.x (fixes branch)
> too - ready for the possible 2.6.
On Wed, 26 Sep 2012, Sven Barth wrote:
Am 26.09.2012 12:28, schrieb Marco van de Voort:
In our previous episode, Sven Barth said:
end;
IInterface = IUnknown;
This depends on whether we want to enable $macro in the system unit...
It doesn't work at all since macro's don'
On 2012-09-26 11:28, Sven Barth wrote:
You are right! I forgot about that. 2.6.0 already supports constref so
we can indeed remove the FPC_HAS_CONSTREF part from trunk.
Awesome! So I guess that could be back ported to 2.6.x (fixes branch)
too - ready for the possible 2.6.2 release some day?
On 2012-09-26 11:23, michael.vancann...@wisa.be wrote:
Since years I am a proponent of a libcall calling convention which
translates to the common library calling convention for the platform.
I like that idea.
Regards,
- Graeme -
___
fpc-devel m
Am 26.09.2012 12:28, schrieb Marco van de Voort:
In our previous episode, Sven Barth said:
end;
IInterface = IUnknown;
This depends on whether we want to enable $macro in the system unit...
It doesn't work at all since macro's don't export over unit borders.
Nowhere did
In our previous episode, Sven Barth said:
> > end;
> > IInterface = IUnknown;
>
> This depends on whether we want to enable $macro in the system unit...
It doesn't work at all since macro's don't export over unit borders.
> My suggestions (if we do indeed enable it):
> intfconst
Am 26.09.2012 12:23, schrieb michael.vancann...@wisa.be:
The FPC_HAS_CONSTREF should disappear as soon as the RTL must not be
compilable with a previous version that does not have CONSTREF.
(which in fact could be 2.6.0, but someone would have to confirm that)
You are right! I forgot about that
Am 26.09.2012 12:16, schrieb Graeme Geldenhuys:
On 2012-09-25 22:16, Henry Vermaak wrote:> I've used a macro for this in
the past. E.g. :
>
> {$macro on}
> {$ifdef windows}
>{$define CCONV:=stdcall}
> {$else}
>{$define CCONV:=cdecl}
> {$endif}
>
> Then use CCONV where you would
On Wed, 26 Sep 2012, Graeme Geldenhuys wrote:
On 2012-09-25 22:16, Henry Vermaak wrote:> I've used a macro for this in the
past. E.g. :
{$macro on}
{$ifdef windows}
{$define CCONV:=stdcall}
{$else}
{$define CCONV:=cdecl}
{$endif}
Then use CCONV where you would specify the calling con
On 2012-09-25 22:16, Henry Vermaak wrote:> I've used a macro for this in
the past. E.g. :
>
> {$macro on}
> {$ifdef windows}
>{$define CCONV:=stdcall}
> {$else}
>{$define CCONV:=cdecl}
> {$endif}
>
> Then use CCONV where you would specify the calling convention.
Couldn't something like
18 matches
Mail list logo
