mayton2019

Без теории тут никак.
Тут 2 варианта: или стройте конечный недетерменированный автомат (с эпсилон переходами), который соответствует этому регулярному выражению и дальше применяйте стандартный алгоритм проверки. что автомат принимает заданную строку. Или второй вариант: пишите динамическое программирование "соответствует ли вот этот префикс заданной строки вот этому префиксу регулярного выражения".

Конечный автомат будет и побыстрее работать и памяти меньше требовать.

upd: ну и, конечно, тут полным перебором рекурсивно можно сделать. Но это будет гораздо медленнее любого из указанных выше методов.

Как вариант, DNS подменить, гуглится такое:
import os
os.system('netsh interface ip set dns "Local Area Connection" static 192.168.0.200')

Токен в параметрах передавай. И включите уже наконец голову, питоноботописатели хреновы

Подробнее можно почитать в книге CLR via C#.

Но если коротко, то все строковые литералы компилятор помещает в отдельную область памяти и заменяет все ссылки на них.

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

Надо отдельно обработать случай y == y1

Что-то много у тебя лишнего в коде

#include <iostream>

using namespace std;

int main() {
    int a = 0, b = 0, c = 0;
    cin >> a >> b;
    int A[a*b]; // not all compilers support this you have to make sure or use new/unique_ptr
    for (int i = 0; i < a*b; ++i) {
        cin >> A[i];
    }

    for (int i = 0; i < a*b / 2; ++i) {
        std::swap(A[i], A[a*b - 1 - i]);
    }

    for (int i = 0; i < a*b; ++i) {
        if ((i) % b == 0)
            std::cout << std::endl;
        std::cout << A[i] << " ";
    }
}

ссылка на поиграться
https://godbolt.org/z/xqf6MYaMK

Словарь и ассоциативный массив - это синонимы. Хеш-таблица - это вариант реализации словарей.

В случае маков можно хранить в keychain.
https://developer.apple.com/documentation/security...

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

В случае винды - можно использовать DPAPI
https://learn.microsoft.com/en-us/previous-version...

Во всех случаях можно хранить не сами токены, а ключи для расшифровки, а сами токены держать зашифрованными в файлах

UPD: на винде есть ещё https://learn.microsoft.com/ru-ru/windows/uwp/secu...
А на линуксе есть libsecret

UPD2: есть готовый Крейт, который это всё многообразие обобщает: keyring

В общем, разобрались.
Когда размер блоба превышает определенный порог, он переносится на overflow pages. Это отдельная страница или несколько. Больше одного блоба на странице переполнения быть не может. А вот на странице данных (в записях) могут быть много блобов.

Вот тут, в разделе 1.6 описаны пороги, при превышения которых блоб переносится на страницы переполнения: https://www.sqlite.org/fileformat.html

Вот главная формула:

X is U-35 for table btree leaf pages or ((U-12)*64/255)-23 for index pages.

Тут U - это размер страницы. Размер страницы у меня 4096, получается, порог переноса будет 4096 - 12 = 4084 для листовой страницы и ((4096-12)*64/255)-23 = 1002 для страницы указателей. Это полный размер записи. За вычетом размера блоба остальная часть записи - 5 байт (подглядел в дампе страницы базы). Значит, пороги переноса блоба будут 4079 и 997.

Провел эксперименты с разным размером блоба. База с WITHOUT ROWID перестает пухнуть при размере блоба 996 байт. А 997 - уже проблема. Вывод: в таблицах с WITHOUT ROWID применяется порог для блобов, который предназначен для страницы индекса.

Вообще, ничто не мешает хранить блобы большего размера на страницах таблиц с WITHOUT ROWID. Вполне возможно, что это ошибка, которую позже поправят. Но пока в sql lite в таблицах с WITHOUT ROWID блобы лучше не хранить.

UPD:
Спросил у на форуме sql lite, ответили разработчики: https://www.sqlite.org/forum/forumpost/ad86fbaa04
Как справедливо поправили - блобы тут не причем, имеет значение общий размер записи (payload). Ответили, что таблицы WITHOUT ROWID сделаны как покрывающие индексы, и унаследовали соответствующие ограничения. В общем, на мой взгляд, не стоит их использовать, если может произойти spliting. Для этого общий размер записи не должен приближаться к 1/4 размера страницы.

Можно пройтись поиском в глубину (DFS) до последнего узла и дальше двигаясь в обратном направлении выполнить вычисления.
1. вначале мы находим самую нижнюю ноду, а она точно цифра (в противном случае смысла нет)
2. делаем шаг назад и выполняем вычисление
3. редактируем имеющуюся структуру "укорачивая" дерево (то есть вместо знака действия у нас теперь цифра)
4. делаем так пока не получим дерево состоящее только из корня, которое и будет решением.

Попробовал написать решение твоей задачки, код по ссылке
https://godbolt.org/z/PzWjYjvfz

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