×

Изучение C++

Всем привет. Ситуация такая что я работаю тестировщиком и в скором будущем желаю быть разработчиком. Из языков начал учить С++. Общие понятия программирования есть(немного работал c PHP, JavaScript, C#). И теперь вопрос — на каком ресурсе или по каким материалам и примерам лучше изучать данный язык?(На курсы программирования пока нету средств) Ответы типа «Ты же тестировщик! Работай и дальше тестировщиком) Хорошая профессия!» не принимаются. Приношу извинения, если что-то написано, по Вашему мнению, некорректно. Заранее спасибо!

👍ПодобаєтьсяСподобалось0
До обраногоВ обраному0
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

из всего списка со стэка для новичка
1) Koenig — хороша но это должна быть вторая книга (я несмог по ней учить в виду сложности примеров)
2) Экель филисофия Си — тут после 200 страницы начинаются абсрактные примеры (закинул)
3) а вот Джесс Либерти Освой Cpp самостоятельно за 21 день — хорошая книга тут сугубо конкретные примеры нет соплей (за 21 день вы неучите си с этого названия народ смеётся) но выучить сможите (указатели и ссылки тут плохо расписаны придётса самому учить что такое стэк, кучя)

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
stackoverflow.com/...ive-c-book-guide-and-list
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

Introductory, no previous programming experience

Programming: Principles and Practice Using C++ (Bjarne Stroustrup) (updated for C++11/C++14) An introduction to programming using C++ by the creator of the language. A good read, that assumes no previous programming experience, but is not only for beginners.

Introductory, with previous programming experience

C++ Primer * (Stanley Lippman, Josée Lajoie, and Barbara E. Moo) (updated for C++11) Coming at 1k pages, this is a very thorough introduction into C++ that covers just about everything in the language in a very accessible format and in great detail. The fifth edition (released August 16, 2012) covers C++11. [Review]

A Tour of C++ (Bjarne Stroustrup) The «tour» is a quick (about 180 pages and 14 chapters) tutorial overview of all of standard C++ (language and standard library, and using C++11) at a moderately high level for people who already know C++ or at least are experienced programmers. This book is an extended version of the material that constitutes Chapters 2-5 of The C++ Programming Language, 4th edition.

Accelerated C++ (Andrew Koenig and Barbara Moo) This basically covers the same ground as the C++ Primer, but does so on a fourth of its space. This is largely because it does not attempt to be an introduction to programming, but an introduction to C++ for people who’ve previously programmed in some other language. It has a steeper learning curve, but, for those who can cope with this, it is a very compact introduction into the language. (Historically, it broke new ground by being the first beginner’s book to use a modern approach at teaching the language.) [Review]

Thinking in C++ (Bruce Eckel) Two volumes; is a tutorial style free set of intro level books. Downloads: vol 1, vol 2. Unfortunately they’re marred by a number of trivial errors (e.g. maintaining that temporaries are automatically const), with no official errata list. A partial 3rd party errata list is available at (), but it’s apparently not maintained.

подивись на пропозиції роботи для різних мов програмування і з’ясуй для себе, чи потрібен тобі С++. Не варто вчити те, що не знадобиться в житті. Я починав з Борланд С 3.1, років 5 вправлявся в розробці програмульок у ВіжалСтудії, а заробляю на сигарети тільки РНР.

Учебники Дейтелов по Си и плюсам, на мой взгляд, просто великолепны.
Очень доступно объясняют сложные моменты. В отличии от того же Лафоре, который, кстати, тоже неплох.
www.amazon.com/...n/dp/0132662361
Еще Шилдт хорош, но как по мне, уступает Дейтелам.

Я цю книгу читав, дуже хороша, якщо потрібна — зроблю хорошу знижку.
kiev.ko.olx.ua/...html#f3d1e32017

а ще можеш спробувати Шилда почитати

с++ програмисты хуже сектантов
сами застряли так еще и молодеж в свое болото тащат
нет что бы чесно скозать что там тишина и мертвые с косами

Кресты они такие — и нести их и вдоль дорог стоят и истинные!

В свое время учил сам по книжке Visual C++ for 21 days. Вот тут более детально, как вложиться в 21 день pricoles.ru/...10/C 21day.jpg

Как для старта — это Стивен Прата: «Язык программирования С++» или можно попробовать Липпман С.Б., Лажойе Ж.: «Язык программирования C++», после — Мейерс: «Эффективный C++», «Более эффективный C++».
В продолжение можно углубляться в шаблоны: Джосаттис Вандевурд «Шаблоны C++»;
и приступать к Страуструпу; начинать параллельно просматривать стандарты (98/03/11/14); Александреску; Саттер ...

