Здравствуйте, binnom, Вы писали:

B>1) что именно пишется в стэк трэда,
Кадр. Любая функция имеет состояние, даже если не заводит переменных на стеке- точку возврата никто не отменял. Впрочем, оптимизирующий компилятор может и развернуть рекурсию.

B>2) почему ты решил использовать именно стэк трэда для определения парности скобок (хинт: recursive approach vs non-recursive)
Я лишь указал, что оба варианта- хранение скобок в стеке потока исполнения и хранение в динамической памяти в структуре "stack"- тупые. Во втором варианте методом лома, т.е. расхода памяти, можно отложить переполнение.

B>и критикал хит:

B>3) можно ли создать свой класс стэка или обязательно использовать именно стэк трэда?
Зачем создавать свой класс? Лучше озаботиться оптимальным алгоритмом подсчёта скобок. Кстати, здесь в топике кроме раздувания щёк никто так и не предложил вменяемый алгоритм. Михаил предложил решение с выгрузкой на диск- не самое оптимальное, но решающее задачу.

UPD:
1) Нарезать блоки фиксированного размера, например 8Mb.
2) Скажем у нас 4 вида скобок. На каждую открывающую скобку записываем 2 бита в текущий блок- смещение в байтах и битах легко вычислить по счётчику. В случае 3 битов чуть сложней формула, но смысл понятен.
3) При заполнении блока, он отдаётся в хранилище блоков. Хранилище блоков все кроме верхнего блока упаковывает deflate-м- так боремся с "паттернами" вроде "({([({([", не изобретаем велосипеды с RLE. Можно с отдельным потоком и блоком синхронизации
4) Хранилище блоков при суммарном размере сжатых блоков больше установленного размера, скажем 128m, сливает сжатые блоки порциями в зависимоси от требований к латентности, или разом в временный файл. При необходимости подгружает поблочно и распаковывает.