[sellme-dev] использование Сишных типов как объектов Objective-C

24 views
Skip to first unread message

Игорь Евсюков

unread,
Aug 9, 2009, 2:46:45 PM8/9/09
to sellm...@googlegroups.com
хорошо в Objective-C то, это простая надстройка над старым теплым, ламповым добрым C, поэтому и программы работают быстро, и с Сишными библитеками можно легко рабоать.

плохо в Objective-C то, что это простая надстройка над Си: т.е. у нас есть отдельно атомарные Сишные типы(int, float и т.д.) и типы Objective-C которые между собой не очень дружат: последствия действия

NSArray *arr = [[NSArray alloc] initWithObjects:666, nil];

будут весьма плачевны.

Для таких случаев написали костыль NSNumber

NSArray *arr = [[NSArray alloc] initWithObjects:[NSNumber numberWithInt:666], nil];

что ситацию, конечно же, спасает.

Однако, постоянно запаковывать/распаковывать примитивные типы в NSNumber, традиционно ленивым программистам, занятие не очень продуктивное.

Так вот, если кто хорошо разбирается в теме, как можно написать плагин к gcc(или llvm), который как минимум, делает такое сам.

В идеале, конечно же, хотелось бы полного аналога типа NSConstantString - @"some string", т.е. будут классы NSint, NSfloat и т.д., которые в коде или автоматически будут пониматься как Сишные типы, или как Сишные типы с приставкой @(т.е. 1 - int, @1 - NSint)

Кто хорошо знаком с gcc, может знает, как это реализовать?

Dmitry Chestnykh

unread,
Aug 9, 2009, 3:02:52 PM8/9/09
to sellm...@googlegroups.com
Наверное, проще написать макросов для
запаковки.

#define ZZInt(x) ([NSNumber numberWithInt:x])

или категории для NSArray и т.д.

- (void)initWithIntegers:...

А вот тут есть макросы для простого
создания всякий коллекций типа NSArray и
т.п.

http://bitbucket.org/snej/myutilities/src/tip/CollectionUtils.h

Там еще есть такие пирожки:
#define $true ((NSNumber*)kCFBooleanTrue)
#define $false ((NSNumber*)kCFBooleanFalse)

Ну а вообще, я не люблю все эти шорткаты
-- постоянно забываю что делает тот или
иной мой макрос, лучше уж писать как
есть, чтобы потом не париться. Все-таки
писать код не такая уж сложная задача --
сложно его *читать*.

Кстати, MacRuby уже, говорят, поддерживает
компиляцию через llvm (пока, правда,
альфа или бета). И работает он на ObjC
Runtime. Как раз для тех, кто любит
покороче :)

PS "над старым --теплым, ламповым-- добрым
C" — супер :)

- Дмитрий Честных.

Vadim Kolontsov

unread,
Aug 9, 2009, 4:09:16 PM8/9/09
to sellm...@googlegroups.com
Привет,

  друзья, я тут написал сегодня небольшой текст - http://habrahabr.ru/blogs/macosxdev/66632/ - мне кажется, это всем разработчикам будет интересно. Речь про "блоки кода" (Blocks) в следующем XCode - ну или в текущем, при условии установки отдельного компилятора.

С уважением,
Вадим.

Игорь Евсюков

unread,
Aug 9, 2009, 4:18:32 PM8/9/09
to sellm...@googlegroups.com
> Наверное, проще написать макросов для
> запаковки.
> ....
не люблю я такие костыли использовать.
Да и вообще страюсь не использовать
хаки. Потом как поломается что-то, поди
догадайся где именно и почему.

Сейчас буду разбираться насколько ли
реально реализовать свою идею. Если
там не все так вмертельно, то получится
неплохая дипломная работа

> Кстати, MacRuby уже, говорят, поддерживает
> компиляцию через llvm (пока, правда,
> альфа или бета). И работает он на ObjC
> Runtime. Как раз для тех, кто любит
> покороче :)
Спасибо, теперь еще осталось
разобраться в устройстве llvm, может
быть будет проще добавить

Vadim Kolontsov

unread,
Aug 9, 2009, 4:28:46 PM8/9/09
to sellm...@googlegroups.com
> Спасибо, теперь еще осталось
> разобраться в устройстве llvm, может
> быть будет проще добавить

В llvm стоит разобраться.. я вот тоже все собираюсь. Это должно быть
идеальным местом для написания защит от исследования, например. Многие
до сих пор верят, что криптоалгоритмы для подписи iTunesDB сделаны
именно на llvm - особенно в это верят люди из libgpod ("The
obfuscation probably took place in the LLVM intermediate language
during compilation, because the same code is used on x86, PPC, and
ARM. It unlikely traditional manual hand-coded assembly obfuscation,
but rather it was done with an automated process.. and the
instructions to perform the hash have been expanded to take up
approximately 10MB in length.." :) Берем intermediate bytecode,
превращаем его в какую-нибудь state machine, отдаем дальше на
компиляцию в native code..

А вообще в последнее время попадается все больше и больше очень
интересных статей на тему llvm.

Вадим.

Semka Novikov

unread,
Aug 10, 2009, 3:04:13 AM8/10/09
to sellm...@googlegroups.com
> сложно его *читать*.

Ох ты, с языка сорвал. Я постоянно себя одергиваю, когда возникает
позыв написать какой-нибудь макрос «помогающий» создавать NS-данные.

--
take care of the brain

Reply all
Reply to author
Forward
0 new messages