[fpc-devel] potential bug, generics vs helpers

[Kornel Kisielewicz]

On Fri, Jan 27, 2012 at 10:25 PM, Sven Barth
<pascaldragon at googlemail.com> wrote:
> On 27.01.2012 19:05, Kornel Kisielewicz wrote:
>> 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.

What I meant was a solution (only for FPC mode) that only allowed
compatibility between specializations.

So if ugen1 and ugen2 would both have specialization TGeneric<> then
the situation would be as now (two instances), only no assignment
would be possible. To have a possible assignment you'd have to have
them both include a common unit that has this particual
specialization. Basically restricting template assignment only to the
same instantiation as stated in the manual, which would allow to
choose between one or several instantiations.

However, this suggestion is void, due to the Matrix/Vector case I
mentioned before.

>> 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).

I actually faked a small part of that in one of my programs by using SizeOf ;).

type GNumeric1 = byte;
type GNumeric2 = packed array[2] of byte;
type GNumeric3 = packed array[3] of byte;
...

// and use the "constant":

generic GenericArray<T,Size> = record
  Data : array[0..SizeOf(Size)-1] of T;
end;

type IntArraySize2 = specialize GenericArray<Integer, GNumeric2>;

Booleans can be similary faked.

> But that's it! No more C++ template ways.

> I don't
> want a turing complete compile time construct in FPC!

I guess it's too late :P.

Let's start with something simple...

generic GNumericInc<N> = packed record
  unused1 : Byte;
  unused2 : N;
end;

generic GNumericAdd<N> = packed record
  unused1 : Size;
  unused2 : Size;
end;

generic GNumericSquare<N> = packed record
  unused : array[0..SizeOf(Size)-1] of Size;
end;

generic GNumericMult<A,B> = packed record
  unused : array[0..SizeOf(A)-1] of B;
end;

However, I have yet to find a way to stop a recursive loop :P (yes,
I've got a Boost background)

On a more serious note however, we don't want a C++ templates-like
monster, however any enhancement that allows more powerful
compile-time code generation that is clean and doesn't affect normal
code isn't something to ditch. Although I'd need to seriously rethink
that, to come up with something powerful, yet clean and simple enough
not to provoke code bloat and exponential explosion of compile time.
-- 
regards,
Kornel Kisielewicz