Jump to content

David Heffernan

Members
 View Profile  See their activity

  • Content Count

    3478

  • Joined

  • Last visited

  • Days Won

    171

Posts posted by David Heffernan

  2. Posted · Edited by David Heffernan

    22 minutes ago, Virgo said:

    UnicodeString for binary hash would be the worst type.

    I was referring to base64. That takes binary input (so bytes) and outputs text (so string). 

     

    For sha1 the yes the input and output should be binary, that is bytes. The you'd have helper functions to take hash output and write in friendly hex format. 

     

    At no point should there be AnsiString. I mean I hope you aren't proposing AnsiString as a place to hold bytes. 

    • Like 1

  3. Posted

    On 1/8/2024 at 8:54 AM, Angus Robertson said:

    the input to encode is AnsiString

    It makes no sense to me that a base64 function could ever accept string input. Input base to be bytes. 

     

    On 1/8/2024 at 8:54 AM, Angus Robertson said:

    The output of the hash function is AnsiString

    This is also kinda weird. Shouldn't it be the native type for text, string. 

    • Like 1

  4. Posted

    5 hours ago, Gord P said:

    I suspected that.  That was nice about using the 80 bit doubles.  From what I understood, there wasn't a huge performance hit.  I was about test all that out, but now I think I will stick with the doubles for now.

    Massive performance hit compared to double on 64 bit

  6. Posted

    Those libraries will be appallingly slow. In terms of the calculation side of it, it doesn't sound like you have a problem. Use double. 

     

    As far as the IDE goes its not surprising that a program written using the Delphi rtl doesn't convert floats to decimal text correctly because the rtl doesn't. Or vice versa. Never has done and in spite of Emba being told more than a decade ago they haven't shown any inclination to address it. 

     

    In my code I use dtoa and dragon4 to do these things so I can get correct values. 

  7. Posted

    12 hours ago, darnocian said:

    Say in serialisation, you construct offsets relative to a certain address (say the start of the first record), and in deserialisation in another process, you convert back to pointers again. The key to it being useful is the layout and relative addressing.

    I'm not talking about generalities. I'm talking about this specific topic. The OP already said that the pointer values that are streamed are ignored.

     

    The problem at hand is that the code does naive blitting of internal records, and these records have different layouts for different targets.

  8. Posted

    2 hours ago, Lars Fosdal said:

    Offsets may be helpful if the streamed order is not the same as the desired order, such as for a tree structure. Personally, I'd opt for identities and rebuild the structure after loading the stream. But, since OP doesn't share sufficient info about content and structure, this is all speculation.

    What would offsets be helpful for given that the data streamed in those fields is never used

  9. Posted

    On 1/2/2024 at 8:24 PM, Gord P said:

    The true value of 1/7 is 0.142857142857142857..., where 142857 repeats itself forever.

    Not in IEEE 754 floating point data types that you are using.

     

    Anyway I'm not actually sure what your actual problem is. Do you feel that there is an issue with the debugger? 

     

    As for 80 bit floats I don't see any future for them. That idea died and everyone uses 64 bit double now. Is double insufficient for your needs? 

  15. Posted · Edited by David Heffernan

    On 1/2/2024 at 11:21 PM, Navid Madani said:

    Value types are copied unless passed by reference. That can impact performance.

    When performance is an issue, pass by reference then. Presumably you are happy to use value types like integer? Or do you shun all value types? 

    On 1/2/2024 at 11:21 PM, Navid Madani said:

    Interfaces can emulate data immutability and prevent bugs.

    Prevent what bugs? Code with interfaces can have bugs too. So it's not some magic solution. 

    On 1/2/2024 at 11:21 PM, Navid Madani said:

    Interfaces can prevent memory leaks.

    Code using interfaces can have leaks. 

    On 1/2/2024 at 11:21 PM, Navid Madani said:

    Interfaces obviate the need for try-finally blocks,

    They are still there, the compiler writes them. 

    On 1/2/2024 at 11:21 PM, Navid Madani said:

    It is not always a simple case of memory allocation/de-allocation with records on the heap.

    It's the exact same pattern as used with classes. It's well known and easy to follow. 

    On 1/2/2024 at 11:21 PM, Navid Madani said:

    There can be issues with access violations, and hard to detect bugs if record pointers are accessed but point to invalid data.

    This is true. But it's simple enough to flow the rules and avoid this. 

    • Like 2

  21. Posted

    30 minutes ago, Fr0sT.Brutal said:

    MS finally listened to demands and now you can create self-sufficient C# apps (with all required DLLs located near the EXE). The same could be with Java, just use a starter that would set path to local JRE.

    That's been possible for years

  22. Posted

    I opened Visual Studio the other day and made some edits to a C# module that implements an API interface for our software. We have interfaces in a variety of languages, C++, Python, C#, etc. 

     

    I was blown away when VS offered me suggestions for the code I was writing. Clearly it's using some AI library to do this. Honestly, the quality of the suggested code blew my mind. I knew what I wanted to write, and so did VS. 

     

    This is only going to get better and better, but it's already amazing. So far as I know, there's nothing remotely like this for us Delphi users. Or would we get this is we wrote our code in an editor like VS Code?? 

  23. Posted · Edited by David Heffernan

    4 hours ago, Uwe Raabe said:

    Ehm, what were your hope based on then? Random mutations of code caused by solar flares?

    I had hope based on my QC reports from XE7 days. 

     

    In any case it's a huge design mistake for Emba to implement windows themed menus as custom draw. Just let the bloody system draw it and then it will always be right!! Well, MDI excluded, but menus are getting deprecated any time soon. 

  25. Posted

    11 hours ago, Darian Miller said:

    So what happens when you drag your window from a non-High DPI monitor to a High DPI monitor and vice-versa?   Do you get a lag and a bunch of flicker?

    Ha ha ha. I think we all know the answer to this. 

     

    They can't even do menus properly. Even for the standard  windows theme the menus are custom drawn and the Emba code gets it wrong in various mixed dpi scenarios. 

     

    When I switched to Delphi 11.3 I'd hoped to avoid having to patch the VCL to suppress its custom drawn menus. Alas that hope was doomed. 

×