Языки и циклические зависимости между блоками компиляции(units)

← →
oxffff © (2011-02-18 15:52) [0]

Добрый день.
Продолжаю усиленно пилить YAR.
Решил наконец добавить модули.
Хочется, чтобы была возможность циклических зависимостей между модулями,
хотя по сути содержимое становится связным и требует дополнительной докомпозиции. Но это лирика. :)

Предполагается паралельная компиляция модулей или неких их аналогов
(Собственно нагородил уже threadvar. И параллельно компилируется. Однако пока нет никаких зависимостей.)

Пока на ум приходит алгоритм.
Проход компиляции один.

1. Параллельный проход до implementation части всех модулей(то есть public часть модуля).
2. Разрешаем все unresolved external ссылки на типы.
Проверяем зацикленность определения всех типов.
3. Параллельный проход после implementation всех модулей.

Где могут быть грабли?

Спасибо.

← →
XXL (2011-02-18 15:58) [1]

> Пока на ум приходит алгоритм.
> Проход компиляции один.

А два прохода религия не позволяет ?
Ведь будет гораздо проще.

← →
oxffff © (2011-02-18 16:01) [2]

> XXL (18.02.11 15:58) [1]
>
> > Пока на ум приходит алгоритм.
> > Проход компиляции один.
>
> А два прохода религия не позволяет ?
> Ведь будет гораздо проще.

А почему будет проще?

← →
KSergey © (2011-02-18 16:10) [3]

Я вот не понял: вопрос про параллельную компиляцию или про проблемы с циклическими ссылками?

← →
Гость (2011-02-18 16:11) [4]

немного не в тему
А не в курсе, почему delphi запрещает это дело?
без издевки, просто не знаю
ну и мысль такая - а чего же они тогда не разрешили такое?

← →
KSergey © (2011-02-18 16:16) [5]

> Гость (18.02.11 16:11) [4]
> не разрешили такое?

Какое? Циклическое?
Формально возникает проблема с рекурсией, причем бесконечной из трёх модулей - легко. Зачем давать возможность писать говнокод? и без этого есть масса способов.

← →
oxffff © (2011-02-18 16:17) [6]

> KSergey © (18.02.11 16:10) [3]

Собственно вопрос как сделать параллельную компиляции с разрешением циклических ссылок.

← →
oxffff © (2011-02-18 16:18) [7]

> Гость (18.02.11 16:11) [4]
> немного не в тему
> А не в курсе, почему delphi запрещает это дело?
> без издевки, просто не знаю
> ну и мысль такая - а чего же они тогда не разрешили такое?
>

Circular Unit References
Occasionally, you"ll have a situation in which UnitA uses UnitB and UnitB uses UnitA. This is called a circular unit reference. The occurrence of a circular unit reference is often an indication of a design flaw in your application; you should avoid structuring your program with a circular reference. The optimal solution is often to move a piece of data that both UnitA and UnitB need to use out to a third unit. However, as with most things, sometimes you just can"t avoid the circular unit reference. Note that circular references in both the interface or implementation section are illegal. Therefore, in such a case, move one of the uses clauses to the implementation part of your unit and leave the other one in the interface part. This usually solves the problem.

← →
Гость (2011-02-18 16:22) [8]

ясно.
А зачем старт-топик это хочет сделать тогда?

← →
oxffff © (2011-02-18 16:25) [9]

При разрешении circular unit references получается, что единицей компиляции может быть как модуль(если он не зависит не откого), или набор зависимых между собой модулей. Не знаю плохо это или хорошо. :)

← →
oxffff © (2011-02-18 16:34) [10]

> Гость (18.02.11 16:22) [8]
> ясно.
> А зачем старт-топик это хочет сделать тогда?

Встречал на форумах желающих, чтобы такое было.

← →
Гость (2011-02-18 16:39) [11]

по мне тоже было б неплохо, на первый взгляд

← →
han_malign (2011-02-18 16:44) [12]

#include(и #pragma once - для заплаток дизайна) - фактически просто сливают все заголовчники в один, со сквозной предварительной декларацией типа:
class Cross1; #include "cross2.h" class Cross1 { Cross2* m_pCrossLink; } - но, блин, разгребать потом эту помойку!!!

← →
KSergey © (2011-02-18 16:47) [13]

