Анекдот с юмором на тему физики:
Две вороны летели со скоростью, много меньшей скорости звука:
- стена!
- вижу...
...шмяк-шмяк!
Две вороны летели со скоростью, близкой к скорости звука:
- стена! - шмяк!
- вижу... - шмяк!
Две вороны летели с гиперзвуковой скоростью:
шмяк-шмяк!
- стена!
- вижу.

Для обращения к item'у по его индексу:

Наоборот, для определения индекса item'а верхнего уровня (index):

Удобным может оказаться и такой вызов (возврат указателя выделенного элемента QTreeWidget):

Для случая большого числа корневых элементов это более удобно.
Была необходимость создания достаточно разветвленного QTreeWidget, с каждым корневым элементом которого сопоставляется проект расчета, производимого программой и структура дочерних элементов элемента проекта строго типизированная. Для реализации такого дерева использовался потомок QTreeWidget из элементов TreeElement (потомок QTreeWidgetItem с указанием типа элемента ч/з enum). В дереве для индексации по корневым элементам использован QMap<int, TreeElement>. Разумеется, данные проекта расчета хранятся в других объектах (различных типов), хранящихся в контейнерах, причем каждый объект данных хранит указатель на соответствующий элемент TreeElement в дереве. Всего же всех элементов дерева, как правило, не более 80 (определяется числом открытых в программе проектов расчета).

- это в принципе возможно, только надо знать "в лицо" конкретные либы от linux-ядра андроида и конкретные функции, которые необходимо вызывать; к тому же, необходимо будет скомпилировать (кросскомпилятивно под железо андроид) либу или либы, которые будут оберткой конкретных функций в JNI-интерфейсы - а) эти либы-обертки можно грузить через статический явовский метод System.loadLibrary(...), б) нужно объявить все необходимые "оберточные" методы статическими в Java-классе, из которого они будут вызываться. Кроме того, есть заморочки с составлением имён "оберточных" методов, хотя их можно и обойти. Тут можно посоветовать почитать книгу Сильвена Ретабоуила про Android NDK.
- повторюсь, что функции доступа работают через механизм JNI и вызываются из кода Java, как интерфейсы, привязанные к реальным функциям C/C++-либ. Поэтому у меня, если я правильно понял вопрос, сделано как раз наоборот: на Qt написана "оберточная часть", а в Java - GUI андроид приложения. Получится ли у вас задуманное - не знаю, скорее, сомневаюсь.

Не спорю, рулят. Necessitas сам по себе, правда, поддерживает версию Qt максимум 4.5 (если верно помню),  свой QtCreator и "свой" Android NDK (тоже старые) - проект не развивается. Сейчас хорошая связка есть для Андроида с Qt5.
В моем случае было интересно адаптировать Qt 4.8.6 под ARMv7-a (на устройствах под управлением ОС Android) в связке с современным Android SDK/NDK, чтоб кросс-компилить компоненты (библиотечные файлы) с динамической линковкой, из которых происходят вызовы C++-функций посредством механизма JNI в обычном классе Activity, т.е. БЕЗ использования всяких там NativeActivity, без Ministro и прочих фишек (эти вещи для моей задачи были неудобны). При этом linux-либы под ARM компилились в обычном QtCreator с настроенным профилем компиляции для ARM, а Java-код GUI приложения на Андроид - в Android Studio 2.0

В прилагаемом PDF-файле описаны действия, произведенные над некоторыми файлами исходников Qt 4.8.6 с целью успешной кросскомпилятивной сборки некоторых библиотек фреймворка (модули Core, Network, Sql) для архитектуры ARMv7-a.
Выбор отдельных модулей из фреймворка Qt4 обусловлен необходимостью решения конкретной задачи:
создание приложения Android/ARM для работы с удаленной БД под управлением MySQL через протокол интернета.
Надеюсь, кому-то будет полезно.

Спасибо вам за конструктивную критику. Ошибки исправил. Сейчас корни выдает верные (с точностью до 0.00005, имеется в виду максимально допустимое отклонение от нуля значения многочлена ax^3 + bx^2 + cx + d после подстановки корней, иначе программа выдает сообщение о критической ошибке). Насчет того, что частные случаи - квадратные и линейные уравнения не решает - это да, только изначально было задумано, чтоб решались уравнения вида ax^3 + bx^2 + cx + d = 0 только при ненулевом коэффициенте "a".

Исправленный проект здесь (ссылка в первом сообщении также исправлена)

Создан класс CubicEquationCardano (обычный класс C++, но с применением объектов из библиотеки Qt, таких как объекты класса QVector, а также всё GUI - Qt-шное), реализующий решение кубического уравнения методом Кардано (вычисляются только действительные корни).
Уравнение общего вида ax^3 + bx^2 + cx + d = 0 реализовано так:
   koeff_A*x^3 + koeff_B*x^2 + koeff_C*x + koeff_D = 0.        (1)
При этом по умолчанию koeff_A = 1, т.е. решается уравнение вида
   x^3 + koeff_B*x^2 + koeff_C*x + koeff_D = 0.                    (2)
В алгоритме класса вид (1) приводится к канонической форме
   y^3 + koeff_p*y + koeff_q = 0                                           (3)
с помощью замены переменных:
   y = x + koeff_A / (3.0*koeff_B)     => x = y - koeff_A / (3.0*koeff_B)
   p = (3.0*koeff_A*koeff_C - koeff_B^2) / (3.0*koeff_A^2)
   q = (2.0*koeff_B^3 - 9.0*koeff_A*koeff_B*koeff_C + 27.0*koeff_A^2*koeff_D) / (27.0*koeff_A^3)

В Википедии приводится алгоритм решениям данным методом не полностью. За восстановление всего алгоритма решения методом Кардано - отдельное спасибо математику Роману Скоробогатову  

Проект Qt с исходниками лежит тут (ссылка исправлена 21.04.2015)

Спасибо вам, vps! Сработало.

Нашел обходной путь, хоть и не считаю это решение вполне приемлимым, но для данного конкретного случая оно работает... по крайней мере, выводится всё так, как нужно мне сейчас - без номера страницы. Просто для объекта QPrinter отступ на странице снизу был задан настолько малым, чтоб номер страницы вообще не умещался на ней:


Но это вовсе не ответ на поставленный вопрос...

При печати QTextDocument (void QTextDocument::print ( QPrinter *printer ) const) на принтере в правом нижнем углу по умолчанию ставится номер страницы. Есть ли возможность убрать этот номер или настроить его значение?