Vitaly

На самом деле вам не нужно ничего и никуда передавать, как мне кажется. Т.к. вторая форма используется только для создания новых элементов. Но обо всём по порядку. В приведённом фрагменте кода я вижу несколько архитектурных проблем (если не интересно, можете игнорироваться все, кроме пункта 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)... Голые указатели уже моветон.

Роберт Седжвик.

PS
Пользуйтесь гуглом и поиском по сайту. Вопрос уже 100500 раз задавали.

Гуглите что такое явная типизация. А если начали изучать C++, то возьмите книгу (синенькую и с лебедями) Страуструпа, и изучайте. Тогда подобные вопросы отпадут.

Скорость создания именно качественного кода (под этим я подразумеваю сопровождаемый код, который решает актуальную задачу) напрямую зависит от трёх вещей:
1) Понимание задачи
2) Знание предметной области
3) Владение существующей кодовой базой

Остальное (скорость набора, IDE, снипеты и т.д.) уже вопрос удобства. Всё это конечно здорово облегчает жизнь, но далеко не так важно.

В вашем случае больше подойдёт агрегация. И, в качестве совета: всегда старайтесь рассматривать агрегацию как альтернативу множественного наследования. Почитайте что-нибудь хорошее по ООП (найдите в сети, есть 100500 ответов на вопрос "что почитать по теме ...").

А каноны ООП -- это нечно мифическое. Есть базовый набор принципов и рекомендаций, а остальное -- опыт и знания. Никогда не будет так как в школе: вот это отлично и так надо делать, а вот это плохо и так делать не надо.

Если очень коротко:
Интерфейс следуют рассматривать как описание набора похожих по смыслу действий, которые можно произвести с экземпляром класса. Например мы можем постучать по всему, реализует интерфейс IKnockable, и в контексте использования данного интерфейса нам не важны остальные характеристики объекта. Постучать, допустим можно по дереву, а можно и по голове.
Понятие наследование от базового класса включает в себя наследование описательных и поведенческих характеристик. Допустим есть класс виджетов, которые умеют себя рисовать, реагировать на команды и прочее. Пусть от виджета наследуется класс MainWindow или класс Dialog. Эти классы умеют себя рисовать как и виджет, имеют свойства прозрачности (допустим) и прочие, однако содержат что-то новое элементы управления по умолчанию, предопределённые свойства модальности иное поведение и пр.
Конечно неплохо было бы учесть некоторые принципы SOLID, но вопрос не про это...

Уже где-то лет 12 провожу почти каждый день, включая выходные и исключая отпуск, за компьютером в среднем часов по 8-10, чаще больше. Причем, сначала это были компьютеры с выпуклыми мониторами и дополнительной защитой поверх монитора... Зрение до сих пор 100%. Ходил проверялся месяца 4 назад, сказали что всё ок.

Я считаю, что зрение в больше степени зависит от генетики. Я бы порекомендовал использовать хороший монитор. Мне, например нравятся мониторы Dell UltraSharp c IPS (уже можно и AH-IPS) и диагональю 27 дюймов. Да и вообще на здоровье влияет ещё и организация рабочего места. Одно дело работать в помещении с плохой освещённостью, неудобным столом и креслом, на компьютере с маленьким TN-монитором, плохим железом и неудобной клавиатурой... и совсем другое дело когда есть нормальные условия для работы. Конечно нормальные условия есть далеко не везде, но это другой вопрос.