[fpc-devel] potential bug, generics vs helpers
pascaldragon at googlemail.com
Sat Jan 28 12:00:09 CET 2012
On 28.01.2012 00:16, Kornel Kisielewicz wrote:
> 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.
I believe that having an overview over which types are assignable to
which other types in a bigger application will be rather difficult.
> However, this suggestion is void, due to the Matrix/Vector case I
> mentioned before.
Maybe it's definitely better if we go the Delphi route even if we won't
be able to define helpers for two "different" specializations using 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).
> I actually faked a small part of that in one of my programs by using SizeOf ;).
> type GNumeric1 = byte;
> type GNumeric2 = packed array of byte;
> type GNumeric3 = packed array of byte;
> // and use the "constant":
> generic GenericArray<T,Size> = record
> Data : array[0..SizeOf(Size)-1] of T;
> type IntArraySize2 = specialize GenericArray<Integer, GNumeric2>;
> Booleans can be similary faked.
A have to admit, that is neat O.o
>> 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;
> generic GNumericAdd<N> = packed record
> unused1 : Size;
> unused2 : Size;
> generic GNumericSquare<N> = packed record
> unused : array[0..SizeOf(Size)-1] of Size;
> generic GNumericMult<A,B> = packed record
> unused : array[0..SizeOf(A)-1] of B;
> However, I have yet to find a way to stop a recursive loop :P (yes,
> I've got a Boost background)
Somehow I fail to see what you exactly want to show me here. Would you
> 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.
The biggest problems are:
* backwards compatibility (I did quite some thinking around many corners
to implement Delphi compatible generics in a way that allowed old
non-Delphi-mode generics to still be compileable as is)
* Delphi compatibility (regarding new features at least so far that
generics can still be used in a Delphi compatible way)
* not too much complication of the parser (it already got a bit more
complicate by me implementing support for "mylist :=
TFPGList<LongInt>.Create" and I don't have yet implemented generic
functions which will allow things like this in the end: "if
myfunc1<LongInt>(42) < myfunc2<LongInt>(21) then ..." [I hope you can
spot where the parser will have problems ^^])
More information about the fpc-devel