Могут ли быть какие-нибуть проблемы в этом случае?

А>Могут ли быть какие-нибуть проблемы в этом случае?

Могут. И обязательно будут, если, например, dll скомпонована с другой версией runtime library.

Здравствуйте, <Аноним>, Вы писали:

А>Могут ли быть какие-нибуть проблемы в этом случае?
Могут и большие. Всё зависит от того, общий ли CRT у длл и основного приложения.
Если нет (статическая линковка) то проблемы будут. Если динамическая линковка, но версии CTR не совпадают — тоже могут быть. Вообще то правило есть, где взял, там и положи. И проблем не будет

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

OV>Здравствуйте, <Аноним>, Вы писали:

А>>Могут ли быть какие-нибуть проблемы в этом случае?
OV>Могут и большие. Всё зависит от того, общий ли CRT у длл и основного приложения.
OV>Если нет (статическая линковка) то проблемы будут. Если динамическая линковка, но версии CTR не совпадают — тоже могут быть. Вообще то правило есть, где взял, там и положи. И проблем не будет

CRT у них всегда общий, какие при этом могут быть проблемы?

Здравствуйте, <Аноним>, Вы писали:

А>Могут ли быть какие-нибуть проблемы в этом случае?

Могут. Зависит от реализации менеджера памяти.
Если менеджер памяти создается в каждом модуле отдельно, то проблемы будут обязательно, если механизм выделения памяти один(HeapAlloc например), то вероятность проблем меньше, но я бы не стал на это рассчитывать. Даже если проблем не будет сейчас, никто не поручится, что они не появятся при переходе на другой компилятор/ОС/платформу. Что будет, если exe и dll соберутся разными компиляторами наверное говорить не нужно.

Здравствуйте, <Аноним>, Вы писали:


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

Здравствуйте, Аноним, Вы писали:

А>Могут ли быть какие-нибуть проблемы в этом случае?
Ну тебе тут в общем описали всякие разные особенности.
Но лучше расскажи попобробнее что надо
1) Система, как я понимаю, Windows
2) Компилятор -- MSVC -- версия?
3) Что за проект? В смысле какая у него структура? Эта dll поставляется независимо от приложения, или это части единого пакета?

Если части единого пакета, и у них общий crt и опции компиляции, то не парься и аллокируй/освобождай где хочешь.

А вот если dll и exe поставляются независимо, то лучше бы как-то подстраховаться.
Например съэкспортировать из dll функцию, которой разрушать созданные её объекты.

Или, наоборот, перекрыть в dll ::new и ::delete и при загрузке сообщать туда как-то интерфейс на правильные ::new и ::delete...

E>А вот если dll и exe поставляются независимо, то лучше бы как-то подстраховаться.
E>Например съэкспортировать из dll функцию, которой разрушать созданные её объекты.

нмв в таком случае правильно пользоваться КОМовскими аллокаторами: CoTaskMemAlloc / CoTaskMemFree
они специально под это заточены

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

A>нмв в таком случае правильно пользоваться КОМовскими аллокаторами: CoTaskMemAlloc / CoTaskMemFree
A>они специально под это заточены

Ну можно и комовскими, а можно и какими-нибудь ещё. Лучше бы узнать задачу... ИМХО

Здравствуйте, Аноним, Вы писали:

А>Могут ли быть какие-нибуть проблемы в этом случае?

А может стоит обернуть голые указатели в простейшие объекты со стратегией аллокирования и получить в качестве бонуса автоматическое управление временем жизни указателя?
Как пример смотри http://www.rsdn.ru/Forum/Message.aspx?mid=2018659&amp;only=1

Автор: remark
Дата: 23.07.06

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

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

_>Тогда в чем смысл выделения чего то в отдельную dll ? Если оно используется только одним процессом-приложением-проектом...

1) Существует более одного приложения, использующего эту dll. Например dll может использоваться как в составе десктопного приложения, так и в составе COM-объекта.
2) Разные команда делают разные dll
3) Более жёсткое разбиенени на модули
4) Более быстрая линковка проекта
5) Поставка продукта "по частям" Кому-то !облегчённую версию", а кому-то "полнофункциональную"
ну и т. д...

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

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

_>>Тогда в чем смысл выделения чего то в отдельную dll ? Если оно используется только одним процессом-приложением-проектом...

E>1) Существует более одного приложения, использующего эту dll. Например dll может использоваться как в составе десктопного приложения, так и в составе COM-объекта.
E>2) Разные команда делают разные dll
E>3) Более жёсткое разбиенени на модули
E>4) Более быстрая линковка проекта
E>5) Поставка продукта "по частям" Кому-то !облегчённую версию", а кому-то "полнофункциональную"
E>ну и т. д...
при всем уважении, пункты 1 и 5 означают что оно потенциально будет иметь разные версии CRT. Автор утверждает обратное. И потом я не вижу противоречия между написанным мной и пунктами 1 и 5.
с 2 и 4 согласен(4 -условно, тк гемороя имхо больше чем выигрыша, но это аргумент).
3 — явно подмножество остальных пунктов

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

E>2) Разные команда делают разные dll
E>3) Более жёсткое разбиенени на модули

