Ошибка string subscript out of range

Подобные ошибки означают, что во время работы программы была предпринята попытка обращения к памяти, не подготовленной должным образом для этого. Программа с такими ошибками содержит неопределённое поведение. Самыми говорящими из рассмотренных в вопросе ошибок являются те, где сказано «subscript out of range». Дословно это переводится как «Индексация вне диапазона». Понятность их обеспечивается в первую очередь тем, что программа собрана в отладочном (Debug) режиме и соответствующий код индексации operator[] того или иного контейнера (std::array, std::string, std::vector) непосредственно содержит проверку значения индекса, передаваемого в оператор индексации. Например, так выглядит код в msvc 2019 для std::array:

    _NODISCARD _CONSTEXPR17 reference operator[](_In_range_(0, _Size - 1) size_type _Pos) noexcept /* strengthened */ {
#if _CONTAINER_DEBUG_LEVEL > 0
        _STL_VERIFY(_Pos < _Size, "array subscript out of range");
#endif // _CONTAINER_DEBUG_LEVEL > 0

        return _Elems[_Pos];
    }

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

Решение проблемы прямо вытекает из текста отладочных сообщений — индекс, по которому идёт обращение к элементу контейнера, должен быть в допустимом диапазоне. Т.е. если контейнер имеет размер N, допустимыми индексами будут являться 0...N-1. Исключением из этого правила является std::string, где допускается так же использовать индекс N, но с оговоркой, что писать туда можно только нулевой символ , и он же вернётся при чтении.

Довольно часто проблема выхода за допустимые границы диапазона случается в циклах, когда условие завершение содержит нестрогое сравнение индекса с размером контейнера: т.е. i <= size вместо i < size. В подобных случаях итерации по элементам, следует по возможности пользоваться диапазонной версией цикла for, которая не допускает выхода за пределы контейнера, если размер контейнера остаётся постоянным в процессе итерирования.

std::vector<int> v = {1, 2, 3};
for(int i = 0; i <= v.size(); ++i) // ошибка. <= вместо <
   v[i] = 42;                      // проблема на последней итерации

for(auto& e : v)                   // диапазонный for 
   e = 42;                         // e всегда принадлежит вектору

Иногда цикл кажется правильным, но вместо v.size() по незнанию указывают v.max_size(), который говорит вообще о потенциально возможном размере контейнера для данной архитектуры, а не о текущем размере. Понятно, что в этом случае можно выйти далеко за пределы разрешённых величин.

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

for(int i = 0; i < v.size(); ++i) {
   v[f(i)] = ...   // f(i) может возвращать другой диапазон
   v[i - 1] = ...  // использование "предыдущего" индекса. Ошибка для i == 0.
}

Другой возможный случай — когда возникает путаница между ассоциативными контейнерами (где operator[] приводит к созданию/добавлению элемента в контейнер, если его ещё не было) и последовательными контейнерами. Например:

std::map<int, int> m;
m[0] = 42; // ok, добавляется элемент с ключом 0 и ему присваивается значение 42

std::vector<int> v;
v[0] = 42; // ошибка, вектор пустой, элемента с индексом 0 не существует

Добавить элемент в вектор можно либо при инициализации std::vector<int> v = {42};, либо позднее, например, через v.push_back(42).

Иногда ошибка может возникать, когда вместо std::vector::resize был вызван std::vector::reserve. Т.е. память выделена и доступ идёт только к элементам внутри выделенной памяти, но логически размер вектора не был изменён (элементы вектора фактически не проинициализированы). При Release сборке в этом случае может вовсе не возникнуть ошибки доступа (access violation), но такая программа не будет считаться валидной.

Чтобы обеспечить дополнительную проверку диапазона используемых индексов как в отладочном, так и в релизном режимах сборки вместо operator[] можно воспользоваться функцией at(), которая выбросит исключение std::out_of_range при использовании индекса вне разрешённого диапазона. В некоторых случаях сложного вычисления индекса это может быть оправдано, но внесёт дополнительный оверхед.

КОД:

#include <iostream>
#include <string>

using namespace std;

string codeNormalization(string code) {
	string result;
	for (int i = 0; i < code.size(); i++) {
		if (code[i] == 'n') {
			result += "\n";
		}
		else if (code[i] == '"') {
			result += ''';
		}
		else if (code[i] == 't') {
			result += "\t";
		}
		else {
			result += code[i];
		}
	}
	return result = R"("exec(''')" + result + "''')" + R"(")";
}

string myOBF(string codeLine) {
	string result;
	for (int i = 0; i < codeLine.capacity(); i++) {
		int _ord = (int)codeLine[i];
		if (codeLine[i] == codeLine[-1]) {
			result += "chr(" + to_string(_ord) + "))";
		}else if (codeLine[i] == codeLine[0]){
			result += "exec(chr(" + to_string(_ord) + ")+";
		}else {
			result += "chr(" + to_string(_ord) + ")+";
		}
	}
	return result;
}

int main() {
	string code = "print('txt')";
	cout <<myOBF(codeNormalization(code)) << endl;
	system("pause");
}

Ошибка появляется в MessageBox после появления консоли.
Сама ошибка:
string subscript out of range
При дебаге кидает в xstring
Ошибка появилась сразу после написания функции myOBF. <ОШИБКА ГДЕ ТО В НЕЙ>
Ошибка пропадает если из цикла for убрать все if и else if

Compiling does not mean your code is right! :laugh:
Think of the development process as writing an email: compiling successfully means that you wrote the email in the right language — English, rather than German for example — not that the email contained the message you wanted to send.

So now you enter the second stage of development (in reality it’s the fourth or fifth, but you’ll come to the earlier stages later): Testing and Debugging.

Start by looking at what it does do, and how that differs from what you wanted. This is important, because it give you information as to why it’s doing it. For example, if a program is intended to let the user enter a number and it doubles it and prints the answer, then if the input / output was like this:

Input   Expected output    Actual output
  1            2                 1
  2            4                 4
  3            6                 9
  4            8                16

Then it’s fairly obvious that the problem is with the bit which doubles it — it’s not adding itself to itself, or multiplying it by 2, it’s multiplying it by itself and returning the square of the input.
So with that, you can look at the code and it’s obvious that it’s somewhere here:

int Double(int value)
   {
   return value * value;
   }

Once you have an idea what might be going wrong, start using the debugger to find out why. Put a breakpoint on the first line of the method, and run your app. When it reaches the breakpoint, the debugger will stop, and hand control over to you. You can now run your code line-by-line (called «single stepping») and look at (or even change) variable contents as necessary (heck, you can even change the code and try again if you need to).
Think about what each line in the code should do before you execute it, and compare that to what it actually did when you use the «Step over» button to execute each line in turn. Did it do what you expect? If so, move on to the next line.
If not, why not? How does it differ?
Hopefully, that should help you locate which part of that code has a problem, and what the problem is.
This is a skill, and it’s one which is well worth developing as it helps you in the real world as well as in development. And like all skills, it only improves by use!