Georgge Bakh

Did someone compare it to https://github.com/BeRo1985/flre ?

Find usages is one of the most useful and most frequently used features of a code editor. Must work flawlessly.

@Remy Lebeau Generics are OK. And very useful. But some implementations are not. 😉 Btw in FPC your code compiles and working properly.

You can use unit scopes for this as partially done in RTL. Place things which need different implementation for different platforms in separate units per implementation. E.g. Windows.Utils, Linux.Utils etc. Or even not bound to a platform but API: OpenGL.Render, DirectX11.Render etc. In uses clause of other units just write Utils or Render. And setup needed unit scope names in project settings - Windows;OpenGL. This approach with some architectural effort will minimize number of IFDEFs in code.

I've checked. As Stefan said if TTest2 is sealed or its method Test() is final the call is non-virtual. If type parameter of TTest is constrained by an interface the correct method is called but despite non-virtual declaration of Test() method the call looks like virtual (FPC inlined the call). GetTypeName(TypeInfo(T)) is 'TTest2' in both cases. Overall the current behaviour of generics in Delphi seems to be too restrictive without any gain. May be in C# it's acceptable because it does have many other capabilities and aggressively optimizing JIT compiler. But for Delphi it's not suitable.

@Kryvich Just curious - what else could output this code? I'm aware of FPC approach to generics and it's much better IMHO. Although not complete too. As of virtual calls - when writing a low-level library code there is not known where exactly it will be used. So trying to avoid virtual calls it normal especially when those are absolutely unnecessary. Thanks for help. Later will check and bench with sealed/final. And will decide on a choice to use ugly IFDEFS or drop Delphi support.

OK, C# is an authority here and my approach is totally wrong. But how it can be achieved in compile time? The task is simple: I have a class, let's call it TDataHandler which use another class as data provider - TDataProvider. TDataProvider can be a simple wrapper over a memory buffer or more complicated stream-based implementation or something else. In TDataHandler I call TDataProvider to get some data and several other data-related things. I could declare methods of TDataProvider as virtual and override them in actual implementation but I don't want to have virtual method calls (non-virtual is acceptable) instead of simply referencing a pointer (as generated by FPC). How it can be done? Please note that in Java (and probably C#) virtual calls is not a problem as JIT compiler will inline even virtual calls if needed and the resulting machine code will be similar to one generated by FPC.

David, if I got you right, your advice is to use the technique with virtual methods because it works. It's a good advice thank you. But I wanted to use generics as it's a powerful technique which I successfully use in other languages and it seems it should work for my case. And a broad range of other cases which can be identified as parametrization by code. If it can't be done in Delphi it's sad but I'd want to know why. Is it a bug? Let's get on with it: I have TTest<TTest2> specialization of the above generic class TTest. May I expect that field FTest will have static type TTest2? If no why?

If I'd wanted virtual methods I wouldn't use generics. Just field of some base class is enough. But it's not a compile time parametrization. It's runtime technique. Why? My logic is: TTest<T> has field FTest of type T. Therefore specialized TTest<TTest2> will have field FTest of type TTest2. How the field can be of type TTest1? TTest1 is just a type parameter constraint after all. It's needed only to allow the use of Test() method in code.

Tried to use generics to parametrize a class with some code. type TTest1 = class procedure Test(); end; TTest2 = class(TTest1) procedure Test(); end; TTest<T: TTest1, constructor> = class(TObject) FTest: T; procedure TestIt(); end; When calling FTest.Test() I expect a method of actual type parameter to be called. procedure TTest<T>.TestIt(); begin FTest := T.Create(); FTest.Test(); readln; end; But actually a method of type constraint (!) is being called. I.e. static type of FTest not depend on actual type parameter. It's always TTest1! Is there a workaround for this? How do you parametrize generic classes with code? Comparators, hash calculators and other useful things which give generics a purpose. It's an essential part of generics which simply not work! How this bug can not even be reported till now? The code works as expected with Free Pascal Compiler. https://quality.embarcadero.com/browse/RSP-27840

I hope there will be something that justifies such a secrecy.

My collections library based on pseudo-templates has a HashMap implementation. Besides of key and value types it can be parametrized with a hash function of the default one is not suitable for some reason. https://github.com/casteng/tacl

If I got it right, you protecting with a critical section (the same one I hope) read access to fields as well as field modifications with change event call. This may be or may be not enough depending on what your program do and what invariants you must ensure. Additionally, with some logic in change event handler there is a risk of deadlock.

Look like Free Pascal has these features. Besides Basic support. Did you considered it? Compiler development is very interesting area. I think you will find people if you decide to go that way.

Self signed certificates can be validated as usual. If lets say a server certificate is self-signed than a root CA certificate which was used for signing (may be self-signed as well) should be trusted by client. If both server and client data are under control it's possible to make the CA certificate trusted. That's how browsers work after all. Diffie-Hellman key exchange by itself doesn't protect from MitM attacks.