On 28.01.2012 00:16, Kornel Kisielewicz wrote:
On Fri, Jan 27, 2012 at 10:25 PM, Sven Barth
<pascaldra...@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 same type...

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.

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

Somehow I fail to see what you exactly want to show me here. Would you please explain?

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 ^^])

Regards,
Sven
_______________________________________________
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Reply via email to