I am a little curious though as why you are returning the binary buffer data in an internal object format, which can't be used directly in Delphi, but have to be re-allocated in another library..?
From an application developer perspective, are there any uses for a buffer of HCkByteData or are there a way to transfer the data in the buffer without having it reallocated/copied in the CkByteData library ?
I'm thinking something like if the HCkSsh library just returned a pointer to a byte buffer or something, a memory stream even, from a Delphi perspective that would be the "normal" way of doing it..
It just seems to me like a lot of unnecessary memory copying, which in the end will affect the performance of the application, but hey, I can only see things from outside the white box
asked Mar 04 '14 at 10:03
For binary data, Chilkat made a design decision to pass it contained within an object (CkByteData) as opposed to passing a memory pointer directly. In effect, this is really the identical design decision taken by .NET -- where arrays are actually objects. The reason has to do with the ability to provide the identical API across many different programming languages.
It is easy to pass data in without copying by using the borrowData method. When doing this, the CkByteData does not own the data, but simply points to it. If a CkByteData contains borrowed data, and then you try to modify the contents of the CkByteData (such as by appending, or deleting some portion of it), then the data is automatically copied to an internal buffer and modified. In other words, the CkByteData has no ability to modify the external memory that it points to.
Here is sample Delphi code demonstrating it:
procedure TForm1.demoBytes(); const aBytes : array[0..7] of byte = (0,1,2,3,4,5,6,7); var success: Boolean;
answered Mar 04 '14 at 10:10