1. std::make_shared всё равно производит одну аллокацию вместо двух, если создавать через new + конструктор. У этого есть плюсы и минусы. Минус: когда был аллоцирован большой объект и все ссылки на него исчезли, а слабые ссылки — нет, то весь большой кусок памяти всё равно висит в оперативке из-за этих слабых ссылок
2. Чисто эстетически мне кажется make_shared выглядит лучше. Потому что при создании через конструктор у нас есть new, но нет delete. Несимметрично.

не make_shared, а make_unique

Спасибо

До c++17 тоже можно было не использовать

Непонял

Забей, всё уже сказали

Как лучше передавать строку в функцию, как const string& или string_view

std::string_view

, если функции владение строкой не передаётся, std::string, если передаётся

Смотря какое у функции тело

Строку не надо изменять

Если дальше по колстеку будет принятие по const std::string& или по сишной null-terminated const char*, то передавай как const std::string&

Спасибо

Никто не знает, когда std переведут на модули,

Насчет сишной не согласен, второй случай внесет свои коррективы, да

Через 3 года

Ок

Интересно вот что...
Я точно знаю, что если функция принимает const string& и внутри не производит никаких копирований (пример - find у map), то при вызове от известной на этапе компиляции const char* компиль может убрать создание string
А прокатит ли такое с data(string_view), если содержимое последней также известно в compile-time?
И что с runtime - будет ли оптимизация, если содержимое const char*-строки на этапе компиляции не известно?

Ну это от компилятора наверно зависит

И от флагов

Я компилирую mingw без флагов оптимизации