Wataru

Спросите у перподавателя.

Может вместо конструкций C++ типа cin, cout, printf надо использовать псевдокод. Типа "ввод x"

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

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

А дальше вам надо посчитать длины трех маршрутов и выбрать из них лучший.

int index = std::distance(NUMBER.begin(), it);
TYPE.erase(TYPE.begin() + index);
PRICE.erase(PRICE.begin() + index);
...

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

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

Главное приемущество: независимость процессов. Потоки делят между собой одну память и ресурсы системы (всякие хандлеры в винде, например).

Если один из процессов завершится или, что чаще происходит, упадет - остальные не будут затронуты. Плюс эта независимость позволяет делать песочницы для безопасности. Так, все современные браузеры запускают js и вообще каждую вкладку в отдельном процессе. Даже если куллхацкер полностью взломает браузер через специальный сайт, он окажется в процессе, который особо прав никаких не имеет, библиотеки особо интересные туда не загружены, а все общение с внешним миром - через жестко прописанные протоколы ipc (inter-process communication). Так что злодею придется взламывать еще и их.

Эта же независимость позволяет выполнять работу даже после завершения основного процесса. Так, если вы хотите сделать автообновятор программы, то после скачки/установки нового приложения, надо будет перезапустить основное приложение, чтобы перезаписать исполняемый файл (по крайней мере в винде). Но поток завершится вместе с программой и кто же тогда потом будет ее запускать? А вот процесс останется работать.

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

Он там не вызывается. Этот приватный конструктор используется в функции

void lib::LinkedList<T>::push(const T&) [with T = Item<int>]

, которая в шаблоне (там где вы создаете Node* tmp). При первом обращении к этой функции компилятор пытается ее инстанциировать и натыкается на эту проблему, о чем и сообщает вам. Пока эта функция вообще никак нигде не используется - программа компилируется.

В приведенных вами примерах вы эту функцию так или иначе трогаете разными способами.

lib::LinkedList<Item<int>> list = lib::LinkedList<Item<int>>()

вызвает проблему пока у вас есть virtual метод в интерфейсе, потому что это тут вызывается конструктор копирования (сначала конструктор по умолчанию для временного lib::LinkedList<Item<int>>(), а потом это все копируется в конструируемый list).

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

Если вы напишите lib::LinkedList<Item<int>> list() - то все скомпилируется, потому что конструктор по умолчанию, видимо, не требует знания о методе push. Также удаление virtual или наследования вылечит эту проблему.

Далее, точно по этой же причине не скомпилируется list.push(a) - это прямой вызов этой запретной функции. Если же вы напишите list.push(Item<int>()), то оно скомпилируется потому что тут вызывается push с перемещением.

Но для исправления этого кода вам надо прежде всего избавится от этой поломанной функции push.

Ну, посмотрите хотя бы хромиум. Там жесткий стиль и хоть качество кода не равномерное, в основном это точно не "Си с классами".

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

Если постоянные жалобы, то устройте код ревью в команде. Пусть ваш код хотя бы пару неделек кто-то постоянно будет проверять перед комитом и выдавать конкретные правки (а вообще код-ревью хорошо использовать всегда. Тот же github дает возможность это делать. Или есть опен сорсный gerrit).

Возможно, вы используете классы только как структуры максимум с какими-то тривиальными действиями (типа get_sum, get_value, set_value и т.д.). Когда как в ООП объекты должны инкапсулировать в себе логику и уметь делать нетривиальные вещи. Сама программа должна состоять из взаимодействующих объектов.

Еще использование stl. Стоит избегать массивов - используются std::vector. Так же вместо char* стоит использовать std::string. Ну и там куча алгоритмов есть: от выбора максимума в массиве до сортировки.

Придется именно лазить туда и смотреть исходиник.

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

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

Проблема в том, что "214" - это строковая константа. Поэтому char *num = "214"; инициализурует указатель num адресом этой константы. Сама эта константа, видимо, лежит в read only памяти. Поэтому когда вы в алгоритме попытаетесь что-то в массив записать, программа упадет.

Если вы внимательно почитаете вывод компилятора (желательно с ключем "-Wall"), то он вам про это выдаст варнинг:

main.cpp:54:17: warning: ISO C++ forbids converting a string constant to ‘char*’ [-Wwrite-strings]

Надо делать так:
char num[] = "214";

Ну еще у вас там в коде ошибка с непроставленным где надо +1 у index. Разворачивать надо кусок правее только что увеличенного элемента. А вы разворачиваете вместе с ним. Поэтому ваша программа еще и повиснет.

Ну и первую перестановку ваш код не выводит.

И последнее, вместо for (; index != -1;) лучше использовать while (index != -1)