> oxffff © (18.02.11 16:34) [10]
> Встречал на форумах желающих, чтобы такое было.

Эээ... так много чего желают на форумах
Почему выбрано именно это?

← →
oxffff © (2011-02-18 16:54) [14]

> KSergey © (18.02.11 16:47) [13]
> > oxffff © (18.02.11 16:34) [10]
> > Встречал на форумах желающих, чтобы такое было.
>
> Эээ... так много чего желают на форумах
> Почему выбрано именно это?

Не совсем понятно это ограничение. Если есть зависимость между модулями - это по идее значит модули являются клиентами друг друга.
И значит они уже связаны. Почему стараются различать interface и implementation зависимости. Не совсем понятно. Если это ограничение конкретного компилятора, то это одно, а есть ли другое ограничение?

← →
DiamondShark © (2011-02-18 16:54) [15]

> Встречал на форумах желающих, чтобы такое было.

Встретишь на улице -- смело бей с ноги в хрюпло. Будут возмущаться -- скажи, что я велел.

Проблема циклических зависимостей может возникнуть только в одном единственном случае -- при одновременной разработке двух модулей одним и тем же разработчиком. Тут одно из двух: либо эти модули должны быть слиты в один, либо общие части должны быть вынесены в независимый модуль.
Если же разработчик вместо переосмысления дизайна начинает хотеть странного от языка, то это значит, что он слишком давно подошву кирзача не нюхал.

А вообще, паскаль в отношении зависимостей достаточно толерантен. В том же дотНет, например, циклические зависимости между сборками запрещены вообще. А в паскале циклические зависимости разрешаются в непубличной части модулей.
Не вижу особого смысла что-то менять.

← →
oxffff © (2011-02-18 16:54) [16]

> Почему выбрано именно это?

До остального еще руки не дошли. :)

← →
DiamondShark © (2011-02-18 17:02) [17]

> Не совсем понятно это ограничение.

Чего не понятного?
Сложность компилятора увеличивается, а выгоды -- меньше нуля.

> Почему стараются различать interface и implementation зависимости.

Потому что если interface успешно прошёл компиляцию, то всех клиентов можно собрать, даже не докомпилировав модуль до конца. Чего тут непонятного?

← →
DiamondShark © (2011-02-18 17:07) [18]

> До остального еще руки не дошли. :)

Есть много более полезных вещей.

Кстати, если в классах описание private членов выкинуть из секции interface, то количество случаев циклических зависимостей упадёт на порядок.

← →
oxffff © (2011-02-18 17:10) [19]

> В том же дотНет, например, циклические зависимости между
> сборками запрещены вообще

ASMMETA?

← →
DiamondShark © (2011-02-18 17:33) [20]

> ASMMETA?

Совсем из другой оперы.

← →
oxffff © (2011-02-18 21:25) [21]

> DiamondShark © (18.02.11 17:33) [20]
>
> > ASMMETA?
>
> Совсем из другой оперы.

?

ASMMETA: Resolving Circular Dependencies
What do you do if you need to do a clean rebuild of a multiassembly project (say, assemblies
A, B, and C) in C# or VB .NET (or both), and you have a circular dependency: A references B,
B references C, and C references A? The high-level compilers such as C# and VB .NET require
all referenced assemblies to be present when you compile an assembly. So which assembly are
you going to compile first?
And please don’t tell me that it is better to avoid the circular dependencies. I agree wholeheartedly.
The question is, what do you do if you have one?
Enter the ASMMETA tool.

← →
DiamondShark © (2011-02-21 11:38) [22]

> oxffff © (18.02.11 21:25) [21]

Во-первых, это методика из разряда "тщательно обработать напильником".
Во-вторых, это решает проблему, аналогичную зависимостям "interface-implementation" в паскале, которая в паскале вообще не является проблемой.

← →
oxffff © (2011-02-21 12:09) [23]

> это решает проблему, аналогичную зависимостям "interface-
> implementation" в паскале,

Про это в тексте ASMMETA ничего не сказано. Сказано про взаимозависимость между сборками.

Поэтому было бы неплохо привести выдержку из документации. Вообщем жду.

← →
DiamondShark © (2011-02-21 13:15) [24]

> Вообщем жду.

