«За несколько лет, прошедших между третьим и четвёртым изданием, мир ощутимо изменился: группа международных террористов, по недоразумению называющихся комитетом по стандартизации Си++, развернула весьма бурную и эффективную деятельность по окончательному уничтожению этого языка. Вышедшие последовательно „стандарты“ C++11, C++14 и, наконец, C++17 не переставали удивлять публику: каждый раз казалось, что более мрачного и безумного извращения придумать уже нельзя, и каждый раз выход очередного „стандарта“ наглядно демонстрировал, что всё возможно; ожидающийся C++20 как будто специально задуман как наглядное подтверждение, что предела этому процессу нет, разве что Си++ всё-таки окочурится. Если под „языком C++“ понимать C++17 или тем паче C++20, то о применении такого инструмента на практике не может идти никакой речи, т. е. с языком Си++ следует попрощаться, устроить торжественные похороны и поискать альтернативу; впрочем, то же самое можно сказать про все его „стандарты“, начиная с самого первого, принятого в 1998 году — строго говоря, язык C++ как уникальное явление был уничтожен именно тогда».

«Большинство нынешних программистов не мыслит использования Си++ в отрыве от стандартной библиотеки шаблонов (STL) и не видит ничего плохого во всё более и более изощрённых (хотя лучше будет сказать — извращённых) возможностях, предлагаемых выходящими с завидной регулярностью — каждые три года — „новыми стандартами“».

«Описание (переменных и типов) стало в Си++ оператором, что позволяет вставлять его в произвольное место программы, а не только в начало блока; напомним, что в чистом Си нельзя описать переменную после того, как в блоке встретился хотя бы один оператор».

«Перегрузка имён функций в этом плане (name mangling) кажется довольно неудачной идеей. Введена она в основном по двум причинам: во-первых, чтобы иметь возможность описать в одном классе или структуре несколько конструкторов, а во-вторых, как мы будем обсуждать позже, чтобы можно было перегружать символы стандартных операций для типов, введённых пользователем, для чего потребовалось позволить нескольким разным функциям иметь одно и то же имя, например, operator+. Но обе эти проблемы могли бы быть решены без введения перегрузки: никто не мешает давать конструкторам разные имена, например, просто помечая их специальным словом constructor, а функции-операции вроде operator+ могли бы быть не функциями, а чем-то вроде макросов, либо можно было потребовать, чтобы функции с именами такого вида всегда были „подставляемыми“ (inline) и не были бы, как следствие, видны линкеру (компоновщику. — Прим. DZ); если операция предполагает сложную реализацию, её можно было бы выполнить в функции с обычным именем, а из operator+ её просто вызывать».

«Ссылка в Си++ — это особый вид объектов данных, реализуемый путём хранения адреса какой-то переменной, но, в отличие от указателя, ссылка семантически эквивалентна той переменной, на которую она ссылается».

«Как говорят, коготок увяз — всей птичке пропасть. В действительности нет никаких причин применять dynamic_cast к ссылкам: если у вас ссылка, а не указатель, примените к ней операцию взятия адреса, превратив её тем самым в простой указатель, выполните dynamic_cast, проверьте результат на неравенство нулю и после чего разыменуйте его обратно».

«Во-первых, мне не нравится подача материала. Мягко говоря, „авторская“. Над автором не стоял вменяемый редактор, потому приходится читать пассажи вроде: „группа международных террористов, по недоразумению называющихся комитетом по стандартизации C++“ (точная цитата) или „убил бы того, кто это придумал“ (неточная цитата) [...]

Во-вторых, [...] 2020 год, а человек всерьёз топит за C++ конца 90-х [...] Типа «Мы не рассматриваем в нашей книге множественное наследование» [...].

В-третьих, [...] то „ну а тех (не очень хороших) людей, кто по каким-то причинам исходные тексты своих библиотек распространять не хочет“, то „программиста, не знающего C, всегда и везде будут воспринимать как сотрудника второго сорта, даже если писать на Си от него не требуется“ [...] Закрываешь книгу, закрываешь глаза и думаешь: что за чушь я только что прочёл?

