Приветствую все читающих.

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

Предварительный ответ: ДА, это возможно — возможно создать механизм, позволяющий решить задачу dynamic_cast на этапе компиляции, но — едва ли подобное будет применяться на практике по причинам как: (1) с самого начала целевой проект должен строиться согласно наперёд заданным правилам, в следствии чего взять и применить методику к существующему проекту, очень трудоёмко (2) существенное повышение сложности кода с точки зрения удобства его читаемости в определённых местах, где, собственно, происходит замена логики dynamic_cast на предложенную ниже (3) использование шаблонов, что может быть неприемлемым в некоторых проектах по идеологическим соображениям ответственных за него (4) интерес автора исключительно в том, чтобы дать ответ на поставленный вопрос, а не в том, чтобы создать универсальный и удобный механизм решения поставленной задачи (в конце-концов, не нужно на практике решать проблемы, которые не являются насущными).

Приветствую всех читающих :)

Целевой хаб не соответствует содержанию статьи, но что поделать… — тематических по цели нет, а наиболее подходящий «С», т.к. читатели именно его с наибольшей лёгкостью смогут воспринять написанное.

Цель статьи

Вариант решение проблемы контроля за глобальными переменными при написании инсталлятора/деинсталлятора средствами NSIS.