А.В.Столяров. Введение в язык Си++

image of the cover

Аннотация

Краткое (объём пятого издания — 156 страниц) введение в язык Си++. Содержание построено по принципу плавного перехода от средств чистого Си: в начале даётся определение ООП как парадигмы, основанной на обмене сообщениями, затем вводится метод для обычной открытой структуры, уже после этого рассказывается о защите и её предназначении, затем (поскольку теперь это необходимо) вводятся конструкторы и деструкторы, и т.д. Так называемая "стандартная библиотека" Си++ (известная также под названием STL) в книге не упоминается вообще, поскольку если начать изучение Си++ с STL, есть риск никогда не узнать сам язык. Для ввода-вывода в примерах используются функции библиотеки Си (printf и др.) Кроме того, в книге сознательно игнорируются все «усовершенствования», предлагаемые авторами так называемых «стандартов».

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

Публикация в бумажном варианте

Пятое издание опубликовано издательством МАКС Пресс (Москва) в 2020 году. ISBN 978-5-317-06294-1.



fourth edition coverЧетвёртое издание опубликовано издательством МАКС Пресс (Москва) в 2018 году. ISBN 978-5-317-05781-7.



third edition coverТретье издание опубликовано издательством МАКС Пресс (Москва) в 2012 году. Книга издана при поддержке компании Юниконтроллерз.



second edition coverВторое издание опубликовано издательством МАКС Пресс (Москва) в 2011 году. ISBN 978-5-317-03552-5.



first edition cover Первое издание публиковалось РИО МГТУ ГА в 2008 г. под заголовком «Методы и средства визуального проектирования. Раздел "введение в язык C++"». ISBN 978-5-86311-660-0


Электронная версия

Электронная версия пятого издания, идентичная печатной версии, доступна здесь: http://www.stolyarov.info/books/pdf/cppintro5.pdf

Электронная версия четвёртого издания, идентичная печатной версии, доступна здесь: http://www.stolyarov.info/books/pdf/cppintro4.pdf

Электронная версия третьего издания, идентичная печатной версии, доступна здесь: http://www.stolyarov.info/books/pdf/cppintro3.pdf

Электронная версия второго издания доступна здесь: http://www.stolyarov.info/books/pdf/cppintro2.pdf

Электронная версия первого издания доступна здесь: http://www.stolyarov.info/books/pdf/cppintro.pdf Внимание! В старых версиях имеются известные автору фактические ошибки!

Статус бумажной версии

В настоящее время может быть приобретена в здании факультета ВМК, а также заказана с доставкой на этом сайте

Прикрепленный файлРазмер
Исходный текст примера "Разреженный массив"3.61 кб
Модификация примера "Разреженный массив" с использованием шаблонов3.76 кб
Исходный текст примера MultiMatrix из последней главы1.93 кб

Спасибо за ваши

Спасибо за ваши книги.
В одной из ваших книг вы говорите, что назрела необходимось в новом языке, который заменит C++.
Какими особенностями должен обладать этот новый язык с вашей точки зрения?

admin аватар

Довольно

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

Если говорить конкретно о Си++, то из его истории нужно извлечь некоторые уроки. Во-первых, перегрузка символов арифметических операций должна делаться не функциями, а макросами; во-вторых, конструкторы и деструкторы должны иметь произвольные имена, а их особая роль должна определяться ключевыми словами. Всё это позволит выкинуть за борт перегрузку функций, а вместе с ней и контринтуитивные правила видимости, и монстра по имени манглинг. В-третьих, механизм виртуальных функций должен быть вытеснен в библиотеку, и туда же должны уйти операции по выделению и освобождению динамической памяти; при развитом макропроцессоре это несложно. Ну и в-четвёртых, this должен быть ссылкой, а не указателем. Это так, навскидку; наверняка что-нибудь ещё можно припомнить.

Ну и ещё один момент: слово "стандартный" должно быть с самого начала объявлено категорическим табу. Никаких "стандартных библиотек", наоборот: как можно больше библиотек, конкурирующих между собой — их многообразие может взять на себя ту роль, которую сейчас играет многообразие самих языков. Ну и, конечно, никаких "стандартов", никаких комитетов и т.п.

Ozon? Really?

Посоветовал коллегам данную методичку для ознакомления с языком, а в ответ узнал, что она продаётся на Ozon. O_o

https://www.ozon.ru/product/vvedenie-v-yazyk-si-pyatoe-izdanie-stolyarov...

admin аватар

Бугага, 957

Бугага, 957 рублей :-) Напоминает налог на неумение искать в интернете.

Обратите внимание, что на этом сайте всё по-прежнему есть, включая электронную версию. Спасибо за ссылку, весьма любопытно :-)

Parthen аватар

И все же, она с

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

admin аватар

Разумеется, не

