2018-06-21 22:50 GMT+02:00 Maciej Izak :
> Coexistence of both has no sense - information stored in Flags will be
> useless, this info is for sure not complement :( .
>
I see 4 options:
1. integration of FastRTTI
2. limited integration, only part of "FastRTTI" branch (only table with
initializa
2018-06-22 20:42 GMT+02:00 Jonas Maebe :
> I would propose to switch all targets to use use ansistrings for symbol
> names.
+1
I was asking for this some time ago in core mailing list... As temporary
solution compiler can be compiled with
OPT="-dsymansistr"
Even without something special like
On Sat, 2018-06-23 at 11:19 +0200, Sven Barth via fpc-devel wrote:
> Am 23.06.2018 um 10:48 schrieb Jonas Maebe:
> >
> > > > I would propose to switch all targets to use use ansistrings
> > > > for
> > > > symbol names.
> > >
> > > Is this the consensus?
> > >
> > > Personally, if I had any sta
On 23/06/18 11:19, Sven Barth via fpc-devel wrote:
But aren't there output formats that do have length restrictions for
symbol names? I take it that ELF and PE/COFF won't be problematic, but
what about those used for OS/2, DOS, etc.?
If needed somewhere, symbol names could be shortened in the
Am 23.06.2018 um 10:48 schrieb Jonas Maebe:
I would propose to switch all targets to use use ansistrings for
symbol names.
Is this the consensus?
Personally, if I had any stake in this, I would be against it. I
mean, FPC is already slower than DCC.
I doubt this is a major contributor to t
On 22/06/18 22:49, bla...@blaise.ru wrote:
On 22.06.2018 21:42, Jonas Maebe wrote:
The rationale for the above is that they need symbols that are longer
than 255 characters.
And such symbols could not be shortened by hashing heads or tails?
The type information must be fully encoded in the
