Vitaly

У вас не такие уж и большие числа. Поищите тут нужный тип: en.cppreference.com/w/cpp/language/types
Если не подходит, то библиотеки вроде gmp.

На самом деле вам не нужно ничего и никуда передавать, как мне кажется. Т.к. вторая форма используется только для создания новых элементов. Но обо всём по порядку. В приведённом фрагменте кода я вижу несколько архитектурных проблем (если не интересно, можете игнорироваться все, кроме пункта 3):
1) Вторая форма создаётся каждый раз, когда пользователь кликает на кнопку add_item. Это утечка памяти, т.к. все формы будут удалены только после удаления главного окна, но не ранее. Почему бы не создать форму один раз и просто её не показывать на действие? Создали в классе поле QScopedPointer m_addItemDlg (ну или std::unique_ptr), один раз выделили память в конструкторе и радуетесь жизни.
2) Это не очень хорошо, что Institution хранится в контейнере QList по значению т.к., скорее всего вы не реализовали семантику перемещения и всё это копируется... Хотя бы по этой причине (и по многим другим) стоит подумать о том, чтобы хранить все элементы как shared_ptr.
3) Наконец-то мы добрались и до вашего вопроса! В Qt есть отличный механизм слотов и сигналов. В вашем случае идея проста: у главной формы надо реализовать слот onInstitutionAdded а у второй формы дописать сигнал institutionAdded и соединить их в конструкторе главной формы. Когда новый объект создан выслать сигнал из второй формы и в слоте главного окна реализовать добавление в коллецию.
Если же нужно будет редактировать какой-то итем в коллекции, то его конечно лучше передать просто по ссылке перед тем как показать форму. Ну и в этом случае посмотреть уже в сторону Qt model-view.
4) Название класса второй формы слишком общее и ни о чем не говорит.

Для сереализации в Qt есть специальный класс QDataStream. У классов которые вы хотите сереализовать нужно реализовать два оператора (для чтения и для записи):

QDataStream &operator<< (QDataStream &out, const T &obj);
QDataStream &operator>> (QDataStream &in, T &obj);

QFile f("path");
if (f.open(QIODevice::ReadOnly) { // or WriteOnly, or ReadWrite
   QDataStream s(&f);
   T obj;
   s >> obj; // for write s << obj
}

Но у вас в коллециях указатели, т.ч. сереализоваться будут адреса, а не сами объекты. Эту проблему нужно как-то решить, т.е. если у вас QList<Institution> lst, то можно просто написатьs << lstдля сереализации, а если указатель, то нет, возможно написать соотвествующий оператор для указателя -- это решение.

А еще возможно стоит присмотреться к JSON (с пятой версии поддержка входит в стандартную библиотеку Qt) если нужно именно сохранять в файлы, потом читать и иметь возможность поправить руками.

PS код писал просто по памяти, поэтому может не скомпилироваться :) Но примерно дела обстоят так.
PPS и лучше используйте какие-нибудь умные указатели вроде QSharedPointer, boost::shared_ptr или std::shared_ptr (с C++11)... Голые указатели уже моветон.

Это зависит от того, какие конкретно приложения вам нужно писать. Если это что-то под сенсорный дисплей, то выбор однозначен (QML), если под десктоп и это еще одна бухгалтерская программа, т.е. нет много 3D, работы с QGraphicsScene или OpenGL, то использовать QML будет приятнее чем классические виджеты -- писать проще и быстрее, но пока не освоитесь будете плеваться и хотеть бросить :)
А так-то посмотрите, например на hh.ru процент вакансий где требуется Qt и именно QML, думаю, что стандартные виджеты еще долго жить будут.

Выше всё верно написали, но перед тем как просто следовать рекомендациям, хорошо бы ответить на вопрос: "зачем?". Все дело в основном (хотя бывают и другие случаи) в скорости компиляции программы. Поменяли что-то в заголовочнике, который включен в 100500 других заголовочников и ушли отдыхать на 15 минут, пока всё это компилится в 8 потоков :) Неприятно в общем. Т.е. золотое правило: чем меньше включено в заголовочник, тем лучше. Правда, в 17ом стандарте будут модули и эта проблема решится (ну всё равно тонны легаси никто сразу вот так прям не портирует, так что еще лет 5-10 эти знания будут актуальны).
Помимо этого, для увеличения скорости компиляции можно использовать pimpl (но осторожно, это не основное предназначение этой техники!) и программы вроде ccache (как, вы всё еще не на линуксе?).

https://ru.wikipedia.org/wiki/%D0%9A%D1%83%D0%B1%D...

Раздел "методы решения".

Ответ на этот вопрос не так однозначен. Существуют стандарты оформления кода, согласно которым должен быть отформотирован весь исходный код. Это актуально и для коммерческих компаний и для открытых проектов. Поэтому "хорошо" или "плохо" сказать нельзя, нужно говорить "соотвествует стандарту или нет". Можете для своих личных проектов выбрать какой-нибудь стандарт кодирования и следовать ему. Вот пример стандарта: https://wiki.qt.io/Coding_Conventions . Помимо этого существуют программы, которые позволяют отформатировать весь код согласно набору правил (astyle, clang-format, uncrustify etc.). Использовать их далеко не всегда удобно, так как зачастую форматирование может быть не стандартным чтобы повысить читабельность кода, но в общем случае нормально.

Что касается вашего примера, я предпочитаю не ставить лишние скобки для тела if в одну инструкцию:

// OK
if (a > 3)
    ++a;

Но никогда не пишите эту инструкцию на той же строке -- не удобно отлаживать (может быть в какой-то IDE и удобно, но обычно каждый разработчик пользуется своей любимой...):

if (a > 3) ++a; // Как поставить бряку на "++a"?

Что касается циклов, то с for лучше всегда ставить скобки, т.к. некоторые IDE в режиме отладки вроде VS2008 (а возможно и более старших версий) не умеют заходить в тело однострочного цикла без скобок.

Да, это баг в CLion, т.к. эта IDE еще сырая и пользоваться ей нормально можно будет через пару-тройку лет, судя по тому что за год они этот баг так и не поправили.
Под Linux советую использовать QtCreator.