pmcgee

@Stefan Glienke do you distinguish between the terms 'anonymous method' and 'anonymous function'? I have mostly heard the word 'method' being used for something like "procedure of object / function of object".

const and const[ref] work differently in this case (for example) : procedure Proc(const nValue: Integer); var pValue: ^Integer; begin writeln(integer(@nvalue)); pValue := @nValue; pValue^:= nValue*2; end; begin var x:=1; writeln(x, ' ', integer(@x)); proc(x); writeln(x); readln; end. 'Const' case prints '1 1', and const[ref] prints '1 2'

Good point. I had overlooked that case. I see what you are saying ... but I haven't worked out what I think as a result. I was looking at the disassembly side by side for four cases ... until a Windows forced a restart on me. Ah ... actually I was using Google Sheets instead of Excel : https://docs.google.com/spreadsheets/d/1ZGJ6seGZR_zNO_mpke6733fHGgOVhoM6PH_q1x7tJB8/edit?usp=sharing (I hadn't finished tracing through all the steps.)

Well, firstly I think if it's not type-safe, then it's surely just not correct. But maybe even more than that, it would be to deny having functions as "first class citizens". If there's evolution ahead in the language, it surely must include being able to pass functions around per-se.

Ok, I get it. I had the bushy end of the pineapple. 🙂 So, we want it to complain in BOTH cases. Yes?

Wait. We DO want a compiler error here, right?? X takes an integer, not a TFunc<Integer>. It makes sense that this should need to be X( f() ).

Just following links from this nice link ... Barry Kelly in 2010 : http://blog.barrkel.com/2010/01/using-anonymous-methods-in-method.html

One thing I noticed about Const[ref] relates to 'reference shadowing' (maybe there's a better term). If you call a function/procedure that takes a const string, the function uses a new reference to the string. With const[ref] it uses the exact existing reference. {$APPTYPE CONSOLE} program Project1; uses system.SysUtils, System.Generics.Collections; type pr = TPair<integer,integer>; procedure call_i1 ( const x:integer); begin writeln( integer(@x) ); end; procedure call_i2 (const[ref] x:integer); begin writeln( integer(@x) ); end; procedure call_c1 ( const x:TObject); begin writeln( integer(@x) ); end; procedure call_c2 (const[ref] x:TObject); begin writeln( integer(@x) ); end; procedure call_s1 ( const x:string); begin writeln( integer(@x) ); end; procedure call_s2 (const[ref] x:string); begin writeln( integer(@x) ); end; procedure call_p1 ( const x:pr); begin writeln( integer(@x) ); end; procedure call_p2 (const[ref] x:pr); begin writeln( integer(@x) ); end; begin var i : integer; var o : TObject; var p : pr; var s : string; writeln( integer(@i) ); call_i2(i); call_i1(i); writeln; writeln( integer(@o) ); call_c2(o); call_c1(o); writeln; writeln( integer(@s) ); call_s2(s); call_s1(s); writeln; writeln( integer(@p) ); call_p2(p); call_p1(p); readln; end. For TPair, the const[ref] makes no difference ... but for string, integer, and Class, it uses the address of the original value or reference.

There is a section of the programming community, from eg Alexander Stepanov, to eg Jason Turner (of C++Weekly) That consider implicit conversion to be evil, or a safety issue. (https://news.ycombinator.com/item?id=24806884) (Google shows me links about it from 2005, 2010, 2015, and 2020 🙂 ) I guess their argument is for explicit casts (if absolutely necessary), over what might be termed 'a wing and a prayer'. Certainly this works : S := 'Testing: ' + string(V);

The original Github repo (https://github.com/rvelthuis/DelphiBigNumbers) has a pdf by Rudy explaining the library. And it says this :

PS : I have submitted an update to the TurboPack repo on Github, with the appropriate attribution back to this thread. https://github.com/TurboPack/RudysBigNumbers/pull/10

Yes. Right. Got it. I did go to the link, but my brain saw the (az+b)(cz+d) and totally failed to see that this was exactly the z = 1.e32 (in binary) that I was using. And thank you for the information about the Elliptic Curve stuff (El-Gamal) to read up on. I'll be very interested to read it.

No, I don't think so. I was just doing the multiplication in pieces that didn't overflow 64 bits. I was just taking a multiplication of two 64-bit numbers, and thinking of it kinda like a long multiplication from school. If we consider each number in their two halves (upper and lower 32 bits), then when we only want to keep the bottom 64-bits, we can throw away part of the multiplications ... and do some of the multiplication in the lower part of the range before shifting it back up again. Yes. I was going to be potentially incorrect in the 64th bit, but it was easy to do, and wasn't affecting the testing I had done to that stage. No, not at all. I have been, with friends, going through Alexander Stepanov's book (and related videos) "From Mathematics to Generic Programming", and he describes RSA in there. We set ourselves the task to implement it in different languages. Its pretty remarkable how simple the mechanical parts are (in concept).

Thanks for your reply. These directives are just quoted as-is from the library on GitHub (uptodate and original) and GetIt. I haven't pulled back to get the higher level view here, having been stuck in tracing through the code to nail down the issues. FSeed is declared as Int64. The function here is : function TRandom.Next(Bits: Integer): UInt32; And the call is : Rnd := Next(32); where Rnd is declared as Integer; I have checked that the actual bits (of course, I guess) stay the same ... but this seemingly cavalier application of (kinda) hidden casting has caused me to squint a little. 🤨 Edit : Incorporating the corrected compiler directives, sanity is returned and FSeed can be calculated in one line again. 🎉 In procedure TRandomBase64.NextBytes(var Bytes: array of Byte); Rnd is declared as UInt64. With the above change, there is a Range Check Error on assigning Rnd (in TRandom.NextBytes) I think it is clear that Rnd should be declared as UInt32. Aaaaannnnd, on reading further down your response, I see you already concluded the same. 😅

{$APPTYPE CONSOLE} program Project1; uses System.SysUtils, System.generics.defaults; type TEmp = class FName : string; FSalary: Currency; FAcNo : integer; function Gett<T> (var field:T) : T; procedure Sett<T> (var field:T; const Value : T); end; function TEmp.Gett<T> (var field:T) : T; begin result := field; end; procedure Temp.Sett<T>(var field:T; const Value : T); begin var lComparer := TEqualityComparer<T>.Default; if lComparer.Equals(Value, Default(T)) then raise Exception.Create('Field must have a non-default value') else field := value; end; // credit to https://stackoverflow.com/questions/5344433/how-can-i-declare-a-pointer-based-on-a-generic-type // regarding Generic comparison to Default(T), and an idea of generic properties. var emp : TEmp; s : currency; a : integer; begin s := 1000.37; a := 123; emp := TEmp.Create; writeln('Name : ', emp.FName ); writeln('Salary : ', emp.FSalary:6:2 ); writeln('Ac # : ', emp.FAcNo ); writeln; emp.Sett(emp.FName, 'Abc Def'); emp.Sett(emp.FSalary, s); emp.Sett(emp.FAcNo, a); writeln('Name : ', emp.Gett(emp.FName) ); writeln('Salary : ', emp.FSalary:6:2 ); writeln('Ac # : ', emp.FAcNo ); readln; end. I was just playing around ... trying to figure out what a simple generic 'property' function could look like. Someone in 2009 had already been thinking down that track.