Здравствуйте, Centaur.

Для этого кода еще существует одна проблема:

Изначально строились 3-и класса CPanel, CScreen и CElement. Все эти классы существуют как некий документ и не более.
Панель — это класс некоторой панели(физическое устройство), которая в свою очередь содержит набор экранов(логические единицы панели), а экраны содержат элементы(логические единицы экрана).

Задача заключается в том, чтобы собрать редактор для добавления экранов в панель и расположения элементов внутри экранов, задавая им некоторые свойства в зависимости от типов. В конечном итоге, при помощи методов store() выгрузить все эти данные в программу управления реальной панелью, которая позволит получить на панели логическую систему меню, сообщений и форм ввода/вывода.
Программа-транслятор, для реальной панели, так-же написана на c++, за исключением платформы(в настоящий момент используется DOS).

По-этому не хотелось делать несколько реализаций классов CPanel, CScreen и CElement для каждой платформы, а сделать всего-лишь один вариант с методами load() и store(). После чего, использовать эти классы в зависимости от того в какой программе они используются (редактор или транслятор), как некое хранилище данных.

Если использовать механизм наследования и создавать потомков класса CElement с готовыми методами для использования их в редакторе (т.е. некие методы DoSomething()), то в результате окажется, что при повторном использовании кода этого класса в трансляторе у меня появится неиспользуемый код, т.к. в трансляторе свойства элементов не меняются и остаются постоянными.

Кроме того — если отказаться от задания типов элементам, то транслятору будет достаточно тяжело определить какого типа элемент он обрабатывает.

Можно, конечно, унаследовать класс CPanel и получить что-то типа CEditablePanel и CTranslatedPanel, но все равно методы редактирования и трансляции будут разными (я не вижу необходимости создавать над всем этим класс), а структура документа (набор свойств элементов) постоянна. И необходим класс для элемента, который мог бы сообщить где он находится на экране, какого он типа и какие данные содержит — больше ничего.

Я пришел к выводу, ест-но, посовещавшись с умными люми, что наиболее подходящим решением будет возвращать индексы эл-тов, а не указатели или ссылки(при этом рассматривался вариант использования итереаторв, но в данном случае он громоздок).

Я, так-же, полностью согласен с высказываниями по поводу возврата пустых ссылок (про руки). Это уже на самом деле был плод больной фантазии невыспавшегося организма. Хотя должен признать, что изначально идея null-referenses мне очень понравилась (хотя это всего-лишь мое мнение, которое не совпадает с концепцией ссылок в с++), но я во благо Человечества решил от нее отказаться .

Очень благодарен за исчерпывающий ответ, мне, как человеку, недавно использующему с++, он дал неоценимую помощь. Ссылки на литературу — это по моему было сверх всяких ожиданий. И я честно обещаю проработать этот вопрос.

Удачи.