[fpc-devel] Looking for clarification on what I think are obviously missing "const" prefixes for parameters in the methods of TRect (the typshrdh.inc one)

[Sven Barth]

Am So., 27. Jan. 2019, 14:12 hat Walter Prins <wprins at gmail.com>
geschrieben:

> On Sun, 27 Jan 2019 at 01:53, John Doe <slightlyoutofphase at gmail.com>
> wrote:
>
>> On Sat, Jan 26, 2019 at 7:44 PM Sven Barth via fpc-devel <
>> fpc-devel at lists.freepascal.org> wrote:
>>
>>> Changing this behavior would not only be a backwards incompatibility,
>>> but would also violate the ABI which describes how records shall be passed.
>>>
>>
>> On second thought, I definitely agree with you that changing the basic
>> behavior of the compiler in that regard sounds like an idea that is not
>> remotely possible due to how it would very likely break large amounts of
>> existing code. That was a dumb suggestion on my part.
>>
>
> Just thinking out loud (probably a bad idea) but:
>
> Would it perhaps be possible to treat this as a type of optimization
> however?  Which is to say, if the called routine makes no changes to the
> passed record, then it should not matter whether compiler implicitly const
> passes the parameter or copies it?  (If the routine *does* change the
> passed record then it does the normal thing.)  Of course I have no idea
> whether the dataflow analysis I imagine needed to support this is
> whatsoever plausible to be done without unacceptable compromises  (And even
> then, I'd guess it's not something there'd be sufficient appetite for even
> if in theory it might be possible...?)
>

We currently have no function specific adjustments of the calling
convention, so this would be rather involved to implement (I know that e.g.
the Visual Studio compiler does that).
Also keep in mind that a unit does not know how it is used. With Lazarus a
package is compiled once for multiple projects where one could be a self
contained application and the other a library that has such a function in
its export section (constructed example, I know, but those things need to
be kept in mind).

Regards,
Sven

>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freepascal.org/pipermail/fpc-devel/attachments/20190127/f516210b/attachment.html>