Jump to content

David Heffernan

Members
  • Content Count

    3711
  • Joined

  • Last visited

  • Days Won

    185

Posts posted by David Heffernan


  1. 24 minutes ago, Mike Torrettinni said:

    Thanks! By setting Capacity (vDataList.Capacity := vMax;) I can make it work as efficient as TArray. I was under impression TList has this magical power of handling with memory, I guess it still needs a little help here and there.

     

     

    How could it possibly know how many items were going to be added?

     

    In reality you often don't know this. I would not be surprised if your array code has lots of lines like SetLength(arr, Length(arr) + 1) which are hideously inefficient.


  2. 20 hours ago, David Heffernan said:

    XmlDoc is typically used to document libraries for the benefit of the consumer. But you seem to be talking about internal documention.

    Read this closely. Here I say that I believe that XmlDoc is not suitable because you aren't doing library documentation for the library consumer. So we are on the same page. 

     

    As I expect you know, my work is in the realm of scientific computing. In our case we are simulating the dynamics and loading of pipes and risers. 

     

    We document the technical aspects outside the code, using LaTeX so that we can present formulae in a readable fashion. We then cross reference to that document from the code. This works fine for us. I think once you decide that you need formatted equations then that takes you to a separate document. 

     

    Anyway, that's how we've settled on doing it. 


  3. You don't need to explain what your code is doing. The code ready tells you the what. 

     

    XmlDoc is typically used to document libraries for the benefit of the consumer. But you seem to be talking about internal documention.

     

    I don't see what's wrong with judiciously used comments on the key methods. After all, the vast majority of methods need no internal documentation. 


  4. 58 minutes ago, hsauro said:

    I know it’s off thread, but this sentence piqued my interest, what kinds of defects are you referring to? I used to do more numerical work on Delphi than I do these days but it would still be interesting learn more about these.mmaybe you’ve written them up or mention them somewhere?

     

    I just saw your last reply to someone else who had the same question, I think you answered the question there.

    The most significant issue is that Set8087CW and SetMXCSR are not threadsafe.

     

    It's a bit of effort to fix it because you need to patch things like the code that handles external exceptions, which also interacts with fp unit control state.

     

    I wrote a comprehensive explanation of the issues, and how I addressed them. On request from Emba staff. I submitted that doc as a QC report. Emba then killed QC and asked me to resubmit all my disappeared QC reports. That pissed me off. 

     

    Doc is here 

     

    https://drive.google.com/file/d/0B2MV9dPR57BUbnVvNW0zaEFnYTg/view?usp=drivesdk

    • Like 7
    • Thanks 2

  5. 1 hour ago, Dmitry Arefiev said:

    Could you please provide RSP numbers. May be even you can provide your patch.

    I submitted many QC reports, including one with a detailed document explaining how to make the floating point control word handling threadsafe. These got deleted when QC was killed. I can't be bothered to add them again. 

     

    Marco and David M know about this.


  6. 1 hour ago, Lars Fosdal said:

    By keeping current, you will deal with changes, one version at a time.

    True. But that's not necessarily less work. By batching a few releases together you reduce the number of context switches. That can easily be significant. 

     

    If you do maintenence then you need to maintain a greater number of Delphi installations per dev machine if never skip. 

     

    In my case I have to apply bespoke patch to rtl code to fix all the floating point defects that Emba won't fix. And that requires a chunk of work for every distinct version of Delphi. Skipping reduces that overhead. 

     

    So blanket statements are easily seen to be bogus. It all depends on context. 


  7. 2 hours ago, Lars Fosdal said:

    From my experience, the complexity of dealing with multiple generations of breaking changes has been far more expensive in man-hours than the cost of keeping current.

    This makes no sense to me. You only deal with breaking changes if you keep current. You present an either or choice that's actually a both or neither! 


  8. It costs me time and money to upgrade and for now I'm missing nothing by sticking to XE7. But that's just me. Different users will have different drivers.

     

    Nobody can made a blanket statement like 

    2 hours ago, Sherlock said:

    When given the option to upgrade: Upgrade. Every single version.

     

    • Like 2

  9. It makes no difference to the operation of the code, its just worth being aware of the difference between THandle, which is a handle to a kernel object, and HWND which is a window handle. The Delphi rtl has been a little sloppy over the years distinguishing different handle types so it's not surprising that some of the rubs off. 

×