Компьютерная графика

Информация о пользователе

Привет, Гость! Войдите или зарегистрируйтесь.


Вы здесь » Компьютерная графика » Дзен » К новости от 16 сентября 2009


К новости от 16 сентября 2009

Сообщений 1 страница 20 из 20

1

Алексей, я давно хотел обсудить с вами эту тему, но руки все не доходили. А тут вы сами просите, так что я не сдержусь.

Для начала не большой preface:
Я работаю в студии a-steroids. Мы занимаемся разработкой игр под iPhone и Android. В ближайшее время к списку присоединится PSP. Среди прочего, я проводил исследование о возмодности декомпиляции iPhone приложений.

Как уже можно догадаться, речь пойдет об objective-с, Apple, Mac OS X и iPhone OS. Или почему я не люблю Apple и предпочитаю писать на С++.

Начнем с неких абстрактных вещей.
Для начала, Mac OS X - одна из самых медленных и ресурсоемких операционных систем на рынке. Этому есть две предпосылки - ядро mach 3 и язык objective-c. Не спешите сразу писать мне гневный ответ, дочитайте сначала до конца. С ядром все просто - отвратительно реализованный механизм IPC приводит к постоянным созданиям копий памяти. Система с большим трудом работает на рабочем iMac 20'' с 1 GB оперативной памяти и Core 2 Duo e8300. В особенности когда речь заходит об исользовании X-Code (к слову MSVS 2005 SP1 на Vista SP1) на примерно аналогичной конфигурации работает значительно быстрей). На моем MacBook 2.1 с 2GB RAM ситуция не сильно лучше. Если быть точным, то примерно через 2 часа использования x-code система становится практически unusable.

А вот теперь более подробно о второй проблеме системы - об objective-с.

Как я уже говорил, я занимался реверсом objective-с кода, как собранного под Arm v6, так и под x86. Во всех случаях код собирался в release режиме с ключом -O2.

Для начала стоит отметить, что objective-с - не совсем язык. Это скорее очень расширенный препроцессор. Вызов собственно objective-с парсера находится перед вызовом cpp (имеется ввиду препроцессор С). Далее же работает сс1 или cc1plus. Это позволяет языку радостно наследовать все костыли С/С++ и добавлять в них свои, персональные. Часть из них правда делается исключительно компилятором

Итак, первый ключевой момент: вызов метода (оно же - посылка сообщения).
[object method:param1 p2:param2] превратится в следующий ассемблер код

Код:
push object
push methodID ; об этом чуть позже
push param1
push param2
call objc_metacall

Из этого уже легко сделать вывод, что посылка сообщения объекту практически равносильна вызову сигнала в Qt. При этом лишена гибкости последнего. Рантайм от Apple правда предоставляет костыль (по другому рука не поднимается назвать), позволяющий добится гибкости модели signal/slot - NSNotificationCentre. Правда в данном случае это обойдется значительно дороже. Впридачу ко всему - это минимум в 2 раза дороже вызова виртуальной функции в с++ (не стоит мне на это рассказывать про возможность получения указателя на С метод. Все адекватные компиляторы с++ в подобных случаях проводят девиртуализацию)

Слегка подробней о methodID. В общем случае это указатель на строку с сигнатурой метода. objc_metacall по object получает его метакласс, находит метод с его сигнатурой (слава богу это кэшируется) и затем передает управление собственно методу.

Второй, и самый страшный момент - рантайм библиотека. Это просто смерть всему живому и жизнь всему мертвому. Во первых, она берет на себя слишком много - от конструирования и уничтожения С++ объектов с нетривиальными деструкторами до эмуляции "стековых" объектов (то есть autorelease). Во вторых ей сопутствует целая куча проблем. Например переполнение RunLoop (подробнее можно почитать на хабре). И все это шлифуется совершено с не ожиданной стороны. Apple'овский as использует LLVM. У этой технологии огромное будущее, но в настоящий момент она абсолютно не предназначена для сборки системных библиотек. В особенности это заметно под x86 архитектурой. Дело в том, что LLVM рассказали, что векторизация кода это крута. И llvm умудряется идеально переносить на sse очень не тривиальные моменты. Однако, по каким-то причинам он иногда забывает про то, что данные должны быть выравнены по границе 16 байт. В частности из-за этого в libstdc++ 4.0 не рабоет std::map (он использует sse для копирования больших блоков). Подобные ошибки приводят hardware исключения. Вкупе с вобщем-то закрытым кодом это приводит к очень серьезным проблемам.

Кстати, касательно "чистоты" objective c кода:
Приведу конкретный пример: у UIView есть property - CGRect frame, описываемый следующим набором структур

Код:
struct CGPoint{
     CGFloat x;
     CGFloat y;
};

struct CGSize{
    CGFloat width;
    CGFloat height;
};

