Well, that's when I said that a new keyword may be necessary so there's
no ambiguity, but in this case, for a single open array, the two are
effectively equivalent. Even in cases where you might pass the array
through the Move routine, you wouldn't do it for the entire record (or
an array of
Am 24.06.2019 um 05:57 schrieb J. Gareth Moreton:
We can't really use a new keyword to define an unbounded array, so I'm
wondering if we can work with the syntax for open arrays. For
example, say we redefined LOGPALETTE to the following:
LOGPALETTE = record
palVersion : WORD;
Fair enough - thank you for the insight.
To clarify, it is easy enough to demand "inline" appear in the interface
section, but it breaks a lot of pre-existing code. I'll have a think
about how to implement the alternative solution of "implementation-only
inline" only affecting the routine
Thought I'd ask. Nothing lost. Just seeking a consensus on how to
address the problem.
Gareth
On 24/06/2019 05:41, Michael Van Canneyt wrote:
On Mon, 24 Jun 2019, J. Gareth Moreton wrote:
Hi everyone,
So after a problem over at
https://bugs.freepascal.org/view.php?id=35753 that led to
On Mon, 24 Jun 2019, J. Gareth Moreton wrote:
Hi everyone,
So after a problem over at https://bugs.freepascal.org/view.php?id=35753
that led to a change of https://bugs.freepascal.org/view.php?id=35671 ,
it became apparent that there may need to be better support for
unbounded arrays in
Hi everyone,
So after a problem over at https://bugs.freepascal.org/view.php?id=35753
that led to a change of https://bugs.freepascal.org/view.php?id=35671 ,
it became apparent that there may need to be better support for
unbounded arrays in record types - not open arrays, but unbounded ones.
Ah, found it. It was buried in the "noise" and me having a bit of a bad
time mentally at the time.
https://bugs.freepascal.org/view.php?id=35346
The patches in that issue fix the inlined methods for
compiler/cstreams.pas and compiler/entfile.pas so that "inline" appears
in the interface
That's a point, true. I've been for openness a lot lately, and one
doesn't normally distribute the PPU files with a closed-source project,
but I guess for those programs that need compiling on Linux before they
can be run, it's not very desirable if the PPU files contain information
on, say,
Am 23. Juni 2019 16:05:05 schrieb Jonas Maebe :
> On 23/06/2019 01:10, J. Gareth Moreton wrote:
>
>> Currently, you can get away with specifying the "inline" directive for a
>> function in just the implementation section of a unit, and the function
>> will be inlined. However, in some
On 23/06/2019 01:10, J. Gareth Moreton wrote:
> Currently, you can get away with specifying the "inline" directive for a
> function in just the implementation section of a unit, and the function
> will be inlined. However, in some situations, this can cause compiler
> crashes which I believe is
Am 23.06.2019 um 01:10 schrieb J. Gareth Moreton:
This one is for Jonas in particular, but also to address a minor issue
in general.
Currently, you can get away with specifying the "inline" directive for
a function in just the implementation section of a unit, and the
function will be
11 matches
Mail list logo
