Acaunt

Проблема вызвана использованием шаблона rewrite из шаблона search.

Если вы перенесете специализацию шаблона rewrite вверх, до специализации search, то все скомпилируется. Или надо где-то выше первого использования шаблона rewrite задекларировать специализацию (что ваш закомментированный код и делает).

Вызвана эта ошибка стандартом.
Надо, чтобы специализация шаблона была задекларирована до любого использования:

Specialization must be declared before the first use that would cause implicit instantiation, in every translation unit where such use occurs:

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

Но вообще, делать так для экономии памяти никогда, категорически не рекомендуется. Код становится менее читаем а экономите вы на спичках. Это локальные переменные - они на стеке. Их много можно выделить только рекурсией или большими массивами (ну не объявите вы в коде миллион локальных переменных). В обоих случаях, если стека не хватает - надо или избавлятся от рекурсии/больших массивов изменением логики, или выносить их в кучу.

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

Полагаю, что вам удобно будет использовать здесь шаблоны, если я правильно понял вопрос.
Например:

template <typename T>
auto search (std::string str) {
    // T - data type
    T res;
    // do something
    return res;
}

int main () {
    auto a = search<int>("a");
    auto b = search<std::string>("a");
}

Каждый вопрос здесь подразумевает довольно большой объем информации при обосновании ответов. В общем смысле весь вопрос сводится к выбору одного из стилей написания кода.
Обычно стиль кода закреплен стандартом языка, но в стандарте C++ такого нет. Поэтому стиль кода в C++ является предметом выбора каждого. Опять же, обычно для C++ стиль кодирования выбирают наобум, просто потому что понравилось так или потому что в этом стиле пишет любимая компания (GCS - хороший пример выбора на эмоциях и яркий пример очень плохого стиля для C++). Но обоснование своего выбора является очень важным.
В C++ Core Guidelines есть отдельная секция с описанием стиля кодирования стандартной библиотеки.
И тем не менее.

1) Как называть переменные:

Зависит от того, как будут называться функции и константы.

2) Что лучше присваивать булевым переменным:

Литералы 0 и 1 имеют тип int. Если тип переменной - bool, то с какой стати справа от типа должны присутствовать значения с типом int?
Следует использовать только литералы с типом bool: true и false.

3) Как лучше называть переменые итераторы во вложенных циклах:

Абсолютно каждое имя должно отвечать на вопрос: "Зачем ты тут существуешь?"
Могут ли однобуквенные имена ответить на этот вопрос внятно через всего одну свою букву? Нет.
Имя - это смысл. Имя - это причина существования. Имя - это цель использования.

4) Очень локальный вопрос стоит ли писать else, если ниже нет другого кода ниже:

Ветвление всегда подразумевает ровно один прыжок или продолжение исполнения кода. Иногда ветвление подразумевает два прыжка: или прыжок в начало альтернативной ветви, или прыжок из конца основной ветви за пределы кода ветвления. Оптимизатор сам выбирает лучший вариант реализации ветвления, более выгодную основную ветвь и от писателя в этом процессе мало что зависит. Но для читателя ветвление и циклы всегда подразумевают очень большое усложнение кода. else стоит писать только тогда, когда без него иначе невозможно.

6) Писать ли пробел между стандартными функциями и скобками:

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

7) Тот же вопрос только про функции, что я сам написал:

С этого момента тебе должно стать понятно, на чем именно нужно делать акценты чтобы не выводить читателя из себя. Главное - это при написании кода всегда помнить, что возможно читать его будет натуральный маньяк-психопат, который точно знает где ты живешь. И ты точно не хочешь разгневать его своим кодом. :)

ГЛОБАЛЬНО:

Тратить время, внимание и силы на педантичный подсчет пробелов и расстановку скобок - контрпродуктивно. Достаточно настроить автоформат перед коммитом и сосредоточиться на корректности кода.

1) Равноправно, но первое веет PEP8
2) Однозначно true/false. Возможность прямого каста чисел в логику является тяжлым наследием C и ведет к интересным потенциальным багам.
3) Обычно i, j, k потому что олдовые программисты учили в первую очередь математику, а потом уже алфавит. А если вложений больше трех, пора браться за рефакторинг.
4) Нет, не стоит. Цель как раз в том, чтобы выпрыгнуть из блока как можно раньше, а не вкладывать блоки друг в друга. Опять же, если вложений больше трех - в рефакторинг
5) Вы пропустили этот пункт, тренируйте внимание
6 - 7) Вкусовщина, лично я не пишу эти пробелы. Но я и не использую египетские скобки для циклов (а вы - используете)

Я бы полистал уже готовые рекомендации по стилю. Из них можно подчеркнуть интересные вещи, которые могут сказаться даже на качестве самого ПО и потенциальных ошибках.
Вот пример.
https://google.github.io/styleguide/cppguide.html

Проблема вот в этой строчке:
return str.c_str();

Тут вы возвращаете указатель на внутренние данные у str. Но при выходе из функуции str уничтожается - это же локальная переменная. В итоге у вас получается висячий указатель (указатель на память, которой вы уже не владеете). Эту память какая-то другая часть вашей программы переиспользует и там остается что-то не ваше, выглядещее для вас, как мусор.

Вообще, это undefined behavior - доступ к висячему указателю. Программа вполне может и аварийно завершится.

Для решения этой проблемы возвращайте std::string. Или выделяйте char* вручную, через new[] (только не забудьте указатель потом удалить в вызывающем коде). Но лучше, конечно, возвращать string и не мучатся с ручным управлением указателями.