Для STL: Мейерс: «Эффективный STL» + Дэвид Мюссер, Жилмер Дердж, Атур Сейми «С++ и STL справочное руководство» + Николаи М. Джосаттис «Стандартная библиотека С++»;
Для понимания концепции языка Страуструп «Дизайн и эволюция C++».

Алгоритмы: Роберт Седжвик: «Алгоритмы на С++»
Дизайн: GoF: «Приемы Объектно-Ориентировочного Проектирования»; Robert Nystrom: «Game Programming Patterns»; Jason Gregory: «Game Engine Architecture» etc
и далее далее далее...

Так же я б посоветовал, для начала, не зацикливаться на новшествах С++11.
И главное — практика, можно придумать задачу и по мере обучения решать ее.

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

Стивен Прата: «Язык программирования С++»
+100500 для начинающего Книга № 1. Написано очень просто и понятно.
главное — практика
Это архиважно, можно в начале написать. Кодить надо больше, чем читать. В конце концов программисты не читатели, программисты писатели!

я уже накодила лабу...ошибок нет, но вот окошко сразу же закрывается, я не успеваю даже посмотреть результат

я уже разобралась, все работает

ошибок нет
Кстати, в курсе, что есть теорема, что в общем случае это доказать невозможно (т.н. «проблема остановки»)? Да и с частными — не весело.
Ну и работающая лаба — не делает программистом. То, что в предложенных книгах (после второй) по большей части не к месту применять в лабах. Задачи типа лабы — это совсем не то, чем обычно (этак в 99% случаев) программисты занимаются (этим занимаются физики десятки лет на фортране и ничо им больше не надо). Если хочется почувствовать — надо что-то побольше написать, например, клон простенькой игрушки (тетрис, flappy bird, 2048), со стартовым меню итп. если есть уровни и выбор их — ещё лучше. Правда на плюсах это ещё та радость, ибо с нуля оч. много на самом деле для этого надо изучить.
Кстати, чем ещё реально может помочь dou обучающимся — ревью кода. Вот выложите вашу лабу — удивитесь сколько будет замечаний, «нет ошибок» это ещё даалеко не всё =) Вангую наличие магических чисел и, вероятно, плохо названные переменные/функции.
Да, проблема с закрывающимся окном — в гугл, такое обязательно надо уметь самой гуглить.

Окно не закрывается, с этой проблемой я справилась. Могу выложить код, если хотите. Он у меня не обьемный получился, так как 1 другу прогеру я уже показывала и он подсказал, где можно сократить

#include <iostream>
#include <math.h>
using namespace std;

int main()

{
double a, b, c, d;

a = 0.345;
b = −2.25;
c = 2.65;
d = 3.99;

double g;
g = fabs(b*c);
double m;
m = tanh(g) / log10(d);
double y;
y = sqrt(m) + (5 * a) / sin(a);

cout << y;
cin.get();
cin.get();
return 0;

}

Сходу маленькое замечание на будущее — если описываете любую константу (в данном случае a,b,c,d, то декларируйте ее как константу — «const».
Ну и старайтесь давать переменным и константам «человеческие» названия. В однобуквенных быстро запутаетесь, как только проект превысит 500-800 строк.

Я бы не писал cin.get() в конце, оно лишнее, и это плохая практика. Консольные программы они от того консольные, что их запускать следует из консоли. Тогда никаких проблем с «видимостью» результата. Кроме того, консольная программа обычно выполняет свою работу и завершается. она не ждет нажатий на Enter. Если же из-под студии запускать, то спасают точки останова, либо запуск в пошаговом режиме. Хотя даже если отладка не нужна, то из-под студии есть возможность запуска без отладки (в том же меню, где и запуск с отладкой), только вот он как раз окошко не закроет, а попросит нажать любую клавишу...

вообще кошмар. в простых программах system лучше избегать.

если пользуете однознаковые переменные то лучше сразу писать комментарии. Еще лучше уйти от однознаковых к переменным с понятными именами. Кроме этого вывод у вас никак не прокомментирован, нада написать что то типа «Результат бла-бла-бла равен: ». Это все типа мелочи но к ним нада сразу привыкать, потому что переучиться очень сложно.

Некоторые говорят, что комментарии не нужно писать. А именна переменных такие, потому что это тригонометрическое уравнение на самом деле. Вотъ ^_^

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

можно было уложить программу в пару строчек, избавившись от промежуточных переменных. и можно сразу писать double a = 0.345, b = ...
но это мелочи и придет с практикой.

// Варіант № 2

#include <iostream>
#include <math.h>
using namespace std;

void main()
{
double a = 0.345, b = −2.25, c = 2.65, d = 3.99;
cout << “Result is: ” << sqrt(tanh(fabs(b*c)) / log10(d)) + (5 * a) / sin(a) << endl;
cin.get();
}

Зануда моде ON/
Все же a,b,c,d — константы и специфическую матфункцию для наглядности стоит вынести из main и назвать соовественно.
А в main оставить только
cout << myPerfectFunc() << endl;
cin.get();
Зануда моде OFF/

Код пишут что бы его читали. И написан он должен быть так что бы легко читался.

я добавлю комментарии =)

