Привет, Fazil6 !



были разные, теперь один... не помогает...


дык один он... это вообще один Solution, в который включены 2 проекта (или как там они у него обзываются)....
да и на мой взгляд необходимости в DLL-ке вроде нет.... просто мой предшественник все, что относилось к ESQL/C решил засунуть в DLL

а почему передача параметров в DLL плохая идея и чем ссылка на объект хуже например указателя на строку?

а функции стараюсь писать универсальные, чтобы действительно эту DLL  м. было другими EXE-шниками использовать

и на мой взгляд проще передать объект, чтобы некто там напихал в него данные, используя его же методы, вместо того, чтобы пихать в объект методы, которые используют вызовы множества ESQL/C функций

стоп...
перейдем к конкретному примеру....
мне нужно отобразить содержимое файла, хранящееся в БД в BLOB-е и некоторые значения полей таблиц
рассмотрим варианты...
имеется универсальная функция уже написанная и откомпилированная...
 ты...
      1) просто ее вызовешь с необходимыми параметрами?
      2) скопируешь ее код в свой проект?
      3) напишешь нечто очень похожее, но свое?

как бы ты сам написал эту функцию?
  1) передал бы ей кучу хэндлов на окна и пущай в них сама все вставляет
  2) забрал бы от нее все данные в статические буфера (для BLOB например 1000К или больше) и сам бы повставлял данные
  3) то же но с динамическими буферами (string, vector и т.д.) (кстати вариант там распределять память, а здесь при закрытии окна освобождать - также не проходит по тем же причинам, приходиться выполнять лишние запросы для уточнения размеров)

поделись плиз логикой...

с ув. BSD
 

я говорил о объектах классов. Если у тебя в интерфейсе dll функция, которая в качестве праметра принимает к примеру std::map,  то как ты эту функцию будешь вызывать, скажем, в Delphi ? Причем, не факт даже, что программа компиллируемая С++ компиллятором всегда сможет работать с такой dll, просто потому что использует какую-нибудь другую версию STL, потому что объект std::list создаваемый ею отличается в силу особеностей компиллятора от объекта создаваемого компиллятором dll. Объект класса - это ведь не int какой-нибудь.

для этой цели нужно использовать переносимые типы в интерфейсе dll. Использование классов резко сужает область применимости такой библиотеки.

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

насчет задачи твоей... Постановка слишком неконкретная. Впринципе возможны любые из приведенных тобой вариантов. Причем здесь dll? Если уж рассматривать некие варианты, то если есть некая либа, которая инкапсулирует, допустим, работу с БД, то функция чтения значения из BLOB записывала бы результат в некий буфер unsigned char* но это далеко не единственное возможное и приемлемое решение. В каждом конкретном случае я буду решать как удобне. У меня тоже есть проекты, которые содержат модули с интерфейсом использующим STL объекты. 

В данном случае, разная.
Не нужно пытаться исправлять ошибку просто обойдя проблему - выставить одинаковый рантайм. Просто не надо выпускать наружу контейнеры STL и всё тут. Используйте копирование, тогда и проблем не будет.

Добавлено через 3 минуты и 1 секунду
Об отладочной куче можно почитать здесь

Привет Все!

Согласен с NiJazz по поводу того, что в 32 битной ОС кучи будут разные, но все равно не понимаю, в чем проблема освободить занимаемую память любой кучи, похоже что для безопасности процессов запрещают насильственными методами (ОС д.б. абсолютно все равно)

и второе... что плохого, что вектор находиться в одной куче и содержит объекты, хранящиеся в другой куче?




кто будет распределять память под буфер???
 с целью оптимизации было бы выгоднее, чтобы модуль сам распределял память (он то знает какого размера BLOB) (заодно бы и сообщения ползунку слала бы о ходе загрузки),  а программа бы в конце высвобождала по этому unsigned char* память. Но так не работает!

кстати отказаться от DLL начинает все больше привлекать меня  (видно не дорос еще я до них)

с ув. BSD

привет Всем!

более внимательное тестирование показало, что я был не прав, утверждая, что std::string работает без проблем по ссылке в DLL модуле.
НИЧЕГО не работает. Ни один объект динамически перераспределяющий память не будет корректно работать с другим потоком

учту ошибки в будущем. Всем СПАСИБО!

с ув. BSD