![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
singalen(устаревшая до рождения микро-статья памяти языка C++, черновые наброски)
Выучили его всего, попрактиковались. Знаете, какова структура объекта в памяти при виртуальном множественном наследовании, как бросается out_of_memory, зачем и когда нужен виртуальный деструктор, как итерировать iostream и инстанцировать binder_2nd, и используете auto_ptr всегда, кроме случаев, когда знаете, что это повредит программе и почему.
Что дальше?
В смысле C++.
Помимо платформенно-зависисмых библиотек (это с большой вероятностью будут MSVC/WinAPI, библиотека POSIX, or whatever), остались вещи, которые нужно знать, осталось нечто, что следует знать всем программистам на цэ-с-двумя-плюсами.
Jeff Alger,C++ for Real Programmers.
Искал хорошие ссылки на помянутые книги, нарыл ссылку, смотреть в конец топика.
Критика ожидается и приветствуется.
Выучили его всего, попрактиковались. Знаете, какова структура объекта в памяти при виртуальном множественном наследовании, как бросается out_of_memory, зачем и когда нужен виртуальный деструктор, как итерировать iostream и инстанцировать binder_2nd, и используете auto_ptr всегда, кроме случаев, когда знаете, что это повредит программе и почему.
Что дальше?
В смысле C++.
Помимо платформенно-зависисмых библиотек (это с большой вероятностью будут MSVC/WinAPI, библиотека POSIX, or whatever), остались вещи, которые нужно знать, осталось нечто, что следует знать всем программистам на цэ-с-двумя-плюсами.
- Boost - уникальная попытка сделать из стандартной библиотеки языка нечто целостное, и вообще сделать C++ лучше. An absolute must know. Содержит мощную кроссплатформенную библиотеку всего, что должно бы быть в стандартной, и много чего ещё, чего, может, там быть и не должно. Сам намерен его внимательно изучать и дополнять этот пост по мере изучения.
- Профайлинг использования CPU, coverage profiling, профайлинг использования (и утекания) прочих ресурсов. Популярные инструменты для этого - BoundsChecker и ко под Windows, ещё?
- Автоматическое управление памятью по методу Hans-а Boehm-а.
- Юнит тестирование, в частности, наиболее популярные инструменты - CppUnit и Boost-овский boost_test.
Jeff Alger,C++ for Real Programmers.
Искал хорошие ссылки на помянутые книги, нарыл ссылку, смотреть в конец топика.
Критика ожидается и приветствуется.
Tags:
![[identity profile]](https://www.dreamwidth.org/img/silk/identity/openid.png){kind=small}
(no subject)
13/10/05 02:19 (UTC):)
13/10/05 02:50 (UTC)(no subject)
14/10/05 04:09 (UTC)а) чтобы увидеть, от каких проблем они избавляют;
б) чтобы уметь пользоваться generic-ами и те де :)
(no subject)
18/10/05 08:24 (UTC)Я в том смысле, что того же Александреску можно и почитать до или после изучения мейнстримовых языков.
Как и "Concurrent Java" Ли - не изучая Джаву.
(no subject)
13/10/05 05:47 (UTC)Есть другой путь — выбрать более или менее безопасное подмножество языка и не искать приключений.
(no subject)
14/10/05 03:27 (UTC)Кто не развивается, тот деградирует.
Касаемо плюсов можно и забить, это уже не мейстрим. Но вообще такой подход для меня неприемлем <:-P
(no subject)
14/10/05 11:44 (UTC)Зависит от цели ;-) По моему скромному мнению, сложность С++ не окупается теми плюсами, которые даёт, скажем boost. Чем больше я использую нетривиальных вещей, тем больше они будет препятствовать людям, которые могут решать задачи в рамках этого проекта, но не провели кучу времени, читая Саттера, Александреску, Josuttis'а и Vandevoorde. Представь, например, отпадёт какой-нибудь хороший алгоритмист или специалист по ЦОС, которому просто не интересно изучать эти вещи, его радуют его реальные задачи. С++ получается языком для экспертов, но реальные-то проблемы решают эксперты в других областях. ;-)
Какой подход для тебя неприемлем, я не понял.
(no subject)
17/10/05 02:31 (UTC)Это допустимо для каких-нибудь хобби или домашних дел. Скорее всего, мне никогда не играть фуги Баха, не готовить свадебных тортов и не возводить панельных зданий.
Но если я пользуюсь инструментом - языком программирования - профессионально, то нужно постоянно совершенствовать свои знания.
Обрати внимание, "знать Boost" не означает "использовать нетривиальные вещи". Более того, наоборот, код тем лучше (профессиональнее), чем он проще. Знать "нетривиальное" нужно с одной единственной целью: вспомнить о нём, когда ОНО понадобится.
Если фирме понадобились юнит тесты - вот в Boost-е готовый фреймворк. "Хороший алгоритмист" почти наверняка напишет свой тестирующий кусочек кода, потом коряво встроит его в билд процедуру, потом все забудут прогонять именно эту программку перед чекином изменений.
Нужна человеческая обработка string-ов iostream-ом? Обработка регистра символов? Мультитрединг (хорошо написанный, с прозрачным интерфейсом)? Подключили, забыли.
Для того, чтобы ИСПОЛЬЗОВАТЬ "продвинутые" возможности, особой квалификации не нужно. Взял доку, прочёл, сделал по образцу. А вот для того, чтобы ВИДЕТЬ, где их можно и нужно использовать - знать обязательно. Это граница между ведущим разработчиком и рядовым.
(no subject)
18/10/05 07:26 (UTC)Моя позиция сводится к тому, что сложность языка ограничивает круг разработчиков и ограничивает набор компиляторов, которыми будет собираться твой проект. Не учитывать связанные с этим риски — не профессионально ;-) Из двух библиотек, при эквивалентной по сути функциональности, я скорее всего выберу ту, что не использует modern C++.
Взял доку, прочёл, сделал по образцу.
Девочка приходит в магазин покупать сметану, подходит к продавщице. "А мама сказала купить сметану". "Давай девочка свой бидончик". "А мама сказала - полный бидончик". "Вот получай, с тебя семь шестьдесят пять". "А мама сказала - деньги в бидоне".
(no subject)
18/10/05 08:09 (UTC)У меня хорошие примеры. Они говорят о том, что Буст может стать стандартом де-факто, и знать его таки-нужно :) А то, что какие-то его части не будут часто использоваться - так это везде так. Мало кто использует std::deque или все функции Винсока.
Я не ратую за использование всех его возможностей всеми. Я только говорю, что его нужно знать - в той мере, которую сам для себя положит, но не менее iostreams/regex/string_algo/test/date_time. А далее потянутся и program_options, thread, function, parameter, static_assert. Графы и "всякую лямбдизну" © Владимир Мутель оставим для тех, кому надо или хочется.
...сложность языка...
Я ж не предлагаю его усложнять. Наоборот. Вышли на некий уровень "мама сказала, что виртуальное наследование выглядит так" - хорошо, вы уже можете работать. И в 99.9% случаев этого будет достаточно. Но если вы хотите добавить себе ещё 0.1% мастерства - изучите boost_mpl/concept_check. Добавите пятьсот раз по 0.1 - это будет +50% :)
Из двух библиотек, при эквивалентной по сути функциональности
Так в том-то и дело, что аналогов ему нет. Кто ещё достаточно качественно сшил строки и потоки ввода-вывода, форматирование строк и case-insensitive работу со строками?
Плюс - мы получаем всё в одном флаконе, портируемое и компилируемое. На определенном этапе развития эта функциональность становится нужна любому проекту.
Ничем не плохо. Почти как в Java :)
(no subject)
18/10/05 09:20 (UTC)...Will produce a compiler error with some compilers (for example Intel 8.1 or gcc 3.4), regardless of whether the template is ever instantiated. A workaround in cases like this is...
Кто ещё достаточно качественно сшил строки и потоки ввода-вывода, форматирование строк и case-insensitive работу со строками?
Как правило, всё это имеет мало отношения к делающему что-то полезное прикладному коду, и только добавит зависимость от boost, не дав ничего для той части проекта, которая собственно, и представляет ценность для заказчика. Но от этого-то хоть можно относительно легко отказаться. А вот если взять и систематически использовать lambda library по всему проекту, то избавиться от неё будет непросто. А представь, заказчику понадобилось собрать проект каким-нибудь сановским компилятором, и что делать?
(no subject)
19/10/05 02:10 (UTC)И давай забудем про лямбдизну - это только одна часть буста. Уверен, что использование boost_lambda составляет менее 1% использования всего фреймворка.
(no subject)
20/10/05 10:13 (UTC)Вот, например, для проекта, который представляет собой кучу математики, работающей с топологией микросхем (преобразование, моделирование процесса фотолитографии) и с изображениями с электронного микроскопа, важны люди, которые могут писать нетривиальные вещи, и совершенно не важен boost.
Если же в проекте надо кодить много бизнес-логики, то, наверное, да, boost мог бы облегчить жизнь. Но в таких проектах должны быть серьёзные требования к производительности, чтобы их стали писать на С++.
Lambda library была призвана олицетворять все библиотеки из boost, которые наровят расползтись по всему проекту.
(no subject)
21/10/05 05:07 (UTC)Я бы сказал, что она в таких условиях не расползется. А если расползётся, то пусть тот, кто выделывается и её всюду суёт, соберёт ещё обратно :) Потому что это организационная проблема.
Кстати, то, что ты помянул - тоже бизнес-логика. Видимо, имелись в виду информсистемы, работающие в основном с int, string и double/Money.
Но с моей точки зрения его полезность ортогональна работе с микросхемами: они могут сочетаться, а могут и не.
Почему C++... видимо, legacy :)
(no subject)
21/10/05 06:58 (UTC)Если кто-то пытается использовать modern C++ в коллективе, где не все хорошо знают, что это такое, то он создаёт не только технический риск, связанные с переносимостью кода, но и риск, возникающий от того, что коллеги не вполне понимают, как такой код работает.
Если уж мы используем что-то такое в проекте, то возникает желание локализовать это в одном месте. Например, мы можем счастливо использовать Boost.Program_options, и при возникновении необходимости достаточно легко отказаться от неё. Есть другой тип библиотек, которые решают повсеместно возникающие задачи, типа смартпойнтеров или lambda library. Использовав такого рода библиотеку в одном маленьком модуле, ты получишь маленькую выгоду, по сути, они расширяют язык и предполагают повсеместное единообразное использование. Решение повсеместно в коде использовать такой "расширенный" С++ труднообратимо.
Кстати, то, что ты помянул - тоже бизнес-логика. Видимо, имелись в виду информсистемы, работающие в основном с int, string и double/Money. Не понял, что — "тоже бизнес-логика"?
Наукоёмкость проекта обостряет риски, связанные с boost — меньше специалистов и больше шансов, что придётся собирать проект, скажем, сановским компилятором.
(no subject)
18/10/05 07:54 (UTC)...где их можно и нужно использовать
Мне кажется, что ты считаешь, что для чего-то реально нужного modern C++ необходим. Я таких примеров сейчас не могу придумать или вспомнить.
(no subject)
18/10/05 08:16 (UTC)А когда оно пригодится - так без знания теории мы и не можем выделить из практики случаи, когда она пригодится.
(no subject)
18/10/05 09:01 (UTC)Вот тут-то и возникает желание ограничить круг вопросов ;-)))
(no subject)
19/10/05 02:00 (UTC)(no subject)
20/10/05 10:17 (UTC)(no subject)
21/10/05 05:08 (UTC)А может, нужно сразу браться за ЛИСП, чтобы дисциплинировать ум и развить его гибкость. См. последний пост :)
(no subject)
21/10/05 06:18 (UTC)Кстати, Братко переиздали.
21/10/05 06:47 (UTC)Не купил, дорого.
(no subject)
13/10/05 23:58 (UTC)(no subject)
14/10/05 08:24 (UTC)Вить, посчитаешь излишним - удаляй это сообщение без лишних вопросов :-)
---
* Jeff Alger - "C++ for real programmers"
* Stanley Lippman - "Essential C++"
* Herb Sutter - "Exceptional C++" & "More Exceptional C++" & "Exceptional C++ Style"
* Scott Meyers - "Effective C++" & "More Effective C++" & "Effective STL"
* James Coplien "Multi-Paradigm Design For C++"
* Josuttis "C++ Standard Library"
* Josuttis, Vandevoorde "C++ Templates. The Complete Guide"
* Александреску "Modern C++ Design"
* Gamma, Helm, Johnson, Vlissides "Design patterns: elements of reusable object-oriented software"
* Martin Fowler "Analysis patterns", "Refactoring..."
* Charnecki, Eisenecker "Generative Programming"
* Александреску "C++ coding standart. 101 guidlines,tips" - Без прочтения предыдущих лучше не читать, т.к. постоянно ссылается на них.
---
(no subject)
17/10/05 02:34 (UTC)(no subject)
21/10/05 06:18 (UTC)(no subject)
21/10/05 06:58 (UTC)