хороший код не нуждается в комментариях. Он самодокументирующийся. С. Макконел вам расскажет подробнее.

Шаблонная херня. Хороший код тоже нуждается в комментариях и правильно комментировать еще нужно уметь. А при наличии сложных мат вычислений, просто необходимо описать алгоритм в общих чертах, иначе следующий программист задолбется весь ваш «хороший код» разгребать.

Чаво? Какой нафиг учебник, я говорю про реальные проекты.

Естественно ссылка на книжку, главу или статью. В коде неочевидные места, а они всегда есть. Свои собственные алгоритмы/идеи понятно тоже.

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

Свой код с комментариями я не могу привести, так как это подпадает под NDA. Но чтобы было понятно о чем я говорю, приведу пример подобных комментариев из open source проектов(boost::graph library):
[code]
// The algorithm implemented in this paper is based on the so-called
// Algorithm 457, published as:
//
// @article{362367,
// author = {Coen Bron and Joep Kerbosch},
// title = {Algorithm 457: finding all cliques of an undirected graph},
// journal = {Communications of the ACM},
// volume = {16},
// number = {9},
// year = {1973},
// issn = {0001-0782},
// pages = {575–577},
// doi = {doi.acm.org/...5/362342.362367},
// publisher = {ACM Press},
// address = {New York, NY, USA},
// }
//
// Sort of. This implementation is adapted from the 1st version of the
// algorithm and does not implement the candidate selection optimization
// described as published — it could, it just doesn’t yet.
//
// The algorithm is given as proportional to (3.14)^(n/3) power. This is
// not the same as O(...), but based on time measures and approximation.
//
// Unfortunately, this implementation may be less efficient on non-
// AdjacencyMatrix modeled graphs due to the non-constant implementation
// of the edge(u,v,g) functions.
//
// TODO: It might be worthwhile to provide functionality for passing
// a connectivity matrix to improve the efficiency of those lookups
// when needed. This could simply be passed as a BooleanMatrix
// s.t. edge(u,v,B) returns true or false. This could easily be
// abstracted for adjacency matricies.
//
// The following paper is interesting for a number of reasons. First,
// it lists a number of other such algorithms and second, it describes
// a new algorithm (that does not appear to require the edge(u,v,g)
// function and appears fairly efficient. It is probably worth investigating.
//
// @article{DBLP:journals/tcs/TomitaTT06,
// author = {Etsuji Tomita and Akira Tanaka and Haruhisa Takahashi},
// title = {The worst-case time complexity for generating all maximal cliques and computational experiments},
// journal = {Theor. Comput. Sci.},
// volume = {363},
// number = {1},
// year = {2006},
// pages = {28-42}
// ee = {dx.doi.org/...tcs.2006.06.015}
// }
[/code]

Это для автогенерации документации, если документация не нужна, то можно и в одну-две строчки уместить.

Да, пожалуйста, со временем поймешь, если останешься в профессии, что писаешь против ветра.

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

Это неплохая документация для некого метода, но ужасный комментарий.

Код должен содержать достаточно информации, чтоб можно было быстро понять что он должен делать. И комментарии для этого не нужны.

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

Ага, а люди на планете должны жить в мире и согласии...
Проблема только в том, что иногда еще нужно знать не только ответ на вопрос «что делает?», но и, например, «почему?», «как?», «зачем?». Не всегда можно быстро понять сложность алгоритма, почему был тот или иной стандартный подход изменен, и т.д. Я сейчас говорю не о глобальных вещах, а о чем-то локальном, специфичном для небольшой чатсти кода. И для таких случаев, пока ничего лучше не придумали комментариев. Почему не хранить информацию в отдельном месте? Вы не сможете все это держать синхронизированным с кодом. Рано или поздно произойдет рассинхронизация. Я думаю многие сталкивались с ответами на вопрос «есть ли какая-то документация?»: «Есть, но старая, сейчас уже все там изменилось.»

