Доброго времени суток уважаемые форумчане,
Может кто сталкивался, посоветуйте
Пишу СДК для некоего устройства. Есть набор классов, которые выполняют логику работы, но возникла задача запихнуть всю имплементацию в Длл-ку. Задумка следующая:  Я отделил необходимые пользоавтелю классы от внутренних. Для первых хочу написать абстрактные интерфейсы - и их предоставить пользователю. Из длл-ки експортировать только фабричные методы создания объектов, которые вернут указатели интерфейсам. Хочу линковаться с CRT статически, и здесь возникают трудности - не правильно создавать обект в одном рантайме, а убивать в другом( с методами Release тоже возится неособо хочется... Как альтернативу рассматриавю std::auto_ptr на интерфейс, но не знаю нормально ли его экспортить из длл. Уважаемые знатоки, подскажите пожалуйста - можно ли экспортить из длл фунцию которая возвращает умный указатель... СДК должно исспользоваться с различными компиляторами (в первую очередь различными версиями VS). 
Заранее огромное спасибо откликнувшимся)  

Ненормально. Авто-птр никак не спасет от разрушения объекта где попало. От этого вообще ничто не спасет кроме запрета вызова delete (или деструктора) с заменой спец. функцией DeleteObject, которая гарантированно будет вызывать правильный RunTime (другими словами, тот самый Release). Кроме того, auto_ptr - самый тупой из всех "умных" указателей. Его область применения весьма ограничена: локальные переменные функции. Все остальное может привести к ошибкам, либо нужно тщательно следить за использованием, получив вместо удобства сплошной геморрой. Лучше чем COM-модель для предоставления интерфейсов не придумано. При этом не обязательно использовать системную реализацию COM (IUnknown etc), можно и свой облегченный вариант. Но указатели с подсчетом ссылок - маст хэв, мне кажется

можно, но для этого необходимо запретить "многокучесть" в exe и dll, для этого надо:
1. экспортировать из exe 2 метода, типа MyAlloc и MyFree, которые просто вызывают malloc и free, соответственно
2. переписать в dll операторы new и delete, вызвать из них соответствующий MyAlloc и MyFree импортируемые из exe

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

главное - не пользоваться в DLL прямыми методами malloc и free, максимум - new и delete

Добавлено через 4 минуты и 7 секунд
но конечно, в таком случае параметры сборки dll и exe будут зависимы, т.е. нельзя будет, например: мешать между модулями флаги MTd, MT, MD, MDd и т.п. для STL, ну и все остальное в таком же духе

в этом случае между dll и exe-шником вообще нельзя использовать ни одного stl-класса (даже auto_ptr), т.к. его реализация в компиляторе, в котором собрана dll, может отличаться (и скорее всего отличается) от реализации в компиляторе, в котором собран exe.
Ничего плохого не вижу в виртуальной абстрактной функции Release, которая реализована как delete this;
У меня таких dll-лек довольно много и всё отлично работает. Даже между студией и (прости Господи) дебилдером.Нужно только учесть некоторые вещи:
1) явно указывать тип вызова каждой функции
2) явно указывать размер выравнивания (pragma pack)
3) не делать в интерфейсе перегруженных функций (write(void); write(int); write(double); и т.п.)

ничего того что создается в одном месте, а убивается в другом. Ничего такого экспортировать что используется CRT, RTL.

Это сообщение отредактировал(а) Dem_max - 16.5.2012, 11:50

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


- немного не подходящий вариант)) - речь идет о сдк!!! по этому костыли в виде жесткой связи между приложением и длл-кой вообще идти не может... В любом случае спасибо - вариант переопределить new и delete у меня был, даже попробовал - но это не оч хороший тон)))

3)

 абсолютно согласен, но он в стандарте) Мне самому бустовый шаред по душе больше)) можно конечно свой изгородить и предоставить с сдк - но нехотелось бы)

4)
borisbn, можно по подробнее по поводу выравнивания.

5)



Спасибо конечно ))) так сказать коротко и ясно... но это было описано в вопросе;)
А суть в том как можно извратиться что бы было хорошо)))

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

Всем огромное спасибо за активное участие!!! натолкнули на хорошие мысли) 
всегда приятно услышать мнение коллег))) 

heavix, если ты не понял, то "костыль в виде жесткой связи между приложением и длл-кой" - это и есть использование auto_ptr,
и об этом тебе сказали все, кроме меня,

я лишь показал, как заставить его работать в твоем случае

Представь, что в настройках проекта длл-ки стоит выравнивание на 4, соответственно в виртуальной таблице указатели на функции будут идти через 4 байта. Если же в настройках проекта экзешника будет стоять выравнивание на 8, то в виртуальной таблице указатели на функции будут идти через 8 байт. Чем это чревато - думаю понятно. Поэтому выравнивание лучше задать явно


И ещё раз про auto_ptr. Представь, что в STL, с которым собрана длл-ка он описан как-то так

а в STL, с которым собран экзешник он описан как-то так


Если уж так хочется, чтоб указатель был "умный" - делай его сам (заодно не нужно объяснять автоптру, что нужно вызывать Release, а не деструктор)

borisbn , спасибо за пояснения - сразу просто не совсем понял о чем именно речь)



Я прекрасно понял) И не спрашивал бы на форуме, если бы хотел его применить)
В любом случае спасибо) Сейчас склоняюсь к своей реализации COM.

Собственно как сделано в интерфейсах Windows. 

Оригинально реализовано в cryptopp... Там переопределяются new и delete причем очень оригинально...
получаются их хендлы из рантайма (в независимости от типа линковки...) Причем у них експортится из
длл-ки класс - наследник от std::exception. Сама либа стабильна и работает нормально))) 
элегантность в том что весь интерфейс либы в своем неймспейсе, собственно в нем же и переопределенные new и delete
которые гарантировано грохают объекты созданные в длл - нужным менеджером кучи... В таком случае можно отказаться от 
умного указателя - и оставить на совести пользователя удаление объекта после исспользования... Анализ показал что одну и универсальную
либу для сдк сделать не получится... Так что скорее буду собирать версии для нескольких поддерживаемых компиляторов и рантаймов...