struct CGRect{
    CGPoint origin;
    CGSize  size;
};

//Следующий код вызовет ошибку компиляции
view.frame.origin.x = 1;

//А вот такой - нет
CGFloat x = view.frame.origin.x;
}

После такого, говорить о плохом синтаксисе с++ лично мне не хочется.

Однако и это не все проблемы, порождаемые Mac OS X. Во первых, многие фреймворки истекают памятью. Во вторых, Apple позволяет себе менять поведение методов. При выходе iPhone OS 3.1 Apple умудрилась поменять поведение класса MKView (отвечает за интеграцию с Google Maps) во фреймворке 3.0. И забыли об этом сказать. На поиск ошибки ушел рабочий день. Вкупе с тем, как они принимают приложение в аппстор, в нашем приложении минимум 2 недели будет ошибка на устройтсвах с прошивкой 3.1. При этом аппл хочет 99 долларов за то, что бы просто иметь возможность тестировать свои приложения на девайсе. Это в плюс к компьютеру с минимум двукратной наценкой и собственно девайсу.

По не понятным причинам, для того, что бы поменять XCode 3.1.3 на 3.1.4 мне нужно заново качать 2.4 гигабайта полного дистрибутива. Я бы не стал этого делать, если бы не оказалось, что я не могу отлаживать на девайсе с прошивкой 3.1 приложения, линкуемые с SDK 3.0 из под 3.1.3

Про ошибки в Snow Leopard я вообще. Один coreaudiod, способный сожрать 4 GB памяти чего стоит (кстати на Leopard он как-то умудрился попасть в своп, когда я смотрел фильм)

Отдельное спасибо Apple за 8 сервис паков и 8 секьюрити апдейтов за 1.5 года. Это не считая "обновления прошивки клавиатуры", всяких QuickTime'ов, iTunes'ов (та еще гадость) и прочих мелочей (а не дай бог стоит iLife...). Кстати один из секьюрити апдейтов не нароком разнес мне журнал файловой системы. Аппл потом даже на оффсайте отписывала, что в его инсталяторе была ошибка.

Опять таки, про не тормозящий iPhone. Запустите Сафари, затем майл (естественно для этого придется сафари закрыть). Закройте mail и наслаждайтесь бешенной скоростью работы девайса с 400 MHz процессором и 128 MB RAM. А уж если вы еще не дай бог во что либо еще поиграете...

Например, AFAIK, для мобильных устройств память выделяют и распределеют уже на старте приложения и потом выделений (и работы сборщика мусора) уже нет.

Только на Java ME устройствах. И то это связанно не со спецификой "языка", а с тем, что хип все равно 1. Jit'ed C# и (в ряде случаев) Java зачастую по скорости обходят С++. Говорить в этом контексте об Objective-C как-то вообще не корретно. В "iPhone Games Projects" один из авторов даже писал, что не смотря на то, что он ярый фанат objective-c, его использования в приложениях, где критична скорость стоит минимизировать (к сожалению, совсем избавиться от него нельзя). В противном случае о скорости и эффективном использовании памяти стоит забыть.

Часть из этого является моим личным мнением. Большая же часть - реальные факты.
PS Большая часть того, что вы называете "идотскими глюками" С++ не вызвало у меня вопросов даже на этапе начального изучения.
PPS Если moc - костыль, то что же тогда Objective-C?

0

2