Разумеется, не продаёт — права торговать моими книгами в электронном виде я никому не дам никогда и ни при каких условиях, а если такое всё же случится — можете быть уверены, что меня подменили рептилоиды.

Что касается продажи бумажной книги — то моего "ведома" тут не нужно, это обычный материальный объект. У меня эту книжку купили оптом (не буду уточнять кто, тут это неважно), теперь вон продают в розницу, в принципе имеют право, наверное, почему нет? Тем, кто купил, я весьма признателен, поскольку с закрытием единственной торговой точки, где эта книга продавалась, у меня нарисовался неиллюзорный шанс так и остаться с кучей этих книжек. Что книга будет продаваться конкретно на "Озоне", мне не сказали, но мне в целом плевать, где конкретно она продаётся, если у меня её уже купили.

Parthen аватар

Спрашивается,

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

admin аватар

Не берут,

Не берут, разумеется. Магазинам намного проще работать с крупняком. Я вам такую вещь скажу, магазины не только у меня не берут, но даже у того издательства, где выходят мои книжки — видимо, оно для них тоже слишком мелкое.

"Если вы знаете

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

А между тем, таких людей довольно много, по-крайней мере было. Дело в том, что когда Borland выпускала свой C++ Builder, ей было влом переписывать библиотеку VCL, изначально написанную на Object Pascal-е. Им было проще допилить компилятор Delphi, чтобы он при компиляции модулей генерировал кроме объектных файлов еще и заголовочные файлы для Си++ и вуаля, в С++ используется написанная на паскале библиотека.

Фортран

Фортран библиотеки еще часто из C++ зовутся. Канонический пример -- вызов функций библиотеки arpack (нахождение спектра оператора) из расчетной программы, написанной на C++.

admin аватар

Спасибо, не знал

Спасибо, не знал

Опечатка

Страница 124:
"В классе GraphObject методы Show и Hide мы объявлены как чисто виртуальные, ..."
P.S.: очень сложная капча

admin аватар

Спасибо

Поправил. У этой опечатки были реальные шансы попасть в текст четвёртого тома, который сейчас корректор вычитывает (корректоры не всемогущи, так что спасибо ещё раз).

Насчёт капчи -- я знаю, но, увы, попытки ослабить её приводят к тому, что рука устаёт спам вычищать. В друпале это сделано не очень удобно. NB: здесь на сайте можно зарегистрироваться (на страничке гостевой книги), зарегистрированным пользователям капчу не показывают.

Не баг а фича?

Приветствую! Сейчас разбирал пример SparseArrayInt и возник вопрос. В функциях Provide и Remove в качестве аргумента передаётся индекс, однако в теле функции он не фигурирует, а также данный аргумент не указан в приведённом коде в книге (5 издание). Соответственно вопрос, это баг или фича?

admin аватар

Что-то этому примеру не везёт

Это однозначно баг, нужно разбираться.

Переход на ++

Добрый вечер Андрей Викторович, появилась необходимость переходить на С++, начал перечитывать ваше 5 издание понимаю, что могу ответить на 3 поставленных вопроса, но не знаю с чего начать, подскажите, где можно посмотреть хорошую реализацию не сложных программ или как правильно проектировать классы, пока нет опыта?

admin аватар

Я не совсем

Я не совсем понимаю, как могут сочетаться тезисы "появилась необходимость переходить на С++" и "не знаю с чего начать". Если перед вами встала практическая задача, ради которой нужно перейти на C++, то с этой задачи и начните. Если такой задачи нет, то, увы, всё плохо.

К сожалению, на вопрос "как правильно проектировать классы" внятного ответа не существует. Многочисленные попытки такой ответ дать по своему эффекту варьируются от безобидных (но бесполезных) вроде Гради Буча с его "ООП в действии" до откровенно вредоносных вроде "Паттернов" от "банды четырёх".

Дети наше всё

Здравствуйте, я хочу обучать ребенка программированию, выбрал язык си++ , сам я с ним не знаком, но какие то минимальные представления о программировании имею. буквально вчера показал ему видео обучение на ютубе и он успел пройти несколько "уроков".
ссылка на обучение - [url removed]

тут все рассказывается очень подробно, я сам успел посмотреть где то до 5 урока

но сегодня попалась на глаза Ваша книга, где Вы настойчиво рекомендуете не использовать iostream

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

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

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

О себе:
мне 38 лет, сыну 12 лет. Живем в селе, и каких то кружков или клубов по интересам здесь нет, по этому приходиться изучать самостоятельно.
Очень надеюсь на Ваши советы.

admin аватар

Какой там к

Какой там к дьяволу iostream?! Начав обучение с C++, вы ребёнка угробите без вариантов и без каких-либо шансов на восстановление, то есть в серьёзное программирование закроете ему дорогу полностью и навсегда. На фоне этого iostream превращается в несущественную деталь.

