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

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

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


Вы здесь » Компьютерная графика » Дзен » Небольшой бенчмарк iPhone 3G и iPhone3GS


Небольшой бенчмарк iPhone 3G и iPhone3GS

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

1

http://aussiebloke.blogspot.com/2010/01 … hones.html

Обратите внимание, что для последней модели цена obj-c message send лишь немного выше стоимости C++ virtual methods call

0

2

Угу, еще очень радует производительность FPU на Cortex A-8. Однако, достаточно взглянуть на различие в архитектурах 1176 и Coterx'a, что бы понять, откуда растут ноги в улучшении показателей message send'a и ухудшении FPU. Только вы не учитываете одного но - не все методы в с++ виртульны и не все виртуальные методы станут виртуальными. А в этих случаях мы имеем производительность чуть выше, чем у IMP-cached (точнее в пределах погрешности, ARM очень эффективно работает со стеком и стековыми кадрами, особенно в сравнении с Intel). В особенности это касается контейнеров. Контейнеры Foundation - откровенно медленная и странная (ИМХО) вещь.
 
Лично меня особенно радует, как грамотно Apple блокирует прошивкой аппаратные возможности используемых чипов. Начиная с Jazelle (и, видимо, TrustZone - судя по тому, сколько критических ошибок безопасности было (и, видимо, есть у iPhone), заканчивая неимоверным количеством блокированной функциональности на графическом чипе. И до безумия впечатляют цены и соотношение цена/качество.

PS Раз уж пошла такая пьянка. Алексей, скажите, почему вы любой пост про уязвимости от MS с хабра сразу же отмечает в блоге, а про уязвимости OSX - никогда. При этом вы стараетесь сгладить акцент на том, где у MS находились уязвимости.

0

3

Я не скрвыю свое отношение к M$ как к сборищу выродков, большинство из того, что они делаеют - уродство и убожество. Хотя вроде бы .net  и VS представляют из себя некоторое исключение (хотя я считаю java/C# бессмысленныыми языками).
Кроме того M$ - монополисты, а Эппл - нет (и не дай бог им когда-нибудь стать монополистом)
А Эппл регулярно делает супер-продукты. Mac OS X -супр система, очеь изящно сделана.

На мой взгляд С++ - это тупик, чем скорее это уродство будет выкинуто на свалку, тем лучше - быстрее появится нормальная замена.
obj-c действительно уступает с++ по скорости в ряде мест, но всюду ли это критично ? Для GUI это вполне нормально, здесь гибкость языка очень кстати
Действительно писать код, который требует высокой производительности на obj-с не стоит, но IMHO на с++ его нужно писать очень осторожно - в первую очередь никаких STL/boost и прочего макро-бреда(IMHO template - ЭТО КРИВЫЕ МАКРОСЫ)
с++ (IMHO) заставляет идти кривым путем - через свои убогие макросы и макро-библиотеки, полностью отнимаю runtime-гибкость.
А objc основан именно на гибкости на этапе runtime и очень много наследует от Smalltalk-а (к сожалению в нашей стране очень мло известного)
На насчет контейнеров Foundation - в чем странность - мне наоборот очень удобно, никаких макросов и прочего STL
А там где нужна скорость  там нужно делать свои контейнеры - stl врядли эффективно птянет работу с милионами точек, custom-реализация будет намного быстрее.
На obj-c мне иногда не хватает элементов из С++ - а именно inline-функций (только нормальных, а не когда слово inline может компилятором полностью игнорироваться) и поддержки абстрактных типов данных (тут у С++ позиции сильны).

0

4

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

А Эппл регулярно делает супер-продукты.

Ни одного качественно-сделанного продукта. Любой их творение, особенно связанное с железом - куча ошибок промышленного дизайна и производственного брака. Начиная с пробивающихся дырок на топлоке пластиковых макбуков и петель аллюминеевых и заканчивая трескающимися корпусами айфонов 3G. А любые удачные решения моментально патентуются, что бы не допустить выход качественного продукта на рынок с теми же возможностями. (При этом тот же mag safe сравнительно быстро ломается). Хорошо, что мультитач им удалось закрыть только в Америке...

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

Mac OS X -супр система, очеь изящно сделана.

С кучей изящных прелестей, типо неадекватного управления памятью, отвратительного ядра, апдейтов, разносящих файловую систему, kernel panic'ов там, где даже XP не давала BSOD. При этом наличествует куча критических ошибок в безопасности системы, которые Apple далеко не всегда торопится закрывать. От волны вирусов их спасает только супернизкий процент на рынке (при этом на барсике было показано, что вирусы и трояны более чем возможны). И такими темпами им монополистами не стать никогда, особенно до тех пор, пока они не начнут адекватно относиться к разработчиками и не начнут предоставлять им адекватные инструменты для разработки.

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

ЭТО КРИВЫЕ МАКРОСЫ

А вот Александреску об этом другого мнения. И он реально демонстрирует, как template'ы помогают в проектировании расширяемых и реюзабельных систем. При этом, код может иметь и гибкие рантайм возможности, что демонстрируется, например, Qt.

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

мне наоборот очень удобно

А мне сильно не хватает работы с машинными типами. А вся "гибкость" в лоб реализуется на С++.

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

А там где нужна скорость  там нужно делать свои контейнеры

Там можно делать свои политики распределения памяти. В большинстве случаев этого хватает, что бы STL исчезла из аутпута профайлера. А вот в Obj-C у меня выбора нет. Я не думаю, что можно значительно улучшить поведение вектора на доступ к элементам и реаллокацию памяти и значительно улучшить реализацию map. (учитывая, что все политики работы легко кастомизируются)

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

а именно inline-функций

Ну, стандарт С99 вообще мало чего гарантирует...
И появляются компиляторо-специфичные убожества типо __attribute__((always_inline)). Здесь, к моему большому сожалению, ничего сделать нельзя...

0

5

Насчет "Ни одного качественно-сделанного продукта" - у меня iPod'ы великолепно работают. И вообще у Эппла всегда была (и есть до сих пор) большая аудитория клиентов(сторонников), пользующиеся продуктами Эппл и очень довольных.

Вот у меня (на хакинтоше) Макось работает очень хорошо мне гораздо удобнее работать с ней, чем с форточками. И все-таки в чем заключатся неадекватность управления памятью" ?
И апдейты у меня не разносят фацловую систему - что я делаю не так :))) ?

