Boost - это набор взаимосвязанных библиотек. Так что на твой вопрос можно ответить и да и нет. В зависимости от задачи.

Ну почитай ты книжки. Распределение памяти - это не тот момент который удобно объяснять на форуме на пальцах.
У того же Страуструпа описано и у Саттера вроде...

Я бы, в подобном случае вообще свой механизм сделал - единый блоковый контейнер для PARAMVALUE и boost::range в LOGRECORD.

Код использования был бы примерно такой:

struct LOGRECORD {
  std::pair<PARAMVALUE*, PARAMVALUE*> params;    ///< массив параметров
  ...
};

struct LogReader {
  ...
  bool tRead();
  bool parseBlock(LOGRECORD& t);
  private:
    ParamValueChihkContainer<PARAMVALUE> params;
};

bool LogReader::tRead() {
  ...
  while(_file -> read((char*)&var, sizeof(var)) > 0) {
    ...
    case 0001:
      log.append(LOGRECORD(rec_descr.size()));
      parseBlock(log.last());
...
  return file_read;
}

/// Разбор одной записи
bool LogReader::parseBlock(LOGRECORD& t) {
  ...
  t.params = params.constrict(rec_descr.size())
  ...
                    t.params[i] = (*jter) -> GetValue(var);
                    t.params[i].evn = 0;
  ...
  return true;
}

tymplate <T>
struct ParamValueChihkContainer {
  std::pair<T*, T*> constrict(size_t n);
  ...
};

Где ParamValueChihkContainer::constrict отдаёт std::pair<T*, T*> на в текущем распределённом блоке, если там есть место, или распределяет новый блок, если места нет.
Опять же, для его реализации я бы воспользовался boost::pool.

Может всё же так:

...
    struct Chunk
    {
        Chunk* next;
        char memory[chunk_size * sizeof(T)];
    };
...

Тогда размер Chunk::memory будет всегда кратен количеству элементов - не будут пропадать попусту невлезшие кусочки.
Ну и размер chunk_size я бы поставил как среднее rec_descr.size() * 100, например.

Да, ты ведь профилируешь релизную сборку, я надеюсь?

Ты выделяешь столько памяти, сколько просит клиент (std::vector). Ровно это же и делает стандартный аллокатор. Т.е. ты ничего не выигрываешь.
Для того, чтобы получить эффект, нужно изменить стратегии выделения - например выделять память сразу большими блоками, а потом раздавать на них место.
Попробуй таки зацепить аллокатор из буста - хоть посмотришь к чему надо стремиться.

Да, можно ещё такой финт провернуть:
При разборе блока параметры загоняешь в список - std::list с быстрым аллокатором.
Когда блок разобран, создаёшь массив std::vector или обычный массив с уже известным размером и копируешь туда данные.
Если все блоки не очень большого размера, то можно выделить для аллокатора списка сразу память под самый большой блок и переразмещений в нём не будет.
И массивы будут размещаться всего один раз.
Стало быть получим количество выделений памяти в идеале: кол-во блоков + 1.
А переразмещений не будет вовсе - что сильно снизает нагрузку на всю подсистему памяти.

Ничего писать не нужно.
Смотри здесь, в самом конеце страницы.

Т.е. у тебя много маленьких векторочков.
В stl у std::vector есть параметр шаблона, который позволяет указать свой менеджер памяти для этого вектора - это именно то, что тебе нужно.
В Qt, QVector не имеет подобного механизма, и сделать тут ничего нельзя.

Выходов может быть несколько:
* Перейти на std::vector и свой аллокатор вместо QVector.
* Запихивать всё в единый QVector, а в LOGRECORD хранить индекс массиве и количество элементов.
* Если все блоки одинаковы по составу (или есть небольшое количество разных составов) то может проще выделить отдельную структуру для этих данных вместо векторов, и включить в состав LOGRECORD (в случае нескольких типов хранить указатель).

Вышел долгожданный новый релиз мингвы.
Качаем.

А чем через датастрёмы плохо?

template <class T>
void setValue(QSettings& settings, const QString& key, const QList<T>& list) {
  QByteArray ba;
  QDataStream out(&ba, QIODevice::WriteOnly);
  out<<ba;
  settings.setValue(key, ba)
}

Пусть, для простаты, всё же будет 2 поля: key и value

insert into B (key, value)
select A.key, A.value from A left join B on A.key = B.key
where B.key is NULL

Вроде SQLite должна поддерживать.

Я бы сначала рассчитывал множество непрерывных ломанных (QVector<QPoligonF>), а потом отрисовывал их скопом.
Ни или собрал бы их всех в QPath и отрисовал его.
Но тут нужно смотреть и тестить, что будет быстрее. Думаю простой цикл, т.к. QPath - довольно сложная штуковина.

Насчёт "сбоя отрисовки" - это твоя личная ошибка, как мне кажется.

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

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

С трёхзвенкой по моему заморачиватся не нужно - только сложность увеличите.

ODF тут уже показали.
RTF - текстовый формат очень похожий на TeX. Есть спецификация от MS, но Word её нарушает при сохранении таких документов.
DOC - бинарный формат документов MS Word. Базируется на технологии OLE Storage. Раньше была доступна для старых версий. Теперь вроде бы доступна полностью. Насколько она полная я не в курсе.

А ежели можно обойтись только данными - используй CSV.
Его нормально читают и ёксель и OOo.

Да, вроде в 4.5 обещали поддержку ODF - можно будет напрямую генерить документы и таблицы для ООо.

Это от дебагера зависит - в любом свои команды есть.

Это значит некоторый свой, по возможности, независимый от Qt набор классов и контейнеров для нужных тебе данных и преобразований над ними.
Делается GUI, который всё это добро отображает.
Далее, делается связь этого добра с базой и/или непосредственно с прибором, чтобы можно было загружать данные.

Т.е. ты в GUI ничего не знаешь о том откуда пришли эти данные и знать не хочешь.
А при работе с базой тебе поровну что, как и где там будет отображаться.
Т.е замена базы или её структуры не затронет GUI.
Кроме того, можно вместо гуя делать какие-то другие штуки - например какой-нибудь анализ и кластеризацию без учёта того как устроена база и есть ли она вообще.

П.С. Кстати, этот слой и называют "слоем прикладной логики" или "бизнес логики".

Для точечных объектов (или объектов видимых на данном масштабе как точечные, нужно проверять не совпадение координат объекта и указателя, а попадение объекта в курсорную область.
Курсорная область - обычно квадрат вокруг указателя, размером в 2-4 пиксела (лучше дать возможность настроить).

Есть книжка: "Unix: Взаимодействие процессов" Уильям Стивенс.
Хотя там собственно про потоки ничего нет, но про синхронизацию разобрано очень подробно.
Т.к. в Qt примитивы синхронизации больше похожи на POSIX чем на WinApi, то книжка вполне полезная.

std::numeric_limits<int>::max()

Пойдёть?

При работе с консолью Qt не помощник. В нём нет никаких специальных механизмов для этого.
Смотри разные *curses или TurboVision.

out и err - это разные файлы, каждый со своей стратегией буферизации.
В stderr буферизация по умолчанию отключена, в stdout нет.
Отсюда и странный эффект.

Тут не в асинхронности дело.
Дело в том, что in и out - это разные файла, со своими буферами.
Т.е. при выводе сначала идёт накопление буфера, и только когда он заполнен его единым блоком выкидывают в устройство.
Для ввода примерно так же, только наоборот: из устройство читают блок данных в буфер, а потом программа выбирает уже из буфера. Как только она прочла всё, процесс повторяется.

Иногда это не то, что ожидается, тогда можно поступать несколькими способами:
1. После вывода сбрасывать буфера принудительно (ключевое слово flush)
2. При создании объекта файла указать что буфера использовать не нужно
3. Для С++ потоков, есть механизм "связывания" файлов (ключевое слово tie). Если с потоком ввода связан поток вывода, буфер потока вывода сбрасывается перед каждой операцией ввода.
Для С файлов тоже что-то подобное вроде есть. Для Qt - не в курсе.

Да вроде бы всё просто: ставишь фильтр на QApplication и ловишь события QEvent::Enter и QEvent::Leave.
Пока виджет, для которого был QEvent::Enter но ещё не было QEvent::Leave - под мышей.

Ну, или в интересующие моменты просто зовёшь QApplication::widgetAt.

П.С. Имей в виду, QEvent::Enter и QEvent::Leave могут приходить в "странном" порядке. По крайней мере я с таким сталкивался в аналоге на WinApi

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

Здесь смотри: http://python.promsoft.ru/index.php?action=resourses