В конце той новости Боресков все-таки не сдержался, и откровения из него начали бить тугой струёй. Вот избранное:
"Замечательный пример - в якобы статически типизированном языке можно объявить функцию с параметром типа const std::string &, и передать ей значение false:
#include
#include
void f ( const std::string& s )
{
printf ( "%s\n", s.c_str () );
}
int main ( int argc, char * argv [] )
{
f ( false );
return 0;
}
Скорее всего это все полностью соответствует стандарту, но ведь это бред - значение одного типа легко переводится в значение совершенно другого типа. И никаких warning, все успешно компилируется и при запуске падает."
Борескову невдомек, что согласно определению C++ является статически типизированным языком (http://ru.wikipedia.org/wiki/%D0%A1%D1%82%D0%B0%D1%82%D0%B8%D1%87%D0%B5%D1%81%D0%BA%D0%B0%D1%8F_%D1%82%D0%B8%D0%BF%D0%B8%D0%B7%D0%B0%D1%86%D0%B8%D1%8F).
Более того такое поведение полностью соответствует стандарту. False трактуется как NULL, а NULL как NULLовский char *. В итоге никакого нарушения в логике работы программы или функционирования компилятора не происходит — говно написали, говно получили. Наука не придумала ещё способа превращать говнокод в шедевр кодирования и алгоритмизации. Хотя возможно Борескову и открылась эта несомненно божественная истина. Кто знает.
«Большая просьба к тем, кто увидев это захочет сказать, что я ничего не понимаю в таком прекрасном языке как С++...»
Таких заявлений я делать не буду ибо с автором лично не знаком.
«... сколько всего на нем написано и т.д...»
На нем действительно очень много всего написано и это зачастую является решающим фактором в выборе языка разработки. Это верно для любой промышленного софта. Хотя незатейливые демки по компьютерной графике можно клепать хоть на Коболе. В этом случае фзык не важен вообще. «...прочтите для начала пару ссылок по objective-C, и сравните с С++. Some Nice Features of the Objective-C Language и моя статья по objective-C.»
Первая статья шлак — просто набор лозунгов. Вторую статью разберу позже.
«Просто, чтобы понять альтернативу.»
Уссачка полная. Сразу вспомнилась боянистая картинка про малолетних идиотов:
Что касается objective-c++:
«Язык был придуман Брэдом Коксом (Brad Cox) в начале 80-х годов прошлого века. Целью Кокса было создание языка, поддерживающего концепцию software IC. Под этой концепцией понимается возможность собирать программы из готовых компонент (объектов), подобно тому как сложные электронные устройства могут быть легко собраны из набора готовых интегральных микросхем (IC, integrated curcuits).
При этом такой язык должен быть достаточно простым и основанным на языке С, чтобы облегчить переход разработчиков на него.»
А вообще самих-то разработчиков кто-нибудь спросил? Они сами-то собираются переходить с C на Объектный С? Что-то мне подсказывает что врядли. Сейчас на C пишутся драйвера, серверное ПО ну и, наверное, компиляторы. Первое и второе врядли будет писаться на Объектном С, компиляторы тоже врядли... В итоге ценность возможности этого перехода весьма сомнительна.
«Одной из целей было также создание модели, в которой сами классы также являются полноценными объектами, поддерживалась бы интроспекция и динамическая обработка сообщений.»
За подобные объединения сущностей надо жечь на костре.
«...в язык С просто добавлены новые возможности для объектно-ориентированного программирования. При этом любая программа на С является программой и на Objective-C (для языка С++ это не верно).»
С++ является «почти» расширением языка C. Просто взяли и выкинули из C фичи, которые явно не нужны или приводили к ошибкам. Поэтому возникла некоторая несовместимость. В Объектный С весь этот шлак видимо вошел в полном объеме. Мой привет авторам )).
«Еще одной из особенностей языка является то, что он message-oriented в то время как С++ - function-oriented. Это значит, что в нем вызовы метода интерпретируются не как вызов функции (хотя к этому обычно все сводится), а именно как посылка сообщения (с именем и аргументами) объекту, подобно тому, как это происходит в Smalltalk-е. Такой подход дает целый ряд плюсов - так любому объекту можно послать любое сообщение. Объект может вместо обработки сообщения просто переслать его другому объекту для обработки (так называемое делегирование)...»
Ах, делегирование это само по себе прелесно. Однако ни одна фича в серьезных проектах не используется сама по себе, а всегда в сплаве с другими фичами. Не всем известно, что такая суперпозиция фич приводит к интересным эффектам. Например взять Python. Там тоже есть делегирование, есть сборка мусора и есть функция del, которая позволяет принудительно удалять созданные объекты. Теперь следите за ловкостью рук: создаем объект, делегируем вызов какого-либо из методов этого объекта другому объекту, для первого объекта вызываем del. Что произойдет при вызове функции del? В больших проектах мы этого сказать не сможем. Потому что при делегировании был передан не только указатель на метод но и неявно был передан указатель на объект, делегирующий вызов своего метода. Ну это вполне логично, потому что метод может использовать поля объекта, и для этого ему нужен указатель на сам объект. Теперь дальше: del удалет объект если счетчик ссылок на него равен 1. Т.е. Кроме ссылки передаваемой del никаких других ссылок нет. А в нашем примере есть. Поэтому удаления не произойдет (кстати dtlete в C++ ведет себя гораздо более честно — нам дана гарантия что для корректного указателя будет корректно освобождена память). Более того, о том что удаление было сорвано мы никак не узнаем — del тупо ничего не возвращает и не кидает исключений. Есть две возможности обойти эту проблему — либо руками лезть в кишки GC механизма, либо для каждого класса делать функцию Release, которая сама будет принудительно удалять выделенные ресурсы. В итоге от чего пытались уйти к тому же и пришли — ручное управление ресурсами, практически ничем не отличающееся от того что реализуется в каждой C++ программе.