Вообще если уж вы на мой сайт пришли, есть, наверное, смысл сначала прочитать, что тут в книжках написано, а уж потом задавать вопросы. Рекомендую взять первый том "Введения в профессию" и прочитать хотя бы предисловия.

Ссылку на "уроки" из вашего коммента убираю; если хоть один человек пойдёт по этой мерзости учиться по ссылке с моего сайта — гореть мне в аду, хоть я в бога и не верю.

C++ и STL

Здравствуйте, Андрей Викторович.
Возникла вот тут такая проблема. Я на вашем сайте, можно сказать, уже давно, и про STL уже прочитал достаточно.
Так получилось, что сравнительно недавно начал разработку программы по химической тематике. Показал первые модули "наставнику", после чего тот одобрил, но "настоятельно рекомендовал библиотеку STL", ведь там есть двусвязные списки, динамические массивы и сортировки, которые я писал вручную, мол, это ускорит вам разработку.
С одной стороны, я внял вашему совету не использовать STL на первых порах, и изменять этому своему решению совсем не стремлюсь.
С другой стороны, возразить нечего, ведь писать самому разных рядовых, скажем так, вещей действительно придётся меньше.

Что вы думаете по этому поводу? На данный момент я аргументированно обосновать отказ от STL не могу, лишь слушаю умных людей (ну то есть вас).
Попробовать всё-таки STL, чтобы всё-таки понять, почему лучше его отбросить куда подальше?

admin аватар

Возразить вам

Возразить вам вообще-то уже должно быть что. Давно пора понять одну простую вещь: нет, STL не экономит время. Наоборот, его использование ведёт к катастрофическим потерям. Просто эти потери вытесняются со стадии кодирования (замечу, самой простой в жизненном цикле программы) на стадии отладки и сопровождения. И, самое главное, вытесняются не просто без пользы, но обычно с кошмарным проигрышем — экономия пяти минут на стадии кодирования зачастую оборачивается потерями недель в ходе сопровождения.

Пробовать STL я бы рекомендовал не раньше, чем вы почувствуете себя в C++ достаточно уверенно — то есть, скажем, после десятка тысяч строк.

Zdravstvuite! uchus` v

Zdravstvuite! uchus` v universitete na programmista. Izuchaiu c++. No mnogoe ne ponimaiu. Xochu nachat` samostoyatel`noe izuchenie, podskajite pojaluista, s chego nachat`? Kakoi uchebnik mozhete posovetovat`? Pryam s samogo nachala. Spasibo.=)

admin аватар

Если бы в мире

Если бы в мире существовал учебник, который я мог бы посоветовать, то писать свой я бы не стал. Так что добро пожаловать в первый том. Остальное (с чего начать и всё прочее) — в его предисловиях.

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

Здравствуйте!Д

Здравствуйте!
Должно быть это опечатка, на стр. 31 на второй строчке слово "про-русски"?

admin аватар

Спасибо!

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

Параметры шаблона

На странице 134 утверждается, что C++ допускает шаблоны с вещественнозначными параметрами (типа double). Насколько мне известно, это неверно. Вроде бы даже и по стандарту (хотя тут с уверенностью сложно утверждать, слишком уж много там текста), но как минимум ни один из широко используемых компиляторов (gcc, clang, msvc) такого не допускает. С другой стороны, целочисленные параметры допускаются любого типа (int, unsigned int, char, и т.д, и даже bool).

P.S. Интересно, существует ли способ отличить ситуацию, когда комментарий ещё не был просмотрен или затерялся от ситуации, когда он не прошёл премодерацию?

admin аватар

Вы совершенно правы

Эта ошибка должна была быть исправлена перед выходом четвёртого издания, но я про неё ухитрился забыть (хотя в моём экземпляре третьего издания это место помечено стикером, как и другие обнаруженные огрехи).

Спасибо! В текст четвёртого тома эта чушь теперь точно не пройдёт.

существует ли способ отличить ситуацию, когда комментарий ещё не был просмотрен или затерялся от ситуации, когда он не прошёл премодерацию?

Формально говоря, такого способа нет; но комментариев тут оставляют не так много, так что я вполне успеваю их все просмотреть. Раскрываю я при этом только те, на которые хочу ответить, либо которые по тем или иным причинам хочу видеть раскрытыми.

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

Практика программирования

В книгах Вы неоднократно повторяете, что для того, чтобы научиться программировать нужна практика. Посоветуйте пожалуйста где ее можно приобрести.
P.S.
Пробовал следующие варианты:

  • Олимпиадные задачи
  • Opensource
  • CTF (capture the flag - задачи по информационной безопасности)

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

admin аватар

Если хотите

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

Самый главный источник практических задач — собственная практическая работа. В этом плане для начала ответьте на простой вопрос: является ли командная строка Unix для вас основным средством взаимодействия с компьютером. Если нет — то я вам ничем помочь не могу (см. т.1, стр. 30); если же да, то мне крайне странно слышать о каких бы то ни было трудностях с поиском практической задачи; повседневная работа с командной строкой ставит такие задачи едва ли не по пять раз на дню.

