BLOG main image
분류 전체보기 (92)
Cocoa Touch (11)
Cocoa (10)
Objective-C (13)
Swift (6)
Development (11)
Tools (11)
Books (7)
etc (21)
Application release (1)
Document Project (1)
105,857 Visitors up to today!
Today 1 hit, Yesterday 1 hit
daisy rss
tistory 티스토리 가입하기!
'Objective-C 2.0'에 해당되는 글 4건
2008. 11. 26. 16:52
Objective-C 2.0에 "@package" 이런 놈이 추가 되었다.
뭔가 했는데 아주 나쁜 놈이다. 이제 프래임웍 안을 휘젓고 다니지 말라는 거군.
그럴거면 필요한 옵션기능 좀 제대로 할 수 있게 해주던가...
간단히 말하면 프래임웍 안에서는 @public으로 프래임웍 밖에서는 @private로... 서브클래싱 해도 맴버 변수 맘대로 가지고 놀기 힘들겠구나... 쩝...

오늘 따라 애플이 사람을 계속 열 받게 만든다.
littlehj | 2008.11.27 16:11 신고 | PERMALINK | EDIT/DEL | REPLY
또 하나의 나쁜 놈을 알게 됐넹? ㅋㅋ
근디 요즘 뭐하냐? 아이챗에서도 통 안보이고...
maccrazy | 2008.11.28 09:44 신고 | PERMALINK | EDIT/DEL
빡세게 일 하지요. ㅡ.ㅡ;; 메신저는... 회사에서... 흑...
정승욱 | 2008.11.27 20:07 | PERMALINK | EDIT/DEL | REPLY
지금 회사에서도 썸네일 뷰 만들줄이야.. 아고고.. 저를 스크롤해주세요
maccrazy | 2008.11.28 09:45 신고 | PERMALINK | EDIT/DEL
ㅋㅋㅋ 인생이라 생각하세요. :)
아이폰용 썸네일 뷰면.. 너무 작지 않나요?
레이어와 스크롤 뷰 적절히 이용하면 뭐... 어렵지 않을듯 한데요..
littlehj | 2008.11.30 19:07 신고 | PERMALINK | EDIT/DEL | REPLY
ㅎㅎㅎ....올초도 썸네일뷰 올말도 썸네일 뷰~ 승욱이 팔자는?
박종암 | 2008.12.06 13:56 | PERMALINK | EDIT/DEL | REPLY
Java의 냄새가....
Name
Password
Homepage
Secret
2008. 8. 26. 12:23
Objective-C 2.0에 추가된 기능 중 가장 큰 것이 Garbage Collector(GC)가 아닐까 하는데 사실 나도 retain/release가 손에 익어서 그런지, GC가 못 미더워서 그런지, 그것도 아니면 호환성 때문인지 아직은 사용하지 않고 있는 기능 중 하나이다.
Objective-C 2.0의 GC는 몇개의 구분된 generation을 기준으로 reclaim을 하는데 이는 대부분의 객체는 임시로 생겼다가 바로 사라진다는 사실을 기반으로 하고 있다. 뭐, 맞는 말이다. 즉, 그렇기 때문에 임시 객체의 소멸은 매우 빠르게 진행되겠지만 오래된 객체의 경우 그 반대일 수도 있다는 이야기가 되는것 같기도 하고... 아직 확인 해보지는 못했다. 이것을 설명할 때 사용되는 용어 중 하나가 "Write-Barriers"이다. 쓰기 울타리? 무슨 말이지?
앞서 이야기 했듯이 GC가 메모리를 몇개의 generation으로 나누어 관리한다. 만일 새로 생성된 객체가 오래된 객체의 영역으로 저장되면 write-barrier는 그것을 표시해두는 역할을 한다. 가비지 컬렉팅이 요구될 때 이미 표시된 객체들이 계속 사용되는지 확인하고 보다 오래된 영역으로 옮기고 사용되지 않는 새 객체들은 모두 제거 된다.
이때 실제 동작되는 모양을 들여다 보면 대입연산자들이 objc_assignIvar나 objc_assignGloabl같은 helper function으로 대체되어서 작동된다. 즉, 약간의 오버헤드가 걸리는데 애플은 이 함수들이 매우 빠르다고 주장하고 있다. :)
밀리네스 | 2008.08.26 12:59 | PERMALINK | EDIT/DEL | REPLY
애플도 자바 vm을 만드니까 자바에서 그동안 발전되어온 gc 코드를 가져다 쓰면 되지 않을까 싶네요.
뭐 썬이 주장하기로는 jvm에 사용되는 jit나 gc는 예술의 경지에 이르렀다고 하고, 실제로 성능도 상당히 나오는 편이니까요. ^^
박종암 | 2009.05.06 01:23 | PERMALINK | EDIT/DEL | REPLY
Garbage Collector는 아니지만, autorelease pool이 관리되는 것도 다르네요?
Tiger에서 버그가 있어서, 디버깅을 해 봤는데, 하나를 그냥 stringWithFormat과 같은 함수로 생성된 NSString객체를 그냥 한 클래스의 내부 변수에 할당을 한게 있는데, 그 클래스의 인스턴스가 release가 되지 않았는데도 Tiger에선 release되더군요. Leopard에선 아무런 문제가 없는데 말이죠. Tiger에서 쓰던 obj-c RunTime이 클래스의 유효성 유무와 상관없이 release를 시킨다는건데..

