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;

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.

You aren't going to get anywhere by just adding a new library, compiling, running, and hoping for magic. It's going to require in depth understanding if how to configure and use any library and how to adapt your own code.

Just remembered, doesn't FastMM5 have some features to support NUMA? Worth a look.

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.

Can you describe how you want to perform this comparison? How you want to compare the 13 bytes in the array with the single byte in the AnsiChar variable.

Can you be precise about the types here. At the moment all we know is the name of the variables.

Packages do work. If you can't make them work in your setting, that's probably more a statement about the constraints that you are imposing.

Using packages would achieve that

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.

Why would it be duplicated? Why would the same RTTI be found in different DLLs? 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?

Why does it make a difference whether or not the code is in a DLL?

@Stefan Glienke is not suggesting that you use a class method. He's just pointing out that the title of this topic is misleading.

You can read the documentation to find out: http://docwiki.embarcadero.com/RADStudio/Sydney/en/Methods_(Delphi)#Class_Methods

I don't think RTTI doubles or triples the size of your executables. I also think that people worry overly about the size of the executables. Certainly worry about this on mobile platforms, but generally on desktop platforms you should be less concerned of the increases due to RTTI.

Presumably it's because of your RTTI settings, which by default allow public methods to be called from RTTI, but not private.

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

As I read the documentation, I think you are right. Well done. On the home straight now. As I said, this is fundamentally a numpy issue. No doubt a numpy expert would have been aware of this.

No. Python buffer API gives you access to the internal buffer of Python objects. Pass that to Delphi and have your delphi code populate it.

It seems odd to me that you won't use the solution that I outlined above which is known to work. But if you won't entertain that then you are probably asking in the wrong place. Because what you are asking is really a numpy question. I'd ask the question on SO and tag it python and numpy. Doesn't matter at all that the array is from Delphi. It's just an array of double.

You want to do more than this don't you. You want to use numpy methods with this shared data. Is that correct?

What @fjames wants to do in Python is to use numpy without copying data between Delphi and Python. Are you aware of a way to do this with numpy that I have missed?

I don't think there's an easy way to get numpy to use your raw array memory. My initial suggestion, I suspect, is the only tractable way to do this without copying.

Beyond the compilation error which is just a typo, pointless to zeroise the record and then write over those zeros.

Something can't be both a Delphi array and a numpy array. You should do what in said. Work with a numpy array's buffer. You'll access that as a pointer in Delphi. Use pointer math.