Я бы не стал называть Mac OS X одной из самых медленных - у меня она быстро работает на обычном PC, по тзывам знакомых даже на Mac Mini работает очень быстро.
Хотя микроядро - это действительно подвергалось серьезной критике за низкую скорость, тем не менее все это отлично раьботало 15 лет назад на имеющемся тогда железе.
На мой взгляд микроядро - это отнюдь не самая главная часть системы, основа - это язык и библиотеки к нему.
Насчет того. что obj-c это обертка вокруг с я согласен. Но только это лучше того УГ которым является С++ - я могу работать с объектами из С. Для С++ этого нет.
Нет идиотской строьгой типизации - если я попытаюсь вызывать неподдерживаемый метод и компилятор об этом знает - я получу warning
По поводщу signal/slot - это как раз и есть костыли для кривого С++ с его полным остуствием метаинформации (толку от встроенного RTTI вообще никакого)
Про вызов метода - я об этом писал- именно что вызовы методо идут через централизованный диспатчер.
И мне это очень нравится - например это позволяет очень легко реализовать распределенные объекты, реализовывать различные proxy  и т.п.
Вообще obj-c отлично поддерживае6т делегирование, полностью выкинутое из С++
Я согласен, что посылка сообщения равна вызову сигнала в Qt, только вот сигнал - это костыли вокруг убогости С++. В родном С++ сигналов нет :(((

Я не понял. что значит, что посылка сообщения лишена гибкости вызова сигнала - в чем именно заключается эта гибкость ?

Я не считаю, что библиотека беретна себя слишком много, в частности с управлением памятью она берет именно то, что надо - предосталяет последовательную и удобную модель. И эта модель отлично работает где-то с 1990 года

Насчет properties - я посмотрю Ваш пример, я думаю, что тут все дело в том, что идет попытка обратится к полю не объекта, а структуры. А метаинформация для структур язком не генерируется.
Кроме того это просто syntax sugar над KVO.
Есть у него аналог в С++ ?
Как с поддержкой Cocoa Bindings в С++ ?
В obj-c можно без труда подключить Aspect-oriented programming на упровне рантайма - именно так как и сделано KVO -  только в С++ этого нет и не будет.

И я действительно считаю, что синтаксис obj-c намного проще и чище, чем у С++. Ваш пример - это мелкий глюк реализации
И давайте разделим все-таки факты и Ваше личное мнение - я не совсем понял, где что.
А moc - это дейстивтельно костылль, причем кривой.
В отличии от целостного и очень гибкого obj-c - кстати как в С++ обстоит дело с persistenceб связыванием со скриптовыми языками (только не надо про boost) ?
Насколько я знаю очень плохо.

0

3

В добавление к предыдущему сообщения - No Offense Suggested,
но просто у obj-c совсем другой подход, чем у С++.
И вся архитектура Mac OS X и iPhone OS заточена под другие подходы - использование паттернов,делегирования (колторые очень плохо поддерживаются в С++ на уровне runtime)
Мне под С++ очень не хватате того, что есть в obj-c - нормальной метаинформации, нормального механизма делегирования, нормальных библиотек (а не бреда вроде STL/boost)

0

4

Вот как раз с библиотеками то и проблема.
Из-за LLVM память течет стабильно в Network, так как нарушается выравнивание адресов и free оказывается не способным очистить память. В iPhone SDK 2.2.1 стабильно текла память при включении акселерометра.

Насчет паттернов (и делегирования в частности). Они не так уж плохо поддерживаются на уровне С++. Буст, кстати, очень хорошо и быстро реализует рантайм связывание по модели сигнал/слот. Контейнеры STL значительно быстрее и более гибкие чем контейнеры obj-c.

То, как в obj-c эмулируется стековые объекты вообще отдельная, и очень грустная тема. Использование deprecated в g++ механизма исключений SJLJ тоже не приносит мне счастья. У obj-с безусловно есть своя ниша (хотя я бы при прочих равных выбирал Qt, где так же есть великолепная поддержка метаинформации), но разработка игр и прогаммирование графики в нее не входит...

У меня совершенно нет желания раводить холивар на тему obj-c vs с++. Я просто хотел показать то, что идеальных языков не существует и не стоит презирать один из них и боготворить другой. Особенно учитывая, что они занимают совершенно разные нишы. С++ уже стал фактическим стандартом в gamedev'е. Obj-c это никогда не грозит.

PS Имхо, но навязывать делегирование везде - не лучшая мысль. Есть много моментов, где удобнее, например, MVC

0

5

Я согласен с тем, что "идеальных языков не существует и не стоит презирать один из них и боготворить другой". В истории с AppleStore для меня гораздо более важным кажется предложенная ими социальная модель бизнеса. При этом они вправе установить свои правила игры. Меня эти правила устраивают, а так как они предполагают написание кода на Objective-C, то в моих интересах использовать его как можно более эффективно, а не страдать от того что С++ лучше. Кроме того в своих маковских прогах в настоящий момент я на Objective-C пишу только морду а в ядре использую С++.

0

6

Паттерны - и как же поддерживается в С++ делегирование - через всякое шаблонное Г ?
Посмтрите на кривость паттернов в С++, отвещающих за создание объектов и сравните в тем как сорздаютсчя объекты obj-c - есть class object, задачей которого является создание объектов-instance
Насчет бстроты STL-контейнеров - у меня на сайте был линк про реализвацию NSMutableArray и как он ведет себя при большом числе элкементов. std::vector - просто УГ по сравнению с этим (при большом числе элементов фактически происходит смена реализвации обеспечивающая высокую скорость работы с массивом, например случайных вставок)
STL-контейнеры еще тянут для небольшого числа орбъектов, но и obj-c контейнеры в этом случае тоже работаю хорошо.
А вот если нужен set<long long> для работя с десятками миллионов элементов, но std::set идет в топку - я за пару дней напишу специализированный контейнер под эту задачу, который порвет std::set
Т.е. для конкретных задача с очень большим числом элементов STL сливает - легко делается эфективная кастомная реализация
И в чем большая гибкость STL-контейнеров по сравнению с контейнерами в obj-c ?
Что Вы подразумеваете под эмуляцией стековых объектов (на стеке там объектов нет) ?

Насчет поддержки в Qt метаинформации - что именно там поддерживается (через костыль в виде moc) ?
И, главное, почему эта поддержка не делается самим языком ???

Кстати делегирование и MVC очень хорошо живут вместе, собтсвенно достаточно посмотреть на iPhone SDK
Разводить холивар на эту тему я тоже хочу, просто :
1. На мой взгляд область применения С++ искусственно расширена за счет отсутствия конкуренции (при этом все кто могут бегут с него на java/c#), т.е. там остались только те, для кого быстродействие критично
2. Я хотел поговроить именно насчет java/C# - а в чем их смысл и не может ли obj-c с набором библиотек из заменить

ЗЫ. Насчет случаев, где java/C# оказываются быстрее С++ - AFAIK это именно те случаи когда сперва выделяется куча маленьких объектов, а потом уничтожается. Традиционно операции выделения,освобождения памяти довольно дорогие. А при сборке мусора можно очень быстро освободить сразу очень большое число (особенно если подряд выделенных) объектов. Так использования пула памяти (custom allocator) легко решает эту проблему

0

7

Сергей, а что ты скажешь про заявленную тормознутость макоси и утечки памяти ?

0

8

Sergey Seitov написал(а):

Кроме того в своих маковских прогах в настоящий момент я на Objective-C пишу только морду а в ядре использую С++.

Я тоже. Я не страдаю от того что приходится использовать obj-c. Однако мне очень не нравиться, когда из него пытаются сделать панацею.

Steps3D написал(а):

Что Вы подразумеваете под эмуляцией стековых объектов (на стеке там объектов нет) ?

Зато есть autorelease объекты. При этом поведение стековых объектов частично эмулируется рантаймом. Это очень критично при использовании исключений.

Steps3D написал(а):

Насчет поддержки в Qt метаинформации - что именно там поддерживается (через костыль в виде moc) ?

MOC это такой же костыль как и Obj-c. Просто у trolltech было желание написать библиотеку для большого числа компиляторов. Obj-с является неотемлемой частью gcc, что позволило "встроить" его в компилятор. Только вот ни gcc, ни g++ компиляторами не являются. Это просто красивая обертка к toolchain cpp->cc1(plus)->as->ld в случае obj-с появляется еще  cc1obj. Таким образом тулчейн Obj-C++ выглядит так cc1obj->cpp->cc1plus->as->ld. У QT так moc->cpp->cc1plus->as->ld. Разницы в упор не вижу

Steps3D написал(а):

Кстати делегирование и MVC очень хорошо живут вместе, собтсвенно достаточно посмотреть на iPhone SDK

Мне его приходится слишком часто использовать. Живут то они хорошо, но только не в этом случае...

Steps3D написал(а):

1. На мой взгляд область применения С++ искусственно расширена за счет отсутствия конкуренции (при этом все кто могут бегут с него на java/c#), т.е. там остались только те, для кого быстродействие критично

Это и есть основная область применения с++.

Steps3D написал(а):

2. Я хотел поговроить именно насчет java/C# - а в чем их смысл и не может ли obj-c с набором библиотек из заменить

Java EE? O_O Я больше поверю в то, что буст + xercec-с + туева хуча других библиотек могут дать хоть какое-то приближенное придставление о Java EE. Obj-с этого не сможет. Foundation реализует сравнительно мало  и in mac way only. Сторонних библиотек катастрофически мало из-за того, что язык фактически используется только apple.

Steps3D написал(а):

Насчет бстроты STL-контейнеров - у меня на сайте был линк про реализвацию NSMutableArray и как он ведет себя при большом числе элкементов. std::vector - просто УГ по сравнению с этим (при большом числе элементов фактически происходит смена реализвации обеспечивающая высокую скорость работы с массивом, например случайных вставок)

Насколько мне известно, на iPhone это происходит при числе объектов > 300.000. При этом для наиболее частых оперециях push(pop)_back, random access он просто догоняет vector (причем со стандартным аллокатором). Вот только массив размером больше 1mb для iPhone это сомнительная штука. Если он появился, то стоит пересмотреть реализацию

Steps3D написал(а):

Паттерны - и как же поддерживается в С++ делегирование - через всякое шаблонное Г ?

Под делегированием я понимаю следующее:

In software engineering, the delegation pattern is a technique where an object outwardly expresses certain behaviour but in reality delegates responsibility for implementing that behavior to an associated object in an Inversion of Responsibility. The delegation pattern is the fundamental abstraction that underpins composition (also referred to as aggregation), mixins and aspects.

В С++ оно реализуется аналогично objective-с. За исключением того, что делегат должен быть строго унаследован от интерфейса, который он должен предоставлять

Steps3D написал(а):

Т.е. для конкретных задача с очень большим числом элементов STL сливает - легко делается эфективная кастомная реализация

Если ее делать С++ way, то для конкретно целевого кода не будет никакой синтаксической разницы и будет возможность легко менять реализации. Если сделать это через ****, то извините, но это уже не проблемы С++

Steps3D написал(а):

И в чем большая гибкость STL-контейнеров по сравнению с контейнерами в obj-c ?

Во всем. Начиная от управления памятью и заканчивая высокой обобщенностью.

Steps3D написал(а):

И, главное, почему эта поддержка не делается самим языком ???

Делается, но со словом performance в уме. Qt этим активно пользуется (правда в придачу расширяя и саму метаинформацию).
.
На закуску:

C++ dispatch is faster than Objective-C dispatch, roughly 3 cycles for a virtual function versus roughly 13 cycles for objc_msgSend when I tested it. It's also vastly less capable

Источник здесь
Это стало новостью даже для меня. Я считал что оверхед не более чем двукратный. В свете этого 30% оверхед на вызов виртульной фукции кажется просто смешным

2 Sergey Seitov
Мы свами говорим одно и тоже, и даже почти одинаковми словами

Отредактировано crsib (2009-09-17 12:33:57)

+1

9

Я не делаю панацею из obj-c, просто IMHO в нем ряд вещей очень удобно и гибко реализованы. И гораздо проще.
Мне больше нравится нормальное ООП, а не бредовое нагромождение практически неотлаживаемых макросов (STL/boost)
Я отлично понимаю, что если мне нужна библитека 3D графики, то obj-c -здесь не подходит - он заточен под объекты, а в этом случае нужны простые и макусимально эффективные АДТ.
Собсвенно это как раз то, что в чем С++ - хорошая поддержка АТД, которе вообще не отлиаются от объектов (и никакой объектной модели нет вообще)
Насчет moc - какую именно метаинформацию он строит (имена и типы, полей, родительские классы, протоколы, методы) ?
Насколько я знаю не существует способа извлечь полную информацию из С++ (в силу его сложности) не компилируя.

Про делегирование - нет в с++ интерфейсов, есть попытка их имитировать, но это не интерфейсы.
И делегирование, которое требует наследование от заданного класса IMHO весьма криво - а если мой объект должен быть делегатом для 10 объектов и я хочу каждому объекту поставить свою функцию, то как поступать в этом случае - интерфейс то всего один

Насчет стоимости посылик сообщения - обычно внутри метода тратится намного больше тактов, чем идет на вызов.
Здесь просто идет tradeoff гибкости и скорости.

Я попробую суммировать чем мне лично нравится obj-c
1. Четкая и удобная объектная модель с поддержкой полной метаинфорации, протоколов, категорий и т.п.
2. Четкая схема управления памятью, мне лично autorelease нравится. Не возникает проблем с тем, что непонятно где данный объект создан - на стеке, в хипе или же он глобальный
3. Класс это не непонятно что, а объект. Все пролемы с т.н. виртуальным констурктором снимаются сразу же
4. Простота - посмотрите сколько занимает полное описание С++ (лет 5 назад это была книга старниц так 700)
5. Всегда понятно во что откомпилируется та или иная конструкция - в С++ компилятор легко сам вставляет какой-то код

Т.е. мне кажется что obj-с это мощный и гибкий язык, незаслуженно обделенный вниманием.
Я уверен, что тот же Qt можно было сделать на obj-c и он был бы гораздо проще и меньше

В С++ мне фактичемски нравится поддержка АТД и inline -функции (когда слово inline будет заставлять компилятор, а не высказывать пожелание, на которое компилятиор может положить ***).
Использование объектов на стеке для RAII -дейсвтительно удобно.
А вот делать persistence, GUI (сколько лет понадобилось, чтобы появились сколько-нибудь нормальные GUI-либы ?), распределенные объекты, взаимодействие со скриптовыми языками - все это делается очень криво (в в первую очередь из отсутсвия объектной модели и поддержки метаинформации)

0

10

Steps3D написал(а):

Насчет moc - какую именно метаинформацию он строит (имена и типы, полей, родительские классы, протоколы, методы) ?

Имена, типы полей, методы, сигналы, слоты, родительские классы. Причем в двух видах - human readable и machine efficient

Steps3D написал(а):

Про делегирование - нет в с++ интерфейсов, есть попытка их имитировать, но это не интерфейсы.

Вполне себе интерфейсы. Семантика абстрактного класса и класса - совершенно разная

Steps3D написал(а):

4. Простота - посмотрите сколько занимает полное описание С++ (лет 5 назад это была книга старниц так 700)

Текущий стандарт - 1100. Однако это полный стандарт. В случае objective-с дается только стандарт расширения, а не underlieing языка.

Steps3D написал(а):

2. Четкая схема управления памятью, мне лично autorelease нравится. Не возникает проблем с тем, что непонятно где данный объект создан - на стеке, в хипе или же он глобальный

А мне - нет. Чисто на любителя. Тем более выделение в стеке всегда быстрее

Steps3D написал(а):

Я уверен, что тот же Qt можно было сделать на obj-c и он был бы гораздо проще и меньше

И значительно медленее, а это тоже не так уж и маловажно. Qt и так не блещет скоростью

Steps3D написал(а):

5. Всегда понятно во что откомпилируется та или иная конструкция - в С++ компилятор легко сам вставляет какой-то код

Мне тоже так казалось. Пока не начал реверсом заниматься. Оказалось что совсем не понятно...

Steps3D написал(а):

1. Четкая и удобная объектная модель с поддержкой полной метаинфорации, протоколов, категорий и т.п.

Ну да. А в с++ ее надо изобрести ))))

Steps3D написал(а):

бредовое нагромождение практически неотлаживаемых макросов (STL/boost)

Все нормально отлаживается. Опять же, дело привычки и вкуса

+1

11

1. Насколько я знаю Qt не использует STL/boost - у него свои строки/контейнеры и т.п.

2. Как moc  понимает темплейты - ибо если их не трогать то все дейстивтельно просто ?

3. Насчет того, что Qt на obj-c тормозил бы - это сказки. NextStep  великолепно работал и не тормозил на Motorola 68040 25 MHz и Intel 486 DX2 50 Mhz с 16 Мб памяти. Сюда входили все основные фреймворки. Вовсю использовались NSString, контейнеры на obj-c и все работало
Т.е. если Qt сейчас подтормаживает - это скорее всего результат борьбы разработчиков с языком

4. Насчет изобретения объектной модели - вот все большие библиотеки ее и изобретают - свою объектную модель, свой RTII, свой persistence и т.д. И каждый делает по-своему и по-своему борется с кривостью языка С++

5. Естественно что постоянно послыать сообщения в tight loop-е никто не будет - для критических по времени частей есть "старый добрый С".
Оlнако я лично в tight loop-е не буду использовать STL.

6. Не могли бы Вы поподробнее в чем именно заключются проблемы autorelease и исключений.
7. Так как в великолепноя языке С++ дело оюбстоит с распределенными объектами/сериализацией/работой со скриптовыми языками.
Первые два пунка были сделаны еще в NextStep-е в 90-м году и отлично работали не ьтребуя всяких танцев с бубном
Для свяки obj-c со скриптовым языком использование метаинформации позволяет написать универсальную прокси.

8. ИТак все-таки в чем преимущества контейнеров в STL и преимущества сисетым слот-сигнал в Qt ?
Я видел несколько библиотек, реалитзующих слот-сигнал - это просто темплейтный бред - абсолютно нечитаемый кривой код.

0

12

1. Я и не говорил, что Qt их использует. Qt контейнеры зачастую медленнее на ряде операций, но идеально подходят под идеологию Qt
2. Также как стандарт допускает использовать виртуальные шаблонные функции. То есть для рантайм части - никак. Для человекопонятной части - как и все остальное, пишет тупо строками. Но повторю, для рантайма это не нужно.
3. Мне не доводилось работать с NextStep и Mac OS classic. Я могу судить только о текущем obj-c, Mac OS X и iPhone OS. Раньше, кстати, и трава была зеленее )))
4. Я бы не сказал что с кривостью. Мне не так уж и часто нужна полная объектная модель. Но правда - каждый борется по своему. И почти всегда - успешно.
5. А я использую. По резултатам профайлинга - все совсем не плохо. В движке, который я сейчас пишу для "удовольствия и обучения" на STL построен, например runloop. STL никогда не является горячим местом. Большая часть используемых операций выполняются за O(1), при этом очень оптитмальным образом. Добавте к этому свой распределитель памяти (его правда предстоит еще доотладить (точнее сделать полностью thread-safe) и дооптимизировать) и получите очень низкие оверхеды.
6. Он выполняется рантаймом из runloop. Последний слегка крив, поэтому не всегда можно точно сказать, что retain count уменшился. И нельзя предсказать когда он уменьшится. А release на объекта с retain count = 0 в свою очередь тоже швыряется исключением (я веду к тому, что блок finally не всегда очень тривиально пишется)
7. Увы, не понял фразы
8. Сигнал/слот? Отправьте на досуге объекту селектор, которого у него нет и сразу все узнаете. Вдобавок, через сигнал/слот намного легче реализовывать связывание между объектами, которым друг о друге знать просто не положенно. Наконец, сигнал можно отправлять любому колличеству слотов. В obj-c такая фишка не прокатит.
Так же я уже давно понял, что у нас с Вами кардинально разное отношение к шаблонам. Учитывая, что в обоих случаях это ИМХО, то я не вижу глобального смыла продолжать дискуссию в этом направлении.

