Риторический вопрос

[Игорь Столяров]

Привет всем !

Если нет других тем, то хочу задать вопрос, с которым периодически сталкиваюсь.
По структуре приложения и именно в контексте Clarion.

Есть некоторое приложение MultiDLL. Так вот, структура позволяет его сделать и как
EXE + 1 DLL и как EXE + несколько DLL. Какой вариант предпочтительней ?
Нет ли каких-то "подводных камней" в том или ином случае ? И какова практика ?

Заранее спасибо !

[PavelNK]

Ритори́ческий вопро́с — риторическая фигура, представляющая собой вопрос-утверждение, который не требует ответа.

[finsoftrz]

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

[Игорь Столяров]

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

Давайте зайдём на вопрос другой стороны: разбиение проекта на несколько DLL несколько увеличивает его размер
(библиотеки, повтор иконок и т.д.) - это понятно. А даёт ли это какое-то преимущество ?

[RaFaeL]

Дает преимущество, когда несколько программистов на проекте, каждый свою dll пилит
Скорость программирования тоже, что пересобрать приложение с 50 функциями и что с 500
Еще заметил что иногда шаблоны конфликтуют, приходится разносить на разные dll функции, их использующие. Ну эт может от кривых рук, конечно
Увеличивать размер сильно не должно, так как общие библиотеки должны лежать в основной dll

[PavelNK]

Если проектов несколько, то позволяет использовать одну и ту же dll в нескольких проектах. Зачем делать двойную, тройную, ... работу

[arlean1]

Есть некоторое приложение MultiDLL. Так вот, структура позволяет его сделать и как EXE + 1 DLL и как EXE + несколько DLL. Какой вариант предпочтительней ?

Раньше в первых версиях клаши ещё в доклассовый период в одной статье журнала Clarion рекомендовалось для повышения скорости работы вставлять в одну DLL в среднем 5 процедур.
Как сейчас требует исследований

[Игорь Столяров]

для повышения скоростиработы вставлять в одну DLL в среднем 5 процедур.

Подозреваю, что в этой статье имелось ввиду "для скорости работы среды разработки Clarion" …

[finsoftrz]

Да шо вы говорите, уважаемые знатоки... Количество процедур на модуль, а не на dll. Для скорости компиляции. Дедушка Баррингтон писал.

[finsoftrz]

И сейчас, к слову, это тоже актуально. Когда отлаживаем, выделяем процедуру в отдельный модуль. Затем объединяем. Количество процедур на модуль зависит от размера. Если простые source, то можно штук по 10-20. Скорость компиляции и сборки возрастает заметно. Я это использую.

Помню, один товарищ писал, что практикует еще выделять не отлаженные процедуры в отдельную dll (не путаем с модулем), а по мере готовности раскладывать в нужные dll. Я пробовал, неудобно. Да и смысла особого нет, и так быстро работает.

[kreator]

И сейчас, к слову, это тоже актуально. Когда отлаживаем, выделяем процедуру в отдельный модуль. Затем объединяем. Количество процедур на модуль зависит от размера. Если простые source, то можно штук по 10-20. Скорость компиляции и сборки возрастает заметно. Я это использую.

Ну, это не про десятку. Десятка по дефолту в модуль кладёт 10 процедур, причём не важно какого размера. У меня где-то 15 таких модулей. Компиляция всего приложения идёт секунд несколько. Нет вообще смысла морочиться. Во времена Баррингтона возможно было по-другому.

Дает преимущество, когда несколько программистов на проекте, каждый свою dll пилит

Согласен. У нас так. Плюс есть ещё разноска по функционалу. Но я бы сократил количество dll. Надо следить за их содержимым. Мы вот чуть запустили порядок, и оказались пересекающиеся процедуры. Удобно всё загнать в один сольюшен и компилировать сразу. А нам надо теперь провести работу по наведению порядка в dll-ках, чтобы сборка прошла сразу. Это обсуждали уже.
Ещё минус мульти-dll - Кларион может сам при компиляции снять запущенный exe-шник, dll-ку не может.

[finsoftrz]

Насколько помню, в C6 дефолтное количество процедур на модуль тоже задавалось. Но это не всегда удобно. Поэтому я предпочитаю ручками делать, времени много не занимает. Да и смысл есть только на больших проектах.

[Игорь Столяров]

Здесь ещё есть связанная тема … Я могу ошибаться, но кажется начиная с C63 была настоятельная
рекомендация не использовать GlobalData External, без атрибута THEREAD …
Т.е. не делать общие области данных в MuliDLL приложениях вне потоков. Или я ошибаюсь ?

[finsoftrz]

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

[kreator]

десь ещё есть связанная тема … Я могу ошибаться, но кажется начиная с C63 была настоятельная
рекомендация не использовать GlobalData External, без атрибута THEREAD …
Т.е. не делать общие области данных в MuliDLL приложениях вне потоков. Или я ошибаюсь ?

По-моему, это чушь. А как вы храните глобальные настройки? Каждая процедура читает из ini-файла, при выходе записывает в ini-файл?