И ещё один момент: если у вас нет практического опыта, то какого дьявола вы вообще делаете на страничке с книжкой по Си++?! ООП можно изучать не раньше, нежели появится свой собственный опыт разработки программ на две-три тысячи строк, а до той поры это не просто бессмысленно, но даже скорее вредно.

Использование errno при создании FileException

Здравствуйте!

Прежде всего, спасибо за книгу и за то, что свободно её распространяете!

В параграфе 3.6 приведён следующий код:

FileException::FileException(const char *fn, const char *cmt)
{
filename = strdup(fn);
comment = strdup(cmt);
err_code = errno;
}

[...]

char* FileException::strdup(const char *str) {
char *res = new[strlen(str)+1];
strcpy(res, str);
return res;
}

Предполагается, что конструктор записывает в поле err_code код ошибки некоторой функции, вызванной непосредственно до вызова конструктора. Но для этого необходимо гарантировать, что FileException::strdup() не изменит errno.

Стандарт Си++ не говорит ничего об errno в описании семантики оператора new (C++2003, 3.7.3.1 Allocation functions), но в сноске 32 написано:

The intent is to have operator new() implementable by calling malloc() or calloc().

В свою очередь, стандарт Си говорит следующее об errno (C99, 7.5 Errors):

The value of errno may be set to nonzero by a library function call
whether or not there is an error, provided the use of errno is not documented in the
description of the function in this International Standard.

В описании malloc() С99 не говорит ничего об errno (7.20.3.3).

POSIX об errno говорит следующее:

The setting of errno after a successful call to a function is unspecified unless the description of that function specifies that errno shall not be modified.

POSIX не специфицирует значение errno в случае успеха malloc().

Не считаете ли вы, что в данном случае лучше просто добавить ещё один параметр для кода ошибки в конструктор FileException, убрав тем самым его неявную зависимость от глобального состояния?

admin аватар

Как говорят, good catch

С одной стороны, к стандартам я известно как отношусь, а в реальности успешный malloc никогда не меняет errno, а неуспешных malloc'ов не бывает :-)

С другой стороны, можно errno присваивать не третьей строчкой тела конструктора, а первой; описанную вами проблему это решит. Вводить для неё параметр мне удачной идеей не кажется: при throw каждый раз придётся лишнее слово писать, документировать его и всё прочее.

опечатка?

Добрый день, уважаемый Андрей Викторович.

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

Замечена опечатка на стр. 68. Вместо этого:
int A::the_static_field = 0;

надо, по всей видимости, писать так:
int Cls::the_static_field = 0;

admin аватар

Большое спасибо!

Действительно ошибка в тексте, и до вас её никто не замечал, то есть ещё бы немножко — и она ровно в таком виде оказалась бы в тексте четвёртого тома "Введения в профессию". Так что я вам очень признателен за сообщение.

Опечатки?

Добрый день!

Когда комментировал в прошлый раз не все разглядел. Возможно, это тоже опечатки.

1) Опечатки на странице 69.

Вместо:
A a;
a.the_static_field = 15; // правильно
A::the_static_field = 15; // тоже правильно

должно быть так:
Cls a;
Cls.the_static_field = 15; // правильно
Cls::the_static_field = 15; // тоже правильно

В тексте абзаца выше тоже есть упоминание необъявленного класса A (четвёртая строка сверху).

2) На странице 82 в статическом методе strdup класса FileException вместо:
char *res = new[strlen(str)+1];

должно быть:
char *res = new char[strlen(str)+1];

admin аватар

Было такое

В ныне существующей версии рукописи (которая пойдёт в 4 том) всё это уже исправлено, только что проверил. Но всё равно большое спасибо!

Вставлю и свои