Насчет Александреску - это его личное мнение и он не является истиной в последней инстанции. IMHO он просто пытался реализовать на С++, то что до этого нормально нельзя было реализовать. Но при этом все его примеры это абсолютно нечитаемый говнокод (IMHO), работающий исключительно на стадии компиляции. А с runtime поп-прежнему ничего - Qt использует специальный препроцессор.
Да у Qt есть гибкость в runtime, но чего она стоит - а вот гораздо больше гибкости дает obj-c, причем гораздо меньшей ценой. Как там у Qt с распределенными объектами, аналогами cocoa bindings, сериализацией, анолагаом NSOperationQueue ? А никак, не делается это нормально на С++.

Каких именно машинных типов Вам не хватает  (все что есть в С есть и в obj-c, а STL врядли можно отнести к машинным типам) ?
И как в С++ можно реализовать key-value-observing, coca bindings и многое-многое другое (чтобы быстро компилировалось и не требовало специальных препроцессоров, выдирающих всю ту информацию, которая по мнению разработчиков С++ не нужна) ?

Политики распределения памяти мало помогут, там где речь идет о миллионах объектов - тут нужны правильные алгоритмы.
IMHO контейнеры STL годятся только для небольшого числа объектов (а для этого слуач и Foundation будет нормально работать) или для прототипирования
А насчет inline я имел в виду именно стандарт С++

0

6

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

у меня iPod'ы великолепно работают

Я тоже так думал, пока не воткнул свои Sennheiser CX-300 в iRiver из тача. Про качество 1g nano я вообще промолчу. Им даже после тача пользоваться не хочется - от качества звука просто тошнит. Работают то они может хорошо, но не как плееры. Да и все у того же nano жуткие проблемы с отзывчивостью управления.

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

И все-таки в чем заключатся неадекватность управления памятью

Ну 2gb при активном использовании уже мало. Даже на висте с аналогичным запущенным софтом я работал абсолютно комфортно, а на аппле переключение между приложениями занимает значительрное время, а иногда приводит к локу системы.

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

И апдейты у меня не разносят фацловую систему

