char* и почему ты не можешь работать конкретно с типом const char*? Obj newO = arr[arr.size()-1];Obj& newO = arr.back();arr.insert(arr.begin(), std::move(arr.back()));
arr.pop_back();Book, ты расширяешь внешний интерфейс именно для Book, но не для какого-либо иного типа. UPD: Вопрос решён. Помогла функция glutTimerFunc(), убираем glutPostRedisplay() из idle-функции, создаём таймер с обновлением в 1000/FPS_LIMIT миллисекунд и создаём новый таймер в том таймере, тем самым таймер создаёт другой таймер и так по кругу.
std::vector<std::string>, а std::set<std::string> и все те же две std::unordered_map<std::string_view, std::string_view>std::set, кстати, тоже есть функция emplace. std::map, а std::unordered_nap. Тебе стоит самостоятельно понять принципиальную разницу этих контейнеров и почему первый в твоей задаче непригоден.std::unordered_map<std::string, std::string>. Первый контейнер хранит прямой перевод, второй - обратный перевод. Контейнеров два т.к. слова в разных языках могут писаться одинаково, а значения у них могут быть разные и переводы, следовательно, тоже разные.emplace. Изучи документацию и найди для себя обоснование - почему именно эта функция будет эффективнее всего работать с парой std::string_view в качестве параметров.std::string в качестве параметров шаблона std::unordered_nap таково, что TranslateForward возвращает std::string_view, который не владеет памятью на которую ссылается. Вместе с этим, тип std::string_view не рассматривается как тип долгосрочного хранения (рассматривать его как долгосрочное хранилище - в большинстве случаев опасно). Такая сигнатура требует от Translator владеть памятью строк возвращаемых из функций Translate*. В самой задаче использование string_view оправдано экономией памяти.
Translator::Add(string("first"), string("second")) - первое выделение делается вот тут. Зачем?data.emplace_back(first) - второе выделение делается вот тут и ниже во втором emplace_back.std::string_view в качестве типа параметров твоей функции?
Реализацию на C++ привел Roman .