В-четвёртых. Может быть, учебник как-то уникально иллюстрирован для улучшения подачи материала? Нет. Может быть, автор как-то уникально излагает материал так, что всё всем понятно сразу? Нет. Может быть, автор оснастил текст иллюстрирующими примерами из своего богатого опыта? Нет. Может быть, автор ведёт читателя за руку по какому-нибудь практическому проекту или практическим заданиям, как это нынче нередко принято? Нет. Может быть, автор... даже не знаю... сделал хоть что-нибудь положительно отличающее текст от бесконечного числа вузовских методичек, призванных помочь студенту сдать экзамен автору методички? Нет».

«Как по мне, такое „Введение в язык C++“ — хороший пример dark side нашего обучения в отечественных вузах — игнорировать прогресс, преподавать свою чудаковатую картину мира (вместо того, чтобы давать студентам объективную реальность), преподавать в отрыве от актуальной практики».

«Можно ли с чисто педагогической точки зрения яростно обличать „стандартизаторов“ языков C и C++? Возможно, не всё, что они делают — правильно, но стоит ли осуждать в учебнике современные стандарты? [...] Местами есть относительно разумные объяснения, какими возможностями из новых стандартов пользоваться не стоит — но в целом „вместе с водой выплеснули ребёнка“, и, скажем, о существовании того же <stdint.h> вообще не упоминается. Можно ли сейчас считать компетентным программиста на C, не знающего о существовании этого заголовочного файла — вопрос риторический.

В общем, местами книги можно считать хорошими, местами — приемлемыми, а кое-что вообще следовало бы вычеркнуть. Явно не подходит для „введения в профессию“ — а вот как элементарный справочник по программированию в Unix-подобной среде использовать можно, если грамотно отделять тараканов автора от фактического материала».

«Из положительного хочется отметить разве что довольно подробную лекцию о IEEE 754 [...] А вот отрицательного, к сожалению, гораздо больше. Во-первых, разбираемое в лекциях подмножество C++, как бы это сказать... совершенно недостаточно для нормальной продуктивной работы».

«Зашёл на ваш сайт по ссылке. Глазки вытекли» (DoctorSinus).

«На сайте вырвиглазная цветовая палитра. Как будто в 2004 год вернулся» (karton1).

«Правильнее было бы назвать „Очередной учебник Паскаля“. Плюс сомнительный трёп на тему „что такое алгоритмы“ и прочее» (hotpil).

«„За пожертвование от 500 рублей фирменный компакт-диск с автографом автора“. Ну и куда его вставлять потом в макбук?» (Deleted).

«А редактора с корректорами совсем не было? Книги на эту тему всегда нужны, но ведь это же графоманский ужас» (anonymous).

«Какое разочарование, я с трудом осилил 71 страницу первой книги. Сборище предубеждений и заблуждений, возведённое в абсолют и подаваемое под видом истины в последней инстанции тоном ментора» (getfr).

«NB: лицензия разрешает распространение файла только в его оригинальной форме и ТОЛЬКО в оригинальном формате, перевод в другие форматы категорически запрещён. Не боитесь, что найду? Анонимность в сети — вещь относительная».

«В последние годы маркетинговая политика отдельных компаний была направлена на смену термина directory словом folder (соответствующий русский перевод — папка). Для профессиональных программистов такая лексика неприемлема хотя бы по той причине, что для смены используемого (и устоявшегося) термина нужны, по-видимому, более веские причины, нежели мнение далёких от программирования сотрудников отдельно взятой коммерческой компании».

«„Отдельная коммерческая компания“ Microsoft [...] использует в MSDN и WinAPI слово directory, а не folder. „Папка“ — это несколько более сложная штука, чем просто список файлов („каталог“ или „директория“). Даже в Windows 95, где впервые появилось это слово, можно было обратить внимание на то, что „папкой“ является и „Панель управления“, и „Мой компьютер“, и „Корзина“ — нет никакой очевидной связи содержимого этих объектов с объектами файловой системы [...] Если не верите — читайте разъяснение за авторством Рэймонда Чена».