PS Алексей, в свое время вы дали мне очень сильный толчок в верном направлении своими статьями. За это я всегда буду Вам благодарен. Однако, в ряде моментов я с Вами бываю не согласен. В этих случаях дискуссия очень полезна как нам обоим, так и многим, кто читает форум, так как позволяет задумываться о возникающих проблемах значительно глубже.

0

13

Я Вам также благодарен за много полезных замечаний как в этой нити так и во вногих других
Отношение к шаблонам у нас действительно разное (и похоже в ходе дискуссии) таки не изменилось, я уверен что их можно эффективно использовать, просто IMHO есть более удобные альтернативы и, как праивло, их использование требует наличия очень большого опыта.

0

14

Приношу свои извинения за то что вновь поднимаю эту своего рода закрытую тему, но сегодня в очереной раз произошло то, что хотелось бы в Вашей традиции назвать "Очередной идиотский глюк Objective-C"

А точнее глюк компилятора от "великой, пишущей хороший код" компании Apple.

Итак, рассмотрим простую ситуацию: у вас имеется сравнинительно большое приложение со сравнительно большим колличеством классов. В случайный момент времени у случайного класса может начать проявляться интересное поведение - приложение будет валится на [Class alloc] с EXC_BAD_ACCESS.

Лезем в отладчик, и что мы видим там? На вершине стека находится одна из функций, вызываемая objc_msgSend (и это при включенной опции компиляции accelerate objective-с method dispatсh). Кстати в стеке до вызова проблемной функции находится еще одна. Но вопрос даже не в этом. Смотрим на команду (ну естественно рантайм не несет за собой отладочной информации) вызывающую исключение и понимаем, что компилятор "ниасилил" корректно сгенерировать метаинформацию для класса. А точнее он ее поломал. Ну, казалось бы ерунда, делаем чистую пересборку и ... получем ту же ошибку. Причем вплоть до мелочей. Единственный способ заставить компилятор (ой не причем тут сам xcode, все что можно чистил, ничего не помогает) это удалить из сборки все связанное с реализацией класса, добавить обратно и пересобрать. И это компилятор языка в котором ВСЕ построенно на метаданных (даже выделение памяти О_О).

