

----

[long before 10.11.14]

1. Нужно двигаться к реализации конкретных идей по проверке корректности
2. Всё началось с необходимость проверять, что ссылки MyCpp используются
правильно
    ? Каковы правила использования ссылок MyCpp ?
	* Объекты, производные от Referenced, должны создаваться оператором new
	* В исключительных случаях возможно создание таких объектов на стеке
	* Если метод принимает аргумент типа "указатель на объект, производный
	  от Referenced", то этот объект должен быть создан с помощью
	  оператора new, если только указатель не помечен как __mpp_auto
		=> все места, где возможно использование объектов на стеке,
		   должны быть отмечены тегом __mpp_auto.
	* Указатели, помеченные как __mpp_auto, нельзя присваивать ссылкам MyCpp.

Итак, первая задача - обеспечить проверку правильности использования ссылкок
MyCpp и ввести тег __mpp_auto.

Что нужно для этого сделать?
    * Во-первых, нужно разбирать объявления параметров функций и методов,
      указателей на объекты, производные от Referenced...
    * ...то есть нужно разбирать объявления объектов, отслеживать
      наследование, пространства имён и области видимости.
    * Плюс нужно разбирать выражения, чтобы определять моменты присвоения
      указателей ссылкам.
    * Ряд важных производных от Referenced объектов выполнен в виде шаблонов,
      значит, шаблоны тоже нужно разбирать.

- Итак, примерный набор информации, нужной для выполнения проверки, определён.
В каком виде представлять это информацию?
    Непосредственно контролируемыми местами являются выражения, содержащие
    присваивания указателей ссылкам и передачу указателей функциям в качестве
    параметров. При этом важен контекст, но порядок вычисления этих выражений
    по отношению друг к другу не важен.
	Можно задать метод для итерирования по всем выражениям, содержащимся в
	единице трансляции.
    ? Как передавать контекст ?
	Для каждого объекта, участвующего в интересующей операции, нужно знать
	его тип и теги, с которыми он был объявлен. Эта информация содержится
        в декларации объекта => нужно предоставить разобранную декларацию.
	    Для упрощения написания анализаторов будут доступны функции
	    поддержки, позволяющие легко определить, является ли объект
	    производным от заданного класса и т.п.

В принципе, для этой конкретной проверки можно проходить по единице трансляции
последовательно, не возвращаясь назад. Но можно также использовать структуру,
представляющую результат разбора всей единицы трансляции, то есть все
объявления по порядку.

! Первый шаг - разбор деклараций и их представление в некотором стандартном
виде. Это раздел 7, "Declarations".

----

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

Первое - разбор деклараций. При разборе декларации получаю два списка:
список спецификаторов и список деклараторов. Разбор списка идентификаторов
оказался рутинной процедурой и поэтому не представляет особого интереса.
Запись деклараторов сложнее. Суть декларатора - в комбинировании следующих
атрибутов типа данных:
    * указатели;
    * ссылки;
    * функции;
    * массивы.
Нужно выработать подходящее представление для _всех_ возможных типов.
-> Сейчас это 'class TypeHead'...

