Может кто нибудь посоветует каким образом лучше передать структуру через COM, я пробовал двумя способами (1-VARIANT, 2-SAFEARRAY), все работает нормально, но все же хочется узнать и про другие существующие варианты передачи структуры.

Заранее спасибо.

Здравствуйте Parfenov Denis, Вы писали:

PD>Может кто нибудь посоветует каким образом лучше передать структуру через COM, я пробовал двумя способами (1-VARIANT, 2-SAFEARRAY), все работает нормально, но все же хочется узнать и про другие существующие варианты передачи структуры.
Ну вот тебе еще способ: пишешь 2 функции, одна твою структуру сохраняет в std::ostream, другая — читает из std::ostream. Пишешь
наследника от std::streambuf (или std::basic_streambuf) для работы с IStream и для удобства — специализацию от std::ostream/std::istream для твоего стримбуфера (назовем их пока oolestream/iolestream). Если надо структуру передать через COM, сохраняешь ее в oolestream, через COM передаешь IStream с запиханной в него структурой, на другом конце конструируешь iolestream из IStream, загружаешь структуру. Достоинства и недостатки очевидны.

PD>Заранее спасибо.

Здравствуйте Parfenov Denis, Вы писали:

PD>Может кто нибудь посоветует каким образом лучше передать структуру через COM, я пробовал двумя способами (1-VARIANT, 2-SAFEARRAY),

А зачем VARIANT то? Можно и сами структуры в параметры заносить.

PD>все работает нормально, но все же хочется узнать и про другие существующие варианты передачи структуры.

Можно и на мидловских заглушках. Но это плохое решение:

• Несовместимо со скриптами, VB6, Delphi...
  
• Требует обязательной компиляции и регистрации прокси/стаба на клиенте и сервере.

Выглядит примерно так:

typedef struct 
{
  int fld1;
  int fld2;
} Struct;

...

HRESULT Func1([in] Struct * pStruct);

Массивы можно задавать фиксировано или через size_is.

Подробнее см. раздел по MIDL в MSDN.


PS

Только я лично не советую пользоваться этим способом.

Здравствуйте VladD2, Вы писали:

VD>Выглядит примерно так:

VD>

VD>typedef struct 
VD>{
VD>  int fld1;
VD>  int fld2;
VD>} Struct;

VD>...

VD>HRESULT Func1([in] Struct * pStruct);
VD>

Только в таком случае все поля структуры должны быть "простых" типов.

Здравствуйте Sergey, Вы писали:


S> Ну вот тебе еще способ: пишешь 2 функции, одна твою структуру сохраняет в std::ostream, другая — читает из std::ostream. Пишешь
S>наследника от std::streambuf (или std::basic_streambuf) для работы с IStream и для удобства — специализацию от std::ostream/std::istream для твоего стримбуфера (назовем их пока oolestream/iolestream). Если надо структуру передать через COM, сохраняешь ее в oolestream, через COM передаешь IStream с запиханной в него структурой, на другом конце конструируешь iolestream из IStream, загружаешь структуру. Достоинства и недостатки очевидны.

Нэнавижу!!! У меня в системе один из интерфесов такой. Для тех, кто считает, что недостатки "очевидны", предлагается обдумать установки секьюрити для вызова такого интефейса по DCOM-у через границы домена (т.е. когда клиент и сервер находятся в разных доменах, не связанных отношениями доверительности).

Здравствуйте George_Seryakov, Вы писали:

GS>Здравствуйте Sergey, Вы писали:


S>> Ну вот тебе еще способ: пишешь 2 функции, одна твою структуру сохраняет в std::ostream, другая — читает из std::ostream. Пишешь
S>>наследника от std::streambuf (или std::basic_streambuf) для работы с IStream и для удобства — специализацию от std::ostream/std::istream для твоего стримбуфера (назовем их пока oolestream/iolestream). Если надо структуру передать через COM, сохраняешь ее в oolestream, через COM передаешь IStream с запиханной в него структурой, на другом конце конструируешь iolestream из IStream, загружаешь структуру. Достоинства и недостатки очевидны.

GS> Нэнавижу!!! У меня в системе один из интерфесов такой. Для тех, кто считает, что недостатки "очевидны", предлагается обдумать установки секьюрити для вызова такого интефейса по DCOM-у через границы домена (т.е. когда клиент и сервер находятся в разных доменах, не связанных отношениями доверительности).

Вот такое пока ни разу не делал. И чем же вызов метода такого интерфейса отличается от передачи SAFEARRAY в плане секьюрити, если не секрет?

Здравствуйте VD, Вы писали:

VD>Только в таком случае все поля структуры должны быть "простых" типов.

С чего бы это?

Поля могут быть любых типов поддерживаемых мидл-ом. Массивы естественно должны бить или фиксированной длинны или с длинной заданой через атрибуты size_is/lenght_is.

Здравствуйте VladD2, Вы писали:

VD>С чего бы это?

VD>Поля могут быть любых типов поддерживаемых мидл-ом. Массивы естественно должны бить или фиксированной длинны или с длинной заданой через атрибуты size_is/lenght_is.

Вот об этом я и говорил, поскольку все это достаточно простые типы.

Здравствуйте VD, Вы писали:

VD>Здравствуйте VladD2, Вы писали:

VD>>С чего бы это?

VD>>Поля могут быть любых типов поддерживаемых мидл-ом. Массивы естественно должны бить или фиксированной длинны или с длинной заданой через атрибуты size_is/lenght_is.

VD>Вот об этом я и говорил, поскольку все это достаточно простые типы.

Ну, если масивы, структуры и объеденения являются простыми тимами (!), то что же по твоему является сложными?

Здравствуйте VladD2, Вы писали:

VD>>>Поля могут быть любых типов поддерживаемых мидл-ом. Массивы естественно должны бить или фиксированной длинны или с длинной заданой через атрибуты size_is/lenght_is.

VD>Ну, если масивы, структуры и объеденения являются простыми тимами (!), то что же по твоему является сложными?

Ключевым словом тут является поддерживаемых мидл-ом, т.е. как я понимаю VARIANT-совместимых и их комбинаций. А сложными я бы назвал, например, STL-e типы или MFC-е.

Здравствуйте Sergey, Вы писали:

S>>> Если надо структуру передать через COM, сохраняешь ее в oolestream, через COM передаешь IStream с запиханной в него структурой, на другом конце конструируешь iolestream из IStream, загружаешь структуру. Достоинства и недостатки очевидны.

GS>> Нэнавижу!!! У меня в системе один из интерфесов такой. Для тех, кто считает, что недостатки "очевидны", предлагается обдумать установки секьюрити для вызова такого интефейса по DCOM-у через границы домена (т.е. когда клиент и сервер находятся в разных доменах, не связанных отношениями доверительности).

S> Вот такое пока ни разу не делал. И чем же вызов метода такого интерфейса отличается от передачи SAFEARRAY в плане секьюрити, если не секрет?

Когда передаешь SAFEARRAY нужно дать права на использование только вызываемого объекта. Когда передаешь IStream (объект!), то нужны права и на использование этого объекта. Причем этот самый айстрим может не принадлежать ни к какому приложению, имеющему AppId. В этом случае права даются в дефолтовом секьюрити. Когда домены разные и не связанные доверительностью, все айдентити нужно удваивать. Не сбился? Тогда скажи мне в скольких местах нужно делать настройку, если на клиенте и сервере разные айдентити?

Здравствуйте VD, Вы писали:

VD>Здравствуйте VladD2, Вы писали:

VD>>>>Поля могут быть любых типов поддерживаемых мидл-ом. Массивы естественно должны бить или фиксированной длинны или с длинной заданой через атрибуты size_is/lenght_is.

VD>>Ну, если масивы, структуры и объеденения являются простыми тимами (!), то что же по твоему является сложными?

VD>Ключевым словом тут является поддерживаемых мидл-ом, т.е. как я понимаю VARIANT-совместимых и их комбинаций. А сложными я бы назвал, например, STL-e типы или MFC-е.

Ключевым словом тут является поддерживаемых мидл-ом, т.е. как я понимаю VARIANT-совместимых и их комбинаций. А сложными я бы назвал, например, STL-e типы или MFC-е.

Ну, тогда на бедующее запомни. В COM сложными типами данных называют структуры, объединения и массивы. Короче, описываемые программистом.

STL-e типы и MFC-е (короче, классы), в прочем как и любые другие типы несовместимые с MIDL в COM использоваться не могут, а потому никак и не называются.

Здравствуйте VladD2, Вы писали:

VD>Ну, тогда на бедующее запомни. В COM сложными типами данных называют структуры, объединения и массивы. Короче, описываемые программистом.
Тут мне, наверное, следовало бы спросить тебя об источнике, из которого взято это определение, но я этого делать не буду, поскольку твоя позиция мне понятна.

VD>STL-e типы и MFC-е (короче, классы), в прочем как и любые другие типы несовместимые с MIDL в COM использоваться не могут, а потому никак и не называются.
Я думаю нет никакого смысла в дальнейшем разговоре на эту тему. Мы говорим об одном и том же, но немного разными словами, смысл от этого не меняется — это типа как бегемот и гиппопотам — слова разные, а смысл один.
Т.ч. удачи.

Здравствуйте VD, Вы писали:

VD>Здравствуйте VladD2, Вы писали:

VD>... следовало бы спросить тебя об источнике...

Документация по пидлу и oleautomation.

PS

Проблема терминологии в том, что называя понятия не принятыми словами легко ввести человека в заблуждение или начать спорить на пустом месте. Посмотри постинги Рыбинкина на ixbt...

VD>>Ключевым словом тут является поддерживаемых мидл-ом, т.е. как я понимаю VARIANT-совместимых и их комбинаций. А сложными я бы назвал, например, STL-e типы или MFC-е.

VD>Ключевым словом тут является поддерживаемых мидл-ом, т.е. как я понимаю VARIANT-совместимых и их комбинаций. А сложными я бы назвал, например, STL-e типы или MFC-е.

VD>Ну, тогда на бедующее запомни. В COM сложными типами данных называют структуры, объединения и массивы. Короче, описываемые программистом.

VD>STL-e типы и MFC-е (короче, классы), в прочем как и любые другие типы несовместимые с MIDL в COM использоваться не могут, а потому никак и не называются.

Надо бы вопрос о типах COM|DCOM поместить в QA.. прям раздел назвать типы мидл..