После этого говорить что у с++ плохие компиляторы лично мне совсем не хочется. И фиг с ним, что msvc до сих пор не умеет выравнивать в стеке параметры функций...

0

15

Ну зафайлимте баг-репорт в Apple
А так я и не понял в чем именно была проблема - может у Вас просто для разных флагов были разные опции компиляции ?
Ну не может компилятор поломать метаинформацию - кстати ее структура документирована - он просто ее генерит с нуля
И Вы случайно не obj-c++ используете, а то по предыдущим постам у меня сложилась именно это впесчатление ?
Не надо это делать - скрещивание ежа с ужом ничего хорошего дать не может - разделите код - отдельно obj-c, отдельно с++
И поменьше STL/boost и прочей дури :))

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

Просто у Вас такое же предвзятое отношение к obj-c как у меня к С++. Только я С++ уже наелся - работаю с Turbo C++ 1.0 и всю его кривость уже давно знаю, момент большой радости от С++ прошел лет 15 назад.
Похоже Вам это еще торлько предстоит

ЗЫ. No offense suggested

0

16

Конеретно в данном проекте - чистый Objective-C. Проблема проявляется именно описанным образом - alloc перестает работать совершенно случайным образом. Но правда если перестал - то не будет работать до выполнения вышеописанных плясок с бубном.

