Доброго времени суток.

Есть проблема c работой векторов совместно с dll
 


Но после того, как делаю вызов этой функции из программы :



выкидывает :



Вот такая проблемка, не знаю что делать, до этого использовал сишные строки и всё работало. 
Может кто подскажет ответ?

dll написана под visual studio 6.0 , вызывается из CBuilder6.
 




 

Скорее всего вязанка и билдер используют разные версии STL. так что не стоит передавать std::string'и да std::vector'а.

http://forums.microsoft.com/MSDN/ShowPost....70&SiteID=1 - 

нашел кое-что,  но я слабо понимаю о чём они там пишут.

Вот тебе и ответ...



Это сообщение отредактировал(а) andrew_121 - 6.3.2008, 15:02

Я же говорю - слабо понимаю английский, да и вообще кто-нибудь объяснит о чём тут написано?

Тестирую dll под вижуалом - всё работает - значит всё -таки проблема с совместимостью STL в билдере и вижуале 

Это сообщение отредактировал(а) alex87 - 6.3.2008, 15:11

Неплохой онлайн переводчик

Особенно хорошая особенность tr1::shared_ptr есть, что это автоматически использует
его за-указатель deleter, чтобы исключить другую ошибку потенциального клиента, "Проблема ПЕРЕСЕЧЕНИЕ-DLL."
Эта проблема собирает урожай выше того, когда объект создан, используя новым в одном динамически связал
библиотеку (DLL) но удаляется в различном DLL.  На многих платформах, такие ПЕРЕСЕЧЕНИЕ-DLL
пары новости/удаления приводят к ошибкам во время выполнения. tr1:;shared_ptr избегает проблемы, потому что
его заданный по умолчанию deleter использует удаление из того же DLL, где tr1::shared_ptr создан. Так, я мог
изменить свой код такое, что все размещения и вычеркивания появляются или в клиента, или DLL но не как, так и
передают общий указатель, чтобы пересечь границу.  Я havent пробовал это еще но будет скоро. Плохо вероятно
использовать увеличение общий указатель.  Имен устройств Visual Studio обеспечивает любой tr1 материал?

За осмысловку не отвечаю.


Это сообщение отредактировал(а) andrew_121 - 6.3.2008, 15:49

Спасибо ;)

      

Я заметил, но решил оставить, так, для прикола...

ответ прост - не используйте объекты в интерфейсе dll.
использование здесь сишных строк как раз и есть решение проблемы.

Нет, решение не в этом.
Нужно, чтобы и Exe и DLL использовали один и тот же экземпляр Run-time библиотеки (потому что там живут статические переменные, которые управляют кучей). Т.е. run-time тоже должна быть динамической (и одинаковой для всех модулей - в смысле дебажности и мультитредности). Тогда C-куча будет общая. А так - возникают проблемы, когда удаление происходит не в том модуле, где было выделение памяти, что у тебя, скорее всего и есть.
Второй вариант (менее удобный) - писать так, чтобы создание\удаление гарантированно происходило в одном модуле. Т.е. что-то типа оберток CreateVector\DeleteVector. Собственно, примерно это и написано в приведенной цитате (если читать оригинал).
Естественно, с малыми объектами - замучаешься. Да и использовать для обертки вектора shared-Ptr - масло масленное.  Проще добиться нормальной линковки с Run-Time DLL. 

нет, решение как раз в этом. То, что ты описала частный случай, далеко не всегда реализуемый 
см. первый пост

С объектами всё работало, речь идёт о реализации внутри объекта .

не будет у тебя так организованная dll работать нормально. 
1.В интерфейсе либы нужно использовать переносимые типы (ты же не можешь передать std::vector из С)
2.Нужно избегать выделения и освобождения памяти в разных модулях ( создание std::string и передача из фунции в приложение, где он будет разрушен(ЧПОК!!! из-за разных CRT) )

Принципиально можно сделать так как у тебя, но работать нормально будет только если и приложение и dll собраны одной версией компилятора, с одинаковыми настройками и одними и темиже реализациями используемых либ (STL и пр.) 

Ну всё правильно : у меня string в интрефейсе, поэтому и не работало.

обернуть в класс и вынести его как COM объект если? ("фтопку просто экпорт)").
да и вообще в COM-е были уже "вектора" ....вроде...

Да, это я прощелкала... Тогда действительно только одно - создание\удаление в рамках одного модуля. И вовсе необязательно COM, можно любые доморощенные обертки использовать. Но, очевидно, все это не слишком удобно, поэтому по мелочам лучше граниуц модулей не пересекать (со всякими векторами-стрингами)