Вставлю и свои пять копеек.
На рутрекере видел эту книжку. Выложил кто-то. Так там к ней один из комментаторов отписал что-то навроде: "В книге используется stdio.h вместо iostream. Для кого автор пишет эту ерунду?". Честно говоря, настолько каким-то глупым и даже провокационным показался этот коммент (а не сам ли автор написал такое?!), что не поленился и скачал. Как выяснилось, книгу эту я уже видел. За издание точно не скажу (может, и не третье), но помню, что впечатление она оставила хорошее. Почему сюда и зашёл, на рутрекере отписываться просто смешно. И как оказывается, тут ещё и новые книги появились. А почему понравилась? Да потому, что она в отличие от многих книг по С++, ставящих всё с ног на голову, излагает языком точным, и совершенно очевидно, что автор ПОНИМАЕТ то, о чём говорит. Даются основы языка С++. Причём именно языка! А что ещё должно быть в книге, озаглавленной "Введение в С++"? И точно указан контингент - учащиеся, знающие язык Си. Всё пристойно, в рабочем режиме. Может, сравним с каким-нибудь другим учебником? Например, с учебником С++ Дятела? Что мы там имеем? Многотонный фолиант (на ногу уронить - пиши, пропало!), начинающийся с полюбившегося некоторым iostream'ного cout, выводящего "Hello, world". Разумеется, никакого предварительного знания языка Си не требуется, поскольку по заверению авторов, "он и сам собой изучится" по ходу пьесы, так что будете знать аж два языка! По довольно тщательному (размерно!) описанию циклов, условий, основных конструкций, становится очевидным, что авторы на полном серьёзе считают, что можно плюсам обучить с нуля! А язык-то, для профессионального пользователя! Программист - это профессия, которой учатся. Не один год. То есть, потенциальный читатель каким-то сверхъестественным образом (видимо, уже при рождении) должен знать с десяток-другой сопутствующих дисциплин. Не смешно? И кстати, если это всё-таки не так, зачем нужен С++ этого самому потенциальному читателю? Знание основ программирования на сегодняшний день - обязательное условие "общей" грамотности. Но не С++ же! Существует куча очень даже приличных языков, позволяющих как быстро освоить, так и успешно использовать их в решении своих проблем пользователям без специальной подготовки. А они читают книжку Дятела, который обещает (как и многочисленные курсы) не только знание языка С++ после завершения "обучения", но и всякие "высокооплачиваемые работы" не без блекджека! То есть, попросту теряют время. Или, может, Дятел этого не знает? Вообще-то, любой человек пишущий по теме "++" не может не являться профессиональным программистом! Стало быть, врёт? Ага! "Маркетинг" по-импортному называется, "мошенничество" по-русски. Кидалово. И благо бы был один такой Дятел, так их - просто полки магазинные ломятся! Так что, в печку всех этих дейтелов, в печку... Вслед за Каутским. Писал бы Булгаков в наши дни, его Швондер однозначно бы был автором учебника по плюсам. И ничуть дела не меняет то обстоятельство, что взявший эту книжку программист найдёт в ней что-то для себя полезное. На то он и программист - он уже умеет читать селективно и в состоянии грепнуть из текста именно то, что ему нужно. А остальное куда? Кстати, для программистов уже состоявшихся существует специальная литература. Максимум, во что может превратиться человек после чтения таких дейтелов, это (кто-то сверху, правда, сказал - "обезьяна", но будем гуманней к несчастным) девочка Маша (сходу такой образ нарисовался), которую взяли кладовщицей на громадных размеров складской терминал с кучей складов-контейнеров, где она ничего не знает, ни где чего лежит, ни для чего оно предназначено. Только что - молодая, бегает быстро! Вот только попроси эту Машу принести какой-нибудь инструмент, пригодный, скажем, для лесозаготовки, то она (поискав с полдня) садовые ножницы и принесёт. Здрасьте! А пройдут годы, поднаберётся опыта? Ну, станет бабой Машей, с тремя радикулитами, ковыляющей между своими контейнерами со скоростью в полузла, но зато прекрасно знающей что лежит в каком контейнере. Вот только попробуй опять собраться куда-нибудь лес попилить, да порубить, она тебе принесёт те же садовые ножницы, что и много лет назад...
Чего-то меня понесло... В общем, повезло тем читателям Столярова, кто на сегодня - студент. Слушай, что взрослый дядя говорит, да делай. Всего делов! Кстати, и не только студентам почитать-то можно - кто-то сверху очень правильно отметил, что изложение просто мозгинаместоставящее. У всех есть где-то какие-то пробелы, а текст "Введения в С++" достаточно короткий, чёткий и вменяемый. Ничуть не удивлюсь, если и обычный пользователь, для своих нужд уверенно пользующий какие-нибудь перлопитоны и работающий где-нибудь в отделе персонала, тоже вполне может поиметь что-то полезное - уж во-всяком случае, при приеме на работу "программиста", аналогичного рутрекеровскому любителю иостримов, вполне самостоятельно сможет поставить правильный диагноз и чётко отработать указателем на объект Двери, не отвлекая от работы людей, занятых программированием.

admin аватар

Писал бы

Писал бы Булгаков в наши дни, его Швондер однозначно бы был автором учебника по плюсам.

Как говорят англоязычные товарищи, you made my day :-) Вот прямо в рамочку и на стену.

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

Вообще-то...

