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
Thank you All … I am thrilled :)
I appreciate your support and kind response …
have good time
regards
> On Apr 27, 2017, at 9:37 PM, Saagar Jha wrote:
>
> The issue is that frame and bounds are only known after the initializer is
> run. Properties are set before the initializer, and they
The issue is that frame and bounds are only known after the initializer is run.
Properties are set before the initializer, and they have can’t access frame and
bounds.
Saagar Jha
> On Apr 27, 2017, at 10:32, Mohamed Salah via swift-users
> wrote:
>
> yes I tried self. but it didn’t work as w
For this you’ll want to use computed properties. let isn’t the right choice
since these aren’t constants—they change as the view resizes. Instead, computed
properties using var will work:
extension UIView {
var width: CGFloat { return frame.size.width }
}
That extension will add a width p
yes I tried self. but it didn’t work as well ….
> On Apr 27, 2017, at 9:30 PM, Adrian Zubarev
> wrote:
>
> Have you tried using self.? It’s a good practice to always using self. to
> avoid issues where the compiler might use other globally available
> variables/constants functions.
>
>
>
Have you tried using self.? It’s a good practice to always using self. to avoid
issues where the compiler might use other globally available
variables/constants functions.
--
Adrian Zubarev
Sent with Airmail
Am 27. April 2017 um 19:28:42, Mohamed Salah via swift-users
(swift-users@swift.org
Thanks for your support … here you are the piece of code
import UIKit
class FaceVeiw: UIView {
/* it make error to use frame or bounds outside any functions WHY WHY WHY
*/
let width = frame.size.width // (Gives an ERROR) frame property is not
known here
let width2 = bounds
First of all, the swift-user list is mainly for Swift related question, which
are not related to other frameworks like UIKit. You might find a better answer
at Apple developer forums or on stackoverflow. ;)
Second, this question is too general and not easy to answer without any code of
yours. W
Would you mind sharing the code you’re having trouble with?
Saagar Jha
> On Apr 27, 2017, at 10:22, Mohamed Salah via swift-users
> wrote:
>
> Hi ,
>
> why UIview frame and bounds properties are not seen outside any functions ?
>
> please advise
>
> thank you
> Mohamed Salah
> _
Hi ,
why UIview frame and bounds properties are not seen outside any functions ?
please advise
thank you
Mohamed Salah
___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users
I need to write some license checking code in Swift.
I know Swift is not optimal for that kind of code in the first place, as it is
harder to obfuscate and easier to patch than say, pure C.
But if the code that needs to know whether the app is registered is written in
Swift, this is still better
Hello,
I'm currently working with a fellow githuber on having GRDB.swift, a Swift
library around SQLite, run on Linux:
https://github.com/groue/GRDB.swift/pull/205
To this end, there is a system package https://github.com/groue/CSQLite.git
whose Package.swift specifies that sqlite should be pr
> 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
22 matches
Mail list logo
