За что я не люблю С++

Только вот как понимать ОО - я не думаю, что программисты, пишущие на Smalltalk'е, сочтут С++ объектно- ориентированным языком. Даже по сравнению с Java С++ явно в проигрыше - нет интерфейсов (зато есть множественное наследование со всеми его проблемами), объектная модель просто отсутствует.

Понятие метаинформации (а также reflection, introspection и т.п.) в С++ отсутствует полностью (а вся среда Smalltalk построена на ней).

Много ли Вы знаете простых и удобных persistence -библиотек для С++, которые бы сами могли сериализовать произвольные объекты ? Максимум, что есть, это сложные библиотек с кучей ограничений и необходимостью вручную (зачастую при помощи макросов) задавать фактически часть метаинформации.

А вот в Smalltalk'е или в Python'е таких библиотек полно.

А как дела у С++ с интеграцией со скриптовыми языками - Perl, Python, Tcl, Ruby и др ? Опять же очень плохо - надо ручками задавать всю необходимую метаинформацию. Есть правда генераторы интерфейсов, которые разбирают Ваш исходный код на С++ и по нему строят необходимые описания.

Только это не всегда работает и почему это не может делать сам компилятор.

А вот Python умеет легко работать даже с такой кривой объектной моделью как СОМ, умеет сериализовать произвольные объекты, умеет на ходу добавлять объекту новые методы.

А как с программироваинем GUI - одна из распространенных кроссплатформенных библиотек Qt использует свой препроцессор языка С++ для выделения необходимой метаинформации.

Кроме того, С++ вообще не различает два существенно РАЗНЫХ понятия - абстрактный тип данных (АТД) и объект.

Классическим примером АТД яволяется класс Vector3D - фактически простая (зачастую inline-овая) обертка вокруг данных. Просто структура, но более удобная в обращении.

Возможно наследование (хотя редко), но только как структур. Никакого переопределения чего-нибудь вообще быть не может. Основной смысл - удобство работы (чтобы не надо было все векторные операции расписывать покомпонентно или наполнять код вызовами addVector, subVector и т.п.).

Естественно, что никаких таблиц виртуальных методов не нужно, зато очень полезной может оказаться возможность переопределения операторов.

Поскольку типы довольно простые, то крайне важна эффективность компиляции (в противном случае зачем вообще нужны такие классы).

Объект, с другой стороны, это то, что с самого начала замышляется как нечто динамичное, расширяемое. Мы всегда можем получить вместо объекта одного класса объект унаследовнного класса (или просто объект, поддерживающий нужный интерфейс).

Для объекта важна максмальная гибкость, как в возможности наследования и переопределения, так и в возможности композиции.

Причем с легкой руки авторов книг по С++ объектную ориентированность обычно понимают только как наследование объектов. А теперь откройте Design Patterns и посмотрите на что там большинство паттернов. А они почти все на композицию объектов - возможность получать новую функциональность путем соединения объектов правильным образом между собой.

Причем это соединение может происходить прямо во время выполнения программы (и ее почему-то не надо перезагружать для этого :)) в отличии от широко известной операционной системы.

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

А вот в Objective-C (другой вариант построения объектно-ориентированного языка на основе С, только в нем используется объектная модель языка Smalltalk) можно прямо на ходу узнать какие интерфейсы поддерживает объект, какие у него есть методы. Можно даже прямо на ходу добавить новый метод. И это компилируемый язык, весь графический интерфйес таких операционных систем как NeXTSTEP и Mac OS X построен именно на этом языке.

Сколько шума была из-за "острого" С (C#) в связи с делегированием - еще одним крайне важным элементом объектно-ориентированного программирования.

Делегирование - это возможность передать запрос другому объекту (делегату). Послушаешь сейчас мелкомягких о крутости делегирования в "остром" С - ну прямо они его и придумали и подарили миру :)).

А вот оказывается 15 лет назад делегирование было одни из краеугольных камней графического интерфейса NeXTSTEP'а. И было там крайне легко и красиво сделано. И была там 32-разрядная ОС, вся графика через Display PostScript (в частности, полная поддержка альфа-канала, появившаяся только в Windows XP), возможность вкладывания звуковых сообщений в любой документ и многое другое.

А в это самое время micro$soft только-только выпустил 16-битовый Windows 3.0.

С другной стороны, посмотрев на С++, становится понятно, почему делегирование замалчивалось. А как его можно реализовать на С++, как можно попросить какой-то объект вызвать какой-то метод (даже, если список входных параметров у него точно такой же) ?

В С++ это практически невозможно сделать. Именно поэтому сперва в Delphi и C++ Builder, а затем и в остром С появилось возможность делегирования как расширение языка.

