Евгений Шатунов

Открываете вакансии и читаете.

Собственно, это нормально и правильно - вы же поменяли сабмодуль? Поменяли.

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

Следовательно, сабмодуль нужно закоммитить и обновить ссылку у родителя (и тоже закоммитить).

Ошибка в недрах стандартной библиотеки. Вы в вашей программе что-то не так делаете и она падает. Это частая проблема в C/C++, можно допустить такие ошибки, что программа упадет.

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

Увидите, что ошибка происходит на строчке:
cout << morze.find( text[i] )->second <<" ";

Проблема возникает при попытке обратиться к second у возвращенного значения. Но почему? Читайте ошибку: "cannot dereference end map/set iterator".

Т.е. find возвращает end() итератор. Действительно, посмотрите в документацию - map вернет end() если искомого ключа в нем нет.

Иправить ошибку просто - исправьте ваш код. Сначала присвойте переменной возвращенный из find итератор, и потом проверяйте, а не end() ли он. И только в противном случае выводите.

Я подозреваю, что символом оказался пробел. Пробела в вашем мапе morze нет, вот все и падает.

Не знаю как сейчас дела с Android, но среди spring'овых разработчиков, ищущих первое рабочее место, конкурс примерно двести человек на одно место. Так что 15 компаний и один месяц - это мелочи.

Фундаментальная проблема - в игрострой стоит очередь фанатов с горящими глазами. Людей, которые пишут игры, играют в игры, моддят игры, хакают игры..., начиная с возраста, когда они смогли дотянуться до клавиатуры (как ваш покорный слуга). При этом, у них столько мотивации, что они могут сами поставить себе задачу, сами нагуглить все, что нужно (Спасибо дяде Немнюгину за его учебник. Это все что нужно знать о DOS, чтобы закодить dOOm) и сами все напишут и нарисуют (работая над этим сутками. Не потому что над душей стоит босс с воплями о лишении премии, а потому что им это интересно).

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

В играх есть много специализаций программирования - хотите графику, придется учить одно (причем на 2d и 3d это одно будет разное), хотите игровую логику и скриптинг - это номер два, хотите системную часть и бэкенд - это будет третье.

Для универсального развития, нужно начинать с простых фиговин вроде тетриса, арканоида, бильярда и прочего (в которых однако есть все столпы игростроя - графика + логика + системный движок, можно и добавить сеть, если подумать) и потом наращивать сложность - делать платформер или RTS.

А куда scanf должна помещать считанные данные? Передай в неё какую-нибудь переменную, с которой она будет работать.
Что-то типа такого:

#include <stdio.h>

int main ()
{
  char str[255];
  for (int i = 0; i < 3; i++)
    {
      scanf ("%s", str);
    }
  printf ("%s", str); // Выведет последнюю введённую строку
  return 0;
}

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

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

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

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

В описанном вами случае - можно, написав внешнюю функцию суммирования.

std::vector<int> operator + (std::vector<int> a, const  std::vector<int>& b)
{
    if(a.size()!=b.size())
    {
        throw std::range_error("sizes mismatch!");
    }
    for(size_t i=0;i!=a.size();++i)
    {
         a[i]+=b[i];
    } 
    return a;
}

Да. Потому что локальность памяти и меньше разыменовываний.

в vector<vector> это фактически указатель на массив указателей. Строки раскиданны по памяти как попало и при обращении к ячейке будет лишнее обращение к памяти, чтобы получить адрес строки.

Если же вы этот двумерный массив линеаризируете и будете сами вычислять индекс, то, во-первых, все будет локально и последовательное чтение массива по строкам будет очень дружественно кешу процессора, во-вторых, вместо двух сложений и двух обращений к памяти будет умножение, два сложения и одно чтение из памяти. А умножить два числа будет всяко быстрее чтения из памяти.

У вас решение за O(NM), когда как есть решение за O(N+M).

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

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

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

Это делается по нескольким причинам.

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

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

Во-вторых, иногда это делается и для удобства. Ибо в этих шаблонах параметры сами могут быть адски нагроможденными шаблонами.

А не проще ли так?

template <const std::size_t other_columns>
 Matrix<rows, other_columns, T> MultiplyOnMatrix(const Matrix<columns, other_columns, T>& matrix)

Переменные прекращают существование после завершения блока, в котором объявлены. Соответственно, используйте маленькие функции, объявляйте переменные как можно ближе к месту их использования и компилятор обо всём позаботится сам.

Метод класса под капотом - это функция, котрой помимо прописанных параметров передается указатель на объект. В вашем случае передается nullptr. Но сама функция не обращается к объекту, да у него и членов-то с данными никаких нет. Поэтому все более менее работает. Но это UB и могло и не повезти. Из-за оптимизаций компилятор мог бы что-то сломать.

P.s. сказанное выше не относится к виртуальным функциям. Там указатель на функцию храниться в vtable в экземпляре класса и вызов через nullptr скорее всего упадет.