Здравствуйте, Erop, Вы писали:
_>>при всем уважении, пункты 1 и 5 означают что оно потенциально будет иметь разные версии CRT. Автор утверждает обратное. И потом я не вижу противоречия между написанным мной и пунктами 1 и 5. E>Вообще-то это проблема исключительно административная. Можно же для каждого проекта собирать свой билд этой dll. Ну или, хотя бы, для каждого используемого компилятора + CRT
а если это просто библиотека ? И вы ее поставляете для использования другими компаниями в их проектах?
_>>3 — явно подмножество остальных пунктов E>Ну интересно бы узнать каких именно Скажем из какого пунтка следует то, что все статические объекты dll строятся до статических объектов её клиента (про статической линковке)
2, 4, 5
вобще я не совсем понял вашего скачка от разбиения на модули(инкапсуляции, разделения труда итд), к статическим объектам в dll. Да и еще исключительно в статически линкуемой dll(не видел такого ограничения в этом топике). Но в целом предлагаю на этом не "тормозиться" Тк это явно мало относится уже к топику
Здравствуйте, igna, Вы писали:
I>Правда? А что, и сегодня это все еще актуально? Честно говоря думал, что и из exe-файла грузится только то, что используется.
Это если тебе адресного простанства не жалко Да и настройка адресов время занимает заметное.
Ну и потом есть ещё и инициализация. В каком-то смысле удобнее иметь загруженный код уже и инициализированным. Мэнеджмент проще.
Скажем грузишь ты спеллеро в ворд. Он или грузится или нет. Если грузится, то значит словари уже нашёл...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, dip_2000, Вы писали:
_>а если это просто библиотека ? И вы ее поставляете для использования другими компаниями в их проектах?
Ну тогда не стоит закладываться на то, что сквозь границу библиотеки можно передавать исключения, владение блоками new|delete и т. п. Либо точно это специфицировать...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Я примепрно об этом же.
Гарантии вроде как есть только для операторов new/delete перекрытых в классе. То, что эффект распространаяется и на глобальные new/delete ИМХО, особенностьреализации...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, minorlogic, Вы писали:
E>>Тгда уж и operator new и delete для этих же классов стоит перекрыть... M>Я не понял о чем идет речь. M>http://www.rsdn.ru/forum/message/2440046.1.aspx
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, <Аноним>, Вы писали:
А>Могут ли быть какие-нибуть проблемы в этом случае?
Да будут проблемы, и очень много но всё решается редиректом (new и delete в exe,dll) в какой-либо модуль, чтобы было одно адресное пространство, иначе есть риск одинаковой адресации обьектов, в нормальных проектах создается модуль называемый менеджером памяти, каторый за это всё и отвечает.
Здравствуйте, Аноним.
По-моему, тема ветки не очень корректно сформулирована, правильнее так: «new в exe — delete в DLL».
Как уже писали, разные модули (модуль — это exe или DLL в рамках Windows-процесса, модуль идентифицируется значением типа HINSTANCE (он же HMODULE)) могут пользоваться разными C++ heap-ами. То есть может получиться так, что в exe глобальный new берёт память у одного C++ heap-а, а в DLL глобальный delete возвращает память другому C++ heap-у. На эту тему есть страшная картинка здесь
Здравствуйте, Wifer, Вы писали:
W>Да будут проблемы, и очень много но всё решается редиректом (new и delete в exe,dll) в какой-либо модуль, чтобы было одно адресное пространство,
В рамках Windows-процесса у всех модулей (exe и DLL-и) и так общее виртуальное адресное пространство, для этого не надо никаких redirect-ов делать.
W>иначе есть риск одинаковой адресации обьектов,
Что такое «одинаковая адресация объектов»? И почему это риск?
W>в нормальных проектах создается модуль называемый менеджером памяти, каторый за это всё и отвечает.
Необязательно создавать свой DLL, можно использовать готовый, например:
* msvcrt.dll, функции malloc, free.
* kernel32.dll, функции GetProcessHeap, HeapAlloc, HeapFree.
* ole32.dll, функции CoTaskMemAlloc, CoTaskMemFree (Awaken уже написал здесь
Кстати, чтобы предотвратить путаницу. Слово «модуль» используется в двух значениях:
* Exe или DLL в рамках Windows-процесса. Именно это я имею в виду под словом «модуль».
* Unit, то есть пара .h-файл (заголовочный файл) и .cpp-файл. Имеется близкое понятие «translation unit» — это результат обработки .cpp-файла C++-препроцессором.
Здравствуйте, Пётр Седов, Вы писали:
ПС>Здравствуйте, Wifer, Вы писали:
W>>Да будут проблемы, и очень много но всё решается редиректом (new и delete в exe,dll) в какой-либо модуль, чтобы было одно адресное пространство, ПС>В рамках Windows-процесса у всех модулей (exe и DLL-и) и так общее виртуальное адресное пространство, для этого не надо никаких redirect-ов делать.
Ну доэтого я считал что ДЛЛ подгружается в свое адресно протсранство, тк это собственно отдельный процесс, и то что ползание одмин процессом по адресам другого неверно не самый лучший вариант, и виндовс со мной согласна )
W>>иначе есть риск одинаковой адресации обьектов, ПС>Что такое «одинаковая адресация объектов»? И почему это риск?
По теории у 2х процессов может по одному и томуже адресу находится различная информация
W>Да будут проблемы, и очень много но всё решается редиректом (new и delete в exe,dll) в какой-либо модуль, чтобы было одно адресное пространство, иначе есть риск одинаковой адресации обьектов, в нормальных проектах создается модуль называемый менеджером памяти, каторый за это всё и отвечает.
Причем тут адресное пространство? Просто new/delete это не функции операционной системы. А функции рантайма. А рантайм у каждого модуля может быть свой. МОжет быть и одинаковый и разнух модулей, но на это нельзя закладываться. Как и на то что new/delete никогда не будут переопределены для данного кода.
Здравствуйте, <Аноним>, Вы писали:
А> Как и на то что new/delete никогда не будут переопределены для данного кода.
А что мне помешает это сделать ?, ты программист — должен следить, тыже не пытаешься вызвать функции класса по нулевому указателю.
Здравствуйте, Wifer, Вы писали:
W>Ну доэтого я считал что ДЛЛ подгружается в свое адресно протсранство, тк это собственно отдельный процесс,
Загруженная DLL — это не отдельный процесс, это модуль в рамках процесса.
W>и то что ползание одмин процессом по адресам другого неверно не самый лучший вариант, и виндовс со мной согласна )
В общем случае читать/писать память другого процесса с помощью C++-указателя не получится (хотя если разделяемая память, то можно, это реализуется с помощью file-mapping object). Для этого надо использовать WinAPI-шные функции ReadProcessMemory и WriteProcessMemory, отладчики так поступают.
W>По теории у 2х процессов может по одному и томуже адресу находится различная информация
Да, это и на практике так. Но так как у каждого процесса — своё изолированное виртуальное адресное пространство, то обычно конфликтов не возникает.
. Там описаны механизмы, предоставляемые Windows kernel-ом, в том числе DLL.
Пётр Седов (ушёл с RSDN)
Re[4]: New в процессе - delete в dll
От:
Аноним
Дата:
07.09.07 22:41
Оценка:
А>> Как и на то что new/delete никогда не будут переопределены для данного кода. W>А что мне помешает это сделать ?, ты программист — должен следить, тыже не пытаешься вызвать функции класса по нулевому указателю.
Фишка в том что программист часто не один, а штук 100. И код должен минимально зависеть от "окружающих условий" дабы оставаться стабильным в течении времени жизни проекта.
Здравствуйте, <Аноним>, Вы писали:
А>>> Как и на то что new/delete никогда не будут переопределены для данного кода. W>>А что мне помешает это сделать ?, ты программист — должен следить, тыже не пытаешься вызвать функции класса по нулевому указателю. А>Фишка в том что программист часто не один, а штук 100. И код должен минимально зависеть от "окружающих условий" дабы оставаться стабильным в течении времени жизни проекта.
Но допустим, что их много, и что, значит необходима архитектура такая чтобы писали правильно, а не как вздумается, но это уже совсем другая история.
E>Я примепрно об этом же. E>Гарантии вроде как есть только для операторов new/delete перекрытых в классе. То, что эффект распространаяется и на глобальные new/delete ИМХО, особенностьреализации...
Я и на это отвечал, что если это особенность реализации то по другому реализовать то и не возможно. И объяснил почему. Очень интересно посмотреть на компилятор который делает по другому, в стандарте можно покопаться , наверняка это жестко зафиксированно.
Здравствуйте, minorlogic, Вы писали:
M>Я и на это отвечал, что если это особенность реализации то по другому реализовать то и не возможно. И объяснил почему. Очень интересно посмотреть на компилятор который делает по другому, в стандарте можно покопаться , наверняка это жестко зафиксированно.
1) АФАИК в стандарте это не зафиксированно,например потому, что там вообще нет понятия DLL и есть специальнеый раздел, где подчёркивают, что глобальный new/delete должен быть один, ну и вообще не зафиксировано это в стандарте. Там наоборот говорят, что если глобальных операторов несколько, то программа некорректна.
2) Компилятор, который делает по другому тебе уже приводили
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Тк это явно мало относится уже к топику 
