По-моему это хороший feature request для Qt

Ну если Вы уже так много знаете - так это еще лучше    Если (как я понял) Вы хотите представить число/значение более короткой комбинацией бит - то от QBitArray Вам не помощи никакой потому что он умеет работать только с 1 битом (как boolean).

Ах как хочется выдать "Учи матчасть !"  Но не буду - непродуктивно. Операции new/delete могут быть перекрыты, если не ошибаюсь, с 1993 года. Легко проверить например так

Поставьте breakpoint на malloc и Вы увидите в отладчике что управление приходит "из недр Qt"

Не вдаваясь в детали: на сегодняшний день такая задача/подход лишен смысла даже в 32-bits (не говоря уже о 64). Я делаю так:

- отслеживаю сам сколько памяти распределено мною (свой менеджер кучи)
- в преференсах позволяю пользователю задать количество используемой памяти. По умолчанию - 80% физической памяти
- если предел превышен - swap на диск, если нет такой возможности - fatal error и выход

Все это обходится весьма недешево. Поэтому если нет абсолютной необходимости - разумно ограничиться простой проверкой не вернет ли new NULL (обычно с испусканием exception). Сделать "быстренько" (используя готовый инструмент) здесь не получится.

Прав, структуру/класс. Управлять из ф-ции намного труднее, будет плодиться много if'ов и.т.п

Да бывает у девушки муж помирает - а у вдовы живет 

Минимальная единица информации - байт, меньше нет. Др. дело что внутри байта Вы можете крутить битами как хотите, паковать и.т.п. Отталкивайтесь от этого, должно полегчать. Операции << и >> никакого отношения к битам не имеют, это просто перекрытые операторы I/O

QList имеет очень мало общего std::list  QList это просто массив указателей, поэтому доступ к элементу столь же быстр как и для QVector + одно разыменование. А в общем Qt молодцы - хороший контейнер сделали QList, там бы еще небольшие буги-вуги почистить - будем надеяться в 4.7

Memory Mapped File - это своя песня и к битовой паковке прямого отношения не имеет. А вот когда надо наладить обмен данными между 2-мя процессами - без Memory Mapped не обойтись.

Программист должен быть ленивым и никогда не делать 2 варианта 

Я это нигде не читал, просто наблюдаю как контейнеры работают. Например операции вставки/удаления. В контейнере 10 элементов. Вставляем на 5-е место. QVector вызовет 5 конструкторов копирования (для всего хвоста) так же как и std::vector. A QList спокойно переставит указатели на объекты - и готово. Пусть QList чуть больше тратит на элемент (+ sizeof(void *)) - это компенсируется удобством работы. В доке правильно написано что надо использовать QList  если ничего особенного не имеется ввиду 

"Массив иассивов" никак не связан с множественным наследованием. QVector лучше использовать для простейших структур. Если же планируете держать в массиве что-то "выше травы" (хотя бы имеющее конструктор/деструктор) лучше использовать QList (пусть он потребляет чуть больше памяти)

Ну это уж Вы сами смотрите по обстановке. "Паковка" дает хорошую экономию по памяти и незначительное увеличение вычислений. Другое дело с ней заботы - стандартный контейнер не попользовать, адрес от этого "3-битового чудика" не получить, надо работать по индексу и.т.п. Все это не смертельно и пережить можно, но, как правило, имеет смысл только если "есть что паковать".

Можно повторить то же через postEvent (прикрепив данные к event), но думается с тем же результатом. Если у Вас есть show - значит есть и hide и надо смотреть его, возможно не сбивается show/hide

На Mac платформе: KillProcess() (с большой буквы, нативная ф-ция)- "цивилизованный" путь, процессу посылается событие quit. Если не понимает - через SIGKILL сигнал. Так делает Qt (terminateProcess/killProcess).

Хотя не пойму откуда такое желание мочить всех направо и налево?  

До кучи: 5 бит на значение встречается не так уж редко (напр. некоторые форматы QuickTime). Реализация скромная, на базе unsigned short (используются 15 бит из 16)

Не сталкивался, но по смыслу сигналы из paintEvent (если уж без них никак нельзя обойтись) должны помещаться в очередь (т.е. connect должен создаваться с QueuedConnection)