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

А>Есть вот такой объект:

А>

А>struct Settings
А>{
А>   uint a;
А>   uint b;
А>   uint c;
А>   std::vector<std::string> strs;
А>};

А>struct SomeDataObject
А>{
А>   std::map<uint, Settings> data;
А>};
А>

А>Нужно в dll расшарить SomeDataObject. Стоит ли вообще тут stl использовать? Или легче все в C-шные массивы загнать?
А>Почитал про проблемы stl+dll..как-то печально стало, а тут еще и shared.

если "расшарить" означает разместить в памяти, разделяемой между различными процессами, то не стоит использовать STL.
с размещением контейнеров STL в расшаренной памяти имеется следующий проблемы:
1. чтобы они выделяли память для элементов и вспомогательных структур в расшаренной памяти.
2. чтобы они использовали указатели, готовые к тому, что данные будут доступны в разных процессах по разным адресам.

теоретически, обе проблемы решаются через свои аллокаторы, если реализация STL будет всегда учитывать тип указателя, заданный аллокатором, и будет производить все выделения/освобождения через аллокатор. практически, это не работает, по крайней мере для STL идущей с MSVC. "правильные" контейнеры STL можно взять в boost::interprocess, там же есть всё остальное для интерпроцессного расшаривания.

С-шные массивы будут работать, если под ними понимать именно С-шныемассивы, а не С-шные указатели, и std::string тоже заменить на С-шный массив.

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