Разносил секьюрити апдейт между 10.5.2 и 10.5.3 Причем Apple признавал эту проблему, но в апдейт стрим отказывался выкладывать исправленную версию апдейта - она была доступа только с сайта.

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

Qt использует специальный препроцессор

В текущей реализации Obj-с - тоже препроцессор, производящий кодо-генерацию в С код.

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

Но при этом все его примеры это абсолютно нечитаемый говнокод

Для меня важно, что при использовании код читаемые, а не то, что в отлаженное реализации он не очень читаемый (ладно, хреново читаемый)

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

распределенными объектами, аналогами cocoa bindings, сериализацией, анолагаом NSOperationQueue

Не вижу ни одной проблемы. В Qt все описанное красиво реализованно и гармонично вписывается в С++. Кстати как-нибудь наберите NSOperationQueue problems в гугле. Много хорошего узнаете о реализации.

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

Политики распределения памяти мало помогут, там где речь идет о миллионах объектов - тут нужны правильные алгоритмы

Что есть правильный алгоритм для вектора? У него должно быть строго-константное (и не амортизированное) время доступа к элементу. Какой алгоритм будет сильно быстрее красно-черного дерева в map? NSArray, кстати, имеет именно амортизированное время. Я даже приводил ссылку с бенчмарком.

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

Каких именно машинных типов Вам не хватает

Мне не хватает поддержки машинных типов со стороны контейнеров.

Отредактировано crsib (2010-01-26 14:46:09)

0

7

У меня почему-то все работает и Тигр на 1 Гб просто летал.
Только один апдейт разносящий ФС - у M$ гадкие апдейты тоже были (насколько я помню). Не надо обобщать один случай на все.
Красно-черное дерево для миллионов объектов - не верю, тут нужно просто менять алгоритм в зависимости от задачи. И вообще многие задачи плохо ложатся на STL - если речь идет о хранении миллинов точек и поисков по области - тут STL идет на ***.
Миллион строк хранить как красно-черное дерево и искать - тоже заведомо кривой подход - хэш будет лучше.
Ну не делается универсальный контейнер для всех случаев, работа с очень большим числом объектов потребует своего подхода, специфические структуры данных - тоже самое.

IMHO STL - большое зло, так как проделвает жизнь  заведомо дерьмовому языку (и кстати наредкость ублюдксим способом)
Да я испорльзую STL - но для небольших проектов и для небольшого числа объектов - когда проще взять готовое, чем писать свое. И регулярно поминаю разработчиков этого уродства последними словами. Все эти контейнеры неявно что-то предполагают от объектов что-то из этого не выполнено, то начинаются странное поведение.
Реально я использую set/map/string и минимум функций, фикаких функторов.
И мне не хочется иметь тонны медленно компилируемых и совершенно неотлаживаемых макросов с которыми к тому же тяжело работать в отладчике. Фактимчески я используяю STL исключительно из-за каких-дибо внешних обстоятельств.

И можно конкретные ссылки насчет Qt - что там дейстсительно есть работающий аналог Cocoa Bidnings/KVO/KVC, distributed objects и т.п. ? Я этого у них не видел.