Ага, а люди на планете должны жить в мире и согласии...
Проблема только в том, что иногда еще нужно знать не только ответ на вопрос «что делает?», но и, например, «почему?», «как?», «зачем?». Не всегда можно быстро понять сложность алгоритма, почему был тот или иной стандартный подход изменен, и т.д. Я сейчас говорю не о глобальных вещах, а о чем-то локальном, специфичном для небольшой чатсти кода. И для таких случаев, пока ничего лучше не придумали комментариев. Почему не хранить информацию в отдельном месте? Вы не сможете все это держать синхронизированным с кодом. Рано или поздно произойдет рассинхронизация. Я думаю многие сталкивались с ответами на вопрос «есть ли какая-то документация?»: «Есть, но старая, сейчас уже все там изменилось.»

PS
На самом деле тот комментарий плох именно, как публичная документация, но вполне неплох как коммент, описывающий моменты внутренней имплементации.

Вы не сможете все это держать синхронизированным с кодом. Рано или поздно произойдет рассинхронизация.
Вот только для комментариев это тоже верно.

Когда ИДЕ будет выдавать ошибку, если комментарий не синхронизирован с кодом, тогда ваши доводы «комментарии лучше документашки» будут иметь смысл.

Пока же, как это ни печально, единственное что всегда синхронизировано и 100% отвечает на вопрос «как эта функция работает» — это код этой функции.

Вот только следить за синхронизацией в коде на порядок проще. Собственно, это и показывает практика, даже без дополнительных требований к разработчикам, им гораздо проще написать/изменить/удалить комментарий в процессе кодирования прямо в коде, чем проапдейтить отдельную доку.
Далее, по поводу ошибок. Для .NET есть FxCop, например, который содержит правила для комментариев для автогенерации документации и при их нарушении выдаст ошибку. Да, он не разбирает текст, но, например, выдаст ошибку при добавлении нового публичного метода/параметра, если для него отсутствует описание, что несколько упрощает процесс.

Собственно, это и показывает практика, даже без дополнительных требований к разработчикам, им гораздо проще написать/изменить/удалить комментарий в процессе кодирования прямо в коде, чем проапдейтить отдельную доку.
Хорошо звучит. Вот только я тоже был разрабом, и прекрасно помню, что «это серенькое» ты просто не замечаешь. Поэтому комментарии, которые забыли поменять, есть в каждом старом проекте.

Более того. Как менеджер, я могу сформировать процесс обновления документации (зарелизили фичу — заапдейтите доку по этой фиче, ссылки в тикет). Но чтоб проверить «обновляемость» комментариев — нужно проверять каждый комит.

А уж всякие нотификации о «незадокументированном методе» порождают только бред в стиле
/*
* splits string by spaces
*/
function splitStringBySpaces(str)

Здрасте. А теперь подумай над эффективностью твоего «процесса обновления документации». Если разработчик будет писать документацию к фиче, которую он месяц назад закончил и уже хреново помнит, что там было, потому что еще пять фич успел реализовать. Документация и будет в стиле: «split string», только для всего проекта, а какая-то часть вообще не будет задокументирована. Плавали, знаем.
Далее, при ежедневных ночных билдах, проверка каждого коммита, вполне нормальная практика. И отнюдь не из-за комментариев. Только это не задача PM’a, а тим лида следить, чтобы код на конец дня оставался в рабочем состоянии.

Если разработчик будет писать документацию к фиче, которую он месяц назад закончил и уже хреново помнит, что там было
И действительно, что же надо сделать?... А, точно, не ждать месяц!
Только это не задача PM’a, а тим лида следить, чтобы код на конец дня оставался в рабочем состоянии.
*фейспалм*, ну да, если документация в комментариях, то тимлид следит за работоспособностью кода.

Кстати, сорцы вы видимо флешкой синхронизируете (ну для полноты картины)?

ОК, я смотрю ты слегка поправил предыдущий коммент. Только один прокол, у тебя апдейт доки после релиза, а очень желательно до, сразу после имплементации. Думаю догодаешься почему. Это будет работать, какое-то время... три-четыре года. Но со временем произойдет рассинхронизация, именно то с чего мы и начинали. Потому что код будет меняться, будут фикситься баги и т.д. Вносили изменения в одну часть проекта, и где-то что-то изменили и коммент не поправили. И даже сам разработчик может забыть по окончании имплементации. А ты и подавно не проследишь, контролировать ты этот процесс не сможешь. А если еще у вас есть public API, где требования к документированию достаточно высоки (как в моем проекте), тогда через несколько лет активной разработки придет понимание, что что-то не так, что документирование — это такой же постоянный процесс разработки. Разработчик внёс изменение и тут же в коде поправил коммент, никаких релизов ждать не нужно. Есть вероятность, что он забудет поправить коммент? Да, есть, он может что-то пропустить, но он меньше пропустит, чем если бы делал то же после релиза. Плюс помогают тулзы типа FxCop. Пусть у меня будет «split string» для тривиального метода, но при этом будет нормальное описание для сложного, чем не будет ни того, ни другого.

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

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

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

