rodel_d:Для джуниора достаточно будет лишь знания основ работы GC. Все остальное уже избыточно.
Yosic:Более того для C/C++ GC - не актуален.
Ну вот, 2 профи имеют разные мнения по одному и тому же вопросу... Кому, нам, пре-джунам верить? 
Yosic, ваш длинный спич опоздал лет так на 30. Знания добротные, но уровень их сложности - для 7-ми классников. Сейчас всё это не актуально. Актуальны функциональные подходы === структуры + математика.
PS Интересующимся состоянием дел порекомендовал бы почитать этот полный боли в ж.... поучительный блог, где очень не глупый С++шник делится впечатлениями от работы с богатым инструментарием, с которым работают самыевостребованныеивысокооплачиваемые на С++.
https://isotoxin-dev.livejournal.com/
Привет.
Кажется я забил на этот блог. А может я забил и на Isotoxin?
Пока затрудняюсь ответить. Стал уделять больше времени другим проектам. Несмотря на то, что Isotoxin кишит багами, я решил пока на них не отвелкаться. Худо бедно работает, и хорошо. Сейчас, если я занимаюсь Isotoxin-ном, то это только портирование. Сразу признаюсь, работа идет со скрипом. Здесь я опишу некоторые трудности. Они, вероятно, будут сильно раздуты и вообще являются лишь следствием моей некомпетентности. Но ведь это я портирую Isotoxin, а не вы, не так ли? Так что можете просто считать этот пост нытьём человека, который идет вразрез правилам. Правилам грамотного написания портируемого кода. А такой путь - это путь боли
Итак.
Как вы, наверное, знаете Visual Studio - это IDE под windows и только под windows. Isotoxin писался с помощью этой IDE. Под линуксом мне понадобилось выбирать редактор кода, который бы был хотя бы в чем-то близок Visual Studio. Нет нет, никаких vim-ов, что вы. Я старый больной человек, мне поздно переучиваться. Да и смысла нет, т.к. я вовсе не собераюсь приобщаться к светлому миру юникса.
Сначала я попробовал использовать CodeLite. Подкупила близость концепции к Visual Studio. Но, провозившись с ней какое-то время, я отказался. Бесконечные мелкие баги интерфейса еще можно было пережить, но, что меня совершенно выбешивало - это глючный build. Ну вот как с эти можно работать: изменяю что-то в файле, нажимаю на build и... трам пам пам, всё прекрасно, build закончен, ошибок нет. Оно просто не выполняло build после редактирования файла. Сначала я перезапускал эту IDE. Потом случайно обнаружил, что если в папке с проектом выполнить make, то build в IDE снова начинал работать, но до следующего изменнеия исходника. Вобщем, в один прекрасный момент снёс это чудо и забыл как страшный сон.
Потом были QTCreator (не заработал вообще, разбираться особо не стал), еще какие-то IDE-шки, которые мне не подходили, т.к. были завязаны на cmake (мне не нравится идеология cmake, не переубеждайте, бесполезно). Eclipse даже пробовать не стал, наслышан о ее жадности до ресурсов (IDE на java - ну нафик. Мне хватило Android Studio. Жрет память как не всебя.)
Короче, пока остановился на Code::Blocks. Тот еще рассадник багов, но хоть build работает, и дебагер завёлся из коробки. За это и терплю.
Как я работаю. Создаю проект, добавляю файлы, настраиваю опции сборки, нажимаю build. Ессесно получаю вагон ошибок, правлю (если это всего-лишь недопонимание со стороны gcc) или пишу новый код, если старый windows-only. Такая себе рутина. Вот только пишу и правлю код я на старой доброй Visual Studio. Но не умеет Code::Blocks того что мне надо! И нет никакой возможности её этому научить. А если и есть, то это сакральное знание нет никакого желания постигать. Все таки я дитя прогресса. Обработка напильником - это для истиных адептов юникс-мира. Не моё это.
Из неудобств: при сохранении убивает кодировку, меняет права доступа к файлу, так, что по самбе они переходят в разряд read-only. Бесит жутко. Нет поиска символов. Нет быстрой навигации по методам в пределах одной единицы трансляции. Переход к определению работает меньше чем в половине случаев. Определение того, будет этот кусок кода компиляться, или будет отброшен из-за #ifdef/#endif - глючит. Приходится добавлять левый символ и пробовать собрать. Поиск медленный и глючный. Доходит до того, что плюю и начинаю искать far-ом по папке, расшаренной в самбе. Это пипец, товарищи. Автоформатирование чудовищное. Логика табов с файлами, если и есть, то я ее не уловил. Табы постоянно меняет свой порядок и постоянно пропадают. А после перезапуска IDE вообще не понятно по какому принципу восстанавливаются. Каша какая-то. Также не сохраняются брейкпоинты. При попытке прервать дебагинг, стоя на брейпоинте, частенько зависает. Если изменить файл и нажать на build, нормальная IDE этот файл сохранит перед сборкой. Но не Code::blocks. Но это еще ладно. Гораздо серьезнее, это то, что IDE не вкурсе, что при изменении файла, требуется пересборка и для всех файлов, которые включают в себя измененный. Приходится делать полный rebuild. Дебажить более одного процесса одновременно нельзя.
Я давно подозревал, что под линуксом софт такой глючный, потому что люди работают в нечеловеческих условиях. Теперь я в этом убедился Это фраза не для холивара. Это просто моё скромное мнение.
Сижу и думаю: а оно мне надо?
Шучу. Надо. Из принципа.
Обновление групчатов
Я сделал это. Сделал постоянные групчаты в tox-е.
Суть проблемы всем известна - групчаты в токсе умирают сразу после дисконнекта. Отвалилась связь? Заходи в групчат по новой. Перезапустил клиент - заходи в групчат по новой. Чтобы хоть как-то снизить градус нелепости происходящего, были придуманы групботы. Групбот - это такой друг (в терминах tox-а - friend), которы online 24/7 и который без вопросов соглашается на приглашение в друзья от любого, кто это приглашение ему пошлет. Этот групбот сидит в неком групчате (или сразу в нескольких) и таким образом оберегает групчат от исчезновения. За одно этот групбот понимает простые команды, типа invite или info. По команде invite, групбот приглашает вас в свою группу, в которой сидит сам.
А теперь пойдет злобный текст.
Как оказалось, такое свойство групчатов tox не потому что невозможно сделать иначе (я слышал фразы типа: "ну это же p2p, там все не так просто"), а потому что irungentoo, тот самый чувак, который и сотворил весь tox (за что ему, конечно, спасибо) забил на разработку. При чем забил, толком не доведя tox до ума. И, как показали дальнейшие события, это был единственный человек, который хоть что-то мог сделать. Все остальные из команды Tox Foundation, просто какие-то импотенты (Ребята, если вам кто-то переведет этот текст, можете меня возненавидеть. Вы реально нихера не умеете. А лучше не рефлексуйте, а идите и работайте). Кстати, существует реализация т.н. "новых" групчатов (тут). Но эту реализацию делали какие-то студенты по программе GSoC, и никто из Tox Foundation не знает как она работает. А она и не работает Поэтому воз и ныне там.
Вобщем, решил я что-то с этим сделать. Покопавшись в коде групчатов примерно с месяц, я сумел полностью их постичь, применив свой любимый метод - переписать нахрен. В процессе переписывания появлялись различные проблемы, которые я решал и смотрел, как они решены в оригинальном коде, тем самым постигая непонятные и, на первый взгляд, сомнительные куски оригинального кода.
В результате на свет появилось обновление к текущим групчатам, выраженное вот в этом PR-е. Как вы можете видеть, PR не принят. Я думаю, он не будет принят никогда. А всё потому что ребятки заигрались в крутую команду разработки, сами при этом нихрена не умеючи. Вобщем, они хотят двух вещей, на которые сами не способны: 1. Понять, как это всё работает. 2. Тесты. Я, тесты, понятное дело, писать не буду, т.к. хватит и того, что Isotoxin с этим обновлением вышел и работает. С первым пунктом, похоже вообще беда.
Трудности портирования 2
Вот смотрите.
Акт первый.
У меня есть свой супер гипер крутой массив. Ну велосипед, да, но пока что возражения типа "юзал бы std::vector и горя не знал" я не принимаю. Так вот, массив этот много чего умеет и состоит чуть менее чем полностью из шаблонов. Например, он умеет быть массивом указателей, для которых надо вызывать delete. Или не надо. По желанию. Понимает, что некоторые типы могут быть непереносимыми в памяти. С такими типами он работает чуть медленнее, вызывая конструкторы и деструкторы при ресайзе массива. А если тип поддерживает перемещение, то такие объекты переносятся в памяти средствами memcpy, что, разумеется, значительно быстрее. Ну и так далее. Велосипед сей написан давно, оттестирован и нареканий в работе не вызывает.
...
Акт четвертый.
Я как-то уже писал, что Visual C++ особо не требователен к шаблонам, в том смысле, что он не пытается их дотошно обрабатывать, пока не столкнется в коде с непосредственным использованием. И вот, Isotoxin на Visual C++ собирается, линкуется и прекрасно работает. Но вот мы пытаемся собрать код под gcc. БОЛТЯРА! gcc банально не врубается, где же тело одного из методов того самого шаблонного класса. Ладно, простим ему его строгость. Я не говорю "глупость", т.к. это Visual C++ слишком умный, а не gcc глупый. Для Visual C++ хватило того, что я эту функцию вызвал в том же файле, где и объявил. Всё. Он это запомнил и больше у него вопроса "а где же эта функция?!" не возникает. Другое дело gcc. Он намеков не понимает. Ему надо явно инстанцировать весь шаблонный класс. И вот тут...
Акт пятый.
Вот тут наступает полная задница. Помните, что в шаблонном классе есть супер гипер массив? Ну тот, который много чего умеет. Так вот, он умеет замещать содержимое ячеек. А что это по сути? А по сути это банальное копирование. Есть инициализированная ячейка, копируем в нее объект. Вот это оно и есть. А помните, что в массиве могут быть некопируемые классы? Ну так вот, инстанцируя весь шаблонный класс целиком, я должен теперь написать функции копирования для некопируемых классов. И плевать, что я нигде для этих объектов не вызываю функцию копирования. Инстанцируешь — будь добр объяви. Чиорт. Сижу, объявляю. Фейковые, разумеется — они ж все равно нигде не вызываются.
И вроде бы и мелочь, но я уже подзаколебался это править. Вот такие вот трудности.
PS. Этот пост был написан... а просто так был написан. Не надо ничего предлагать. Я всем доволен
), ни передачи по ссылке и по значению, ни всего остального там нет и знать это не надо 
