Сегодня использование англиканизмов в профессиональной среде трактуется как признак низкой квалификации. Квалифицированный специалист способен объясняться исключительно терминами родного языка.
Индирект - косвенность. Statement'ы - выражения.
Когда человек сыпет тяжелыми на слух англиканизмами, его становится тяжело понять. Это заставляет слушателя напрягаться и нервничать. А это уже ведет к обострению общения и может быть воспринято как неуважение.
По поводу стиля кода. Оформление, откровенно говоря, рваное. Это точно так же заставляет задумываться, вчитываться и искать. Думаю, поэтому у тебя пока еще нет ответов. Лично мне потребовалось 4 раза перечитать код чтобы увидеть в нем инициализатор. Первые три раза я видел просто неправильный синтаксис. В широкой практике инициализатор оформляется примерно схожим образом: блоком по строкам. Посмотри пример.
Example(): и до тела конструктора - вообще псевдо код, предположительный синтаксис, который бы подошёл. Наверное, нужно было это указать
floppa322 , шаблон класса - это, прежде всего, шаблон типа. Это еще не тип и работать с шаблоном как с типом невозможно. Шаблон всегда требуется инстанцировать, результатом инстанцирования шаблона типа всегда будет тип, у которого уже можно получить доступ к полям и функциям.
добавляя "фиктивные" шаблонные параметры как-то слишком костыльно
После инстанцирования шаблона с параметрами, статическое поле MEMBER_TO_BE_ACCESSIBLE_OUTSIDE будет принадлежать только пространству инстанцированного типа. Иными словами, для каждой уникальной комбинации аргументов шаблона MEMBER_TO_BE_ACCESSIBLE_OUTSIDE будет иметь свой уникальный адрес размещения.
Извиняюсь за глупый вопрос, но откуда у пользователя возьмётся корректный стек вызовов?
Вот эта самая Backward-cpp и ей подобные выдачу коллстека и сделают корректной. Современная инструментация отладки позволяет опознать фрагменты встроенного кода и правильно оформить коллстек для выдачи.
И на производительности конкретно установка обработчиков тоже не сказывается.
подводные камни - это возможность полной декомпиляции твоей программы по ее отладочным меткам. В наши дни эта проблема решается обрезанием отладочной информации в процессе релиза для пользователей. В результате пользователи при падении видят только отчет со стеком вызовов и все. Это действие - джентельменский минимум уважающего себя производителя ПО.
While the compilation time issues makes sense, I don't see how you could have such drastically different binary sizes. While the intermediate object files might contain many duplicate symbols from inline functions, these should all be merged into one by the linker. The resulting binary should look roughly the same.
можно, но, как я написал выше, более чистым решением мне видется вызов приватного метода