P.S. Ах, да, ещё нужна документация «как оно вообще работает» для манагеров, маркетологов и прочих неразумных, которым влом лезть в код. Но тут уж ничо не поделаешь — надо писать отдельно, и резолвить проблемы несоответствия.

Обычная описка, я заметил, но не стал править. Надо же что-то оставить, к чему бы ты мог придраться. Я объясняю зачем нужны комменты в коде. А так да, и юнит-тесты с мокингом есть, и комментирование, и автогенерация документации при ночных билдах, у меня все отлично.

комменты в коде — это как брызнуть одеколоном на потную подмышку. Вроде стало лучше, но все равно воняет.

Фиксить лучше причину, из-за которой пришлось коммент добавить.

А мне видится, что ты вообще предлагаешь не мыться, воняют подмышки, ну так давайте вообще не мыться. Коммиты проверять тебе влом, комментировать код тоже. Детский сад.

У тебя просто память короткая. вот, держи:
dou.ua/...c/10293/#590702

а зачем её писать через месяц если её можно писать сразу? Добавляем обновление документации в дифинишен оф дан.

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

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

Это если изменений не много. А если над проектом работает несколько команд, несколько minor релизов и один major в год, то синхронизация превращается каждый раз в серьезную проблему.

Несколько команд над одним и тем же функционалом? такого не было — всё остальное было.

Каждый тим овнит свои документы и мейтенит их документацию в разумных обьёмах.

Нет. Конечно, каждая команда должна работать в своей изолированной области, да и программисты желательно тоже. Речь идет о синхронизации не между параллельно работающими программистами, а с предыдущей версией документации, а также максимальная автоматизация процесса. Если мы депрекейтнули метод, то нужно, чтобы это было отражено автоматом в документации. Добавили новый метод, задокументируйте, иначе ошибка при сборке, и так далее. Это требования для public API, для внутренней реализации таких драконовских требований нет и не нужно, там попроще, но комментировать код тоже нужно. Это если упрощенно, в реале документация собирается из нескольких источников, не все нужно тащить в код, есть примеры на разных языках программирования, которые тоже нужно проверять на ошибки компиляции и т.д. Это реально удобно и экономит кучу времени в итоге. И как бонус, более-менее свежая документация всегда доступна всем.

работать в своей изолированной области, да и программисты желательно тоже.
Я знаю людей готовых поспорить с этим утверждением.

Я также абсолютно согласен с Павлом, автогенерированная документация может устаревать точно так же как и написанная руками. Знаю, поскольку в моём текущем проекте она собирается сфинксом. Забыл поправить описание к методу — и всё. В большом пул-риквесте этого не отыщешь. А качество этих комметов отдельная история.

ИМХО здесь нету абсолютно правильного решения. Всё это вопрос выбора. Можно делать и так и так, во всём есть свои плюсы и минусы. Я лично предпочтаю руками написанную документацию. Для API действительно неплохо работают комметы, вот только описывать то надо не только АПИ. Я б даже сказал что описание АПИ — вещь далеко не первой важности.

у меня вопрос насущный — в коде лабораторок обязательно комментарии делать? просто так-то там программы небольшие и выполняют свою маленькую задачку из конкретного задания..посему не увидела смысла в комментариях

Если небольшие — то смело начхать. Код — сам лучший комментарий. Но переменные и функции называть осмысленно, code convention любой нагугленный, но соблюдать.

Да. Смысл лабораторной — делать всё максимально «по-настоящему».

По-настоящему там только текст задания лабы скопипастить хватит для мелких лаб. И самому на мелких задачах сложно понять, что надо комментить, а что — нет. Небольшие задания надо делать просто, а не городить github.com/...terpriseEdition

Ну, тут чувак просто стебётся. Эдакий тонкий троллинг :). Хотя, видел на форумах для начинающих похожих слонов из мух.

круто! но у меня не настолько крутые алгоритмы пока, чтоб брать их из книги, обычно я сама их придумываю, а формулы беру из тырнетика >_<

Код пишут, чтобы решить поставленную заказчиком задачу. И уже во вторую очередь, он должен быть легко читаемым, и это тоже безусловно важно. Но кому нафиг нужен ваш красивый код, если он не работает или работает нестабильно?

