C++ слишком сложен?
Иногда почитываю хабр. И когда заметил пост http://habrahabr.ru/blogs/cpp/111403/, честно признаюсь, он задел меня за живое. Я использую язык C++ как основной много лет. Еще раз честно признаюсь: так и не знаю его полностью. Вряд-ли я смог бы сотворить что-либо подобное Boost::MPL, Boost::Spirit или Boost::Xpressive. Но повод ли это говорить о сложности языка? Да, стандарт языка C++ раза в два больше стандарта C#. Но посмотрите на содержание: http://www.ecma-international.org/publications/files/ECMA-ST/Ecma-334.pdf и http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2461.pdf. Разница заметна? Подсказываю, что для полноты использования языку C# не хватает очень многого из того, что является частью .NET. Вообще-то C++ тоже можно использовать без STL и даже без run-time части вообще. В молодости даже ОС начал писать, где загрузчик был на ассемблере, а все остальное на C++. То, что STL включена в стандарт и подробно описана, в отличии от .NET, является большим плюсом языку C++ и большим минусом C#. Именно поэтому, хотя я и посматриваю с небольшой долей зависти на новости о C#, но применять не планирую. Моя основная ОС – Linux и проект Mono не кажется мне решением проблемы с .NET.
Любой язык программирования сложен до тех пор, пока не найдешь время разобраться с ним. Или кто-то считает, что есть идеальные полноценные языки с полным описанием на 10 страничек и абсолютно без подводных камней? Я о таких не слышал. Зато много лет подряд слышу о том, что C++ уже мертв или медленно умирает, советы обходить его труп стороной. Всяческие рейтинги показывают, что на первом месте у нас то-ли Java, то-ли C#. Но вы присмотритесь к содержимому жесткого диска, где там большая часть ПО на Java или C#? Да сами Java и C# написаны на C++ (ну по крайней мере так было раньше).
За что я ненавижу C.
Сразу уточняю, что моя ненависть берет начало еще со времен C89. Как только я пригляделся к этому языку, сразу понял, что ненавижу его. Особенно вот такие конструкции:
void main(argc, argv) int argc; char **argv; { ... } Зачем повторять аргументы два раза? Или объявления функций просто как func(), какие аргументы она принимает? Понятно, что любые и возвращает int, а как же контроль типов? И приходится выискивать реализацию, чтобы выяснить тип аргументов. Только вот при изменении реализации я могу и не узнать об этом, что приведет к неопределенному поведению.
Мне до сих пор приходится работать с кодом, унаследованным от C. Это просто сборище переполнений буфера и утечек. Частенько натыкаешься на ошибку и неудоумеваешь, и как оно до сих пор работало? “C++ быдлокода не терпит”, правильно. А вот C почему-то наоборот способствует его написанию. Точнее не почему-то, причины понятны: нет ссылок (которые безопасней указателей), нет типобезопасности (сплошные void *)… много чего нет. А то, что есть, только способствует ошибкам: strcat, printf, gets… Нет ни RAII, ни сборки мусора, от сюда и множество утечек. За годы у меня накопилось огромное количество аргументов против языка C, и на столько редко его использую, что сейчас все даже и не вспомнить.
Но я не предлагаю писать драйвера и ядра ОС на языке C++. Конечно же C для этого подходит лучше. Вероятно, для небольших библиотек и утилит язык C тоже более подходящий выбор, чем C++. Но для среднего или крупного проекта, разрабатываемого обычными наемными программистами, выбор в качестве языка C – вряд-ли хорошая идея. Кому может понадобится транслировать хотя-бы сотню тысяч строк в ассемблер? А миллионы? Если уж кому-то такая идея понравится, так тем более C++ лучший выбор, там этого ассемблерного кода будет значительно больше :–)
Преимущества C++ над C:
- Большая безопасность
- Возможность писать обобщенный код с помощью шаблонов
- Возможность использовать объектно-ориентированный подход
- Управление ресурсами с помощью RAII
- Упрощение кода за счет перегрузки функций и операторов
- Более простая обработка ошибок за счет исключений
- C++11!
- …
Остается только использовать эти преимущества правильно. К примеру не использовать исключения в качестве замены goto, не перегружать оператор запятая и т.д.
Недостатки:
- Долгая компиляция
- Больший объем сгенерированного машинного кода
Долгая компиляция становится проблемой только в случае неправильного подхода к заголовочным файлам (когда бесконтрольно суют в них все, что есть) или при использовании библиотек вроде Boost::Xpressive. К примеру немаленький проект Qt на моей машине (2-х летней давности, 4 ядра, 8Гб RAM) полностью пересобирается всего за 15 минут. Ну а объем… необходимая жертва.
За что я ненавижу Java.
Я честно пытался использовать программы написанные на Java. Много раз и в течении многих лет. Но практически ни одна из них не могла нормально работать. Для примера известная программа Eclipse образца 2008 года в версии для Windows в качестве IDE для C++. С помощью eclipse.exe оно не запускалось. Уже не помню, что там была за ошибка, но работать отказывался. Только если запускать с помощью eclipsec.exe, который оставлял консольное окошко, что терпимо. Но через некоторое время и этот способ перестал работать. Полез на форумы, нашел секретные действия для файла eclipse.ini и все заработало! Но не надолго. Сначала перестал работать запуск eclipse.exe, потом и eclipsec.exe. Снова пришлось искать способ его запустить. Оказалось, что желательно сразу указывать workspace при запуске. Сделал .bat файл. Но и этого хватило не на долго. Возможно проблема была в том, что проект содержал несколько миллионов строк кода… но по моему, это не повод так себя вести.
Самое неприятное, что во всех случаях eclipse выдавал стек вызова на Java и закрывался. Ни одного вменяемого сообщения об ошибке. И еще более неприятное, что так делали практически все программы, написанные на Java!
Вторая долгая история была с AS2 сервером (http://en.wikipedia.org/wiki/AS2). Он был в виде приложения для Apache Tomcat. Тогда я еще не знал, как программисты на Java любят мучить людей XML файлами и считал его вполне приемлемым форматом. Но больше я так не считаю, и ненавижу XML также, как и Java. Так вот, уже после установки сервера он отказался запускаться и писал в лог все те же непонятные стеки вызова. Поправил java.policy и java.security, разыскал нужные файлы local_policy.jar и US_export_policy.jar, начал работать. Но не всегда, время от времени продолжал вместо работы писать стеки. В итоге пришли к выводу, что легче написать свой сервер. Сделал бы это раньше, сэкономил бы кучу времени.
Программы на Java работают медленно и жрут много памяти. Не все и наверняка не большинство, но многие из опробованных мной. При этом я с удовольствием использую программы на python или ruby и не ощущаю никаких неудобств. А теперь еще и непонятное поведение Oracle.
И C++ я тоже ненавижу
Люблю и ненавижу одновременно. За тяжелое наследие в виде C. За долгую компиляцию. За множество неоднозначностей, не все из которых унаследованы от C. За то, что так долго пришлось ждать C++11. За чудовищные конструкции, которые приходится создавать. За отсутствие слова finality. За отсутствие интроспекции. За множественное наследование и отсутствие примесей. За различия в разных компиляторах и ОС… Да, недостатки у него есть. Они везде есть. Но в моей области, в большинстве случаев, достоинства C++ перевешивают. И самое главное, он совершенно не конфликтует с интерпретируемыми языками вроде JavaScript, Ruby, Python… а вполне мирно с ними уживается.
А что же я люблю?
GW-Basic. Первая любовь – это на всю жизнь.
Автор: nekipelov