Steps3D написал(а):

Ну не может компилятор поломать метаинформацию - кстати ее структура документирована - он просто ее генерит с нуля

Он ее должен генерировать с 0. Что он делает реально - известно только программистам Apple. Документрована структура Mach-O файла в свете работы с objective-с runtime. И именно яблочным рантаймом. Если требовать у компилятора на выходе Asm файл - то да, компилятор изображает из-себя следование стандарту. А дальше начинает работать LLVM back-end. И поверьте, потом в дизасме живого места не найти. Начиная с того, что бэкендом напрочь игнорируются комментарий к расположению данных в сегментах. Заканчивая совсем поразительными оптимизациями при компиляции с -O0 -g (какого лешего они там забыли тоже не понятно). И, простите, когда потом в рантайме на месте метатаблицы оказывается черти-пойми-какой адрес (я бы еще понял, что 0), а затем смотришь на дизасм приложения ....

Steps3D написал(а):

Не надо это делать - скрещивание ежа с ужом ничего хорошего дать не может - разделите код - отдельно obj-c, отдельно с++

Ну да, для всего time-critical только c++ без малейшей примеси obj-c. И главное никакого Foundation. Если конечно нет необходимости хранить > 300 000 объектов obj-с

Steps3D написал(а):

Тут пересмотрел нашу дискуссию - четсно говоря ощущение, что Вы очень плохо знаете obj-c - по крайней мере как работает механизм  сообщений и сколько он стоит очень хорошо документировано