А это уже зависит от вашей способности предвидеть развитие событий.
Понимаете, что делаете промо-фигню, которая завтра умрет? Ну да, можно писать абы как.
Ожидаете, что продукт нужно будет поддерживать несколько лет — тогда вопрос читаемости и поддерживаемости кода вылазит на первое место (фичу вы сдадите 1 раз, а поддерживать потом 4 года будете).

Печально, когда команда не видит дальше своего носа или ближайшего дедлайна.

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

С противопоставлением «работоспособности» и «читаемости».

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

И это мнение ошибочно. Обычно так оправдывают хреновый код — дескать хреново, зато работает.

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

Читабельный, но не работающий верно код, всегда может быть легко исправлен.

P.S. А уж заказчику, ни программисты ни код не нужны. Ему решение проблемы нужно.

Про хреновый/хороший код я уже давным давно не спорю. Реально не интересно, это все так условно и относительно... Взять например STL, кому-то нравится, хороший интерфейс, хорошо спроектрирована. А другой говорит, да дерьмо ваше STL, херовый интерфейс да еще и тормозная. А реализация Dinkum для студии вообще ужас, ничерта в коде не поймешь.

Я уже где-то приводил объективный критерий «хорошести» кода:
время на понимание «что тут происходит».
Если больше 30 сек на функцию — это плохо.

У нас в компании регулярно открываются вакансии для С++ программистов, в том числе для начинающих. И мы пришли к необходимости создания целого обучающего раздела на корпоративном сайте. Там есть примеры хороших задач на ООП, примеры вопросов для подготовки к собеседованиям, разбор исходного кода с комментариями. И, кроме того, мы сделали подборку полезной литературы по С++ и не только: www.fulcrumweb.com.ua/archives/1834 Надеюсь, что-то полезное Вы для себя там найдёте.

Огромнейшее человеческое спасибо, добрый человек :)

Такі книги, по порядку:
1.C++ Primer * (Stanley Lippman, Josée Lajoie, and Barbara E. Moo) (updated for C++11)
2.книги Scott Meyers
3.GOF , code complete
4.Inside the C++ Object Model
5.The Design and Evolution of C++
6.The C++ Programming Language
7.Large-Scale C++ Software Design
Можеш попорядку фігачити)

я с++ учил на курсах. 3 месяца курсы по 3 раза или по 2 раза в неделю. Разница с книгами — чувак куски кода с реальных проектов давал. Например разбор строки по словам или переопределение функции printf. Сколько после этого книг видел — нигде разбора строки по словам не разжовывалось, тоесть когда читает практик он кроме теории показывает еще лучшие наработки до которых самому нада доходить года три.

Не подскажешь, что за курсы? Буду очень признательна

давно было, нада искать новые

C++ - очень сложный язык(очень много времени уйдет на изучение всяких либ и прочих бустов), но постигнуть его азы необходимо каждому кто программирует, имхо. Здесь вам правильно пишут — вакансий очень мало. И устроиться джуном — крайне не реально.
Поучите «плюсы», затем берите любой си-подобный но «повыше», учите «core level», дальше выбирайте технологию и go deeper!

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

Не ешьте меня!!111одинодин...

а по теме: Что-то вы «не так» переписываете.
printf("hello kitty"); он работает в любой студии. И да, дело не в студии, совсем.

#include <iostream> // Заголовочный файл
#include <conio.h>
main()
{
//Пусть определенны две переменные с некоторым значениям
int a = 2, b = 5;
cout<<"\n Сумма"<<(a + b)<<"\n Разность"<<(a — b);

return 0;
}
Как-то так, выдает ошибку что не определен идентификатор cout

#include <iostream> // Заголовочный файл
using namespace std;

спасибо. В книге этого не было :*(

но выдает что отсутствует спецификатор типа int
Ошибка 1 error C4430: отсутствует спецификатор типа — предполагается int. Примечание. C++ не поддерживает int по умолчанию c:\users\анна\documents\visual studio 2013\projects\проект4\проект4\исходный код.cpp 5 1 Проект4

какую вы посоветуете? И какого года издательства?

Начните с теории алгоритмов

І мови програмування mix, ага.

Большое при-большое мерси. Прата кстати заказала уже, издательство этого года ;) на образовании нельзя экономить

спасибочки огромное. Я кстати 3дс макс по видеоурокам учила =)

Возьмите темы и проработайте их по гуглу. Добавляя ключевые слова sample code, source. Гуглить что такое, синтаксис использования, типичные случаи применения. В гугле необыкновенно полная и актуальная инфа.

