지난 시간에 이어서 간단한 클래스 예제를 통해서 클래스를 작성하고 활용하는 방법을 살펴보도록 하겠다. 그리고 객체가 가지는 추가적인 비밀스런(?) 메소드나 속성에 대해서도 조금 더 알아보겠다.
개인적으로 데이터나 함수를 묶어두는 용도로 굳이 클래스를 써야하는가에 대해서는 회의적인 입장이다. 모든 객체인스턴스는 속성이나 메소드를 참조하기 위해서는 내부적인 lookup 과정을 거치기 때문에 사실상 사전으로 대체하는 것도 무방하다고 생각한다. 그럼에도 불구하고 이번에는 클래스로 정의해두는 것이 훨씬 더 사용성을 높이고 편리하게 사용될 수 있는 케이스에 대해서 접근해보겠다.
더 보기 »벡터를 클래스로 표현하기 (Python)IJulia는 Jupyter용 Julia 커널로 Jupyter 노트북에서 julia를 사용할 수 있게 해준다. Julia 패키지를 설치하고 빌드하면 현재 버전의 Julia 커널이 자동으로 설치된다. 이 글은 Julia를 제거한 후에 새 버전으로 재설치하면서 IJulia를 새로 설치하는 과정을 정리한 것이다.
더 보기 »IJulia 설치방법
최근에 많이 보게 되는 질문 중 하나가 ‘파이썬은 인터프리터 언어입니까? 컴파일언어입니까?’라는 것이다. 개인적으로 이 질문은 사람을 참 난감하게 하는데, 어떻게 답해야하나에 앞서 아직까지도 이 개념을 이렇게 잘못 가르치는 교재 혹은 과정이 대부분이라는 점 때문이다. 그럼 인터프리터 언어와 컴파일 언어가 무엇인지 알아보고, 과연 파이썬은 인터프리터 언어인지 생각해보자.
참고로, 보통 나는 이 질문에 ‘반만 맞다’고 말하거나 더 이상의 설명이 귀찮은 경우에는 ‘통상 인터프리터 언어라고 합니다.’라고 답한다.
더 보기 »파이썬은 인터프리터언어입니까?한글 문자열의 초/중/종성을 분리하는 예제를 포스팅한 적이 있는데, 이 때는 미처 알지 못했지만, 중요하게 놓친 문제가 있다. 그러니까 초/중/종성에 해당하는 자모와 각각의 낱자가 다른 글자라는 점이다.
예를 들어 ‘한'(U+D55C)자를 보자. 이 글자는 ‘ㅎ’, ‘ㅏ’, ‘ㄴ’ 의 세가지 자모로 분리된다. 이 때 ‘ㅎ’이 초성일 때와 종성일 때에는 같은 ‘ㅎ’으로 보이기는 해도, 같은 코드가 아니다. (그리고 지금 ‘ㅎ’으로 낱자로 쓰고 있는 이 글자 역시 같은 코드가 아니다.
‘ㅎ’을 표현하는 방식에는 다음 세 가지 방식이 있다.
이는 유니코드에서는 완성형과 조합형 한글을 모두 지원하기 때문이다. ‘가’에서부터 ‘힣’에 이르는 자모로 조합가능한 모든 한글글자는 Hangul Syllables 블럭에 정의되어 있다. 그리고 이러한 Syllables를 조합하는데 사용되는 자모들은 모두 Hangul Jamo에 정의된다. 낱자로서의 자모는 Hangul Compatibility Jamo 에 정의되어 있다. 기존의 초성 구하기 코드에서 구하는 답은 자모 코드에 해당한다.
이 자모 코드는 기본적으로 서로 결합하여 완성된 글자(Hangul Syllables)를 구성하는데 쓰인다. 따라서 자모 문자의 코드값으로부터 문자를 얻어서 출력했을 때에는 각 자모 낱자의 출력결과와 구분할 수 없기는 하나 정확한 답이 아닌 것이다.
더 보기 »한글의 음소분리 문제클래스를 설명할 때 흔히 쓰는 표현은 ‘클래스는 거푸집에 해당하고 객체는 그 거푸집으로 찍어내는 벽돌에 해당한다.’는 것이다. 물론 완전히 틀린 설명은 아닌데, 이 개념에서 출발해서 클래스를 이해하는 것은 객체와 클래스의 관계와 클래스를 어떻게 다룰 것인지 등 여러 관점을 정립하는데 많은 어려움을 유발한다.
이 글은 파이썬 초보자들이 클래스에 대해 접근하고 이해하는데 도움을 주고자 작성됐다.
파이썬에서 통용되는 가장 중요한 대전제는 모든 것이 객체라는 것이다. 1, 2와 같은 숫자값도 C처럼 원시값이 아니라 int 타입의 객체이다. 함수 역시 객체이고 모듈이나 패키지도 객체처럼 취급된다. 모든 것이 객체라면, 클래스 그 자체도 객체라는 말이된다. 그럼 이 시점에서 다시 한 번 되물어보자. 도대체 객체란 무엇인가?
더 보기 »[Python] 클래스 이해하기https://developer.apple.com/documentation/swift/unsaferawpointer
UnsafeRawPointer 타입은 자동 메모리 관리, 타입 안정성 및 메모리 정렬 보장이 되지 않는 원시 포인터 액세스를 제공합니다. 이 타입을 사용하려면 누수를 피하고, 할당된 메모리의 라이프 사이클을 직접 관리해야 하며, 그 외의 정의되지 않는 동작들을 회피해야 합니다. 수동으로 직접 관리하는 메모리 영역은 특정한 타입에 바운드되거나, 타입이 지정되지 않을 수도 있습니다. 메모리 영역에서 해당 영역이 특정 타입에 묶여있는지 여부와 무관하게 순수 바이트를 액세스하려할 때 UnsafeRawPointer 타입을 사용할 수 있습니다.
막 할당된 Raw 메모리는 타입화되지도 초기화되지도 않은 상태입니다. 이 메모리는 타입화된 연산을 사용하기 전에 반드시 초기화되어야 합니다. (초기화되려면 초기값을 가져야하고, 이는 타입화를 수반해야한다는 의미가 됩니다.) 초기화되지 않은 상태에서 특정 타입에 바인등하려면 bindMemory(to: count:)를 사용합니다. 이 메소드는 타입화된 포인터를 반환하며, 이후에는 해당 포인터를 사용해야 합니다.
C에서 특정한 T타입의 배열은 메모리 상에서 연속적인 공간입니다. 이 때문에 정적 배열이든 동적 배열이든 배열을 액세스하는 것은 필연적으로 포인터와 관련됩니다. 반면 Swift의 배열에서 원소들은 반드시 이런 식으로 배치되지는 않습니다. C의 배열이 단지 원소값이 나란히 배치된 메모리 영역임에 비해 Swift의 배열은 struct로 구성되는 보다 복잡한 내부 구조를 가지고 있습니다.
이 때 T 타입이 차지하는 바이트 수가 고정되어 있으므로 배열의 시작번지와 인덱스 값을 알고 있다면 해당 인덱스에 위치한 값을 액세스할 수 있습니다. C에서 배열 이름은 암묵적으로 배열의 시작번지를 의미하므로, arr[i]로 표현되는 i 번째 원소의 값은 실제 컴파일러는 *(arr + i) 로 변환하여 접근합니다.
Swift에서도 UnsafePointer를 사용하여 포인터를 다룰 수 있는데, 이 때 범위(capacity, Pointee 타입의 메모리 사이즈 x 원소의 개수)내에는 동일타입을 구성하는 값들이 연속하여 배치되어 있습니다. 따라서 (ptr + i).pointee 와 같은 식으로 i 번째 원소에 대해 액세스가 가능합니다. 이것은 C의 접근방법과 매우 유사합니다. 하지만 이것은 단순한 메모리 연속체에서 특정 지점을 액세스하는 법일 뿐, Swift의 배열을 다루는 것과는 차이가 있습니다. Swift의 배열은 원소가 연속해있으면서 Sequence, Collection 프로토콜에 의한 여러가지 연산을 지원받습니다.
그 옛날(?) ARC가 없던 시절에 Objective-C 및 코어 파운데이션에서 객체에 대한 참조수 관리는 완전한 수동 방식에 의존하고 있다. 어떤 객체에 대한 retain(참조수를 늘리는 것) 동작은 반드시 그에 수반하는 release(참조수를 내리는 것) 동작을 필요로 했다. 그리고 이 짝이 제대로 맞지 않으면 객체는 필요한 시점에 사라지고 없거나, 반대로 메모리 누수가 발생했다. 그러던 중 자동 참조수 카운팅(ARC)이 도입되었는데, ARC 환경에서는 모든 retain/release/autorelease 콜이 컴파일러에 의해 코드에 자동으로 삽입되었다. 이는 전체적인 코드량의 감수는 물론 개발 난이도를 매우 낮춰주는 역할을 했다.
ARC가 도입된 이후 Objective-C 메소드에 의해 반환되는 모든 Objective-C 객체와 코어 파운데이션 객체의 메모리 관리는 자동으로 이루어졌다. 하지만 C 함수에 의해 리턴되는 코어 파운데이션 객체는 이러한 은혜를 받지 못했다. 따라서 여기에 속하는 객체들에 대해서는 여전히 CFRetain(), CFRelease()를 호출하거나, __bridge*로 시작하는 함수를 통해 Objecitve-C 객체로 브릿징해야 했다.
Swift는 C API와의 상호작용 혹은 고성능 자료구조의 구현등을 위해 포인터를 통한 메모리 액세스를 제한적으로 지원하고 있습니다. 기본적으로 Swift 타입 혹은 Swift 에서 인식할 수 있는 C 타입에 대한 포인터는 ‘타입화된(typed)’ 포인터라고 하며, UnsafePointer를 사용합니다. UnsafePointer는 제네릭 struct 타입으로 특정 Swift 타입에 대한 포인터로 기능합니다. UnsafePointer는 메모리 주소를 통한 액세스를 허용해주기는 하지만 값의 불변성을 보장하기 때문에 해당 포인터가 가리키는 값(pointee)를 변경하는 것을 허용하지 않습니다. 변수에 대한 포인터는 UnsafeMutablePointer를 별도로 사용합니다.
Operation(NSOperation)은 특정한 작업을 수행하기 위한 코드와 데이터를 감싸는 객체로 해당 작업을 동기/비동기로 필요한 시점에 실행하기 위한 용도로 사용한다. NSOperation은 OSX 10.5에서도입되었는데, 이 시점의 Objective-C에서는 클래스의 외부에서 코드를 주입할 수 있는 언어적인 장치가 존재하지 않았기 때문에, 이를 사용하려면 무조건 NSOperation의 서브클래스를 만들어야 하는 불편한 점이 있었다. 따라서 간단한 코드 조각을 실행하기 위해서 NSOperation을 사용하는 것은 꽤나 불편한 일이었다.
OSX 10.6(스노우레퍼드)부터 GCC/Clang을 기본 컴파일러로 사용하게 되었고 이때부터 코드블럭 기능이 지원되었다. 즉 별도의 서브클래스를 작성하지 않더라도 코드 블럭의 형태로, 마치 클로저처럼 코드와 코드가 캡쳐링하는 데이터를 주입하여 오퍼레이션 인스턴스를 만드는 것이 가능해졌다. 실질적으로 NSOperation을 그대로 사용해야할 이유는 현재로서는 찾아보기 힘들다.
더 보기 »Swift – BlockOperation 사용하기