Можно сколько угодно рассуждать на тему: "как можно улучшить с++". Но толку от это не будет никакого. Мы ведь не комитетчики.
Толк будет, если обсуждать такие темы, решения которых можно реально применить на практике.
Честно говоря, я сначала подумал, что у вас есть какое-то мнение по этому вопросу...
А С++ можно легко улучшить, написав свои "умные указатели", если они конечно получаться лучше стандартных.
Не просто мнение, а готовое решение. Хотя оно и не до конца соответствует моим ожиданиям.
Механика разрабатывалась в рамках 2003 стандарта языка, когда был выбор: либо буст, либо велосипеды.
Целевая аудитория моего механизма: разного рода библиотеки/приложения, разработчики которых посчитали нерациональным добавлять тяжелую зависимость от boost только ради того, что бы можно было использовать boost::shared_ptr
В настоящие дни, ввиду всеобщей доступности std::shared_ptr мой механизм уже не актуален, даже не смотря на более проработанный дизайн.
Однако, мой механизм обладает большей областью применения, нежели стандартные аналоги.
А именно: учитывает и элегантно разруливает проблему программирования на языке с++ в терминах интерфейсов, и проблему создания корпусов (которая вытекает из проблемы интерфейсов). Чего не умеют делать стандартные смарты.
Этот нюанс сыграл свою роль: у меня на работе действительно рассматривалась возможность использование моего мопеда взамен стандартных.
Но он был признан не готовым. Его реализация была признана не соответствующей требованиям к библиотечным механизмам в рамках 11 стандарта. Мне предложили выполнить рефакторинг, и заменить всю самописную 2003 инфраструктуру для поддержки мета-программирования на аналоги из стандартной библиотеки 11 стандарта.
Если я это сделаю: возможно мой велосипед примет участие в коммерческом проекте.
Ради фана, если есть желание можно обмусолить дизайн этого решения. Но, как я уже писал выше - это тема для длительной дискуссии. И прежде, чем я вступлю в дискуссию по поводу этой темы, я хочу услышать развернутый ответ на два вопроса:
***
Представьте себе на секундочку, что вы работаете с готовым движком. Он предоставляет наружу 3 пользовательских класса:
1. Простая картинка. Можно загрузить картинку с диска, произвести с нею манипуляции (разворот, масштабирование и тп).
2. Последовательность картинок. Что-то вроде контейнера простых картинок, который предоставляет пользователю возможность управления принципом следования кадров:
sequence.SetQueue("B...E, R3(B ... E/2)");
//B - begin индекс начального кадра
//E - end индекс конечного кадра
//R - repeat повторение задания (если не указано сколько раз - повторение до бесконечности)
//через запятую перечисляются задания
//в данном примере:
//сначала проигрывать все кадры от первого до последнего
//затем три раза повторить проигрывание от первого до половины
Последовательность картинок эксплуатирует класс простых картинок для своей деятельности.
3. Класс анимации. Что-то вроде обертки над классом последовательности картинок. Анимация умеет плавно и красиво проигрывать покадровый ролик. Она учитывает всевозможные нюансы по работе с движком: переключение кадров по времени (можно замедлять/ускорять проигрывание покадрового ролика), учитывает и корректно реагирует на возможные рывки фпс, и прочие движковые лаги.
Первый вопрос:
Должны ли разработчики движка предоставить пользователю наружу класс простой картинки, и последовательности кадров?
Или напротив, они должны спрятать эти два класса подальше от пользователя, предоставив ему только класс анимации?
Второй вопрос:
Механизм анимации покрывает область применения простых картинок и последовательности кадров.
Так например: простая картинка - это незапущенная анимация из 1 кадра
Очередь картинок - это незапущенная анимация из нескольких кадров.
Если скрыть от пользователей факт существования простой картинки и очереди, то все пользователи будут работать с одним единственным типом данных - анимация. Если разрешить - пользователям придётся учить и держать в голове целый заоопарк вместо одного.
Что лучше для пользователя:
1. Один механизм, который элегантно покрывает всю возможную область применения для решения всего круга задач?
2. Целый зоопарк механизмов, каждый из которых покрывает лишь незначительную часть области применения этого же круга задач?
Имейте ввиду: интересует исключительно удобства пользователей движка, а не его разработчиков.
