Сообственно сабж и ваше отношение к нему...   

И почему он оказался не востребованным? 

Приятная вещь. И даже несколько крупных проектов на нем написано. НО, если вспомнить 
объектно-ориентированную надстройку на TurboPascal и сравнить удобство работы с ней и с ObjectPascal (Delphi), то я думаю, что станет ясно почему - зачем держать ООП-надстройку над C, когда есть гораздо более мощный и совершенный C++? А те, кому C++ не нужен остались на чистом C. Им просто ООП ни к чему. 

popovda, только не надо, пожалуйста, мешать в одну кучу «объектно-ориентированную надстройку в TurboPascal» и Objective-C/C++! (Именно так, есть оба языка: и Objective-C, и Objective-C++!)
(А может быть, Вы путаете слова «Object» и «Objective»?)

Objective-C/C++ -- это самостоятельные и вполне развитые языки програмиирования, которые активно используются там, где призваны и обосновались в силу, в основном, исторических причин. 
Цитата из Википедии: 
«Компилятор Objective-C входит в GCC и доступен на большинстве основных платформ. Язык используется в первую очередь для Mac OS X (Cocoa) и GNUstep — двух реализаций объектно-ориентированного стандарта операционной системы NeXTSTEP/OpenStep.»

И крупные проекты на нём и для него, действительно, написаны. И, в основном, как раз, для Mac OS X. Например, Cocoa и Xcode.

А те, кому не достаточно Objective-C, мне кажется, могут обратить внимание на Objective-C++: http://developer.apple.com/releasenotes/Co...ective-C++.html


Это сообщение отредактировал(а) V.A.KeRneL - 22.12.2009, 23:16

Насколько я знаю, Objective/C и C++ -- это, прежде всего, две разных парадигмы. Разные подходы к расширению C: С++ -- идеология языка Simula (достаточно строгая объектная типизация, классы как расширение структур и т.п.), Obj/C -- это идеология Smalltalk (все более гибко, есть т.н. метаклассы, "методы классов" и "методы экземпляров" и т.п.) Т.е. сравнивать даже немного некорректно: слишком разные подходы к ООП.

И нельзя сказать, что Objective C совсем уж не востребован: на нем в свое время написано много было, особенно на таких платформах как NEXT и рабочие станции всякие. Большая популярность C++, по видимому, объясняется тем, что 1) реализация ООП, конечно, эффективнее, 2) подход к внедрении ООП в язык более эволюционный, поэтому людям, переходящим с C, все было понятнее.

Ну извините, граждане, ляпу дал.  Кстати, после слов о MacOS началь мучительно вспоминать, где мне пришлось с ним сталкиваться. Наверное, это insight при сборке в Linux'e его затребовал. НО! К сожалению у нас о нем не очень-то слышно, видимо из-за отсутствия маков на массовом рынке.
И еще, по-поводу gcc, я то и посчитал, что это настройка, т.к. в моем дистрибутиве Linux Objective-C 
идет как ДОПОЛНИТЕЛЬНЫЕ БИБЛИОТЕКИ к gcc, в отличии от g++.

Еще раз извините. Счастливого Нового Года.

А кто сказал что С++ эффективнее? У Obj-C футпринт как правило меньше.

В Мac OS X очень даже популярен. На нём написаны многотонные фреймворки. В Mac OS X есть два основных интерфейса: Carbon и Cacao. Carbon чисто сишный, и вообще создан для лёгкого портирования с Mac OS Classic, не имеющей с Mac OS X практически ничего общего. Интерфейс Carbon по устройству подобен UI других OS, поэтому на него удобно портировать. Тем не менее, Carbon уступает Cocoa. Ну, не знаю, как это объяснить. Это пользоваться надо. Например, если у меня открыто окно QuickTime Player, то у него в заголовке имя открытого файла со значком. Так вот, этот значок "настоящий", его можно перетащить куда–нибудь, и эффект будет тот же, как если бы я перетащил его из той папки, где он лежал. Можно копировать, можно перенести, можно открыть в другой программе, всё как положено. А вот Word 2004, который на Carbon, такого не позволяет. Начинаешь тащить значок, а перетаскивается всё окно. Или, например, я поставил проверку орфографии, во всех прогах работает. Вот даже сейчас я пишу, у меня слова «прогах», «сишный» красными точками подчёркиваются. А в Carbon прогах это не работает. Выше упомянутый франкенштейн Objective-C++ создан как раз, чтобы из C++ прог использовать Cacao. ЕМНИП ObjC++ есть только на Mac OS X.


Ничего не имею против ООП, но C++ — это последний ЯП, на который я смотрю, когда оно мне нужно.

Смею напомнить слова Alan Key:
http://www.smalltalk.org/articles/article_20040731a.html