아.. 은근스레 Tiger하고 Leopard하고 다른게 꽤 있어서, 다 관리하는게 좀 복잡하네요. :)
Name
Password
Homepage
Secret
2008. 7. 30. 15:26
Fast enumeration은 Objective-C 2.0에 새로 추가된 기능 중 하나인데 컬렉션의 모든 맴버를 접근하는 쉽고 간단한 방법이며 NSEnumeration보다 빠르게 작동할 뿐 아니라 코드도 더 읽기 쉽다.
아래와 같이 간단하게 사용할 수 있다.
무엇보다 큰 장점은 실수로 바운더리를 벗어나는 억세스를 만들어 내지 않고 안전하게 enumeration할 수 있다는 점이다. 멀티 쓰레드 환경에서 동시에 enumeration 할 수 있지만, 만일 enumeration 중에 값이 변경되면 익셉션을 발생시킨다.
NSFastEnumeration 프로토콜을 지원하는 모든 컬렉션(NSArray, NSDictionary, NSSet, NSEnumerator)에서 사용가능하다.
만일 직접 만든 컬렉션에서 fast enumeration을 지원할려고 하면 NSFastEnumeration 프로토콜을 지원하면 된다.

자, 그럼 커스텀 컬렉션에서 fast enumeration을 지원하는 방법을 알아보자.
MyCollection이라는 새로운 컬렉션을 하나 만들고 메인 코드를 다음과 같이 작성하고 빌드를 했다.
어라.. 아래와 같은 워닝이 발생한다. 당연하지. 아직 프로토콜을 구현하지 않았다.

/Users/cgkim/FastEnumTest/FastEnumTest.m:11: warning: 'MyCollection' may not respond to '-countByEnumeratingWithState:objects:count:'

자 다음 코드를 보자. 프로토콜을 지원하기 위해 MyCollection안에 새로 구현한 메소드이다.
이게 조금 복잡해서 일단 파라메터를 2개로 나눠서 생각해야 한다.

먼저 NSFastEnumerationState라는 구조체가 있고 id *인 aStackbuf와 NSUInteger인 aLen이 있다.일단 뒤에 두 파라메터는 사용하지 않겠다.
aState->state안에는 현재 어디까지 enumeration했는지에 대한 정보가 들어있다. 단순히 C 어레이를 이용했으니 그 값은 그냥 인덱스로 사용하겠다. 처음 countByEnumeratingWithState... 메소드가 불리면 0이 들어있을 것이다.
처음 불렸을 때 aState->state 안에 돌려 줄 아이템의 갯수를 넣는다. 그리고 itemsPtr에는 아이템이 들어있는 C 어레이를 넣는다. 그리고 mutationsPtr에는 self를 넣어주면 되겠다.
그리고 마지막으로 리턴 값으로는 몇개의 아이템을 넣어보내는지 알려주면 된다.

자, 그럼 뒤에 두 파라메터는 언제 쓰는가?
만일 컬렉션 안에 C 어레이 형태의 스토리지가 없다면, 뒤에 딸려오는 두개의 파라메터를 이용하면 편할 것이다. 먼저 aLen에는 aStackbuf의 크기가 오는데 객체를 aStackbuf안에 최대 aLen만큼 넣어주면 된다.
그리고 aState->state는 어디까지 enumeration했는지에 대한 정보를 aState->itemsPtr에는 aState를 aState->mutationsPtr에는 self를 넣어주면 된다. 그리고 리턴 값은 처음의 경우와 동일하게 몇개의 아이템을 넣어보냈는지 알려주면 된다. 별도의 코드는 작성하지 않겠다.