Г. Шилдт, С++ Шаг за шагом.

int main()

Но судя по примеру книги — выбросьте ее.

Купите Прату Язык программирования C++. Лекции и упражнения

Спасибо огромезное ^__^

Однако это мог быть Страуструп. Но не уверен.

У Вас не указан тип возвращаемого значения у функции main.
Должно быть так:
int main()
{
// Тут ваш код
...
return 0;
}
т.е. Вы пропустили int перед main.

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

конио же только на винде есть, не стоит юзать конио

Якщо в книжці використовують conio.h — викидайте її, як тільки це побачите. Інклюди без обґрунтованої потреби і специфічні для платформи до добра не доведуть.

Якщо в книжці використовують main() замість int main() та cout без using namespace std; або не як std::cout, це книжка можливо і хороша, але однозначно сильно застаріла.

Книга застаріла значно більше, ніж з 2005 — простір std зʼявився як принципіальна властивість десь у 1996-97 роках. Я б сказав, що вона писалась не пізніше ніж у 1995, ще вслід cfront’овським версіям мови десь района 1.2-1.5.

Да, часто приклади застарілі.

С++ — це часто біль, як для початку, так і для нормальної роботи.

Для початку це біль тому, що існує багато реалізацій з багатьма версіями, і якщо говорити про інструменти від M$, то ці проблеми помножуються в квадраті (з їхнім умінням винаходити нестандартні велосипеди). С++ біль для початківця і тому, що це складна мова і помилитись легко (як в синтаксисі, так і в поведінці коду). Не знаю, наскільки адекватна порада, але по-моєму на початку краще уникати наворочених IDE і писати або в coder-friendly текстовому редакторі (Notepad++, vim, Emacs), або в «легкому» IDE типу Codeblocks. Для початківця біль ще й у тому, що IDE часто заточені на використання конкретних технологій і створюють купу стороннього коду, який має «допомагати». Так що рекомендую Codeblocks або редактор+MinGW і пізніше освоїти якусь пристойну систему збірки (build system) (хоча б make), щоб справді розуміти, що відбувається.
tl;dr: раджу Codeblocks або подібнe IDE.

Для повсякденної роботи це біль тому, що кодові бази бувають дуже різної якості і з використанням різних підмножин С++ і з використанням *різних* версій стандарту. С++ практично не придатний для скриптування, яке зараз досить важливе (весь веб тримаєтья на ньому, воно проникає в ігри, для практичних задач його часто вистачає з головою). Тут я б радив ще раз подумати, чи справді потрібний С++, а не якась високорівневіша мова.

і якщо говорити про інструменти від M$, то ці проблеми помножуються в квадраті (з їхнім умінням винаходити нестандартні велосипеди).

На винді можна безкоштовно встановити codelite, з яким йдуть clang і mingw, свіжі версії і без тараканів від MS.

Несложный

У меня с книгой возникла такая путаница — переписую пример кода 1 в 1 как в книге, тучу синтаксических ошибок находит. Может дело в том что у меня последняя Вижуал Студия?
Посоветуйте что-то, пожалуйста. Лабу нужно написать

тучу синтаксических ошибо
а ты их здесь покажи, а мы посмотрим

#include <iostream> // Заголовочный файл
using namespace std;

main()
{
//Пусть определенны две переменные с некоторым значениям
int a = 2, b = 5;
cout<<"\n Сумма"<<(a + b)<<"\n Разность"<<(a — b);

return 0;

}

к чему возвращать 0 как результат программы? Это не несет никакой полезной нагрузки. Значит объявляем функцию main() как void и убираем return 0;

В данном случае return 0; показывает успешное завершение программы.
В старых версиях C++ для функции main() можно было указывать тип возвращаемого значения void, но нынешний стандарт не рекомендует этого делать.

а вот ошибка: Ошибка 1 error C4430: отсутствует спецификатор типа — предполагается int. Примечание. C++ не поддерживает int по умолчанию c:\users\анна\documents\visual studio 2013\projects\проект4\проект4\исходный код.cpp 5 1 Проект4

перед main поставить int, похоже.