В ObjC идеология SmallTalk внесена только наполовину. С моей точки зрения то, что нужно, как раз в ObjC и не попало вовсе. Это просто рекламная ложь сформировала стереотипы. Даже если не знаешь C++ и ObjC, уверен, что C++ — от Simula, ObjC — от SmallTalk. Нифига подобного.

Поясняю. В SmallTalk объекты обмениваются сообщениями. Именно сообщениями. Это не то же самое, что вызовы методов. Подобная штука называется МАС, многоагентной системой. Важное свойство, её легко распараллелить. Есть одна прикольная библиотека для C, Protothreads, довелось поиграться. Там обыгрывается несколько особенностей языка C. По сути, удачный хак. Смысл в том, что можно делать безстековые легковесные потоки. 

Насколько мне известно, на просто легковесных потоках (со стеком) уже пытались выиграть в производительности (в Solaris). Правда, как я понял их проблему, если какой–то LWP вызывает блокирующую операцию, она блокирует и мастер–поток, и вообще может привести к тупику. Если честно, у меня напрашивается вопрос, а не поменять ли все блокирующие операции (в том числе примитивы синхронизации) на их аналоги, которые бы корректно работали в среде LWP. Все операции ввода–вывода заменить на асинхронный ввод–вывод с передачей управления мастер–потоку, и т. д. Ну да ладно, пусть сами разбираются.

Протопотоки круче легковесных, потому что их может быть ну очень много. Легковесным нужен стек, а протопотоки используют стек своего мастер–потока. Им только свои локальные переменные хранить. В принципе, протопотоки можно даже форкать.

С точки зрения внешнего наблюдателя, протопоток представлен некоторой функцией. Её вызываешь, а она возвращает результат, вызывать её ещё или нет. Как уже организовать сосуществование и взаимодействие этих протопотоков, библиотека не указывает. С точки зрения внутреннего наблюдателя, эта функция не теряет управление. Ну, разве что, все локальные переменные приходится хранить в структуре. И это вообще не функция. Это поток.

Вот такую бы вещь, только не в виде хака, я бы мог ожидать от Objective C. Но нет. В Objective C это просто завуалированный вызов метода. Ну да, чуть замудрённый. Но по сути те же Delphi, только с фигурными скобками. Это уже не SmallTalk.

Apple только на словах "Think different". Может, когда–то оно так и было. Сейчас скатились до ширпотрёба.


http://gcc.gnu.org/frontends.html
Английским по белому написано:

Всякие Паскали и Модулы — это надстройки, Objective C — нет.

Если у вас в GCC нету Objective C, или Ады, или Фортрана, или вообще чего–либо из этого списка, значит, у вас нет GCC. Или он ну настолько стар, что ещё не включал в себя этот frontend.

В современных ОС пакеты под названием GCC содержат 20% GCC или около того. А те самые «дополнительные» в кавычках дополняют его до желаемых 100%.

В этом плане свинство Apple просто поражает. Дистриб ОС поставляется на DVD. Леопард ЕМНИП на двуслойном DVD. В дистрибе всегда есть утилиты разработчика. Вот же жь сюрьприз был, когда на таком здоровенном дистрибе не оказалось установочных файлов GNAT. Очень неприятно было 170Mb (на самом деле 290Mb, там PowerPC отдельно 120Mb, он мне тоже нужен) с нета качать, когда вообще–то всё уже должно было быть на месте, тем более, места–то допупища.

Антиреспект, в общем.


C++ эффективнее Objective C. Участков кода получается больше, но эти участки специализированные. Универсальный код по определению работает медленнее.

Не удержался и вношу свои 5 копеек 

В чем ее еще мерить, эту эффективность. С++ приложение почти наверняка будет кушать больше памяти, чем аналог на ObjC, особенно если использует всякого рода template'ы (в лице, скажем, STL), что может сильно сказываться на производительности.
Да, OCTAGRAM, насчет участков кода свою мысль поясните, пожалуйста - что там универсально и специализированно в С++ и ObjC (это не наезд, просто реально интересно ).

По поводу собственно языка. Возился с ним недолго, но в целом он мне понравился побольше С++: простая и внятная реализация ООП, интересный подход к управлению памятью (в Cocoa), наличие RTTI ну и всяко такое.
Огорчили, правда, такие вещи:
1. излишний, на мой взгляд, динамизм: возможность послать любому объекту любое сообщение, ИМХО, являет собой отличную почву для трудноуловимых runtime-ошибок. Мне в этом плане спокойнее живется под гнетом строго компилятора, который не разрешит вызов метода, которого у объекта заведомо нет.
2. если private-метод еще можно создать, воспользовавшись кой-какими трюками, то создание protected-метода в ObjC, похоже, невозможно, что также не есть гут: у меня часто возникают ситуации, когда метод потомкам должен быть доступен (для переопределения или просто внутреннего использования), однако выставлять его во всеобщий доступ по ряду причин нельзя
Были еще кой-какие недочеты, но они в большей степени относятся к Cocoa, нежели самому ObjC.