[fpc-devel] potential bug, generics vs helpers
pascaldragon at googlemail.com
Fri Jan 27 22:25:01 CET 2012
On 27.01.2012 19:05, Kornel Kisielewicz wrote:
> On Fri, Jan 27, 2012 at 6:37 PM, Sven Barth<pascaldragon at googlemail.com> wrote:
>> Am 27.01.2012 17:46, schrieb Thaddy:
>>> On 27-1-2012 17:25, Marco van de Voort wrote:
>>>> In our previous episode, Kornel Kisielewicz said:
>> This compiles!
>> So there MUST be specific code in place in the Delphi compiler to allow the
>> assignment from ugendiamond2.TSpez2 to ugendiamond1.TSpez1 as those are
>> different definitions. Thus this can not be a bug, but must be an
>> intentional feature. Allowing this in FPC as well would be doable.
>> Now regarding Kornel's problem: we could(!) change the way the compiler
>> works in non-Delphi modes to what is described in the documentation (by
>> adding the type symbol's name to the generic's name as well), but this will
>> mean that we would have to define how units in Delphi and non-Delphi modes
>> can interact here. After that the corresponding code in the compiler can be
>> implemented to ensure this.
> What I still don't understand is the way the code is compiled in the
> diamond case. Let's assume that TGeneric in this example has a lot of
> code. So after compilation we have:
> As you stated, the ugendiamonddecl.ppu holds the tokens for generation
> of TGeneric, so the code is "kept" in ugendiamonddecl.ppu. What about
> the object files? The only reasonable general solution I see is that
> both ugendiamond1.o and ugendiamond2.o hold the generated code --
> Delphi may do it otherwise because it may use different intermediate
> file formats (true?)
The ugendiamonddecl.ppu does not contain any code of the TGeneric<T>
class while both ugendiamond1.o and ugendiamond2.o contain both their
own version of the specialization. And there is no other way to solve it
without much hazzle, because if ugendiamond1 and ugendiamond2 don't
depend on each other then there is nothing that stops you from using
only ugendiamond1 or only ugendiamond2 and then the generated code needs
to be available. Delphi uses the same way.
> In this case FPC's specialize could be the mode to be "smarter"
> requiring a explicit instantiation that at the same time shows in
> which object should the code be stored.
No. A definition should be stored where it is defined. I can't just use
ugendiamond1 for storage, because then ugendiamond2 will depend on
ugendiamond1 which might not be the intention. Also what about units
that were definitely compiled by different people, but by "accident"
have the same specializations? You can't store them in the
ugendiamonddecl.ppu/.o either, because that file must be considered fix.
It's already good like it is. We just need to decide whether we want to
support assignments like Delphi does or not. Then we can fix the
compiler, because currently it's only working correctly in half of the
> Also, I'd be a big fan of extending the FPC version of templates in
> the direction allowing more powerful generic metaprogramming (without
> the broken C++ heritage), and I think that explicit instantiation
> would simplify that quite a lot.
The only thing I would add to FPC generics that's a bit in the direction
of C++ templates (besides constraints which are also a Delphi feature
and thus need to be supported sooner or later) would be the ability to
"specialize" a generic with constants (and that only if I have too much
time and no other feature to attend to). But that's it! No more C++
template ways. I don't want a turing complete compile time construct in FPC!
More information about the fpc-devel