Vitaly

Лучше Python, потому что он объективно проще плюсов и позволит сконцентрироваться на решении задачи, а не на инструменте формализации решения. Это означает, что у вас будет больше времени на освоение типовых алгоритмов и структур данных.

Не для кого ни секрет, что так называемое спортивное программирование -- это про умение понять к какой категории относится задача, быстро увидеть паттерн и написать какой-то низкокачественный код, чтобы проходило тесты. Вот и всё.

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

С реальным практическими задачами, где C++ будет выгоднее выбрать с точки зрения скорости работы программы и объёма потребления ресурсов, вы, вероятно ближайшие лет 10 не столкнётесь, если столкнётесь вообще.

В плане DS/ML (и прочих модных штук в этой области), Python однозначно более широко используется, чем C++. Ну всякое вроде R.

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

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

Вопрос в другом: чего вы хотите добиться, читая исходные коды программ?

То что создатели курсов подразумевают под основами программирования надо выяснять у них.
Рекомендую прочитать книгу Чарльз Петцольд Код + любой язык на базовом уровне. Этого должно хватить.

В сообщении об ошибке UI в верхнем регистре, в коде, i в нижнем. Посмотрите, как сгенерирован файл ui_anotherwindow.h, там пространство имён должно совпадать с пространством имён из anotherwindow.h, ну и везде по коду.

Я пользуюсь Das Keyboard (https://www.amazon.com/Das-Keyboard-Ultimate-Mecha... Очень удобная и качественная механическая клавиатура. Не тонкая конечно же.
Многие программисты ещё всякие гнутые эргономичные клавиатуры предпочитают (вроде таких: https://www.amazon.com/Microsoft-Ergonomic-Keyboar...

Можно взять любой из этих Dell UltraSharp UP2716D, U2715H или U2717D. Сам пользуюсь подобным, отличные мониторы.
Ездить по магазинам смысла нет -- только время тратить. Подобрали, заказали, вам привезли всё :)

Я не удивлён, ведь "весовые коэффициенты" -- это из теории графов. Вероятно вы столкнулись с плохим переводом или некомпетентным преподователем. Скорее все вам нужно гуглить про приоритеты процессов в Linux.

На самом деле, интересоваться основами программирования -- это хорошо и правильно, побольше бы веб-программистов это делали!
Хороший задачник для начального уровня: Златопольский Д. М. "Сборник задач по программированию". Потом можно Сэджвика почитать по алгоритмам (уж не помню, есть ли там упражнения, но вроде есть) или Кормена, но он в некотором роде сложнее.
По практикам написания хорошего кода есть другие книги. Там и какой код назыается хорошим написано :)

std::string securityLib_GetCode()
{
   return "CODE";
}
// ...
auto code = securityLib_GetCode();
auto size = code.size();
auto raw = code.c_str();

Всегда используйте std::string в качестве обёртки над char *. Ну кроме очевидных случаев, например, когда это API какого-нибудь модуля и может случиться беда из-за разных рантаймов.

В Sublime можно самостоятельно компилировать файл? У меня задача с argc argv , нужно самому аргументы передать до того как файл скомпилируется, на всех сайтах онлайн-компиляторов компиляция происходит сразу без выбора аргументов

Вы немного путаете, чтобы передать аргументы выполнения, нужно запустить исполняемый файл (т.е. после успешной компиляции). Например:
./myProg 123
Здесь argc == 2, и argv[1] == "123".

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

Что касается кода... Код как код. Если есть реальная потребность возвращать по конст ссылке и без этого не обойтись, так возвращайте. Разумеется, если это не противоречит стандартам кодинга в вашей компании, структуре API и всему такому. В любом случае вы должны просчитать все последствия и варианты использования в реальном приложении. На синтетическом примере этого не увидеть. Я бы если честно предпочел видеть умные указатели, если приложение уж не совсем такое, где надо на всём экономить (а уж чтобы не использовать умные указатели, нужны обоснования и веские).
Если пользовательский тип поддерживает implicit sharing (можете прочитать про это в доках Qt, у них даже есть специальные классы, которые облегчают жизнь тем, кто хочет создавать свои "copy on write" классы), то его смело можно возвращать по значению. Это же справедливо и для smart pointer'ов.

Годик можно поработать, параллельно изучая что-то более актуальное, а потом уехать в город побольше с крупными компаниями, интересными проектами и т.п. Конечно лучше сразу это сделать пусть даже и работать за еду стажером и арендовать подоконник :) Зато будет вагон неоценимого опыта и коллектив профессионалов у которых можно учиться. Ну может конечно не супер профессионалов, но вероятно лучше чем на нефтянном заводе. Через год-два (от вас зависит и только от вас) можно уйти на более интересную работу ну или вырости в джуна-мидла в этой же фирме.
Откройте например hh.ru и ужаснитесь количеству вакансий для программистов на делфи. Очень уж нишевой это язык и стек технологий.

С открытыми полями можно сделать разве что какую-нибудь структурку вроде std::pair, которая допустим откуда-то возвращается в качестве результата (например это результат вычислений и какой-нибудь тэг) или которая используется только в рамках одного класса или просто в одном cpp файле как вспомогательная, но не где более.
В остальных случаях всегда нормальная инкапсуляция иначе потом будет плохо и вы будете страдать. Представьте ситуацию с большим проектом, когда вам нужно банально поставить бряку и посмотрять кто и когда изменил значение поля. Или например добавить любую логику перед установкой/получением значений (хотя бы банальные нотификации).
Просто возьмите за правило инкапсулировать и все. Нажать пару кнопок для генерации методов лучше, чем потом страдать.

Есть же cx_Freeze, например. Там все очень просто.