can3p (can3p) wrote,
can3p
can3p

Category:

c++, продолжение

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

Из прочитанного мне показалось, что основная сложность в с++ происходит в частности из:

  • Автоматического приведения типов. Дело не только в потере точности, хотя и в этом. В отдельных местах подобное приведение просто усложняет понимание того, что происходит. Меня весьма впечатлил пример в главе про перегрузку операторов, где при наличии функции a(double, double) и a(long&, long&), но вызов функции с параметрами a(static_cast<long>(a_int), static_cast<long>(b_int) приведет к вызову первой функции. Я прочитал объяснение, ок.

  • Большое количество сложности в языке заложено из-за нежелания копировать информацию. Отсюда референсы со всеми их сложностями. Не мне судить, очевидно это важно, просто важно не всегда, но при этом накладывает тень на весь код.

  • Ключевое слово friend, как и mutable показались адскими хаками. Если семантика языка не позволяет - то, конечно, нельзя, но если хочется, то можно. Если кратко, то в приватные поля класса лазить нельзя, но если определить функцию как friend, то ей можно! А если объект определен как const, то в нем менять ни одно поле нельзя, но если определить его как mutable, то можно!

  • В языке не предусмотрена возможность узнать, бросает ли функция/метод исключение, так что в теории взорваться может любой вызов, код которого вы не читали. Чтобы решить эту проблему и не перечислять возможные исключения, сделали наоборот - ключевое слово noexcept. Из описания я так понял, что компилятр попытается проверить, чтобы не было исключений, но если оно в таком методе все же произойдет, то программа просто скрешится и все. Т.е. либо по недосмотру программа рухнет от одного, либо от другого.

  • Перегрузка операторов. Прекрасная идея, но по факту от нее только проблемы. Даже в примере, где автор показывает перегрузку оператора сравнения для двух объектов, он дальше же и рассказывает, что для сложных объектов (в его случае был класс Box - коробка), сравнение будет субъективным (допустим, по объему, но вдруг надо по длинной стороне?), в результате не получается так элегантно, как хотелось бы, зато сложности - хоть отбавляй. По моему опыту просто еще один метод в сто раз понятнее любой перегрузки операторов - во-первых можно назвать метод понятно - biggerByVolume или biggerByLongSide, во-вторых не ломается семантика языка. Там же автор рассказывает, что хотя булевы операторы тоже можно перепределить, но это сразу сломает семантику операторов (короткое замыкание, когда остальные аргументы в выражении не вычисляются, если результат уже понятен). Зачем тогда это делать? Можете себе представить, как это все работает вместе с неявным приведением типов.

  • Последнее - это придирка не к с++, а скорее к ООП в том виде, как она в языке реализована. Когда его писали, казалось, что наследование - это серебряная пуля. На практике же чаще всего это наименее гибкое решение. Если хочется полиморфизма - то лучше интерфейсы, а так лучше композиция.

Теперь понятно, откуда ноги росли у дизайна go, у них скорее всего был такой же список вещей, которые они не хотели тащить в язык. И у них получилось! Если в этой книге длиной в 700 страниц даже были сноски, что мы тут вам не про все рассказали, а вот продвинутые фичи языка смотрите отдельно, то в го практически нечего изучать при отличной выразительности. Дженериков нет, ну и ладно.

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

Начинаю хендбук по расту. Сравнение будет нечестным, конечно, хотя бы из-за разницы в возрасте языков, ну да какая разница.

Subscribe

  • Из прочитанного. Выпуск 60

    Добавлю новый тег, т.к. какое-то количество книг я добавил себе в список на прочтение после прослушивания подкастов Юзефоыич на медузе. 1) Midnight…

  • Ссылки и указатели

    Наткнулся на один осмысленный пример применения ссылок вместо указателей. TLDR: указатели могут быть пустыми, а ссылки - нет. Так что ссылка в…

  • Субботник

    Ну или не совсем. Каждый год раздражаюсь, но в этом просто решил принять как факт. Каждый сентябрь в Амстердаме - это месяц раскопок. В промышленном…

  • Post a new comment

    Error

    Anonymous comments are disabled in this journal

    default userpic

    Your reply will be screened

    Your IP address will be recorded 

  • 5 comments