1 марта 2012 в 15:51

C++*

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++ (ну по крайней мере так было раньше).
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. Первая любовь – это на всю жизнь.

Жесть какая. Давайте, что ли, по-порядку.

Про C. У языка есть своя конкретная ниша, и он очень чётко в неё вписывается. Непонятная типизация? Ну не знаю, как там в C89, но лично я такого кода никогда не видел — везде объявлены типы, везде всё достаточно чётко. В C нет ООП, сборшика мусора, умных указателей? Ну так а кто вам мешает их добавить? Серьёзно, если вы профессионально пишете на C, то грех не иметь пары-тройки персональных библиотек, которые бы полностью удовлетворяли вас и при этом не тянули за собой кучу того, что вы не используете.

Про Java. А есть разница между адептами C++, которые кричат про непонятность мира Java и адептами Java, которые кричат про запутанность C++? Java the language — прост как палено, Java the world — не менее сложен, чем C++. Но и то, и другое нужно знать и уметь этим пользоваться на практике. В Java меня точно также раздражают невнятные непойманные эксепшены, но не меньше меня раздражают ошибки сборки C++ программы (особенно под Linux — ммм, как много нам мгновений чудных...).
Ну и да, скорость программы на Java определяется исключительно пряморукостью программиста и правильностью архитектуры. Современные JVM, такие как HotSpot, умеют очень и очень неплохо оптимизировать код, причём прямо в рантайме и в зависимости от условий выполнения.

Про сложность. Есть 2 сложности — сложность изучения и сложность использования. Haskell сложен для изучения. Одного только изречения про монады достаточно, чтобы понять, сколько времени у вас уйдёт на понимание всех фишек этого языка. Однако если вы справились с изучением, программирование на этом языке превращается в сказку — свобода выражения мысли, практически никакой отладки (если скомпилировалось, то 99%, что программа корректна) и ясный красивый код. C++ в свою очередь сложен как для изучения, так и для использования. Для изучения — потому что фич много. Для использования — потому что эти фичи плохо друг с другом совместимы. Мне особо доставляет количество вариантов представления строки. В С++ тонны фич, дублирующих функциональность, но имеющих чуть-чуть другую семантику, и про всех них нужно помнить и явно описывать варианты использования. А при композиции функций количество вариантов использования растёт экспоненциально, и программист очень быстро теряет возможность держать в голове и контролировать систему. Всё это следствие мультипарадигменности и общей философии C++, в которой считается абсолютной необходимостью иметь фичу на абсолютно любой случай. В Haskell такой проблемы нет: вы всегда знаете, что над аргументами вашей функции можно совершить чётко определённые операции, что вычисляться они всегда будут лениво, что неиспользуемыми ресурсами займётся сборщик мусора и т.д. У вас есть набор гарантий, а это значит что 1) вам не надо держать в голове несколько десятков вариантов использования; 2) вы можете серьёзно оптимизировать свой код. В C++ таких гарантий просто нет. Даже в C есть, а в C++ нет. (Здесь ещё интересно сравнить другую пару языков — Common Lisp и Scheme. В CL также намного мощнее своего оппонента, но в то же время из-за мультипарадигменности с ним зачастую очень сложно работать).

Про время компиляции и модульность. Проект компилируется всего за 15 минут?! Пардон, 15 минут — это мало? Нет, я в курсе, что для С++ это нормально, но вы с другими то языками сравните. Проблема в C++ в том, что в нём напрочь отсутствует модульность и раздельная компиляция. Я не говорю про хитрости типа precompiled headers и компании, я говорю про сам язык. Отсутствие модульности не только усложняет процесс разработки крупных программ (ок, неймспейсы и классы в целом помогают), но и накладывают серьёзные ограничения на технические возможности систем. Java позволяет на ходу подменить один класс другим (см. JRabel, а также иерархию класслоадеров), Lisp позволяет переопределять функции прямо в REPL. Как сделать такое на C++? Довольно непросто, не так ли?

Не поймите превратно. Я не люблю и не ненавижу C++. Я отношусь к нему как к инструменту. Как к лопате или швейцарскому ножу. Но не как ко всему сразу — если мне ныжно выкопать яму, я всё-таки схожу за лопатой, а не буду ковыряться в земле ножиком.

C++: простые реализации atoi и itoa

19 ноя 2012 ... C++: простые реализации atoi и itoa ...то есть, стандартных сишных функций преобразования строки в число и числа в строку. http://blog.kislenko.net/show.php?id=867

Нет ссылок (которые безопасней указателей), нет типобезопасности (сплошные void *)… много чего нет. А то, что есть, только способствует ошибкам: strcat, printf, gets…

Если руки прямые, а извилины — кривые, то ошибок не будет,
Если наоборот, то и в c++, и в java, и в питоне, и даже просто в алгоритме можно полнейший бред понаписать. Умные указатели медленнее простых.
Указательная арифметика, быстрые функции стандартной библиотеки (да, я о принтф, сканф, мемсэт, atoi и даже нестандартизированной itoa,(тем не менее в 2х самых популярных компиляторах реализации совместимые))
Сишные функции много быстрее плюсовых, и следует всегда юзать сишные (если это необременительно).
Более того, маллок предпочтительней new для простых типов (кстати, для простых типов конструкторы содержат вызов malloc в реализации от VS2010).
Короче, основные плюсы «плюсов» — возможность писать код как удобно разработчику, органмчно смешивая функциии, ООП и работу с памятью.
Ну а объем… необходимая жертва.
Вот поэтому я почти никогда не юзаю шаблоны.
В с++ я особенно ненавижу дебильную, устаревшую, оставленную только из-за совместимости, архитектуру компилятора, когда единица компиляции — отпрепроцессеренный файл.
имхо
1 единицей трансляции должен быть проект
то есть при трансляции проект анализируется как единое целое, а не только то, что в текущем файле
2 #include должен остаться для всяких извращений, а для включения должно быть добавлено ключевое слово import, делающее именно то, что от него ожидают — связывание символов в текущем файле с символами в импортируемым, если в текущем они объявлены, а в импортируемым — определены (или наоборот), и объявление и связывание, если в текущем они не объявлены, а в импортируемом объявлены или определены.
таким образом решатся многие проблемы с ошибками компиляции, ускорится сама компиляция, да и логичнее это.
Правда это поломает многие скрипты сборки, но невелика проблема.
Достаточно ведь просто файла проекта исходников и немного флагов.
Скрипты таким образом тоже упростятся, так как не нужно будет для каждого файла вызывать отдельно компилятор, потом линковщик и весь тулчейн.
3 отсутствие стандарта на ооп в shared libraries