Алексей Обухов

Question

C++
+3 ещё

Простой

Как собрать и сконфигурировать дистрибутив из кучи разрозненных файлов?

3 подписчика
более трёх лет назад
161 просмотр

0

ответов

Answer 1 · 2016-02-22 11:35:45

Для постоянного цикла вам лучше реализовать слот, который будет постоянно вызываться в конце самого себя:

test.h:

private slots:
   void workMethod();

test.cpp:

void Class:workMethod()
{
     ....
    QMetaObject::invokeMethod(this, "workMethod", Qt::QueuedConnection);
}

Тогда ваш метод будет выполнять каждую итерацию под управлением очереди сообщений и в любой момент вы можете остановить поток.

Answer 2 · 2013-06-11 10:19:01

Поскольку на библиотеки деньги в нашей конторе выбить нереально, то реализовывал свой велосипед с шифрованием посредством vfs.
Использовал постраничное RCA шифрование. Ключ генерил на лету на основании кодовой фразы.
Внутри vfs шифрование осуществляется всех страниц, кроме первой. Т.к. к ней движок sqlite обращается очень часто для блокировки/разблокировки файла базы.
Потом уже дописывал исключение для журнальных файлов, мне их шифровать незачем.

Если руки не кривые — работы 2 дня + тесты автоматизировать под вашу задачу.
У меня БД не нагруженная и общая производительность приложения упала в пределах погрешностей измерения.

З.Ы. И еще — для детектирования что БД зашифрована на первой странице файла БД вставляю метку в неиспользуемую часть заголовка базы.

Answer 3 · 2018-05-07 10:33:13

Меня тоже интересует данный вопрос. Рассматривал кучу вариантов, но по итогам не сказал бы что за вменяемые деньги можно что-то найти.

* Проект MegaD от ab-log.ru. Правда не сказал бы что интерфейс у этого контроллера дружественный. Цены приемлимые.
* Wiren Board - Удобно, красиво, молодежно. Но цены зашкаливают.

Answer 4 · 2013-06-11 10:33:48

С помощью функции вы сможете зашифровать только отдельные поля в БД.
Причём придется эту функцию вставлять во все запросы, использующие шифрованные поля. Не очень удобно.

Правда с шифрованием всей БД есть свои минусы:
— накладные расходы на шифрование всякой служебной информации (можно было бы и не делать)
— в случае повреждения БД всю базу можно выкинуть.

Но в моём случае эти минусы не существенны.