Ну а lib в этих случаях чем хуже?

E>4) Более быстрая линковка проекта

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

E>5) Поставка продукта "по частям" Кому-то !облегчённую версию", а кому-то "полнофункциональную"

Ну да, а потом придумываем, как предотвратить совместное использование dll из разных поставок.

---

Мое мнение: dll стоит использовать тогда, когда выгода от их использования конкретна и очевидна. А не на всякий случай.

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

Здравствуйте, Аноним, Вы писали:

А>Могут ли быть какие-нибуть проблемы в этом случае?

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

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

I>P.S. Да, я понимаю, что демонстрация собственных умственных способностей руководству и коллегам может быть конкретно и очевидно выгодна.
Я всего лишь привёл коллегам несколько популярных поводов использовать dll, котрые не являются отдельными продуктами, а всегда входят в состав чего-то ещё. НИчего личного. Мало того, я не являюсь ярым сторонником dll

E>>2) Разные команда делают разные dll
E>>3) Более жёсткое разбиенени на модули

I>Ну а lib в этих случаях чем хуже?
1) у lib нет формального интерфейса. То есть любые потроха разных Lib могут перепутаться
2) Есть много неявных зависимостей. Например, порядок инициализации статических объектов неопределён... (У DLL определён, например)

E>>4) Более быстрая линковка проекта

I>Популярный аргумент, на деле нередко оказывается, что экономится несколько процентов от общего времени затрачиваемого на компиляцию-линковку. Это сэкономленное время приходится затем вернуть с лихвой при отладке и/или решении проблем вроде "как разместить тут, а удалить там".

На деле, если ты используешь dll только формально, то никаких таких проблем нет
Какая разница из какого файла мапируется код?

А экономия проистекает из-за того, что разные DLL на разных этапах проекта пересобираются в разной степени часто. Например, у меня есть dll которая содержит в себе очень много статических данных и методов, осуществляющих к ним запросы. И есть её эесперементальная версия, которая имеет тот же интерфейс, но работает через MS SQL, и есть клиент второй версии, который генерирует cpp для статических таблиц первой.
Так вот, первая версия линкуется полтора часа. Но случается это очень редко

E>>5) Поставка продукта "по частям" Кому-то !облегчённую версию", а кому-то "полнофункциональную"

I>Ну да, а потом придумываем, как предотвратить совместное использование dll из разных поставок.
А чего придумывать?
1) Ставь все dll в папку продукта (это от lib вообще ничем не отличается, кстати )
2) Манифесты там всякие бывают кроме всего прочего
3) Вообще-то у DLL бывает интерфейс. И смена версий часто допустима, кроме всего прочего

I>

---

I>Мое мнение: dll стоит использовать тогда, когда выгода от их использования конкретна и очевидна. А не на всякий случай.

Моё мнение такое, что вопрос нужны ли DLL или нет в первую очередь определяется маркетинговыми соображениями
В сложных проектах они часто нужны, ну удобны во всяком случае, но не все приложения могут их себе позволить. Опять же по маркетинговым соображениям (типа нужна работа без инсталлятора)

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

M>Используй виртуальные деструкторы для шареных классов, это минимизирует большую часть проблем.

Тгда уж и operator new и delete для этих же классов стоит перекрыть...
А то не поможет

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

_>при всем уважении, пункты 1 и 5 означают что оно потенциально будет иметь разные версии CRT. Автор утверждает обратное. И потом я не вижу противоречия между написанным мной и пунктами 1 и 5.

Вообще-то это проблема исключительно административная. Можно же для каждого проекта собирать свой билд этой dll. Ну или, хотя бы, для каждого используемого компилятора + CRT
Я уже не говорю о том, что CRT меняется всё-таки очень редко...

_>3 — явно подмножество остальных пунктов
Ну интересно бы узнать каких именно Скажем из какого пунтка следует то, что все статические объекты dll строятся до статических объектов её клиента (про статической линковке)

E>1) Существует более одного приложения, использующего эту dll. Например dll может использоваться как в составе десктопного приложения, так и в составе COM-объекта.
E>2) Разные команда делают разные dll
E>3) Более жёсткое разбиенени на модули
E>4) Более быстрая линковка проекта
E>5) Поставка продукта "по частям" Кому-то !облегчённую версию", а кому-то "полнофункциональную"
6) Отложенная загрузка чего-то большого/очень редко нужного
7) Несколько версий реализации чего-то. Соответсвенно загрузка только нужной реализации (скажем синхрообъекты разного толка на случай разного окружения, код, оптимизированный под разные процы и т. п. )

ну и всё равно т. д...

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

I>>P.S. Да, я понимаю, что демонстрация собственных умственных способностей руководству и коллегам может быть конкретно и очевидно выгодна.
E>Я всего лишь привёл коллегам несколько популярных поводов использовать dll, котрые не являются отдельными продуктами, а всегда входят в состав чего-то ещё. НИчего личного. Мало того, я не являюсь ярым сторонником dll

Ты только не восприми это мое про демонстрацию на свой счет, никого конкретно ввиду не имел; более того, я даже не отношусь негативно к такой демонстрации.