tugo

Qt. Посмотрите на клиент Телеграм. Вроде неплохо, неправда ли?

В Qt имеется возможность управлять внешним видом при помощи CSS-подобного языка.

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

ООП рассчитано не на скорость исполнения, а на скорость разработки. Как, впрочем, и многие другие современные технологии разработки. Всё, что ООП делает, можно реализовать и без ООП, и даже эффективнее. Стоит ли — другой вопрос.

Какую задачу конкретно решает ООП? Обуздать сложность разработки программ, собранных из взаимодействующих компонентов. Вот от этого и пляшем: если программа не модульная (например, какой-нибудь сложный научный расчёт), ООП мало поможет. Также ООП не поможет, если стандартная реализация ООП недостаточно эффективна по процессору или по памяти — например, в мою бытность JavaMe’шником ООП не жаловали, поскольку памяти много ел, типичный мобильник имел от 215 до 800 килобайт доступной памяти. Также плохо будет работать там, где нет взаимодействия (на типичном PHP, который выдал страничку и исчез).

Что на PHP можно реализовать объектно?
• Поддержку каких-то протоколов (БД, почта, какая-нибудь внешняя веб-служба наподобие VK API или Mandrill).
• Что-нибудь из предметной отрасли, что меняет своё состояние — например, генерация картинок, звуков, архивов, PDF…
• Может, сделаешь какой-нибудь генератор страниц, который сначала собирает каркас страницы, а затем, в зависимости от настроек и целевого устройства, обращивает его HTML-кодом.

но меня смущает вызов 2 дополнительных функций в шаблоне

1. Функции заинлайнятся, за производительность тут переживать не стоит.
2. У вас немного разные алгоритмы. В шаблоне никто не запрещает вам пройтись циклом по итераторам и посчитать среднее тем же способом, что и в первом варианте.
3. Использование stl-функций предпочтительнее своего велосипеда. Читать код легче. Я увидел accumulate и сразу подумал о свёртке. А в первый пример пришлось вчитываться. К тому же он ещё и не оптимальный - ведь деление можно вынести из цикла.
4. Данный вариант с шаблоном намного гибче - его можно использовать с любым контейнером, который реализует итератор.

Дело было в переходнике. Вот он.

А вот с таким - никаких проблем.

Честное слово, про OpenFrameworks сейчас впервые услышал. А Qt проверенное годами решение. И с лицензией Qt в вашем случае проблем нет - используйте LGPL.

Начинать с Python c книги Лутц или Доусон к тому же питон поддерживает

несколько парадигм программирования, в том числе структурное, объектно-ориентированное, функциональное, императивное и аспектно-ориентированное. Основные архитектурные черты — динамическая типизация, автоматическое управление памятью, полная интроспекция, механизм обработки исключений, поддержка многопоточных вычислений и удобные высокоуровневые структуры данных. Код в Python организовывается в функции и классы, которые могут объединяться в модули (они в свою очередь могут быть объединены в пакеты Википедия

насколько я слышал, он распространен больше всех.

а это к PHP