Жди.
У меня пропадает желание общаться, когда собеседник проявляет нарочитое отсутствие желания понять что-то самостоятельно.

← →
XXL (2011-02-21 13:17) [25]

> oxffff © (18.02.11 16:01) [2]
> А почему будет проще?

Потому что, эти все циклические зависимости - всего лишь человеческая заморочка из разряда так удобнее.

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

PS: Я не спец по компиляторам, просто мой неискушенный мозг так думает.
PSS: А спасет мир динамическая линковка ;)

← →
oxffff © (2011-02-21 14:18) [26]

> DiamondShark © (21.02.11 13:15) [24]
>
> > Вообщем жду.
>
> Жди.
> У меня пропадает желание общаться, когда собеседник проявляет
> нарочитое отсутствие желания понять что-то самостоятельно.
>

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

> XXL (21.02.11 13:17) [25]
>
> > oxffff © (18.02.11 16:01) [2]
> > А почему будет проще?
>
> Потому что, эти все циклические зависимости - всего лишь
> человеческая заморочка из разряда так удобнее.
>
> В первом проходе препроцессор, в случае обнаружения зависимостей,
> делает закладки, мол такой модуль использует другой и наоборот.
>
> Во втором проходе для компилятора уже не должно быть отдельных
> модулей.
>
> PS: Я не спец по компиляторам, просто мой неискушенный мозг
> так думает.
> PSS: А спасет мир динамическая линковка ;)

А почему бы эту задачу не делать в один проход. И не мусолить одно и тоже по два раза.

← →
XXL (2011-02-21 14:32) [28]

> oxffff © (21.02.11 14:22) [27]
> А почему бы эту задачу не делать в один проход. И не мусолить одно и тоже по два раза.

Потому, дабы избавиться от вопросов:
- Как бы сделать за один проход, причем с использованием параллельной компиляции и других извращений...
Двухпроходная (а то и трехпроходная) схема решает задачу в лоб без лишних заморочек.

← →
XXL (2011-02-21 14:39) [29]

> Пока на ум приходит алгоритм.
> Проход компиляции один.

Кстати, пришла еще одна мысль на базе вашего 0 поста.
Первый проход.
> 1. Последовательный проход до implementation части всех модулей (то есть public часть модуля).

Второй проход.
> 2. Разрешаем все unresolved external ссылки на типы.
> 3. Параллельный проход после implementation всех модулей.

> XXL (21.02.11 14:32) [28]
>
> > oxffff © (21.02.11 14:22) [27]
> > А почему бы эту задачу не делать в один проход. И не мусолить
> одно и тоже по два раза.
>
> Потому, дабы избавиться от вопросов:
> - Как бы сделать за один проход, причем с использованием
> параллельной компиляции и других извращений...
> Двухпроходная (а то и трехпроходная) схема решает задачу
> в лоб без лишних заморочек.

Без комментариев.

> XXL (21.02.11 14:39) [29]
>
> > Пока на ум приходит алгоритм.
> > Проход компиляции один.
>
>
> Кстати, пришла еще одна мысль на базе вашего 0 поста.
> Первый проход.
> > 1. Последовательный проход до implementation части всех
> модулей (то есть public часть модуля).

Будут unresolved ссылки на типы, которые должны быть позже разрешены, т.е.
1. Они либо внешние
2. Либо это forward using before declaring
3. Это можно сделать паралеллельно.

P.S. Старайтесь думать параллелльно.

← →
XXL (2011-02-21 14:45) [32]

> параллелльно.

параллельно.

> XXL (21.02.11 14:45) [32]
>
> > oxffff © (21.02.11 14:40) [30]
> > Без комментариев.
>
> Не хочешь комментариев - не пиши сюда.
> Написал - имей терпение.

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

Циклическая зависимость между двумя модулями, в сущности, означает, что это один модуль.

> Alkid © (22.02.11 10:16) [35]
> Циклическая зависимость между двумя модулями, в сущности,
> означает, что это один модуль.

Еще раз с Днем рождения. :)

> oxffff © (22.02.11 10:31) [36]
> Еще раз с Днем рождения. :)

Спасибо!
Но я решительно против циклических зависимостей!
:)

Языки и циклические зависимости между блоками компиляции(units) Найти похожие ветки