Вообще-то, не раз случалось в течение жизни брать в руки какую-либо толстожопую книжку по "плюсам" с немалым желанием извлечь из неё нечто для себя нужное. Что-то как-то никогда сильно не шло... Давно уже принял для себя, что "по жизни" мне и Си - за глаза и за уши, максимальная по размеру программа не превышала десяти тысяч строк. "Плюсы" устойчиво ассоциировались с инструментом, необходимым лишь для проектов требующих десятков и сотен программирующих особей и задач, близких к космическим.
Однако, уже несколько самых первых строк Вашей книжки несколько изменили точку зрения. Аж с момента представления элементарной структуры, куда (надо же!) можно запихать относящуюся к ней функцию. Прямо не отходя от кассы взял свою же уже довольно старую программу и попробовал переписать. Интересные ощущения! Заместо висящих где-то функций, вдруг получилось нечто куда более структурированное и куда более понятное. А если верить, что "машинный код" от этого действа не изменяется, это совсем не так уж плохо! То есть, один "плюс" - уже налицо. За "второй", покамест, ничего сказать не могу. Поживём, увидим, может и приспособятся куда-нибудь эти самые "плюсы" со временем... Но по любому, написано так, что перевода с русского на русский не требует. Так что, однозначно, книжка пользователя имеет. Дело за малым - чтобы попала она в руки этому самому пользователю, который с полок магазинов сметает нечто куда более ненужное. Хорошее введение. Нужное.
Ну, а порадовавшие меня (чисто из общих и стилистических соображений!) штрафные в сторону ворот Степанова сотоварищи, наверно, тех, кто давно в "плюсах", порадовать и не могли - STL им нужен хотя бы уже потому, что спрашивать их при приёме на работу не будут не то, что о каких-то предпочтениях, но даже и о языке. На каком скажут, на таком и писать будут.
В общем, Введение хорошее. Спасибо.

ЗЫ Капча у Вас тоже неплохая, чёрт возьми...

admin аватар

Спасибо :) А за

Спасибо :) А за капчу прошу прощения, без неё у меня руки устают спам стирать.

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

Опечатка?

Андрей Викторович, возможно, на стр. 6 в сноске опечатка
"Любителям громких заявлений ОТ неотделимости стандартной библиотеки..."

admin аватар

точно

да, вы правы, спасибо

Опечатка

Страница 103, нижняя половина. Абзац начинается так:

Когда переменная scene_lenght...

admin аватар

Спасибо!

Болшое спасибо, эту опечатку вы заметили первым. Я пометил её в своём экземпляре, так что если дойдёт дело до четвёртого издания, там опечатка будет исправлена.

Преобразование указателей

Спасибо большое за книгу!
Когда читал, одна вещь вызвала серьезные затруднения для понимания. Меня мучил такой вопрос: будет ли при private наследовании работать неявное преобразование указателей от указателя на наследника к указателю на предка? Я проверил и убедился, что не будет. На странице 90 есть фраза о том, что есть случаи, когда тот факт, что один класс унаследован от другого сам по себе является деталью реализации, но дальше в книге говорится только о защите методов и полей, а о преобразовании указателей не упоминается. Нельзя ли внести несколько слов в книгу о таком эффекте private наследования?

admin аватар

приватное наследование

Дело в том, что вы не совсем правы. Неявное преобразование указателей будет работать там, где разрешено использование знания о том, что унаследованный класс является наследником своего предка. Например, если сделать некую функцию "другом" наследника, то внутри этой функции преобразование по закону полиморфизма работать будет: этой функции _разрешено_ знать, что наследование имеет место. То же самое будет происходить и, например, в методах наследника, включая статические — там это знание тоже разрешено.

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

Тут ещё такой момент есть, что в реальной жизни приватное наследование никогда не применяется — я, во всяком случае, ни разу с таким не сталкивался и с трудом представляю себе ситуации, когда оно зачем-то может понадобиться; ну а объём книжки хотелось бы сохранить небольшим. Есть ведь и более серьёзные вещи, которые в книжке полностью обойдены вниманием: namespaces, например, или множественное наследование, или там указатели на метод класса, да ещё много чего.

Не компилируется

"Исходный текст примера MultiMatrix из последней главы" не компилируется

multimatrix.cpp: In member function ‘T& MultiMatrix::operator[](unsigned int) [with T = int, T init_val = -0x00000000000000001]’:
multimatrix.cpp:67:21: instantiated from here
multimatrix.cpp:60:28: error: ‘class Array’ has no member named ‘Elem’

admin аватар

Спасибо!

Там действительно какая-то странная версия оказалась, частично исправленная, частично нет. Я выложил исправленный вариант, можете попробовать.

Кстати

Кстати, в четвёртом издании книги эта ошибочка на месте

admin аватар

Good catch

Исходники примера поправил, а исходник рукописи книжки — забыл, естественно.

Нынче в работе четвёртый том "введения в профессию", там я это дело пометил жирным "к доработке", так что в этот раз злая бага не проскочит. Спасибо.

Const

Здравствуйте!

На стр.57 возможно за место MyInt operator++(int) {/*...*/} стоит написать const MyInt operator++(int) {/*...*/}, чтобы, например, не было такого:
MyInt test(4);
test++ = 16;