이것이 별로 마음에 들지 않는 이유 중 하나는 편의를 위해서 랭귀지를 임의로 확장했다는 것이고 다른 하나는 랭귀지의 확장이 랭귀지에서 그치지 않고 프레임웍(NSFastEnumeration)과 연결되어 버렸다는 점이다. 랭귀지의 특정 기능을 이용하기 위해서 더 상위개념인 프레임웍을 반드시 이용해야 하는 상황이 이상한 것은 나 뿐인 것인지 궁금하다.
홍민희 | 2008.07.30 16:00 | PERMALINK | EDIT/DEL | REPLY
프레임웍이 언어의 일부라고 본다면 이상하지 않을 수도 있지요. 실제로 Python, Ruby, Java, C# 등의 많은 언어가 특정 인터페이스를 구현하면 언어 구조로 제공되는 for, foreach 문 따위를 사용할 수 있게 해놓았습니다. Objective-C 같은 경우에도 모든 클래스는 NSObject 클래스를 상속받아야 한다는 스펙이 이미 있지 않았나요?
maccrazy | 2008.07.30 17:25 신고 | PERMALINK | EDIT/DEL
프레임웍을 언어의 일부로 봐야 할지는 조금 더 논의가 있어야 하겠지만 Objective-C에서 모든 클래스가 꼭 NSObject로 부터 상속 받아야 하는것은 아닙니다. 예로 NSProxy같은 것은 그 자체로 루트 클래스이죠. NSObject 이외에 다른 루트 클래스도 있을 수 있다는 것이죠. 물론 NSObject가 구현해놓은 많은 것들을 직접 구현해야 한다는 괴로움이 있지만 가능은 합니다.
예를 들어주신 많은 언어들이 비슷한 방식을 사용하고 있지만 마지막에 제가 이야기 한 부분은 그게 정말 맞는 접근 방법일까 하는 것이죠.
좀 고전적인 언어로 비교하면 이상하겠지만, MFC가 C++ 자체의 일부가 아닌것 처럼 프레임웍이랑 언어는 때 놓고 보는게 맞지 않냐는 것이지요.
어떤 프레임웍이 꼭 특정 언어만으로 사용되지도 않고 (Cocoa가 루비나 파이썬 같은 언어로 코딩될 수 있는것 처럼) 또, 만일 저런 식의 확장이 계속 된다면 다른 어떤 플랫폼에서 Objective-C를 사용하고 싶어도 프래임웍까지 줄줄 끌고 오지 않으면 그 기능을 다 쓸 수 없다는 것도 문제가 될것 같군요.
박종암 | 2008.07.30 21:45 | PERMALINK | EDIT/DEL | REPLY
framework은 언어의 일부로 절대 볼 수가 없습니다.
framework은 전통적으로 library로 볼 수있는데, 전통적인 것과의 다른 점은 library + 연관된 리소스인 것이죠.

홍민희 님 안녕하세요? 제가 egloos에 있을때, 종종 들어오시던 분이네요.
han9kin | 2008.07.30 23:33 신고 | PERMALINK | EDIT/DEL | REPLY
maccrazy님은 프레임웍과 프로그래밍언어가 같이 섞이는 것이 말도 안되고 이상하게 생각되나 봅니다. 흐흐..
뭐, 종암님말씀처럼 프레임웍을 전통적으로는 라이브러리처럼 보신다면 그렇긴 하죠.. 하지만. 꼭 그런 건 아니라 생각됩니다.
저도 잘은 모릅니다만, Ruby on Rails와 같은 경우 이미 프레임웍과 언어의 경계가 모호해져있는 상황인 것 같구요. 코코아와 Objective-C도 사실은 이미 이런 경계가 거의 무너졌는데 인정을 안하고 있었던 것 뿐이 아닐까 생각합니다.
그리고, 말씀하신 NSObject와 NSProxy... 맞는 말씀입니다만, 애플의 코코아에서 NSObject와 NSProxy이외의 루트클래스를 만들 수 있습니까? 가능하지 않은 것으로 압니다만...
마지막으로, Objective-C 2.0의 fast enumeration 기능상, 편의상 좋은것은 인정합니다만, 속도가 더 빠르다라는 증거가 있나요? 왠지, 애플의 광고일 뿐일 것 같다는 생각이 듭니다. 제가 간단한 테스트를 해봤었거든요. 속도차이를 별로 못 느끼겠다라는... 너무 간단한 거라서 그런가요?
박종암 | 2008.07.31 13:33 | PERMALINK | EDIT/DEL
제가 보기에도.. 언어를 프레임워크랑 밀접하게 연결시켜버린 것은 좀 아니라고 생각이 듭니다.
그런데 한편으론 이해가 가는 면이 있어요.
우선은 Objective-C이 minimalism을 표방하기 때문에, 가능한 언어 자체를 안바꾸고 편의를 제공한다라는 면이 있겠구요. 그러다보니 프레임워크의 도움을 받았다라는... 그리고 gcc에서 objective-c는 그다지 활동이 활발하지 않다는..
근데 조만간 Apple이 Objective-C 2.0을 GNU의 gcc에 반영한다고 했는데, 현재 어떤 상태인지 모르겠네요. 반영하게 되면 이 fast enumeration이 어떻게 될지 궁금해집니다.
maccrazy | 2008.07.31 14:05 신고 | PERMALINK | EDIT/DEL
Objective-C 2.0 문서에서 발췌한 내용입니다.
만들기 힘들다는 말은 있어도 못 만든다는 말은 없죠. :)

