Comments 40
Уважаемые, не сочтите за спам, но с чего начать изучаение C++?
Логичное завершение недели ненависти к C++ на хабре)))
Я уже не помню с чего начинал и сейчас С++ почти не использую. Но видимо лучшими будут книги Страуструпа и Шилдта. Первого я читал по диагонали уже с определёнными знаниями, а на второго начал поглядывать когда необходимость в изучении плюсов уже отпала, так что возможно будут советы и лучше.
Я уже не помню с чего начинал и сейчас С++ почти не использую. Но видимо лучшими будут книги Страуструпа и Шилдта. Первого я читал по диагонали уже с определёнными знаниями, а на второго начал поглядывать когда необходимость в изучении плюсов уже отпала, так что возможно будут советы и лучше.
Я учился по книге стивена Прата. Очень доступно и подробно описано, включая тонкие мометы использования шаблонов и множественного наследования. Также в этой книге есть множество примеров и задач для самостоятельного решения (по-моему, даже с решениями).
UFO just landed and posted this here
У Страуструпа появилась Программирование: принципы и практика использования C++, исправленное издание возможно она будет легче для новичков.
Но вообще Прата или Шилдт для начинающего самое то.
Но вообще Прата или Шилдт для начинающего самое то.
С классики разумеется!
Бьярн Страустрап. Введение в язык Си++
Бьярн Страустрап. Введение в язык Си++
эээ вы серьезно? Страустрап пишет совершенно нечитаемо да еще и введением то о чем он пишет назвать сложно.
Есть хорошая серия свободных книг: Thinking in <lang-name>
в вашем случае Thinking in C++ — автор Брюс Эккель. В русском варианте переведена как Философия Си++
Там две книги — первая как раз для изучающих язык
Есть хорошая серия свободных книг: Thinking in <lang-name>
в вашем случае Thinking in C++ — автор Брюс Эккель. В русском варианте переведена как Философия Си++
Там две книги — первая как раз для изучающих язык
Страуструп пишет прекрасно, но изучать с него си это как отправить мальчика лепящего из бумаги самолётики собирать Су-27.
Начинать, всё таки советую с Шилдта, хотя каждому своё.
Да, ещё лучше понять зачем Вам нужен именно С++, и только если Вы на 100% уверены что Вам нужен именно этот язык, принимайтесь за изучение.
Начинать, всё таки советую с Шилдта, хотя каждому своё.
Да, ещё лучше понять зачем Вам нужен именно С++, и только если Вы на 100% уверены что Вам нужен именно этот язык, принимайтесь за изучение.
+1 к Эккелю, великолепный старт.
Но надо иметь в виду, что книга довольно старая и в ней присутствует несколько фактов, которые уже не актуальны или ложны. Например, необходимость вложенную объявлять структуру как дружественную, чтобы иметь доступ к её членам (том1, стр. 201), использование
enumstatic const
С С!
С «Hello, World»!
А если серьезно, то сначала нужно определится с задачей — для чего — Сдать сессию? Переквалифицироваться? Добавить еще один скилл? Просто для фана?
А если серьезно, то сначала нужно определится с задачей — для чего — Сдать сессию? Переквалифицироваться? Добавить еще один скилл? Просто для фана?
Скорее третий вариант.
Тогда начинать надо с авторов, рекомендованных выше, а продолжать:
Андрей Александреску (англ. Andrei Alexandrescu) Современное проектирование на С++: Обобщенное программирование и прикладные шаблоны проектирования = Modern C++ Design: Generic Programming and Design Patterns Applied.
Герб Саттер (англ. Herb Sutter) Решение сложных задач на С++. — Москва: Вильямс, 2008
И, конечно, решать конкретные задачи — проще всего, если что-то по работе нужно (и разрешают заниматься самообразованием)
Андрей Александреску (англ. Andrei Alexandrescu) Современное проектирование на С++: Обобщенное программирование и прикладные шаблоны проектирования = Modern C++ Design: Generic Programming and Design Patterns Applied.
Герб Саттер (англ. Herb Sutter) Решение сложных задач на С++. — Москва: Вильямс, 2008
И, конечно, решать конкретные задачи — проще всего, если что-то по работе нужно (и разрешают заниматься самообразованием)
Вот советовать Александреску, на мой взгляд, очень вредный совет, на людей без реального опыта плюсов он иногда оказывает вредное воздействие, ведущее к написанию «write only» кода…
Я бы советовал Александреску читать тем, кто уже знает как работают шаблоны, и хочет углубить знание и трюки…
Я бы советовал Александреску читать тем, кто уже знает как работают шаблоны, и хочет углубить знание и трюки…
Полностью согласен! Мне кажется, Александреску будет вреден в большинстве случаев.
У него есть вполне милая книжка «Стандарты программирования на С++», в соавторстве с Саттером. Ее вполне можно читать, она местами достаточно полезна. И не травмирует психику, как «Современное проектирование..».
Думаю для новичка эта книга легче усвоится: Брайан Керниган, Роб Пайк Практика программирования.
Имею обе на практике студенты-новички отдавали предпочтение Кернигану и Пайку.
Стиль изложения более близкий начинающему.
Имею обе на практике студенты-новички отдавали предпочтение Кернигану и Пайку.
Стиль изложения более близкий начинающему.
А если несколько пунктов из Вашего списка одновременно? )
Некоторые ветвления могут привести к тому, что вместо С++ выгодней изучать другой язык — например C# :) Недавно я общался с head hunter-ом в моем регионе, и он сказал, что работы на С++ становится меньше (но если есть опыт, то найти не проблема, разве только времени больше займет). Зато оплачивается лучше Java и .NET.
Самый выгодный вариант, если можно решать несложную задачу на работе, и при этом есть с кем консультироваться.
Для самообучения дома — можно скачать Visual Studio Express, и написать игру Жизнь, к примеру…
Самый выгодный вариант, если можно решать несложную задачу на работе, и при этом есть с кем консультироваться.
Для самообучения дома — можно скачать Visual Studio Express, и написать игру Жизнь, к примеру…
Спасибо за дельный совет! Java уже в копилке, но останавливаться нельзя :)
Я с С++ пришел в Java через JNI — обратный путь тоже вернен.
Хотя это очень частный случай — у меня было много работы по интеграции native кода с managed (Java, .NET) и разного рода инструментации.
Хотя это очень частный случай — у меня было много работы по интеграции native кода с managed (Java, .NET) и разного рода инструментации.
А вам какие задачи нравитс решать? Если это был дельный совет, то, похоже, гуи. Если сервера, то учите лучше Erlang. Для практичного фана лучше не найти, но и работа потихоньку появляется.
Глаза, на самом деле, разбегаются от обилия языков. Я, похоже, поддался стереотипу, состоящему в том, что «знать С++ престижно». Боюсь только что спрос на Erlang в нашем краю возникнет не скоро. Но всё равно спасибо)
А GUI на С++ лучше не стоит писать — рынок маленький. Там как раз .NET рулит.
Gtk#, уточняйте. А то падаваны по вашему совету пойдут клепать одноплатформенные без хорошей на то причины софтины.
С Qt, видимо, не сталкивались?
Я лично крайне редко последние 5 лет сталкивался с разработкой GUI на С++… всё либо .NET, либо Java (для кросс-ллатформенного GUI). А C/C++ только на server-side или для системного программирования. Но это, наверное, просто кому как повезёт :)
Про QT я, естественно, знаю… чтоб не соврать только… первый раз ее году в 93-ем пробовал — такая куча дискет и суперские демки были…
А про GTK# не в курсе, забавно…
Про QT я, естественно, знаю… чтоб не соврать только… первый раз ее году в 93-ем пробовал — такая куча дискет и суперские демки были…
А про GTK# не в курсе, забавно…
Представляю сколько это вам нервов стоило. Молодцы, что справились)))
Последний случай («не совсем утечка») мы обнаружили ровно вчера во фронтенде отдающим аватары для агента@mail.ru. На редких пиках активности получаем больше десяти тысяч одновременных соединений. Память под буферы чтения/записи, которую мы выделяем, не возвращается системе, «застревая» в границах brk. Процесс пухнет до полутора гигабайт и остаётся на этой отметке.
Я так думаю, что единственный нормальный способ с этим бороться, это порождать дочерние процессы как в Apache и рециклить (перезапускать) их периодически. На солярке еще libumem должен проде помогать — судя по паре постов в Интернете, он умеет память отдавать (там mmap() используется вместо sbrk()).
С другой стороны, организация работы с дочерними процессами как в Apache, это ужасный геморрой — архитектура сильно усложняется.
С третьей, вот IPlanet процессы ресайклить не умеет, и зачастую имеет проблемы с памятью из-за кривых плагинов. Наверное, его только малая распространенность и спасает :)
С третьей, вот IPlanet процессы ресайклить не умеет, и зачастую имеет проблемы с памятью из-за кривых плагинов. Наверное, его только малая распространенность и спасает :)
Это недостаток аллокатора. Я тоже думаю, что можно поменять аллокатор на использующий mmap.
В целом это не является большой проблемой, если сервер запущен на специально выделенной под него тачке. У нас как раз такой случай.
В целом это не является большой проблемой, если сервер запущен на специально выделенной под него тачке. У нас как раз такой случай.
Всегда боялся C++ в highload как огня, почитав вас думаю что не зря :)
Поскольку у нас везде чистый С то как правило сталкиваемся со случаями 3-его типа, как верно заметил коллега выше.
Из моей практики самый интересный с долгим расследованием был следующий:
Проксирующие nginx на проекте новости@mail.ru с нашим рекламным модулем иногда отжирали память цеплялись за своп и моментально уходили в нопинг задыхаясь под нагрузкой.
Пытались найти утечку очень долго: снимали coredump в момент перед наступлением ПП, искали утечки valgrind, ничего не помогало. В какой-то момент смогли проверить гипотезу — снятие нагрузки на уже распухшем сервере моментально приводило его в норму по занятой памяти. Значит как таковых утечек в модуле не было в чем же была проблема оставалось непонятно.
Помог вдумчивый анализ кода. Программист выделял буфер для записи ответа рекламного модуля с запасом независимо от реального размера ответа (памяти выделялось сверх необходимого больше где-то в 20 раз). Иногда на редких пиках нагрузки это позволяло зацепиться за своп с последующей смертью сервера. Починили просто — выделять память под ответ когда становилась известна его длина, после получения тела ответа в статический буфер.
Также надо сказать что проблема стала проявляться когда вместо двух проксирующих серверов временно оставили один на что в начале работы по проблеме не обратили внимания.
Поскольку у нас везде чистый С то как правило сталкиваемся со случаями 3-его типа, как верно заметил коллега выше.
Из моей практики самый интересный с долгим расследованием был следующий:
Проксирующие nginx на проекте новости@mail.ru с нашим рекламным модулем иногда отжирали память цеплялись за своп и моментально уходили в нопинг задыхаясь под нагрузкой.
Пытались найти утечку очень долго: снимали coredump в момент перед наступлением ПП, искали утечки valgrind, ничего не помогало. В какой-то момент смогли проверить гипотезу — снятие нагрузки на уже распухшем сервере моментально приводило его в норму по занятой памяти. Значит как таковых утечек в модуле не было в чем же была проблема оставалось непонятно.
Помог вдумчивый анализ кода. Программист выделял буфер для записи ответа рекламного модуля с запасом независимо от реального размера ответа (памяти выделялось сверх необходимого больше где-то в 20 раз). Иногда на редких пиках нагрузки это позволяло зацепиться за своп с последующей смертью сервера. Починили просто — выделять память под ответ когда становилась известна его длина, после получения тела ответа в статический буфер.
Также надо сказать что проблема стала проявляться когда вместо двух проксирующих серверов временно оставили один на что в начале работы по проблеме не обратили внимания.
С Си у вас будут те же проблемы. Для больших проэктов приходится для модульности чисто чтобы не потонуть в сложности проэкта вводить какую-то аналогию объектной модели, а тут встретите все те же проблемы только в большей мере потому что С++ стандартные возможности уже лучше отлажены и бага вилезает уж в очень особенных случаях, а ваше придётся еще проверить и в обычных. Да и кросплатформенная разработка как в автора наверное на любом языке привносит свои проблемы, даже у JVM на разных платформах хватает своих недокументированых особеностей реализации.
Sign up to leave a comment.
Утечки памяти в программах на С/С++ — история нескольких багов