За книжку большое спасибо!

admin аватар

век живи, как говорится

Вот ей-богу, до сего момента я был уверен, что значение (если оно не ссылка) леводопустимым не будет и так. Заметим, если функция возвращает обычный int, то присваивание применить не получится. Стало быть, для классов сие правило не работает.

Кошмарная штука этот C++, если подумать.

Точно

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

admin аватар

временный объект, ага

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

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

this

Здравствуйте!

Не совсем понял о чем здесь речь.

Судя по тому, что мы тут видим, this — не ссылка, а указатель, и по нему временные объекты передавать, видимо, можно

Можно поподробнее? Просто мы говорили об этом:

MyInt operator++(int) {MyInt tmp(*this); i++; return tmp;}

По указателю ничего не передается. Или я что-то не так понял?

admin аватар

Да уж, не поняли

Начать с того, что тело операции ++ никак не может оказать влияние на то, как её можно, а как нельзя вызывать. Тело и вызов вообще могут быть в разных единицах трансляции.

А по указателю передаётся объект при вызове операции ++. И речь здесь о том, что, оказывается, временный/анонимный объект можно передавать в его методы по неконстантному this, что, мягко говоря, неожиданно, особенно с учётом того, что передавать временные/анонимные объекты по неконстантным ссылкам нельзя, и это объясняется так, что неконстантная ссылка по смыслу — выходной параметр, а временные и анонимные объекты по смыслу — не леводопустимые (то есть как бы константы, хотя и не const).

очепятка?

стр. 82, char* FileException::strdup:
char *res = new[strlen(str)+1];
-> char *res = new char[strlen(str)+1];

не ?.. на первый вариант gcc (4.7.2) ругается: expected type-specifier before «[»

admin аватар

Спасибо!

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

Файлы к книге

А где же скачать обещаные тексты примеров программ, приведённых в книге?

admin аватар

Ой

И вправду нету. Надо сказать, за три года вы первый, кто это заметил :)

Я постараюсь эту ситуацию исправить в ближайшее время; вас что-то конкретное интересует? Если скажете, с чего начать, с того я и начну.

UPD: Основные примеры выложены, если интересует что-то ещё — пишите.

Хорошая книга

Хорошая книга для первого раза, но все таки от едких коменнтариев по поводу СТЛ можно было бы воздержаться. Еще можно было бы добавить в соответсвующие места ссылки на "первоисточники" Cатера, Мейерса... (например почему не надо перегражет приведение по типу и т.д.) И ессно уже С++11 на дворе, хотя я подозреваю, что автор скажет несколько нелестных слов о новомо стандарте.

admin аватар

Ага, щас

Ну вы там свою книжку тогда напишите с блэкджеком и шлюхами и в ней воздерживайтесь от чего хотите, а мне не надо рассказывать про достоинства STL, моё мнение по поводу этого бастарда окончательно и пересмотру не подлежит — как, впрочем, и относительно людей, которые не понимают, почему STL именно бастард, а не что-то иное. Я, кстати, не понял, какой "первый раз" имеется в виду, книжка-то, между делом, выдержала три издания, и у меня она не первая и не единственная.

Под первоисточниками лично я привык понимать ровно те материалы, которые использованы при подготовке текста, и никакие иные. В данном случае Мейерс и кого вы там ещё упоминаете — в число "первоисточников" не входят, я вообще не считаю нужным тратить время на чтение "современных" книжек по C++ (последняя книжка, прочтение которой не было пустой тратой времени — это "дизайн и эволюция", но, естественно, старого издания, ещё до начала STL-ной эпохи), а "почему не надо использовать операцию преобразования типа" — вынесено из личного опыта.

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

первый раз