Около года назад подобная возможность наконец-то вошла в стандарт С++. Правда в очень кривом виде. Осталось теперь только дождаться компилятора, который ее правильно реализует - кстати посмотрите в книге Александреску на каких компиляторах он весь код свой проверял, скорее всего вы ни одного из них просто не знаете.

Итак, с объектной ориентированнностью получается плохо - есть какая-то странная смесь АТД и объектов (половина от одного, половина от другого), объектной модели нет вообще, основная гибкость относится ко времени компиляции. Наиболее гибким элементом языка являются шаблоны. И именно на них А. Александреску и творит свои чудеса.

Язык должен быть эффективным

Вспомним "Вы не платите за то, чем не пользуетесь".

А как же исключения ( exceptions ), а как же RTII ?. За них то я всегда плачу всегда !!!

Крайне интересной особенностью С++ является то, что компилятор в ряде случаев сам генерирует код и тихо вставляет его в вашу программу.

Так если функция описана следующим образом:

void f ( const std::string& s );

А если Вы ее вызвали как f ( "Hello, world!" ), то скрыто от Вас будет создан объект класса std::string (а Вы знаете что в английском языке сокращение STD расшифровывается как Sexually Transmitted Deseases , т.е. заболевания, передающиеся половым путем), он передается функции, а потом уничтожается.

Т.е. вполне корректный и правильный код несет в себе скрытые затраты на создание и уничтожение объекта.

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

Еще одной интересной особенностью языка являются ссылки ( references ). Давайте сравним два описания функции:

void func1 ( A& a );

void func2 ( A a );

В чем разница между этими описаниями (кроме того, что возможно программист просто пропустил символ '&') ?

А в том, что во втором случае внутрь функции передается не то, что попросил передать программист, а лишь его копия. Т.е сначала вызывается copy-constructor , а по возвращении еще и деструктор.

Т.е. всего один символ в описании параметра может привести к очень большим затратам на создание и уничтожение вот этих временных объектов. А если это достаточно "тяжеловесный" объект или данная операция проводится в цикле, то затраты могут оказаться очень большими.

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

Т.о. вполне правильный (вроде бы) код может работать очень медленно (и неправильно). Особенно это относится к STL, где копирование объектов весьма распространенная вещь.

Причем для понимания таких мест нужно довольно хорошее знание языка. Конечно проффессионалы с многолетним опытом написания программ на С++ таких ошибок не делают (ну или почти не делают).

А вот те, кто только начинают использовать С++, насколько сильно эффективность их программ страдает от подобных особенностей языка ?

Есть примеры на STL, когда эффективность на простых строковых операциях падала в десятки раз.

Т.е. на С++ МОЖНО писать очень эффективно. И НЕКОТОРЫЕ даже пишут. Вопрос только - относитесь ли Вы к их числу ? Вполне возможно, что и на Симуле можно было эффективно писать, просто г-н Страуструп не знал как (т.е. знал Симулу также как большинство сейчас знает С++).

Вывод по этому пункту - можно писать эффективно, но пройдет несколько лет, прежде чем Вы начнете это делать. А пока, скорее всего, об эффективности можете забыть.

Итого - данное требование выполнено только для профессионалов, которые и так пишут эффективный код. А для всех остальных - это скорее игра случая.

Язык должен быть таким, чтобы программисты с С могли легко на него перейти

Ага, Щас прямо :))))

Посмотрите на пример выше, легко будет программисту на С понять в чем ошибка ?

А понять чем же отличается ссылка от указателя ?

А почему во втором случае он не получает того эффекта от вызова функции, на который рассчитывал ?

А почему вдруг у него в программе течет память, если она течет в тех вызовах, которые за него сделал сам компилятор ?

Простейшим примером ситуации, когда у в Вашей программе на С++ может потечь память является автоматическое создание (и их вызов) операторов присваивания и copy-конструкторов.

Если Вы их не написали, то компилятор заботлиыво сделает их за Вас. Только скопирует он все поэлементно, в том числе и указатели на динамически выделенные объекты и ресурсы.

При этом внешне все в порядке - нигде явно операции копирования не вызываются. Просто объекты на время помещаются в контейнерный класс.

Мне как-то пришлось искать почему программа, написанная аспирантом ф-та ВМиК МГУ падает через пару недель работы (она должна была работать на сервере месяцами). Именно по этой самой причине - копирование и уничтожение объектов при хранении объектов в контейнерных классах.

Конечно это лечится :))) - нужно написать правильные copy-конструктор, оператор присваивания и декструктор. Но оказалось, что выпускник ВМиК МГУ (работающий в программистской фирме) этого не сделал. И на клинического дебила при этом не похож.

