Здравствуйте, VladD2, Вы писали:

VD>На самом деле все не так просто (однозначно). Вот граматика из спецификации:
VD>

VD>compilation-unit:
VD>    extern-alias-directives-opt 
VD>    using-directives-opt 
VD>    global-attributes-opt
VD>    namespace-member-declarations-opt
VD>

VD>Как видишь, по сути глобального пространства имен даже не существует. using и глобальные атрибуты как бы находятся в compilation-unit-е. И это не с проста, ведь глобальные атрибуты могут быть только тут. Вот, для сравнения, описание тела пространства имен:
VD>

VD>namespace-body:
VD>{
VD>    extern-alias-directives-opt 
VD>    using-directives-opt 
VD>    namespace-member-declarations-opt
VD>}
VD>

VD>Как видишь, структура похожа, но не идентична. В принципе было бы правильно вообще избавиться от глобального пространства имен, но уж больно удобно им пользоваться.

VD>Нет, главное отличие — это наличие глобальных атрибутов. В принципе можно было бы создать базовый класс (RNamespaceBase) от которого породить RNamespace и RCompileUnit. Тогда у RNamespace можно было бы добавить имя, а у RCompileUnit список глобальных атрибутов. Тогда можно было бы наиболее полно применять полиморфизм.

Попробовал для начала просто пронаследовать RCompileUnit от RNamespace, почикал дубликаты ф-ий. Попатчил еще cs.atg в районе CS() дабы другая структура получалась. В принципе заработало. Но во первых правильнее как ты написал через RNamespaceBase сделать, во вторых возможно где-то в другом месте что-то отвалилось, Юнит тестов нет, фиг узнаешь.

VD>Видимо так и нужно будет сделать. Но насколько это актуально? По мне так приоритетность у данной задачи не велика.

Мои ощущения были такие что, каждый элемент дерева построен парсером из куска кода и все непосредственные дети этого элемента покрывают собой этот кусок кода но не пересекаются между собой. это мое ощущение и было нарушено .

L>>Про разрешение имен.
L>>Это всякий геморой связаный с разрешением ссылок на ф-ии, Argument Depended Lookup и т.д?

VD>Что-то вроде. Одним словом — это разрешение всех ссылок. Например, в коде программы есть ссылки на переменные. Сейчас — это неразрешенные ссылки, а надо сделать так чтобы имея объявление переменной можно было бы быстро найти все ее вхождения. И наоборот, имея некоторое вхождение узнать ее объявление, типа и т.п. Тоже самое с методами, классами и т.п.

Правильно я понимаю что:

для второго пункта надо иметь деревообразное пространство всего проекта и импортированых в него сущностей(не знаю как это назвать) и бегать по нему снизу вверх в поисках нужных ссылок. Алгоритм очевидно будет более сложный в силу множественности мест откуда могут приезжать типы и переменные и т.д. Дерево проекта уже есть осталось только дерево импортированых сущностей и бегать.

для первого видимо нужна какая то другая структура где каждая переменная будет содержать список ссылок на места где она используется либо каждый раз бегать по дереву и генерировать этот список. Т.е. бегать придется всегда а вот сохранять или не сохранять?