Андрей, для первого раза, я имел ввиду для начинающих. А по поводу stl и с++11 с вами многие не согласятся. Я только соглашусь, что из-за всех нововведений и без того сложный язык,
стел еще сложнее для эффективного использования.
В чисто вычислительных задачах на кластерах до сих пор используется фортран, с++ претендует на нечто большее, и дает много новых возможностей, которые не обязательно использовать.
Например, если мне нужен hash map, у меня нет желания подключать стороние библитотеки или писать его самому пока это не будет критическим. Или как написать операторы сложения матриц без копирования временных обьектов (a+b+c) без rvalues& или expression templates? Конечно, из-за нагромождения всяких бесполезных структур данных с++ программа может начать работать медленее чем на скала (так случилось на моем лаптопе с кодом из http://research.google.com/pubs/pub37122.html). Но это уже квалификация разработчиков - не надо микроскопом забивать гвозди. В целом, спасибо за книгу.

admin аватар

Конечно, не согласятся

Андрей, для первого раза, я имел ввиду для начинающих.

Принято.

А по поводу stl и с++11 с вами многие не согласятся.

Многие? Я больше скажу: со мной не согласятся практически все, кто C++ увидел после 1999 года (или 1995, если речь идёт об англоязычных программистах), и многие из тех, кто C++ увидел раньше. При этом всех этих "несогласных" можно поделить ровно на две части: (1) те, кто пишут на C++ (с использованием STL и прочих примочек) и (2) те, кто на C++ больше не пишут, потому что "это просто мрак какой-то".

При этом если мы разделим программистов, знающих (но не обязательно использующих) C++, по другому признаку, а именно — на людей, разборчивых в выборе средств, и на тех, кто плевать хотел на грамотный выбор инструмента, лишь бы быстро сляпать, чтобы как-то работало — то получим ровно те же самые две категории людей. Те, кто в выборе средств не разборчив, используют C++ в связке с STL. Те, кто разборчив, в большинстве своём просто уходят из C++ на другие языки, кто-то "вверх", на питон, например, или на Java, кто-то "вниз", на plain C, причём часто даже ANSI C. Замечу, мне часто приходится видеть ООП на чистом С в исполнении таких людей, они моделируют наследование, вручную строят таблицы виртуальных функций и т.п., но о возврате к C++ при этом даже не помышляют, ибо весь этот кошмар с STL'ем, RTTI и прочими примочками — ну, кошмар и есть кошмар.

Остаётся ещё очень малочисленная группа людей, разборчивых в средствах, но при этом понимающих, что C++ сам по себе — инструмент неплохой, если не считать STL и всякие Boost'ы имманентной принадлежностью "C++-программирования" и если быть готовым, например, к --disable-rtty и отказу от исключений. К этой последней группе принадлежу, собственно, я, и я очень надеюсь, что эта группа пополняется за счёт моих учеников и читателей моей книжки.

Например, если мне нужен hash map, у меня нет желания подключать стороние библитотеки или писать его самому пока это не будет критическим.

Ну так пишите на Java или на Питоне, кто мешает? Зачем вам C++, если вы готовы одним махом (подключением STL) угробить все его достоинства?

. Или как написать операторы сложения матриц без копирования временных обьектов (a+b+c) без rvalues&

Как-как, известно как — сделать отдельно объект реализации этой матрицы со счётчиком ссылок и copy-on-write.

Конечно, из-за нагромождения всяких бесполезных структур данных с++ программа может начать работать медленее чем на скала [...] Но это уже квалификация разработчиков

Вы одну простую вещь поймите — это не разработчики виноваты, это вот так вот на мышление программиста действует этот монструозный конгломерат. То есть если быть неразборчивым в средствах, то в результате такая вот "низкая эффективность" будет лишь одним из неизбежных негативных последствий. Ну а человек, разборчивый в средствах, STL применять не станет.

не надо микроскопом забивать гвозди.

Забивание гвоздя микроскопом начинается в тот момент, когда использовано ЛЮБОЕ имя из namespace std. Коготок увяз — всей птичке пропасть.

В целом, спасибо за книгу.

Пожалуйста, мне не жалко. А вам она зачем, если не секрет? Вы на перворазника вроде не похожи.

Спасибо за

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

admin аватар

Пожалуйста-пожалуйста,

заходите ещё :)

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

http://habrahabr.ru/post/1517

http://habrahabr.ru/post/151760/
Доступен предзаказ 4-го издания «The C++ Programming Language» by Bjarne Stroustrup

Интересно будит ли так же отличатся спецы обученные до 4-го издание и после него? (как вы заметили своей книги для 3-го).

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

admin аватар

Логичный следующий шаг, да

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

Пора новый язык изобретать.

До третьего

До третьего издания включительно? В сети бродит «Специальное издание третьего»

Rust изобрели! Новый, но об его пользе есть сомнения и даже опасения.

admin аватар

Нет,

Нет, разумеется, не включительно. Третье уже начинается с STL без объяснений, что это и как сделано, то есть эта книга нацелена на создание безмозглой обезьяны, а не программиста. Special Edition вышло на несколько лет позже, но это уже неважно — начиная с выхода третьего издания, Страуструпа всерьёз воспринимать нельзя.

Ну а Rust — это даже хуже. Это не просто язык для программирования без применения мозга, этот язык делает вид, что способен выловить за программиста все его ошибки, то есть провоцирует "программиста" отбросить остатки аккуратности и внимательности.

Ну а нормальных языков, увы, сейчас просто нет.

Вы, кстати, обратили внимание, что отвечаете на коммент девятилетней давности?

Да, на дату

Да, на дату обратил внимание. Уж очень хотелось уточнения, касаемо второго и третьего (спец.) изданий книг Страуструпа и модного/молодёжного Rust. Не создавать же отдельный вопрос. :-)

Спасибо за отзывчивость и ясный ответ.

Настройки просмотра комментариев

Выберите нужный метод показа комментариев и нажмите "Сохранить установки".