Если это вызывает у Вас улыбку, подумайте, пишете ли Вы для своих классов корректные copy-конструкторы, операторы присваивания и деструкторы.

Просто маленький такой подарочек от автора языка.

Откройте почти любую серьезную книгу (а не С++ за 24 часа) по С++ - о чем там написано ?

Как НЕ НАДО делать.

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

Прямо такое море граблей, заботливо прикрытах травкой - идешь себе, идешь и вдруг - БАЦ ! Прямо по лбу !.

Сравните объем описания языка С и С++ - разница в объеме во много раз.

Книгой самого Страуструпа вообще убить можно :))(А вот прочитать до конца практически нельзя :))

Известных консультант по ООП, Алистер Коберн в своей книге "Surviving object-oriented projects" считает, что при отсутствии значительного опыта "С++ представляет собой наиболее серьезный технический риск для выживания проекта". И призывает не надеятся, что программисты на С смогут легко перейти на С++.

Ему принадлежит следующее высказывание - "Легче научить программиста на С Smalltalk'у, чем С++". Подумайте об этом, этот человек видел и консультировал очень много проектов.

Мы уже упоминали о "легкости" понимания разницы между ссылкой и указателем (фактически ссылка это третий тип передачи параметра, причем выглядящий как передача по значению, а работающий как передача по ссылке, так ведь удобнее, правда :(().

Кроме уже упомянутых "удобств" С++ можно вспомнить и такую

list <set<string>> a;

В этом объявлении есть ошибка - последнии два символа '>' компилятор сочтет за оператор битового сдвига и выдаст ошибку. Правда удобно и понятно ?

А упомянутые тонкости с копированием, присваиванием и разрушеним объектов ?. Для программиста на С это все ново и на этих местах он, скорее всего, будет ошибаться.

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

Т.е. с этим требованием полный пролет.

Компилятор должен находить все возможные ошибки

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

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

Т.е. С++ скорее называть языком макропрограммирования, чем ОО языком.

И при всем этом компилятор зачастую не ловит даже простейших ошибок.

class A
{
	string	str;
	
public:
	A ( const string& s ) : str ( str ) {}
};

С точки зрения компилятора (по крайней мере части компиляторов) это вполне законная конструкция. А вот практика показывает, что распил памяти (а значит и падение программы) неизбежен.

Боле того, оказывается, что компилятор в ряде случаев не ловит даже такую ошибку, как лишние параметры. Известен случай, когда в библиотеке векторов для обозначения скалярного произведения переопределили оператор ','.

А потом другой разработчик месяц искал почему программа работает неправильно. А все оказалось крайне просто - просто одной функции передавался лишний параметр. Слишком умный компилятор сперва сам перевел этот параметр в вектор, а потом соединил получившийся вектор с другим параметром и посчитал их скалярное произведение.

Как Вам такая ошибка - компилятор не просто не нашел тривиальнейшей ошибки, а сгенерировал по ошибочному тексту программы работающий (правда неправильно) код. И эта милая ошибочка обошлась в месяц работы.

Причем, что самое главное, компилятор в принципе может обнаруживать лишь ошибки в структуре языка. В то время как набор тестов способен определять ВСЕ ошибки.

В литературе по экстремальному программированию Вы найдете много полезной информации об организации тестирования.

Конечно, писать и поддерживать тесты гораздо сложнее, чем просто впихивать свой код компилятору и смотреть, что получится (а обычно получается GIGO - Garbage In, Garbage Out).

Однако система тестов намного надежнее и писать серьезный проект без системы тестов просто глупо - Вы будете постоянно повторять одни и те же ошибки, причем натыкаться на них будете, скорее всего, в совершенно других местах, чем те, где ошибки были совершены. И, скорее всего, гораздо позже по времени, чем когда ошибки были сделаны.

А система тестов (в комбинации с системой контроля версий) позволит Вам практически сразу же определять появление ошибок, причем с довольно точной привязкой к месту и времени их совершения.

Недавно я наткнулся на статью о том, какие языки скоре всего будут использоваться в будущем. И автор выдвигал мнение, что в будущем гораздо более распространенными станут гибкие и простые языки типа Python, Ruby и т.п.

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

А за жесткость и негибкость С++ приходится расплачиваться большим временнем компиляции. В системах из многих миллионов строк кода небольшое изменение одного из классов (особенно при активном использовании шаблонов и STL) приводит к перекомпиляции огромного объема исходного кода, что может занимать многие часы.

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

Краткий итог - даже простейшие ошибки могут не обнаруживаться компилятором. И выгоды от переваливания проверок на компилятор крайне незначительны. Тестирование гораздо надежнее и удобнее.

Итоги

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

А получается что НИКАКИЕ требования полностью не выполнены. Но мы имеем огромный и очень сложный язык с массой ловушек.

Язык, который приходится вручную интегрировать со скриптовыми язками, где для получения persistence приходится самому программисту вручную задавать необходимую информацию о членах класса (вместо того, чтобы использовать для этой цели компилятор).

Язык, на котором с огромным трудом реализуется делегирование, с трудом рализуются основные паттерны проектирования, который своей убогостью заставляет программистов решать такие задачаи, которые в ОО языках просто не возникают.

Простейшим примером такого рода является так называемый виртуальный конструктор, т.е. создание объекта, класс которого на момент компиляции не известен. Для С++ это серьезная задача, на эту тему написано много статей, есть различные подходы.

А вот в Smalltalk'e и Objective-C таких проблем вообще нет. Там для этого используется метаинформация (в виде объекта класса) - достаточно просто передать метаинформацию для требуемого объекта и по ней объект легко создается.

Еще несколько интересных моментов в языке С++.

Язык сильно закладывается на использование шаблонов, т.е. создание параметризованных функций и классов, где в качестве параметра выступает имя типа.

Это конечно здорово, но вот как узнать является ли этот тип каким-либо из элементарных типов, указателем или ссылкой ? Является ли он const или нет ?

Конечно есть библиотеки, предоставляющие подобную функциональность (например boost), но посмотрите на их исходный код, а еше лучше попробуйте его понять.

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

Для программистов на С++ понятие инкапсуляции как-то незаметно перешло в "data hiding" - прятание данных. Только это разные понятия. Одно дело собрать вместе связанные элементы, а совсем другое превратить это вместе в черный ящик.

Зачем прятать данные от библиотеки, реализующей persistence ?

Чтобы потом всю эту информацию набрать ручками, вместо компилятора ?

Мне недавно очень уважаемый мной разработчик сказал, что метаинформация вообще противоречит идеям объектно-ориентированного программирования. Если инкапсуляцию понимать как data hiding , то конечно противоречит.

А вот с точки зрения инкапсуляции все нормально - объект предоставляет информацию о себе в стандартизованном формате. Это позволит тем, что умеет (или кому она нужна) реализовать свою задачу (это может быть persistence, делегирование функций или связывание со скриптовым языком).

А насчет "опасности открывать структуру" - так ведь всегда можно сделать так -

memset ( &myObject, '\0', sizeof ( myObject ) );

Вполне законная конструкция, но сами понимаете, что она делает с объектом. Поэтому способов нарушить целостность объекта всегда хватает.

Реальною угрозу предоставляет именно попытка что-то сделать с объектом, не учитывая его внутреннюю структуру. Проще всего декларировать интерфейс, тогда он показывает соотвествие этой структуре, хотя явное приведение типа (Object2 *)&object1 еще никто не отменял.

А использование метаинформации как раз и позволяет учитывать эту самую внутренню структуру. Причем именно на этапе выполнения. Хотите делегировать функцию mouseClick другому объекту - просто проверьте, есть ли у него функция mouseClick с правильным списком параметров и типом возвращаемого значения.

И это ничуть не опаснее жесткой типизации, но зато это гораздо более гибкий механизм. И в языке Objective-C есть возможность как узнавать поддерживает ли данный объект определенный интерфейс, так и проверять есть ли у объекта заданная функция.

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

Сразу возникает вопрос об эффективности - как это по имени искать метод, а если у меня цикл ?

Вот тут С++ действительно в пролете - каждый вызов будет нести в себе цену вызова виртуальной функции. А в Objective-C можно один раз по имени получить адрес метода, как обычной функции, после чего вызывать ее в цикле как обычную функцию (т.е. overhead виртуальности просто нулевой).

Сразу отвечу на вопрос поечему же я не пишу на том же Objective-C.

К сожалению для данного языка (кроме как на Маках) нет интегрированной среды, язык практически не поддерживает АТД (а для графики возможность использовать такие АТД как вектора и матрицы очень удобна).

Многие ли купят книгу даже по интересной теме, если весь код там на незнакомом и малораспространенном (хотя и очень простым, перейти на Objective-C с С действительно вопрос нескольких дней) ?

Многие ли заказчики захотят получить продукт на таком языке ?

Просто смотря на этом язык очень легко видны многие слабости и дыры (в дизайне) С++. Когда видишь, как на компилируемом языке (основанном на С) легко и просто реализуются сложные вещи, реализация которых на С++ очень сложна (если возможна), начинаешь видеть в С++ то, о чем обычно просто не задумываешься (хотя бы потому, что просто считаешь это невозможным или слишком сложным).

А теперь немного об STL

std::string	a = "abc";
std::string b = a;