암묵적 언랩 옵셔널 타입이 함수의 인자로 오는 경우 (Swift)
암묵적으로 언래핑되는 옵셔널 타입은 흔히 옵셔널이 아닌 것처럼 쓰는 트릭이라고 혼동하기 쉬운데, 실제로는 엄연한 옵셔널타입이다. 이를 적절하게 사용하는 방법에 대해서 알아본다.
OpaquePointer
OpaquePointer OpaquePointer는 Swfit2.x 에서 COpaquePointer가 이름이 바뀐 타입으로 불투명한1 C 포인터를 감싸는 래퍼 타입이다.1 타입을 반입할 수 있는 구조체의 포인터라면 원 구조체 Tc타입을 Swift 로 반입할 수 있고, 이 경우에는 UnsafePointer<Tc> 의 형태로 쓸 수 있다. 하지만 원 타입을 Swift가 이해할 수 없다면, 그 타입의 크기를 결정할 수 없으므로 이에 대한 포인터 역시 Swift 내부에서 결정하는 것은 어렵다. 물론 UnsafePointer<Void> 타입을 이용하는 것도 가능하다 생각할 수 있지만, 이 경우에는 C에서 void * 타입이며, 어찌됐든 pass 시점에 캐스팅해야 하는 한계가 있다.… 더 보기 »OpaquePointer
SQLite3 C API를 Swift에서 사용하는 방법
Swift에서 SQLite3를 사용하는 방법은 크게 두 가지이다. 하나는 Objective-C에서 SQLite3를 액세스하는 래퍼 클래스를 작성하고, 이 것을 Swift 프로젝트에 포함시켜서 컴파일하는 것이다. Swift는 Objective-C와 자연스럽게 상호호환되기 때문에 Objective-C에 친숙하다면 이 방법도 나쁘지 않다.
관련글 : Objective-C 래퍼를 통해 Swift에서 SQLite3를 사용하는 법
다른 한가지 방법으로는 sqlite3.h 헤더를 Swift에서 반입하여 Swift에서 SQLite3 C API를 바로 사용하는 것이다. 결국 업어치나 메치나 똑같은 것이기는 한데, Swift에서 C API를 직접 사용하는 것은 Swift와 C의 연계 방식에 대한 이해가 필요하다. 이 글에서는 Swift에서 Sqlite3를 사용하기 위해 필요한 배경 지식들에 대해서 살펴볼 예정이다. SQLite3 API에 대한 자세한 설명이 필요할 수 있는데, 이 내용은 Objective-C에서 SQLite3를 사용하는 법을 다룬 위 링크에서 대략 소개하고 있으며, 이 글에서는 최소한 SQLite3 API에 대해 알고 있다고 전제하겠다.
SQLite3 C API를 사용하여 쿼리를 실행하는 결과에 대해서는 다음의 과정을 거친다.
- 데이터베이스 연결
- 쿼리 컴파일 및 쿼리 바인딩
- 쿼리 실행 및 각 Row의 데이터 획득
- 연결닫기
(Swift) 에러 핸들링 기법
에러 핸들링은 프로그램 내에서 에러가 발생한 상황에 대해 대응하고 이를 복구하는 과정이다. Swift는 에러를 던지고, 캐치하고, 이전하며 조작할 수 있는 기능을 언어의 기본 기능으로 지원한다.
어떤 동작들은 항상 유용한 결과를 내놓거나 완전하게 실행되는 것이 보장되지 않는다. 결과가 없는 경우에 이를 표현할 수 있는 옵셔널 타입을 사용할 수도 있지만, 처리 자체가 실패하는 경우, 어떤 원인으로 실패하였는지를 알면 코드가 이에 적절히 대응할 수 있도록 할 수 있기에 그 원인을 하는 것은 유용하다.
예를 들어 디스크상의 파일로부터 데이터를 읽고 처리하는 작업을 생각해보자. 여기에는 작업이 실패할 수 있는 경우가 꽤 많다. 주어진 경로에 파일이 존재하지 않거나, 파일을 읽을 수 있는 권한이 없거나 혹은 파일이 호환되는 포맷으로 인코딩 되어 있지 않을 수도 있다. 이런 상황들을 구분하는 것은 프로그램으로 하여금 에러를 스스로 해결하거나, 자동으로 해결할 수 없는 에러에 대해서 사용자에게 보고할 수 있게끔 한다.더 보기 »(Swift) 에러 핸들링 기법
클로저 내부에서 self를 캡쳐하는 방법 – Swift
항상 [unowned self]를 써야 할까요?
http://stackoverflow.com/questions/24320347/shall-we-always-use-unowned-self-inside-closure-in-swift 의 내용중 일부를 번역하였습니다.
아니오, 분명히 [unowned self]를 쓰지 말아야할 상황이 존재합니다. 특정한 클로져가 호출되었을 때에 그 시점까지 self가 파괴되지 않고 살아있음을 보장할 필요가 있을 때가 있단 말이죠. 예를 한가지 들어봅시다. 비동기 네트워크 요청을 하고, 요청에 대한 응답을 받았을 때 self로부터 어떤 무언가를 호출해야 한다고 가정해봅시다. 비동기 요청이 끝나는 시점 이전에 해당 객체가 해제되어 사라졌다면
프로그램이 뻗고 말겁니다.
그렇다면 언제 unowned self 나 weak self를 써야하는가? 바로 강한 참조 사이클이 만들어질 때입니다. 이는 두개 이상의 객체가 서로 순환하면서 서로를 순서대로 참조해나갈 때 생길 수 있습니다. 이 경우 사이클 내의 객체들은 어떤 경우에도 항상 참조수 1 이상을 갖기 때문에 파괴되지 않고 리소스를 낭비하게 됩니다.더 보기 »클로저 내부에서 self를 캡쳐하는 방법 – Swift
Swift Array의 메소드, flatMap에 대해 알아보자
flatMap에 대해서 뭔지 모르겠다는 이야기들이 들려와서 나름대로 한 번 정리해본다.
더 보기 »Swift Array의 메소드, flatMap에 대해 알아보자
Swift의 프로퍼티에 대한 이해
프로퍼티(property)는 직역하자면 “재산”, “소유물” 등으로 번역되는데, 보통은 속성이라고 번역하여 쓰는 것이 일반적이다. (“속성”이라는 의미의 attribute와 혼동이 있을 수 있지만, 일단 언어의 기능으로 한정했을 때에는 크게 상관은 없을 것 같다.) 프로퍼티는 클래스나 구조체 혹은 열거체(enum 타입)의 객체 인스턴스가 그 내부에 가지고 있는, 객체의 상태에 관한 정보를 말한다. 이렇게 말하면 Swift의 프로퍼티는 마치 C 구조체의 멤버 변수와 다름 없다고 생각될 수 있는데, 조금 차이가 있다. Swift의 프로퍼티 개념은 Objective-C의 선언 프로퍼티의 개념을 이어 받은 것이라 볼 수 있다. 따라서 프로퍼티에 대해 생각할… 더 보기 »Swift의 프로퍼티에 대한 이해
SKNode를 이름으로 찾기 – SpriteKit / Swift
SKNode의 트리탐색
씬의 노드트리에서 어떤 노드를 탐색하고 특정하는 일이 종종 필요한데, 상위 노드에 대한 참조만 가지고 하위 노드를 찾기 위해서는 각 노드에 미리 이름을 부여하는 것이 필요하다. 노드의 .name 프로퍼티는 노드의 이름을 저장하며 알파벳과 숫자로만 이루어지며 공백이나 구두점등은 포함해서는 안된다.
노드의 이름은 중복되어도 상관없다.
playerNode.name = "player"
monsterNode1.name = "goblin"
monsterNode2.name = "ogre"
위 예에서 게임에 등장하는 고블린이 여러마리라면 이 고블린 노드의 이름은 제각각 유니크하기가 힘들것이며, "goblin"이라는 공통의 이름을 갖게 된다. 하지만 플레이어 캐릭터는 게임내에서 유니크하므로 다른 노드와 이름이 중복되지 않아야 한다.
더 보기 »SKNode를 이름으로 찾기 – SpriteKit / Swift
(Swift) – 힙(Heap) – 자료구조에 대해
heap은 일종의 바이너리 트리를 단일 배열을 이용해서 구현한 구조로, 부모 자식 간의 직접적인 참조를 갖지 않고 배열의 인덱스에 의해서 위치 관계를 파악한다. 특히 내부 배열의 상태는 부분적으로 정렬되는 것과 비슷한데, 항상 “맨 앞의 원소를 꺼내었을 때 그 값이 최대 혹은 최소가 된다”는 특성을 가진다. 힙은 흔히 최대힙과 최소힙으로 구분하는데 이는 동일한 것이며 단지 정렬 순서만 다르다. 주로 자료 구조에서는 최대/최소 힙, 바이너리 힙, 힙 큐 혹은 우선순위 큐와 같은 이름으로 불린다.
참고로 이 자료 구조의 파이썬 구현은 [우선순위 큐 혹은 최소/최대힙]에서 한 번 설명한 바 있다.
힙으로 할 수 있는 일은 다음과 같다.
- 우선순위 큐를 만든다.
- 힙 정렬 수행
- 변경가능한 집합의 최소값(혹은 최대값)을 빈번히 계산해야 할 때 유용하다. (특히 최단거리 탐색 시)
꼬리재귀와 트램폴린
꼬리 재귀(tail recursion)는 함수가 내부에서 자신을 재귀 호출할 때, 재귀 호출한 결과를 그대로 리턴하는 모양을 만드는 것이다. 이는 return 구문의 모양에 의해서 쉽게 판별할 수 있고, 재귀 호출의 결과 값에 대해서 추가적인 처리를 하지 않기 때문에 컴파일러가 쉽게 최적화할 후 있다. 재귀 호출의 결과를 그대로 사용한다는 것은, 재귀 호출을 수행하는 시점에 함수 내부의 지역 변수를 더 이상 사용하지 않는 것을 의미하므로 함수 호출에 의한 새로운 스택 프레임을 생성하는 대신, 현재 스택 프레임을 재활용할 수 있다. 따라서 꼬리 재귀는 반복 연산의 모양으로 변환이 가능하며, 이 과정은 기계적으로 처리될 수 있다.
꼬리 재귀는 컴파일러가 꼬리재귀 최적화를 지원하지 않는다면, 재귀 깊이에 한계가 있다는 단점이 있다. 따라서 재귀 호출 자체를 직접적인 반복문으로 변경할 수 있도록 재귀 호출을 수행할 함수를 리턴하는 것으로 스택 오버플로우를 회피할 수 있다.
더 보기 »꼬리재귀와 트램폴린