Note: Implementing a new root class is a delicate task and one with many hidden hazards. The class must duplicate much of what the NSObject class does, such as allocate instances, connect them to their class, and identify them to the runtime system. For this reason, you should generally use the NSObject class provided with Cocoa as the root class. For more information, see the Foundation framework documentation for the NSObject class and the NSObject protocol.
박종암 | 2008.07.31 13:22 | PERMALINK | EDIT/DEL | REPLY
에.. Ruby on Rails가 그런가요? 글쎄요. Cocoa와 Objective-C는 거의 둘을 떼고선 생각할 수가 없을 정도가 되었다는 면에선 그렇겠지만, 사실 Cocoa만 쓸 필요는 없는거잖아요? 어떻게 하다보니, 그게 주된 프레임웍이 된 것일 뿐이죠. 그렇다면.. Ruby Cocoa binding이 되면 Cocoa는 Objective-C에 속하는건지, ruby에 속하는 건지... F-Script같은 경우는 또 어떤지..
어떤 면에선 이런 구분이 의미가 있을지는 모르겠지만..

그리고 NSObject외에 루트 클래스를 만들 수있는지에 대해선.. 만들 수있는거죠. Apple이 하는 식으로 하면 되는거죠. 혹은 잘 아시다시피 GNUStep의 그것대로 만들어도 될거구요.
사실 이 쪽에 대해서 제가 예전에 블로깅을 했는데.. 뭐 아주 기술적인 이야기는 아니구, 가쉽 말하듯이 했죠. http://jongampark.wordpress.com/2008/05/02/objective-c-without-cocoa/

그리고 Fast Enumeration은.. 더 빠르다고 합니다. 예전에 어디서 읽었어요. 속도 테스트까지 했구요. 항상 빠르진 않았던거로 기억합니다. 이유가 뭐였더라....
han9kin | 2008.07.31 16:46 신고 | PERMALINK | EDIT/DEL | REPLY
죄송합니다. 제가 헛소리를 좀 했군요.
maccrazy님께서 제 코멘트를 보고 루트클래스를 만들다가 살짝 열받으신 모양인데.. ㅋㅋ
어떻든 루트클래스 자체를 만드는 건 쉽네요. 다만, 돌아가게 할려면 NSObject protocol을 구현해야하는 등 삽질을 해야하겠지만...
그리고, 저는 개인적으로 코코아 프레임웍없는 Obj-C는 "별로"라는 생각이라 애플이 더욱 공격적으로 코코아와 Obj-C를 개선하기를 바라는 사람입니다. maccrazy님께서는 반대로 코코아없이도 Obj-C를 편하게 사용할 수 있기를 바라시는 것 같고 그 이유도 충분이 이해됩니다... ㅋㅋ
저는 Obj-C가 @""로 NSString도 생성시키면서 @[ @"", 1, nil ] 따위로 NSArray나 @{ @"" => 1 } 따위로 NSDictionary를 만들지 못하는지 불평하는 한사람입니다. 흐..
maccrazy | 2008.07.31 16:49 신고 | PERMALINK | EDIT/DEL
못말려...
그래도 @[ @"", 1, nil ], @{ @"" => 1 } 는 재미있군요.
han9kin님이 너무 편한 랭귀지만 쓰다보니 많이 게을러진 것 같네요. :)
박종암 | 2008.08.01 00:08 | PERMALINK | EDIT/DEL
두 분.. 벌로다가 구현하신 루트 클래스! 블로깅 해 주세요. 그냥 버리기 아깝습니다.
어제 maccrazy님은 han9kin님이 루트 클래스 구현하느라 머리 싸맸다고 그랬는데, 이 글을 보니 반대인거 같군요. 제가 잘못 들었나요?
그제 지진이 났더랬습니다. 그래서 인터넷 접속도, 패킷이 가다 안가다.. 어제도 좀 그러더군요. 그래서 거의 글을 못 썼습니다. 이해 바랍니다.
박종암 | 2008.08.01 00:11 | PERMALINK | EDIT/DEL | REPLY
같은 사람이 쓴 글인데, 하나는 CodeProject에 있고 다른 하나는 자기 웹 사이트같은 곳에 있군요.
무엇이 framework인가에 대한 대단히 추상적이어서 알기가 좀 뭐하지만, 폼은 나는 글입니다.
저의 정의는 간단했는데.. 이렇게 말을 풀어낼 수가 있군요.

