Objective-C для программистов C++

Толсто! И это все (неумелый троллинг, отсутствие познаний в Смолтоке, откровенный бред) есть продукт недалёкости и заблуждений фрейма-куна.

А по существу есть что-таки сказать?

>и не смотрел онемэ

Ну и напрасно.

>То, что до Cocoa был Carbon?

Carbon — чистый C, без исключений.

Кстати, может, даже среди регистратов есть спецы по яббло-апи: интересует инфа, как там устроены RunLoops. В доке всё на уровне рецептов, а что-то более-менее advanced сделать сложно.

Как, например, запретить user interaction, а потом подождать, пока обработаются все накопленные в очереди собщения. Ну и в таком духе.

> Carbon — чистый C

Я знаю, что он написан на обычном процедурном Си. И то, что MacApp для него написан таки на C++ - и именно на С++.

А теперь вопрос какое отношение имеет Obj-C к С++, кроме как Objective-C++? Что конкретно имелось в виду?

>C# мой хлеб.

да вы батенька копрофаг

>А по существу есть что-таки сказать?

про существо под ником Bioreactor мне нечего сказать

>>: С# - попа с ручкой
>гаааааа :) Ну вы жгуны, братва! :)))))))
>Java - кофе, пропущенное через sun.
Так как уже писали, что C# это Java + syntax sugar, то
Java - жопа с ручкой.

>А теперь вопрос какое отношение имеет Obj-C к С++, кроме как Objective-C++? Что конкретно имелось в виду?

Вот это. Если ты хоть чуть-чуть на этом писал, то должен понять. http://idisk.mac.com/adarovsky-Public/Exception.png

>> C# мой хлеб.
> да вы батенька копрофаг

А без троллинга никак? Лишь бы ляпнуть?

Никогда не понимал людей яростно доказывающих, что язык Х лучше языка Y. Плохих языков не бывает.. бывают кривые программисты.

+1

Я уже говорил откуда это взялось. Куски кода от CodeWarrior пока не подчищены. Но какое отношение это имеет собственно к Objective-C, а не legacy библиотекам?

А еще бывают кривые программисты, пишущие такие недоязычки, не нужные никому, кроме своих создателей, как, например, C#.

Да, кстати, в 64-битной среде модель исключений общая между Obj-C 2.0 и С++. И даже деструкторы плюсовые можно вызывать корректно. И что? В C++ уже есть позднее связывание?

>Я уже говорил откуда это взялось.

говорил, только не то и не о том. Оно там для того, чтобы поддерживать как исключения Obj-C, так и C++. Потому что ябблы, в отличие от обитателей лора, лангофобиями не страдают.

>Куски кода от CodeWarrior пока не подчищены

можно поспорить, что и не будут.

>Но какое отношение это имеет собственно к Objective-C, а не legacy библиотекам?

Такое, что ябблы, в отличие от обитателей лора, лангофобиями не страдают. И даже в (sic!) приложениях для iPhone можно использовать C++. Не иначе, зловредный CodeWarrior и туда проник :)

>В C++ уже есть позднее связывание?

ты хоть знаешь, что это такое? :) Виртуальные функции, по твоему, как работают?

Вот в Obj-C его нету, зато есть интроспекция, счёт чего проще делать гуёвые приложения. Qt для этого, например, пришлось изобретать сигналы, слоты и метаклассы.

>Вот в Obj-C его нету

точнее, нету в понимании C++. Создание классов при загрузке модуля можно обозвать поздним связыванием, при желании.

> Виртуальные функции, по твоему, как работают?

Это я знаю http://developer.apple.com/documentation/Cocoa/Conceptual/OOP_ObjC/Articles/c... (врезка Late Binding:)

> Вот в Obj-C его нету

Формулирую более четко - в С++ есть _динамическая типизация_

Варианты ответов:

1. Да

2. Нет

> интроспекция

Интроспекция есть и в Жабе. Но в Жабе нет динамической типизации. В Smalltalk динамическая типизация есть. В O-C тоже есть.

> нету в понимании C++

За корректное уточнение - респект!

>Формулирую более четко - в С++ есть _динамическая типизация_

Там строгая статическая типизация.

В Obj-C, кстати, тоже :) Единственное место, где есть "слабина" — собственно, заимствование из SmallTalk — посылка сообщений. Но разделить это дело и интроспекцию довольно сложно. Можно ведь и из С вызывать objc_msgSend. Который известным образом будет этот метод искать и вызывать.

>Интроспекция есть и в Жабе. Но в Жабе нет динамической типизации