Я честно не понимаю откуда такая любой к заведомо уродскому и кривому (не говоря ужде про безумную сложность) языку ?
У меня это тоже было, но уже очень давно как прошло - навреное именно когда я начал разбинраться с работой NextStep и думать можно ли это сделать в С++. Тогда правда было проще - сразу было видно, что это нельзя сделать. Сейчас тонны макросов создают иллюзию, что можно :(((
obj-c намного проще и красивее. Там четко разделены интерфейсы, объекты и структуры, полная поддержка метаинформации, четко понятно что во что откомпилируется, есть простой C API к объектам. А если нужно быстродействие - то С-часть языка не куда не делась

0

8

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

хэш будет лучше

Для этого в SGI STL есть hash_map. Естественно, что выбор контейнера должен зависеть от требований к данным. И да, далеко не все реализовано (да это и не возможно).

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

distributed objects

Их нет. Это не портабельно и сравнительно редко нужно в общем смысле. При этом, есть много библиотек, предоставляющих возможности для распределенного программирования.

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

KVO/KVC

Красивые названия для паттерна Observer и не более. В Qt он реализован через механику signal/slot. Которая для реализации, кстати, не требует прохода дополнительного препроцессора. Балансировка задач на пуле потоков тоже есть.

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

Я честно не понимаю откуда такая любой

Какая любовь, вы о чем. Как сказали на геймдев.ру - С++ - не панацея, а суровая реальность. У языка тупо нет аналогов и свой сегмент (куда суперплотно входит гейдев) он держит в абсолютно безвыходном положении. И аналогов в обозримом будущем не предвидится. (D не в счет. DigitalMars сначала радостно показывал как он плохо умеет читать чужие стандарты. А сейчас - как плохо писать свои.) Так что приходится смириться и познавать дао.

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

фикаких функторов

Очень часто использую. Хотя возможно мы о разных вещах говорим...

Отредактировано crsib (2010-01-26 17:07:40)

0

9

Насчет хэша я имел в виду что для больших объемов по любому нужны специально затеченные контейнеры. Универсальные хороши для прототипирования или при небольших объемах данных.
Насчет KVO/KVC/Cocoa Bindings у меня ощущение, что Вы не совсем понимаете о чем речь - да в принципе это сводится к паттерну observer, но между signal/slot в Qt и ними огромная разница. И, кстати signal/slots требуют препроцессирования.
Про функторы - я имею в виду compile-time объект с определнными operator ().
По сути это Command паттерн, только сделанный через ж*** - только compile time и страшно неудобный и абсолютно нечитаемый код - макрос и есть макрос.
Ну а про реальность - к сожалениею полностью согласен - это ублюдская реальность и пока не видно разумной альтернативы - переходить на С как-то неудобно и куча девелоперов еще верят в С++, вместо того, чтобы признать что это всего лишь уродская реальность и что С++ не развивается а разваливается.
Поэтому кто мог давно ушли на другие языки. А остались либо те кто не может из-за специфики задач/требований или все еще верит, что С++ хороший язык
А obj-c это хороший пример каким может быть язык основанный на С и с действиетльно нормальной объектной моделью. Да, лн сильно не похож на С++/java/C#, но это IMHO как раз и позволяет понять что есть и другие пути развития языка (кроме С++)

0

10

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

да в принципе это сводится к паттерну observer

Я не нашел глобальных отличий. Видимо у нас разный способ оценки удобства и гибкости) Но когда я начинал писать на Obj-C я часто и с любовью вспоминал signal/slot

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

И, кстати signal/slots требуют препроцессирования.

Не требуют. Они даже не требуют С++ под собой (они есть в 3-ем GTK). Существует очень много, в том числе и удобных реализаций signal/slot не требующих ничего, кроме компилятора. При этом с валидацией того, что slot owner скопытился и не предупредил об этом рантайм (а вот в MapKit ее нет (хотя это тоже единичный случай). В том же преусловутом бусте этих реализаций аж две штуки.

0

11

Отличие принципиальное - в Mac OSX /iPhone OS не нужно никаких шагов - просто берете готовый класс (можно и без исходного кода) и просто по имени получаете значение и можете подписаться на уведомление об изменении значения - для поддержки этого ничего не нужно - все делает obj-c runtime, на ходу подменяющий setter у конкретного объекта.
А в общем случае соответствсующий код нужно вставлять ручками - если я заранее не подумал, что надо будет наблюдать за этим полем и в setter не вставил посылку сообщения, то все. А если вставил - то каждый экземпляр класса фактически будет за это платить.

Про signals/slots - я имел в виду как это сделано в Qt. А так это можно сделать через тонны макросов и очень долгую компиляцию. Ну не умеет это уродство (С++) нормально работаеть с казателями на методы без макросов и идет создание новых классов, зачастую с виртуальными фунекциями и т.п. По сути указатель на метод в С++ вообще есть непонятно что и сделан через большую Ж***

0

12

И кстати про ненужность distributed objects - это не ненужность, а не возможность их сделать на С++ не через жопу.
А с нужностью все в порядке - плагин, запущенный отдельным проецессом чтобы при падении не порушить основное приложение, если я не ошибаюсь в Chrome даже табы сделаны как различные процессы с той же целью.
Взаимодействие объектов, находящихся на одном компе но в разных адресных прострнатсвах (процессах) - это вполне пример на DO.

И насчет кривости и глючности Mac OS X Вы раскажите на каком-нибудь маковском форуме, например applelife.ru и послушайте, что Вам скажет много людей, постоянно работающий с Маками.

0

13

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

это вполне пример на DO

Это вполне пример не на DO. Это пример того места, где сначала надо думать головой, а потом использовать IPC. Который абсолютно замечательно себя чувсвует на всех так или иначе адекватных языках (при наличии реализации механики со стороны ос, а она есть на всех полновесных осях), включая и С, и С++. Идите и расскажите раработчикам Апача, Сысоеву, Trolltech (упс, Nokia), Торвальдсу что для взаимодейтсвия процессов на одной физической машине нужны DO. Пусть посмеются люди. DO нужен для распределенного программирования, а не для того, что бы заниматься взаимодействием между процессами и уж, боже упаси, потоками. Нет, его конечно можно применять и для этого, но это тоже самое, что палить по воробьям из гаубицы. Да и так уж сложился мир, что все обещания легкой масшатбируемости на гетерогенные вычислительные системы обычно ломаются о реализацию. Это как раз тот случай, где выбор алгоритма и инструментария строго индивидуален.

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

Вы раскажите на каком-нибудь маковском форуме, например applelife.ru

Там об этом регулярно пишут. Как и на ру_маке. Как и в блоге apple на хабрахбре. Как и на любом другом ресурсе. И отвечающие делятся на две категории - на тех, кто недавно перешел на яблочную продукцию и пока еще в эйфории (я пребывал в ней года полтора) и на тех, кто ей пользуется давно, знаком с большинством проблем, так как у самих возникали, но по какой-то причине привязанны к платформе и не могут безболезненно с нее вернуться на PC (и даже не обязательно на Windows). Людей первой категории так же отличают фразы типо этого или фразы моей сотрудницы (у который mb pro около трех месяцев) "Хорошо, что когда он сломался, я была в Германии, там отстояла в очереди в авторизированный сервис центр. Но все равно Apple лучше всех"

0

14

Так как все-таки с KVC/KVO/Cocoa Bindings в Qt (или просто на С++ ) - никак, на этом г* (С++) этого не бывает
Про DO - они не всегда нужны, например если нет объектов то и DO тут ненужны.
Но если речь именно о взаимодействии объектов а не просто переливание данных то DO будут вполне удобны. Кстати они вполне нормально работали (как и Foundation/AppKit) на старых Next'ах с 25 МГц процессором и 12 Мб памяти.
Да DCOM/CORBA - это редкостные гаубицы, а вот DO на obj-c - это очень просто (а вот нормальный TCP/IP стек будет просто редкостным монстром по сравнинию с DO на obj-c)
По поводу форумов - в обще-то речь о "кривости и глбчности" Mac OS X - а у Вас как-то разговор переведн на  сбои железа. Сбои железа бывают у всех компов, ни один бренд от этого не застрахован.
Но речь идет именно о Mac OS X - где ругань на сбои и т.п ?
Ну и где люди которые очень хотят уйти с Мака но не могут (M$ в свою время придумали подобную сказку, но их быстро разоблачили)?
У Маков есть устойчивое и лояльное коммьюнити порльзователей - у кого из компьютерных брендов это есть ?
И пока у Вас все-таки аргументы на уровне "об этом регулярно пишут" - а реальных примеров нет

А насчет Qt -люди, которые его написали, просто герои - сделать такой качественный продукт на таком дерьме как С++

И, кстати, в чем странность контейнеров Foundation - по-моему наоборот очен удобно и  просто.
Просто это не так как в С++. У меня есть ощущуение, что многочисленные наезды на тот же obj-c связаны с тем, что он ДРУГОЙ, там другие подходы и приемы, другая идеология
Как и в Mfc OS X - она просто другая и построена на других принципах.

А signal/slot d QT для меня - это криво сделынный NSNotificationCenter (хотя я намного  раньше разобрался с NSNoticiationCenter чем с QT)

Мне кажется что Вы просто привыкли к Qt и пытаетесь все заточить под идеологию Qt а с objc/Cocoa это не получается
Ну и водгонку - еслия не ошибаюсь Qt не испорльзуют  STL/boost и очень мало используют темплейты
И еще как пример - Google C++ style guide - никакого множественного наследования, никаких exception-ов  (значит STL/boost  в основной массе идут  на*)
Получается что серьезные разработчики как-то не рвутся использовать весь этот макросный бред

Вы очень верно написали "С++ - не панацея, а суровая реальность. У языка тупо нет аналогов и свой сегмент (куда суперплотно входит гейдев) он держит в абсолютно безвыходном положении. И аналогов в обозримом будущем не предвидится" - и пока все будут так считать и не пробовать/искать альтернативы так и будет - вон сколько лет COBOL уже живет в своей ниже и ничего.
На мой взгляд obj-с как минимум показываем, что есть другие пути, кроме С++ и что эти в ряде случаех удобнее и проще

0

15

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

KVC/KVO/Cocoa Bindings

Все эти ваши модные слова не несут за собой больше, чем Observer. При этом они жестко нарушают инкапсуляцию (на пару с рантаймом языка - он явно отдает больше информации чем нужно). На Qt я тоже могу взять готовый класс, без исходного кода и по имени подписаться на изменение тех величин, которые разработчики библиотеки сочли нужными открыть тем или иным способом. При этом я не нарушу инкапсуляции и вероятность того, что я поломаю работу библиотеки намного ниже.

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

на старых Next'ах с 25 МГц процессором и 12 Мб памяти

Я не работал с этими машинами. И, если честно, почти уверен, что и вы тоже. Я не могу давать комментариев по этому поводу. Зато я уверен, что Foundation и *Kit изменились чуть менее, чем полностью.

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

а вот DO на obj-c

То есть PDO работает за счет магических сил Джобса? Не хочу вас огорчать, но это всегда IP на layer 3 и почти всегда TCP/UDP на layer 4. Ну конечно не считая случаев, когда это IPC или работа с просто шаренной между потоками памятью.

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

Но речь идет именно о Mac OS X - где ругань на сбои и т.п ?

Да вы сами почитайте. Там только про них и пишут. И это нормально для форумов.

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

Ну и где люди которые очень хотят уйти с Мака но не могут

Я хочу. Но не могу. Потому что на работе пишу под iPhone. Мой сотрудник хочет, но не может по той же причине.

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

У Маков есть устойчивое и лояльное коммьюнити порльзователей

У маков есть толпа далеких от IT фанатов с большими кошельками. Чем менее популярно направление, тем менее адекватны его фаны. Возьмите тот же фашизм... У него есть устойчивое комьюнити - скины. Их сравнительно мало и они все малоадекватны. У Apple ситуация чем-то лучше, но почти все радостные вопли идут от людей, которым важны просто понты. Которые считают, что они чем то выделяются. Если бы Microsoft принадлежала столь же незначительная доля рынка, то у него тоже были бы толпы фанов.

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

И, кстати, в чем странность контейнеров Foundation - по-моему наоборот очен удобно и  просто.

Я вполне четко объяснил чем. Они медленные и умеют работать только с наследниками от NSObject.

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

Mfc OS X

Опечатка по Фрейду

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

она просто другая и построена на других принципах.

Она не построенна на других принципах. Это просто очень неудачная реализация всего - начиная с ядра, которое взяло от идей Таненбаума только худшие черты, заканчивая application layer'ом - причем я сейчас о Foundation, а не о CoreFoundation. Система валится в кернел паники по малейшему сдвигу в сторону. Недавно ее завалил флеш-плеер.

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

никакого множественного наследования

Внимательно перечитываем документ. Гугл разрешает множественное наследование от чисто абстрактных классов всегда и в обычном смысле там, где это очевидно полезно - то есть все base классы предоставляют реализацию разных понятий. Про шаблоны не сказанно не слова - в Qt, кстати, они используются довольно часто. Причин не использования исключений явно не указанно - но почти наверняка ими не пользуются из-за того, что не все компиляторы следуют ANSI стандарту.

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

На мой взгляд obj-с как минимум показываем, что есть другие пути

Obj-С - тупик. как было сказано, если не ошибаюсь, на stackoverflow - "obj-c взял скорость от Smalltalk и безопасность работы с памятью от С". Язык не быстрее Java/C#, и в его случае  то, что он компилируется в машинный код - скорее минус, чем плюс. То, что язык "быстрее" на Cotex A8 - жесткое исключение. Волею звезд в одном процессоре оказалось много кеша и почти бесплатный бранчинг. И то, все хорошо, пока генерируются short-call. Работа с foundation явно показывает сколько стоят far-call'ы на Arm архитектуре...

0

16

Все эти ваши модные слова не несут за собой больше, чем Observer. При этом они жестко нарушают инкапсуляцию (на пару с рантаймом языка - он явно отдает больше информации чем нужно). На Qt я тоже могу взять готовый класс, без исходного кода и по имени подписаться на изменение тех величин, которые разработчики библиотеки сочли нужными открыть тем или иным способом. При этом я не нарушу инкапсуляции и вероятность того, что я поломаю работу библиотеки намного ниже.

Если Вы не понимаете что они несут - почитайте хорошо про Cocoa Bindings - там столько всего, что на С++ в принципе не сделать.
Кстати тот же observer может быть асинхронным, distributed - как с этим в Qt (только если есть - prooflink plz)

Посмотрим на http://habrahabr.ru/blogs/qt_software/82665/ - вот к чему идет Qt - QML + javascript и все.  И это логично и понятно - гибкость которой на С++ не было и никогда не будет. Вот  оно светлое будущее для Qt  :)))

Я не работал с этими машинами. И, если честно, почти уверен, что и вы тоже. Я не могу давать комментариев по этому поводу. Зато я уверен, что Foundation и *Kit изменились чуть менее, чем полностью.

Да лично я практически е работал - у меня хоршие друзья много работали и после перезда в Штаты купили себе старый Next - смотришь, что он может и понгимаеь - это ВЕЩЬ, легендп.
А насчет того, кто работал на NextStep - Кармак работал, собственно Doom 1/2/Quake делались именно на Next-ах, можете почитать что КАрмак писал об этой платформе.

К сожаление Вы пока так и не привели релаьных ссылок на море людей, страдающий под Mac OSX - flash это основная проблема, а что есть кроме нее. Желательно с prooflinkами на кучи страдающих людей.

Ну и про тупиковость/глбчность и т.п - попробуйте рассказать это кому-то из людей, который многие годы пишут под Mac OS X - mikeash.com, http://ridiculousfish.com/blog/, http://wilshipley.com/blog/, http://daringfireball.net/, http://www.bignerdranch.com/
Часть из них работает еще со врем NextStep - и кстати контейнерные классы очень мало изменились с тех пор. Стало чуть больше методов и все.

Ну а stackoverflow - то, что Вы процутировали - просто бред безграмотного разработчика, не знающего ни smalltak ни obj-c
А тупик - это именно С++ с кучей изначально заложенных в него дыр, вокруг которых понастроили кучи космтылей и подпорок - язык стал очень сложным, но кривость никуда не делась.
Как указатели на методы были кривой и малопригодной сущностью, так они и остались (надо быть законченным дебилом, чтобы сделать что указатели на методы базового и дочернего класса не совместимы ни в одну сторону) - хотя с помощью template'ов это можно подправить ценой увеличения сложности и создания новых сущностей.
Сваливание в одну кучу структур, объектов и интерфейсов - явно бредовый ход, те же jva/C# от этого отказались.
Множественное наследование объектов (не интерфейсов)- полезность этого сомнительна, а вот проблем создает множество.

Читая Ваши посты создается впечатление, что Вы постоянно в tightloop-е вызываетие методы - но вряд ли Вы так делаете на самом деле.
Для GUI быстродействие методов практически не важно.
А все, кроме вызовов методов пишется как и в С и будет выполняться с той же скоростью (в отличии от java).

ЗЫ. Глядя на многочисленных знакомых я заметил, что есть два непересекающихся класса - кому нравится Perl и кому напрвится  Python - пересечение отсутстувует.
Возможно с C++ vs obj-c ситуация аналогична.
Давайте закончим ругань obj-c - я привел места, где можно это сделать с участием людей, обладающи очень большим опытом работы с Mac OS X и obj-c - там я с удовольствием присоединюсь к этому

0

17

Присоединюсь к вашей дискуссии.
Интересует мнение о современных Паскалях - как то Lazarus(визуально как делфи, но и под все ОС), Delphi(компилит и под мак нативные проги), Free Pascal.
Насколько я понимаю, стандартные библиотеки просты и эффективны, работа с классами и типами тоже хороша.
А ассоциативные массивы и b-tree я и сам на Паскале писал :)

0


Вы здесь » Компьютерная графика » Дзен » Небольшой бенчмарк iPhone 3G и iPhone3GS


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