One drawback I've noticed is that there's no clean way to free the
optinfo pointer when the tai object is destroyed, plus there's the
danger of the pointer being used as a plain integer instead of pointing
to an actual structure (conversely, the Tag property in components was
often used to hold an object pointer, especially in the 32-bit days). I
would like to propose having a Boolean field named "OwnsOptInfo" that,
if True, calls Dispose on optinfo's value in tai's destructor so we
don't get memory leaks.
Gareth aka. Kit
On 03/10/2021 13:15, J. Gareth Moreton via fpc-devel wrote:
That's useful to know - thanks Jonas.
On 03/10/2021 13:10, Jonas Maebe via fpc-devel wrote:
On 03/10/2021 14:04, J. Gareth Moreton via fpc-devel wrote:
I'm aware that the tai class declares an "optinfo" field, although I'm
uncertain if this is safe to use or not given it's wrapped by an
conditional define and is of type Pointer.
It's wrapped under {$ifndef NOOPT}, because it's intended for use by
assembler optimisers and when NOOPT is defined, no assembler optimisers
are included.
It's defined as pointer because it's a field of an abstract base class
in a unit that has no dependencies on target-specific units, and the
actual type could be different for different target architectures.
Its purpose is indeed to attach a pointer to a record with extra
information that is only collected/updated during the optimisation
phase.
Jonas
_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
--
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus
_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
