On 28 Apr 2017, at 09:10, Quinn The Eskimo! via swift-users
wrote:
> * If the memory is in a zone that uses fixed sized buckets, it may not be
> possible to reduce the memory that you freed by reducing the size
D’oh!
For “to reduce the memory” read "to reuse the memory”. Sorry about the
co
On 28 Apr 2017, at 03:09, Rick Mann via swift-users
wrote:
> Because this runs on iOS, I'd like to reduce the amount of time I hang on to
> memory as much as possible (there's a lot of parallel processing happening in
> our pipeline). I'd also like to avoid copying the data.
>
> The resizing
You will need to take full control over allocation and deallocation.
Here is a piece of code from my project SwifterSockets (on github, see the link
in my signature)
public func tipReceiverLoop(
socket: Int32,
bufferSize: Int,
duration: TimeInterval,
receiver: ReceiverProtocol?)
Yeah, okay. So: how do I do this in a way that is safe?
--
Rick Mann
rm...@latencyzero.com
> On Apr 27, 2017, at 23:00, Rien wrote:
>
> To address your question:
>
> https://developer.apple.com/reference/foundation/data/1779823-withunsafemutablebytes
>
> "Warning
> The byte pointer argument
To address your question:
https://developer.apple.com/reference/foundation/data/1779823-withunsafemutablebytes
"Warning
The byte pointer argument should not be stored and used outside of the lifetime
of the call to the closure."
Which is exactly what you are doing, hence the code is unsafe (no
> On Apr 27, 2017, at 7:31 PM, Rick Mann wrote:
>
>
>> On Apr 27, 2017, at 18:56 , Hooman Mehr wrote:
>>
>> You should be able to type your `dataBuffer ` as [Int8] (Byte array). Then
>> you won’t need `withUnsafeMutableBytes`. You can simply call it like this:
>>
>> self.request = c_library
> On Apr 27, 2017, at 18:56 , Hooman Mehr wrote:
>
> You should be able to type your `dataBuffer ` as [Int8] (Byte array). Then
> you won’t need `withUnsafeMutableBytes`. You can simply call it like this:
>
> self.request = c_library_call(¶ms, dataBuffer) // Call as if it is a C
> array
Hmm.
So, the dataBuffer has a maximum initial size, then I resize it down to the
actual resulting size (the data comes from a sensor and real-world vagaries
change the resulting volume of data). Then it eventually gets passed to
existing Objective-C++ code, and on to C++ code that wants a void* and l
You should be able to type your `dataBuffer ` as [Int8] (Byte array). Then you
won’t need `withUnsafeMutableBytes`. You can simply call it like this:
self.request = c_library_call(¶ms, dataBuffer) // Call as if it is a C array
It works because of C interoperability compiler magic.
As long as th
> On Apr 27, 2017, at 01:48 , Alex Blewitt wrote:
>
...
> The let constant may not even be stored in a single place; if it's known to
> be constant it can be in-lined at the point of use and potentially unpacked
> and dead code elimination throw away the unused members, for example.
>
> If y
> On 27 Apr 2017, at 09:41, Rien via swift-users wrote:
>
>>
>> On 27 Apr 2017, at 09:54, Rick Mann wrote:
>>
>>>
>>> On Apr 26, 2017, at 23:37 , Rien via swift-users
>>> wrote:
>>>
>>> 1) When you obtain a pointer, it can no longer be ensured by the compiler
>>> that you won’t write to
> On 27 Apr 2017, at 09:54, Rick Mann wrote:
>
>>
>> On Apr 26, 2017, at 23:37 , Rien via swift-users
>> wrote:
>>
>> 1) When you obtain a pointer, it can no longer be ensured by the compiler
>> that you won’t write to it.
>> 2) A ‘let’ variable (constant) allows way more optimizations than
> On Apr 26, 2017, at 23:37 , Rien via swift-users
> wrote:
>
> 1) When you obtain a pointer, it can no longer be ensured by the compiler
> that you won’t write to it.
> 2) A ‘let’ variable (constant) allows way more optimizations than a ‘var’. I
> would not be surprised if the majority of ‘l
1) When you obtain a pointer, it can no longer be ensured by the compiler that
you won’t write to it.
2) A ‘let’ variable (constant) allows way more optimizations than a ‘var’. I
would not be surprised if the majority of ‘let’ constants never see any memory
allocation at all.
Regards,
Rien
Sit
Hi Rick,
My understanding on this is that withUnsafePointer() requires an inout argument
because it has to take a reference to the variable in order to be able to
derive its pointer. The languages requires inout arguments to be vars, leading
to withUnsafePointer() requiring the passed object to
We have withUnsafePointer(to:) and withUnsafeMutablePointer(to:). Why does the
first take an inout parameter? The function names imply that the first will not
modify the pointer (which I take to mean its contents), and it makes it quite
clunky to pass in constant things.
--
Rick Mann
rm...@lat
16 matches
Mail list logo