Jump to content

David Heffernan

Members
 View Profile  See their activity

  • Content Count

    3499

  • Joined

  • Last visited

  • Days Won

    174

Posts posted by David Heffernan

  1. Posted

    51 minutes ago, Dalija Prasnikar said:

    No. Only iOS and Android are LLVM based. http://docwiki.embarcadero.com/RADStudio/Rio/en/Delphi_Toolchains AFAIK first Linux release (Tokyo) was also LLVM.

     

    And you don't want to have LLVM on other platforms for few reasons.

     

    Not only it is slower than "old" handcrafted Delphi compiler, more importantly LLVM cannot handle exceptions in way Delphi compiler does. Using LLVM on desktop would break a whole a lot of code. 

     

    You can fin more at https://dalijap.blogspot.com/2018/10/catch-me-if-you-can.html

     

    That's surely not a problem with LLVM per se, rather the Delphi compiler on top of LLVM?

  3. Posted · Edited by David Heffernan

    9 hours ago, PeterPanettone said:

    I could easily write a small script-tool which fixes the commas. But at a more general scope, it would be interesting if it was possible to fix these syntax errors with the help of the compiler?

    Writing a tool is how I would approach this. Learn a language like Python so that task like this can be done very easily and quickly.

     

    Of course, an even better solution is to fix the process that is generating erroneous code in the first place. 

  9. Posted

    1 hour ago, Mike Torrettinni said:

    Eh, I just got some unexplained nil pointers and exceptions... and debugger kept hiding value of TList variables, never had so much hassle with TArray. So I converted all code from TList<T> back to TArray<T>,

    I will keep TList<T> for just simple cases. Well, I tried.

    When done right, it is simpler and cleaner to code using higher level constructs. Sounds like you are blaming the tools. 

  13. Posted

    5 hours ago, Mike Torrettinni said:

     

    I like the DLL option, but the client is not too happy about it as they don't want to have additional external files for deployment.

    Spend the time to get the deployment right and it's no problem. If you can deploy a single exe file then you can deploy a dll alongside it. If anyone is complaining then perhaps you aren't deploying correctly. I wonder, you aren't trying to deploy to system 32? 

  17. Posted · Edited by David Heffernan

    2 hours ago, Rudy Velthuis said:

    I have put code through godbolt quite a few times already. Yes, the generated code is not bad, but can still be improved, manually.

    That's not the same as starting from scratch.

     

    Also, didn't you have trouble with bugs in you asm code in your bigint library? 

  18. Posted · Edited by David Heffernan

    37 minutes ago, Rudy Velthuis said:

    The ideal situation would be, of course, if the compiler automatically added (wrote) such a destructor for us, using the knowledge it has about the types in the record at compile time, instead of simply compiling in a function like FinalizeRecord and type info. But what I have seen (and which was removed again) already showed a lot of promise.

    Well, that's exactly what I have been arguing for. It seems utterly insane to me that this task is handled at runtime when it can be handled at compile time.

     

    Anyway, as I understand it the record dtor would run in addition to the RTTI based finalization code. So adding a dtor could only ever make code slower. 

    • Like 2

  19. Posted

    4 minutes ago, Rudy Velthuis said:

    And yet I think well but manually written assembler beats every compiler, despite the often used "a good compiler ... etc.".

    True years ago, but these days not so. Just put some code through godbolt and marvel at the code that it generates. You don't have to get that complicated before you see the compiler spotting optimisations that are very far from obvious. Optimisers now have deep knowledge of hardware architecture and can use that to make choices that are beyond almost all human asm programmers.

    • Like 1

  20. Posted

    That's because your button event handlers run busy message loops waiting for the child processes to finish.

     

    Your mistake is to run those busy loops in the main thread. You should consider running those loops in dedicated threads, and obviously remove the message processing. 

     

    You code leaks the process handles and has other problems. Duplicating the code is a bad idea. 

     

    You should be using CreateProcess to create processes. 

     

    Fundamentally I would say that your main issue is that copying code without understanding it is a bad idea. You then become unable to maintain it and are unable to critique it. 

    • Like 1

  21. Posted

    1 hour ago, Rudy Velthuis said:

    That is why the new constructors/destructors etc. would be so cool: you can do your own initialization, finalization and copying manually, i.e. your code knows what to do with which field and doesn't have tediously to loop through type info.

    Why would we want to finalize records manually? What a terrible retrograde step. 

  22. Posted

    32 minutes ago, Rudy Velthuis said:

    Well, no compiler without a language. If I don't like the language, it is very unlikely I will gladly use a compiler for it.

    I don't much care what you like, or don't like.

     

    My point was that there exist plenty of compilers that can emit optimised code that is exceedingly efficient, and extremely hard to beat by humans writing code themselves. 

    • Like 1
×