Яблочной документации верить не стоит. Там очень часто забывают описывать полное поведение чего-либо. Иногда это относительно безобидно, а иногда и нет. Runtime от GNU думаю обсуждать даже и не стоит. Кстати описание стоимости традиционно очень поверхностно. Есть только один способ оптимизировать программу на Obj-C - переписать ее на чистом С. Все остальное даже не полумеры, а просто экономия десятка тактов.

Steps3D написал(а):

Просто у Вас такое же предвзятое отношение к obj-c как у меня к С++.

У меня было великолепное отношение к obj-с когда я только начинал им пользоваться. Потом я копнул вглубь. Правда года 3 назад я например боготворил Apple. Через год прошел восторг от их продукции, в особенности от ОС (железо - отдельная, и очень грустная тема).

PS Я далеко не в восторге от С++. Я просто не вижу ему альтернативы. Лет через 5 до него может дорастет D (и дай бог это произойдет раньше). Если мне внезапно понадобится "сверхгибкость" я воспользуюсь Lua (Python'ом, Ruby, Java'ой/C#'ом в конце концов). Кстати Вы копните на досуге глубже UIKit. CEGUI и то проще кастомизировать и подстроить под себя...

PPS Для меня пока скрыта тайна, чем так плохи STL/boost, особенно если уметь ими пользоваться))