Ура! Там про спецификаторы вообще ни слова не сказано( какая же ошибка была скачать эту книгу

так поставить этот спецификатор перед переменной, может тогда компилятор и успокоится. Щелкни мышкой по ошибке, и студия покажет, где в коде ошибка

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

Скачай сразу десять разных. Всех уровней. что там советовали? Прату, Саттер, Александреску, Страустрап
вот всё отсюда: stackoverflow.com/...-guide-and-list

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

я видела здесь рекоммендуют Прату и Страуструпа, а на Тостере читала что очень хвалят Совершенный Код Макконела. Совершенный Код и Прату уже заказала, жду когда отзовонится менеджер. А то по тем методичкам,что нам дали не научишься, увы =(

Да вы погибните за Страуструпом.
Возьмите что-то полегче. Страуструп — потом

Гадаю що у книзі Страуструпа не всі приклади компілюються.
Точніше, вони не компілюються в простих смертних.
Бо кажуть що всі С++ компілятори на будь-який брєд Страуструпа викидають єдиний рожевий ворнінг «Yes, Master!» і коректно компілюють буль-яку маячню творця.

А я хвалю Липпмана «С++ Базовый курс», особенно последнее издание (5-е), в нем описан 11 стандарт.

я Динмана читала, так оказалось что там много ошибок((

покупаем и качаем, и гугл в помощь завем. А MSDN на ночь — это святое

Вам на форум телепатів треба.

Нафига, рынок ц++ программистов как то окончательно скукоживается: www.indeed.com/...trends?q=c++&l=

Коментар порушує правила спільноти і видалений модераторами.

я в школе и универе Страуструпа ботанил, но я бы на вашем месте что то другое выбрал
Python, Ruby например. Причина — работы для джуниоров крайне мало.
А вот еще можете Object C попробовать (или Swift)

тут isocpp.org обещали выкладывать материалы и для новичков. беглый осмотр показал только pluralsight.com/...mming-cplusplus

А, вот ещё там же раздел геттинг стартед с рекомендованной литиротурой и вообще
isocpp.org/get-started

Р. Лафоре — Объектно-ориентированное программирование в С++ лучшей книги для новичка не видел. Все просто и грамотно.

Страуструпа, того что «Язык C++» лично я так и не прочитал, хотя допускаю, что книга хорошая. Сам начинал с Шилдта (умея уже ассемблер и C), который посредственного качества, но как старт сгодился.

Потом были Мейерс: «Эффективный C++», «Более эффективный C++» и «Эффективный STL» — очень хорошие и легко читающиеся книги.

После них можно почитать Саттера «Сложные задачи C++» и «Новые сложные задачи C++».

Конкретно для шаблонов стоит почитать Вандервуд, Джосаттис «Шаблоны C++». Есть еще Александреску, но мне он показался скучноватым. Для практики мне было интереснее в Boost поковыряться.

Еще рекомендую на досуге Страуструпа «Дизайн и эволюция C++» — объясняет, почему C++ именно такой какой он есть, помогает лучше понять язык.

Отличный список. После Шилдта и перед Мейерсом с Саттером я б добавил еще книгу Джосаттиса «С++ стандартная библиотека» . (The C++ Standard Library A Tutorial and Reference — название оригинала)

Брюс Эккель философия с++, хорошо описано. Страуструпа только имея определенный опыт, не понимаю, что думают люди, которые советуют Страустрыпа изначально, разве что хотят убрать конкурентов в будущем) Страуструп это больше справочник чем учебник. Видел много людей, которые перечитывали Страуструпа >2 раз, но не видел ни одного, который бы научился кодить по нему, а автору, видимо, это нужно.
Если работаешь в большой конторе, можно подойти к менеджеру, описать свои стремления, и попросить параллельно тебя включить в команду, где на с++ пишут, я так в свое время подключился на параллельные проект и раздуплился с qt.
Но в любом случае, научиться кодить это задача, которая не имеет четкого решения и в кадом случае индивидуальна.

Я бы тоже не отказался что-то почитать из этой темы. С книгами понятно, но вот в соседнем треде про JS были очень интересные ссылки на статьи, околоJS'ные ресурсы и прочее. Хотелось бы что-то по плюсам такое увидеть.

Стивен Прата — самое простое и доходчивое обучение С++, как по мне. Я с него начинал, причем с английской версии, даже в ней все было понятно со слабым университетским английским. Гораздо проще Страуструпа для новичка.
www.ozon.ru/...ail/id/7979735
www.amazon.com/...y/dp/0321776402

www.ozon.ru/...ail/id/5354710
отличная книга, когда-то учил C++ по ней. С выходом С++ 2011-го не в курсе актуальна она или нет.

Помню, когда-то вот эту книгу хвалили:
www.books.ru/...science-790887
(Р. Лафоре — Объектно-ориентированное программирование в С++)

Имхо, только Страуструп и Либерти

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

Не то, что б обязательно. А ОБЯЗАТЕЛЬНО.
Как-никак Страуструп — создатель С++ :).

Підписатись на коментарі