Jump to content

David Heffernan

Members
 View Profile  See their activity

  • Content Count

    3710

  • Joined

  • Last visited

  • Days Won

    185

Posts posted by David Heffernan

  4. Posted

    16 minutes ago, Anders Melander said:

    Regardless, if they're aiming for improved FP performance it would make sense to get early feedback from those to whom it actually matters.

    I've spoken to Marco enough times about this. Perhaps they'll have the sense to invite me anyway. 

  6. Posted

    1 hour ago, Steve Maughan said:

    One aspect I appreciate is some attention to the compiler's output. It seems 10.5 will finally get some floating point optimization!!

    I also would be ecstatic if this was delivered effectively. 

    • Like 1

  9. Posted · Edited by David Heffernan 

    try
  Foo := TFooBar.Create;
  ...
finally
  Foo.Free;
end;

    Consider the above. Suppose that TFooBar.Create raises an exception. In that case the finally block is executed, and `Foo.Free` is called on an uninitialised variable (Foo). That leads to undefined behaviour.

     

    So the correct pattern is

      

    Foo := TFooBar.Create;
try
  ...
finally
  Foo.Free;
end;

    Here, if TFooBar.Create raises an exception, the try is never reached, and so the finally block never executes.

     

    Now another pattern was also mentioned

      

    Foo := nil;
try
  Foo := TFooBar.Create;
  ...
finally
  Foo.Free;
end;

    This is also valid, because Foo is initialised before the try executes. And so in case of constructor exception we would call Free on a nil reference which is fine. However, this pattern is pointless and should be avoided in the scenario here where there is just a single object. It is useful sometimes if there are multiple objects and you want to avoid deep nesting.

     

    A better example of using this pattern is if the object is created conditionally:

      

    Foo := nil;
try
  if someTest then
  begin
    Foo := TFooBar.Create;
    ...
  end;
  ...
finally
  Foo.Free;
end;

     

    • Like 4

  10. Posted

    2 hours ago, Jud said:

    I think it should be invisible.

    That would be nice. But in my experience, developing a program to work well with NUMA requires detailed knowledge from the programmer. I personally don't think there is any way round that. 

  13. Posted

    Yeah, NUMA requires a completely different memory allocation strategy. When I faced this problem I concluded that there was no memory manager available that could do what I needed. So I wrote my own that is essentially a wrapper around the Windows heap manager. The trick is to have different heaps for each NUMA node. 

  18. Posted

    1 minute ago, A.M. Hoornweg said:

    Of course there's duplicated code, the whole sense of libraries is that they contain stuff meant to be re-used.  I bet that every DLL of mine carries tStringlist, tButton and a thousand common objects more. It's not the duplication of code that bothers me, it's the big block of non-code I didn't ask for. 

    If you really want to reduce the size of what you deploy then use runtime packages instead of DLLs and you won't duplicate RTL/VCL classes. Likely that would save you far more than you would save by stripping RTTI in the RTL/VCL code that you link, were it even possible for you to do that.

  19. Posted

    1 hour ago, Dalija Prasnikar said:

    If you have many DLLs with bloat is duplicated.

    Why would it be duplicated? Why would the same RTTI be found in different DLLs?

     

    14 minutes ago, A.M. Hoornweg said:

    These DLL's have many code libraries in common. The problem is that the RTTI of those libraries gets linked into every one of them.  It adds up.

    Why are you singling out the RTTI here? Isn't the fundamental issue that you have duplicated code. If the duplication of the code bothers you, don't have duplicated code. And guess what. You then won't have duplicated RTTI.

     

    Or am I missing something?

  25. Posted · Edited by David Heffernan

    1 hour ago, Lars Fosdal said:

    I have an affection for Shell's sort - but it has a weakness as it does not preserve order for equal rows, which is easily worked around - but then again, it is not recursive and does not degrade on already sorted or partially sorted lists.

    Timsort is stable, and performs well on partially ordered data. It's the default sort for Python and Java.

    • Like 1
×