0

17

А можно посмотреть пример файла с этой ошибкой, а то как-то очень странно оно выглядит.
Вы имеете в виду, что у класса в произвольный момент оказывается битым isa или же сами данные в class object битые?

IMHO D не тянет на среьезную альтернативу
Мне хочется именно язык ориентированный на нормальноее ООП, а не катрированный вариант как в С++
И obj-c мне лично очень нравится, пока что все что Вы писали касается исключительно реализации языка, точнее реализации его runtime

А STL/boost - просто уродство - кривая попытка добавить в язык, то что он не тянет по дизайну.
В результате получаем непонятно что.
Мне не нравится идея строить на этапе компиляции сложные шаблонные классы, вместо того, чтобы внести в зяык нормальные средства, например нормальный RTII

0

18

Steps3D написал(а):

битым isa

Скорее всего - isa. Но странность в том, что он не всегда "битый". То есть в одном случае все будет в порядке, а в каком-то конкретном isa (хотя точно сказать трудно, приложение валится при поиске селектора у класса) будет черти какой. Говорить о состоянии Class Object навскидку тяжело - обфускатор делает свою работу хорошо.

Steps3D написал(а):

А можно посмотреть пример файла с этой ошибкой, а то как-то очень странно оно выглядит.

В том то вся и проблема. Он происходит "рандомно". То есть полностью оттестированный класс может спустя пару месяцев перестать работать (после перекомпиляции) (((

Steps3D написал(а):

например нормальный RTII

Он целиком покрывает мои скромные потребности ))

Steps3D написал(а):

Мне хочется именно язык ориентированный на нормальноее ООП, а не катрированный вариант как в С++

Только он не будет компилируемым (а точнее non managed). В этом то вся и беда. Да я не спорю, С++ далеко не ООП язык

Отредактировано crsib (2009-11-03 18:41:27)

0

19

Почему "он не будет компилируемым (а точнее non managed" - вот obj-c как пример такого языка - компиолируемый и non-managed.
У Вас претензии почти полностью по реализации

А про вашу багу

". В случайный момент времени у случайного класса может начать проявляться интересное поведение - приложение будет валится на [Class alloc] с EXC_BAD_ACCESS"

Я прпавильно понял что на каком-то вызове происходит падение, но до этого такие же вызоу в этому же классу успешно проходят ?
Если это так - то Вы пилите память
Я специально порылся в инете с поисках Вашей ситуации - все что я видел, случайные падения - результат распила памяти/некорректного управления временем жизни объекта.

0

20

Steps3D написал(а):

У Вас претензии почти полностью по реализации

Язык очень тяжело опирается на рантайм. Так что во-первых он в какой-то мере managed, а во-вторых, а к чему у меня должны претензии? я могу задать произвольную грамматику. Например, с хорошой поддержкой ООП. Но это не делает грамматику хорошим языком...

Steps3D написал(а):

Я прпавильно понял что на каком-то вызове происходит падение, но до этого такие же вызоу в этому же классу успешно проходят ?
Если это так - то Вы пилите память

Все жестко и часто мониторится акулой на предмет утечок (ну да, Foundation течет) и определяем различные распилы. Во-вторых каким образом можно избежать распила путем передобавления файла в проект?

Steps3D написал(а):

Я специально порылся в инете с поисках Вашей ситуации - все что я видел, случайные падения - результат распила памяти/некорректного управления временем жизни объекта

Я тоже рылся. И проблема далеко не в этом.

0


Вы здесь » Компьютерная графика » Дзен » К новости от 16 сентября 2009


создать свой форум бесплатно