[fpc-devel] QueryInterface on linux/i386 - adding 'in' parameter type?

[Marco van de Voort]

In our previous episode, Jonas Maebe said:
> > 
> > It is meant to avoid a heavy ifdefed solution which is IMHO even worse. 
> 
> That should not be required here. Afaik, only AddRef() and ReleaseRef()
> need it.  All other routines are safecall, which can be used in FPC (after
> Joost's patch) and on Delphi.

The main reason is that I doubted using a new syntax element to describe
interfaces that need to be implementable in a Delphi compatible way without
ifdefs.

The alternative, a $directive to set the const<>ref situation can be also
used globally , and can be added to the ifdef FPC section in some global
section, and also usable for other cases than specifically this case.

I was thinking more of cases where a bit of control over structure ref/value
passing might avoid changing heaps of headers of Delphi origin to (slightly
incompatible) pointer syntax if some discrepancy in how structures are
passed is found on this or that platform.

To fix problems where value passing is expected, but not done, there even is
no workaround in FPC.

> > It is also meant to avoid the combinatorial aspect.  For calling conventions
> > you need a separate one for each detail deviation.  Or you need to introduce
> > separate modifiers for separate aspects of the calling convention.
> 
> A constref parameter is a different kind of parameter, just like a value,
> var and out parameter (basically the equivalent of a "typename const *"
> parameter in C).  A header can perfectly contain both plain "const" and
> "constref" parameters of the same type passed to routines using the same
> calling convention.

More related to the other side of changing what calling convention modifiers
mean every so and so often, and want to at least provide the possibility
(even if it costs work like global directives) for users to keep the old
situation running.

These were my two main concerns in suggesting a directive, and also try to
have a way to allow users to fix/workaround such issues without having to
migrate to trunk all the time (if a such a directive reach mainstream in
the future)

Anyway, it was my opinion on the matter, and I still think it is the better
one over const ref. (or how it is named)