http://www.codeproject.com/KB/architecture/WhatIsAFramework.aspx
http://www.marcclifton.com/Articles/DesignAndArchitecture/WhatIsAFramework/tabid/95/Default.aspx
박종암 | 2008.08.28 15:22 | PERMALINK | EDIT/DEL | REPLY
오늘 Apple의 Obj-C 메일링 리스트에 Fast Enumeration의 속도를 비교한 문서가 있는지 질문을 했더니, 한 링크를 주더군요. http://www.cocoabuilder.com/archive/message/cocoa/2008/5/24/208090

그런데, 이상한게 왜 index를 이용한 iteration은 잘 사용하지 않을까요?
사실 현재 3가지 방법이 있죠? NSEnumerator, Fast Enumerator, 그리고 index를 이용한 iteration..
maccrazy | 2008.08.29 10:02 신고 | PERMALINK | EDIT/DEL
제 경우 대부분 index를 이용한 iteration인데요.. :)
하지만 index를 이용하는 방법은 속도문제를 떠나 치명적인 약점이 있는거 같습니다. 바로 index의 바운더리를 항상 체크해줘야 한다는 것이죠.
김지영 | 2008.09.01 10:24 | PERMALINK | EDIT/DEL | REPLY
안녕하세요.
사이텍미디어 출판사의 미디어개발부 김지영입니다.

저희가 현재 번역출간 계획 중인 도서가 Programming in Objective-C 2.0 (2nd Edition) 9780321566157 by Kochan(Pearson Technology Group)입니다. 이 책에 대해서 좀더 자세한 내용을 알고자 이리저리 검색을 하다가 이곳을 방문하게 되었습니다. 괜찮으시다면 책에 대해서 의견을 구하고자 합니다. edita0912@scitech.co.kr로 연락주시면 감사하겠습니다.
행복하고 즐거운 하루 되세요.
maccrazy | 2008.09.01 10:55 신고 | PERMALINK | EDIT/DEL
메일 보내드렸습니다. :)
| 2008.09.03 04:43 | PERMALINK | EDIT/DEL | REPLY
비밀댓글입니다
| 2008.09.06 12:00 | PERMALINK | EDIT/DEL | REPLY
비밀댓글입니다
Name
Password
Homepage
Secret
2008. 7. 29. 16:06
이글루에서 옮겨온 글입니다. 2007/02/10 09:23


Objective-C 2.0이 발표된지도 반년이 지났지만 귀차니즘으로 미루고 미루다가 이제야 한번 봤습니다.
예전 발표 당시에 대충 들은 내용이라 후다닥 지나가고 있었는데 그때는 눈에 안띄던 protocol의 변경사항이 눈에 들어왔습니다. 그때는 왜 눈에 안 띄었는지 모릅니다. 졸았을 수도 있고... :) 변경 사항은 이제는 category를 이용하지 않고 informal protocol을 protocol로 구현 할 수 있게 되었습니다.
기존에 있던 informal protocol들은 어떻게 될까요? catrgory를 이용한 형태로 그대로 있을까요? 아니면 2.0방식으로 다 바뀔까요? 호환성을 위해서 예전 방식으로 둘것 같기도 하지만...
Objective-C 2.0에 대한 의견이 좋다는 쪽으로 일방적으로 흘러가지 않은건 기존의 Objective-C도 충분히 좋았고 이때까지 랭귀지 자체 스팩을 개선해서 좋은 꼴 본게 얼마 없다는 것이겠죠. 마치 C++처럼 오랫동안 중구난방이 될지도 모른다는 걱정이 있기 때문이 아닐까 합니다.
Name
Password
Homepage
Secret
prev"" #1 next