Можно через reflection добыть метод, и вызвать. Не имея явной декларации типа. ИМХО, сильно похоже на objc_msgSend. Другое дело, что многословнее, и обычно не поощряется. Статическая типизация, таки, быстрее. Позднее связывание отрабатывает один раз, и во время вызова метода он не ищется, что есть большой плюс в производительности.

> Позднее связывание отрабатывает один раз, и во время вызова метода он не ищется, что есть большой плюс в производительности.

Многие Smalltalk VM умеют оптимизировать посылку сообщений так, что во время вызова в 80% случаев ничего не ищется - так называемая IL-оптимизация. Судя по моему опыту нормальная Smalltalk VM (типа Visual Works) делает, например, жабу и по скорости и по потреблению памяти как стоячую. Image с загружеными ~5K классами и полной средой разработки жрёт меньше 80Mb RSS - сколько отжирает любая жабская IDE только при старте думаю рассказывать не нужно. Про скорость работы это всего я лучше вообще промолчу. Вот вам и статика vs. динамика.

> Там строгая статическая типизация.

> В Obj-C, кстати, тоже :)

Хм....

Таки IMHO "средней строгости" (сильнее, чем Smalltalk, слабее чем Java) ДИНАМИЧЕСКАЯ типизация. Хотя википедисты говорят, что "слабая динамическая"

http://en.wikipedia.org/wiki/Objective-C

-----
По поводу типов у Гослинга много "мыслью по древу" в гл.11 4-го издания, хотя в Джаве интроспекция проста как 5 копеек

import java.beans.BeanInfo;
import java.beans.Introspector;
import java.beans.IntrospectionException;
import java.beans.PropertyDescriptor;
public class SimpleBean {
private String name = "SimpleBean";
public String getName() { return this.name;}
public void setName(String name) {this.name = name;}
// ...
public static void main(String[] args) throws IntrospectionException {
BeanInfo info = Introspector.getBeanInfo(SimpleBean.class);
for (PropertyDescriptor pd: info.getPropertyDescriptors()) {
System.out.println(pd.getName());
// ...
}
}
}

Задачка для автора статьи. Перенести код в Obj-C. :)

ЗЫ. Спасибо за дискуссию! :)

> делает, например, жабу и по скорости и по потреблению памяти как стоячую.

И более того, VA for Java был написан на ST. Бимеры загубили проект. Сейчас убогий "иклипс", который только внешне весьма грубо и отдаленно напоминает смолтоковские среды типа VAST. Если Java Browsing перспективу поставить.

В Tiger'e тоже была отдельная утилитка из меня для просмотра Джава классов, но в Leopard'e её я не наблюдал. Забили, видать. :-(

> Судя по моему опыту нормальная Smalltalk VM (типа Visual Works) делает, например, жабу и по скорости и по потреблению памяти как стоячую

Судя по всему, Obj-C не может себе таких финтов ушами позволить. Потому что нет гарантии, что кто-то напрямую туда полезет.

>ЗЫ. Спасибо за дискуссию! :)

велкам )

> Судя по всему, Obj-C не может себе таких финтов ушами позволить. Потому что нет гарантии, что кто-то напрямую туда полезет.

Такие финты оптимизации IMHO без VM вообще невозможны - ибо VM собирает статистику по вызовам и на лету перекомпилирует методы при необходимости. Как такое учудить без VM я плохо представляю.

уж слишком много в нем smalltalk-а, D куда естественнее.

> нормальная Smalltalk VM (типа Visual Works) делает, например, жабу и по скорости и по потреблению памяти как стоячую. Image с загружеными ~5K классами и полной средой разработки жрёт меньше 80Mb RSS - сколько отжирает любая жабская IDE только при старте думаю рассказывать не нужно.

Свежезапущенный Эклипс отжирает примерно 100М. Правда, не уверен, что там всего-навсего 5К классов.

> Свежезапущенный Эклипс отжирает примерно 100М.

Чаво ?!!! Только что проверил - ganymede SR1 - чистый старт - 342 метра RES и 1.1Gb VIRT - amd64. И ползает при этом как черепаха, на двухядерном камне и 2Gb мозгов. Да, полный эклипс - over 38K классов. Но, извините, это совсем не показатель - сырцы hibernate более чем в четыре раза толще сырцов GLORP'а, а функциональность практически один в один, и я таки уже молчу про удобство использования. Свежезапущенная IDEA отжирает 320M и через полдня работы спокойненько отжирает полтора гига на средненьком проекте, я и второй гиг в ноут добил только из-за неё - для остального гига хватало за глаза.