Я не скрвыю свое отношение к 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 может компилятором полностью игнорироваться) и поддержки абстрактных типов данных (тут у С++ позиции сильны).

Насчет "Ни одного качественно-сделанного продукта" - у меня 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 я имел в виду именно стандарт С++

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

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

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

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

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

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

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