Re[8]: COM vs DLL vs OOP
От: Plutonia Experiment Беларусь http://blogs.rsdn.org/ikemefula
Дата: 12.03.04 11:04
Оценка:
Здравствуйте, Зимнее Безмолвие, Вы писали:

ЗБ>Ты какой маршалинг имеешь в виду? Межапартаментный? Так если COM'а нет, нет и апартаментов...так?

А ты не думал, для чего эти апартменты и маршалинг и тд. ?

Я виде много проектов, где люи говрили, что COM это фигня и можно без него.
Люди изоретают все механизмы COM, даже не зная об этом.
Re[5]: COM vs DLL vs OOP
От: Plutonia Experiment Беларусь http://blogs.rsdn.org/ikemefula
Дата: 12.03.04 11:06
Оценка:
Здравствуйте, AIDS, Вы писали:

VD>>Получился ком в чистом виде. Украдено почти все.


AID>Иногда приходится так делать

AID>Когда продукт многоплатформенный, как у нас — Win32, Win64 (AMD, Itanium), Solaris, Linux, AIX, OS/400, OS/390, BSD, HP-UX, Mac
AID>А ведь хочется удобства и однообразия, а COM — он только под Windows.

Хорошо, когда это понятно. А то фанатичные вопли,что "здесь лучше, чем в IE" просто смешны.
Re[9]: COM vs DLL vs OOP
От: Зимнее Безмолвие Россия  
Дата: 12.03.04 14:04
Оценка:
Здравствуйте, Plutonia Experiment, Вы писали:

PE>А ты не думал, для чего эти апартменты и маршалинг и тд. ?


Хм...вообще, честно говоря, слабо представляю, по-моему для изоляции потоков и обеспечения взаимодействия между потоками с помощью очередей окон, ассоциированных с соответствующим апартаментом. Может, объяснишь на примере, зачем это может понадобится? Чем плохо взаимодействие между потоками без использования апартаментов?

PE>Я виде много проектов, где люи говрили, что COM это фигня и можно без него.

PE>Люди изоретают все механизмы COM, даже не зная об этом.

Мы ничего не изобретали, если только пара строчек кода на изобретение тянут. Видимо не надо было, либо все свои проблемы с помощью других механизмов решали, Net'а, к примеру.
Re[9]: COM vs DLL vs OOP
От: Аноним  
Дата: 12.03.04 14:07
Оценка:
Здравствуйте, Plutonia Experiment, Вы писали:

PE>Параллельные интерфейсы — это очень неслабый геморрой.


Кто сказал параллельные? Внешних интерфейсов на порядок меньше и они практически не пересекаются, это просто еще один уровень абстракции.


PE>Я про то и говрю, зачем писать эти механизмы, а не использовать готовые ?


Несколько строчек кода. Тем более, зачем NET c COM спрягать?
Re[10]: COM vs DLL vs OOP
От: Plutonia Experiment Беларусь http://blogs.rsdn.org/ikemefula
Дата: 12.03.04 16:15
Оценка:
Здравствуйте, Аноним, Вы писали:

PE>>Я про то и говрю, зачем писать эти механизмы, а не использовать готовые ?

А>Несколько строчек кода. Тем более, зачем NET c COM спрягать?

NET со стороны COM виден как COM. COM co строны NET виден как NET. Здесь никаких особых телодвижений и не надо.
Re[10]: COM vs DLL vs OOP
От: Plutonia Experiment Беларусь http://blogs.rsdn.org/ikemefula
Дата: 12.03.04 16:23
Оценка:
Здравствуйте, Зимнее Безмолвие, Вы писали:

ЗБ>Хм...вообще, честно говоря, слабо представляю, по-моему для изоляции потоков и обеспечения взаимодействия между потоками с помощью очередей окон, ассоциированных с соответствующим апартаментом. Может, объяснишь на примере, зачем это может понадобится? Чем плохо взаимодействие между потоками без использования апартаментов?


Окна нужны именно из за синхронизации. Багодаря этому можно писать объекты не заботясь о синхронизации.

Если у тебя будет максимум один поток, никаких скриптовых клиентов, не предусматривается расширения(чтобы внешний объект не был отличим от внутренних), не нужна аутомация, длл всегда лежат в одном месте, версии четко известны, плагины(алгоритмы какие) простецкие — можно и без COM.

Имея COM, любой из вопросов решается очень просто. Да те же плагины и расширения — CoCreateInstance().
Если ты пишешь что то отличное от CoCreateInstance и ей подобных функций — уже есть велосипед.

PE>>Я виде много проектов, где люи говрили, что COM это фигня и можно без него.

PE>>Люди изоретают все механизмы COM, даже не зная об этом.

ЗБ>Мы ничего не изобретали, если только пара строчек кода на изобретение тянут. Видимо не надо было, либо все свои проблемы с помощью других механизмов решали, Net'а, к примеру.


А как вы нет подключали без COM?
Re[5]: COM vs DLL vs OOP
От: VladD2 Российская Империя www.nemerle.org
Дата: 12.03.04 22:47
Оценка:
Здравствуйте, AIDS, Вы писали:

AID>а COM — он только под Windows.


КОМ — это не монолитное и монументальное произведение. КОМ — это набор концепций. Никто не запрещает использовать его ровно настолько насколько это нужно твоим задачам.

Борланд портируя Дельфи на Линукс и МС портируя дотнет на Фришку реализовали необходимую им часть КОМ-а и прекрасно им пользуются.

Тут же на лицо банальное воровство идей с заменой названия. По сути описанное и есть КОМ, но под другим названием.
... << RSDN@Home 1.1.3 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[11]: COM vs DLL vs OOP
От: Зимнее Безмолвие Россия  
Дата: 15.03.04 06:32
Оценка:
Здравствуйте, Plutonia Experiment, Вы писали:

PE>NET со стороны COM виден как COM. COM co строны NET виден как NET. Здесь никаких особых телодвижений и не надо.


Ну и так особых телодвижений не нужно
Re[11]: COM vs DLL vs OOP
От: Зимнее Безмолвие Россия  
Дата: 15.03.04 06:57
Оценка:
Здравствуйте, Plutonia Experiment, Вы писали:

PE>Окна нужны именно из за синхронизации. Багодаря этому можно писать объекты не заботясь о синхронизации.


PE>Если у тебя будет максимум один поток,

Ну, у нас больше чем один поток и что? То же самое, что и MTA, по сути.

>>никаких скриптовых клиентов, не предусматривается расширения(чтобы внешний объект не был отличим от внутренних), не нужна аутомация,

.Net

>>длл всегда лежат в одном месте, версии четко известны,

да

>>плагины(алгоритмы какие) простецкие — можно и без COM.

Непонятна связь, ибо смысл-то один и тот же, что там интерфейсы, что тут интерфейсы, какая разница, как они реализуются?

PE>Имея COM, любой из вопросов решается очень просто. Да те же плагины и расширения — CoCreateInstance().

PE>Если ты пишешь что то отличное от CoCreateInstance и ей подобных функций — уже есть велосипед.

Пара строчек

PE>А как вы нет подключали без COM?


Через MC++, гораздо удобнее, чем через COM
Re[12]: COM vs DLL vs OOP
От: Plutonia Experiment Беларусь http://blogs.rsdn.org/ikemefula
Дата: 15.03.04 07:54
Оценка:
Здравствуйте, Зимнее Безмолвие, Вы писали:

ЗБ>Ну и так особых телодвижений не нужно.


Поделись секретом, как использовать сборку нета из нативной проги, не используя COM.
Re[12]: COM vs DLL vs OOP
От: Plutonia Experiment Беларусь http://blogs.rsdn.org/ikemefula
Дата: 15.03.04 07:57
Оценка:
Здравствуйте, Зимнее Безмолвие, Вы писали:

PE>>Окна нужны именно из за синхронизации. Багодаря этому можно писать объекты не заботясь о синхронизации.


PE>>Если у тебя будет максимум один поток,

ЗБ>Ну, у нас больше чем один поток и что? То же самое, что и MTA, по сути.

Мы говорили про окна сообщений — это STA. Для MTA окна сообщенй не нужны.


PE>>А как вы нет подключали без COM?

ЗБ>Через MC++, гораздо удобнее, чем через COM

MC++ — это managed c++ что ли ?
Re[13]: COM vs DLL vs OOP
От: Зимнее Безмолвие Россия  
Дата: 15.03.04 13:09
Оценка:
Здравствуйте, Plutonia Experiment, Вы писали:


PE>Поделись секретом, как использовать сборку нета из нативной проги, не используя COM.


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


C#
public delegate void ManagedFunction();


MC++

[System::Runtime::InteropServices::DllImportAttribute("kernel32")]
extern "C" int lstrcpyn(ManagedFunction* ,int iEmpty, int iSecondEmpty);

class CUnManaged
{
  public:
    typedef void (*LEAVE_USER)();

    CUnManaged(LEAVE_USER pFunction) : m_pFunction(pFunction)    {};
private:
    LEAVE_USER m_pFunction;
};

__gc class CManaged 
{

  public:

    void ManagedFunction();
};

CManaged __pin* oManaged = new CManaged(); 

ManagedFunction __pin* pManagedFunction = new  ManagedFunction 
            (oManaged, CManaged::ManagedFunction); 

CUnManagedTrackUsers oUnManagedTrackUsers(CUnManagedTrackUsers::LEAVE_USER)lstrcpyn(pManagedFunction,0,0));
Re[13]: COM vs DLL vs OOP
От: Зимнее Безмолвие Россия  
Дата: 15.03.04 13:16
Оценка:
Здравствуйте, Plutonia Experiment, Вы писали:

PE>Мы говорили про окна сообщений — это STA. Для MTA окна сообщенй не нужны.


я к тому, что можно синхронизацию поставить на входные функции, вот и получился STA из, по сути MTA. В смысле, теперь одновременный доступ к объекту невозможен. Разве не так?

PE>>>А как вы нет подключали без COM?

ЗБ>>Через MC++, гораздо удобнее, чем через COM

PE>MC++ — это managed c++ что ли ?


он самый
Re[14]: COM vs DLL vs OOP
От: Plutonia Experiment Беларусь http://blogs.rsdn.org/ikemefula
Дата: 15.03.04 13:38
Оценка:
Здравствуйте, Зимнее Безмолвие, Вы писали:

PE>>Поделись секретом, как использовать сборку нета из нативной проги, не используя COM.

ЗБ>что-то я утратил нить...не пойму. зачем это надо? Вообще, у нас обычно наоборот, надо из Net вызвать

Так с этого и начинать то надо.
Re[14]: COM vs DLL vs OOP
От: Plutonia Experiment Беларусь http://blogs.rsdn.org/ikemefula
Дата: 15.03.04 13:40
Оценка:
Здравствуйте, Зимнее Безмолвие, Вы писали:

PE>>Мы говорили про окна сообщений — это STA. Для MTA окна сообщенй не нужны.


ЗБ>я к тому, что можно синхронизацию поставить на входные функции, вот и получился STA из, по сути MTA. В смысле, теперь одновременный доступ к объекту невозможен. Разве не так?


Все это хорошо. Только зачем синхронизировать объекты, если они STA ?

PE>>MC++ — это managed c++ что ли ?

ЗБ>он самый

Ну... И чего ты раньше этого не сказал ?
Re[15]: COM vs DLL vs OOP
От: Зимнее Безмолвие Россия  
Дата: 15.03.04 14:56
Оценка:
Здравствуйте, Plutonia Experiment, Вы писали:

ЗБ>>я к тому, что можно синхронизацию поставить на входные функции, вот и получился STA из, по сути MTA. В смысле, теперь одновременный доступ к объекту невозможен. Разве не так?


PE>Все это хорошо. Только зачем синхронизировать объекты, если они STA ?


Ну дык...STA — то нет, ибо COM'а нет, приходится самим синхронизировать. Но это же не особенно сложно, точнее вообще особого труда не составляет...Кстати, вот скажи, может знаешь — чем STA с очередью лучше обычного объекта с синхронизацией? Зачем надо было очередь приплетать?

PE>Ну... И чего ты раньше этого не сказал ?


Кхм...что-то подумалось, что это само-собой разумеется — если есть нет и нативные библиотеки, то нужен MC++ обязательно для связи. Не подумал что-то, что можно и подругому
Re[16]: COM vs DLL vs OOP
От: DarkGray Россия http://blog.metatech.ru/post/ogni-razrabotki.aspx
Дата: 15.03.04 15:10
Оценка:
ЗБ>Ну дык...STA — то нет, ибо COM'а нет, приходится самим синхронизировать. Но это же не особенно сложно, точнее вообще особого труда не составляет...Кстати, вот скажи, может знаешь — чем STA с очередью лучше обычного объекта с синхронизацией? Зачем надо было очередь приплетать?

Гарантия, того что каждый объект работает только в своем потоке. В итоге можно четко локализовать границу взаимодействия нескольких потоков.
пример:
допустим объект A вызывает объект B, который вызывает объект C
объект A живет в другом потоке, чем B и C
с объектом C также работает еще несколько других независимых клиентов
если у объекта B Mta-синхронизация, то придется прикручивать и синхронизация для объекта C.
так как взаимодействие B<->C является опасным
в случае, если B — Sta-синхронизация, то взаимодействие B<->C уже является безопасным

В Sta проще решается проблема Deadlock-ов.
Re[16]: COM vs DLL vs OOP
От: Plutonia Experiment Беларусь http://blogs.rsdn.org/ikemefula
Дата: 15.03.04 15:11
Оценка:
Здравствуйте, Зимнее Безмолвие, Вы писали:

PE>>Все это хорошо. Только зачем синхронизировать объекты, если они STA ?


ЗБ>Ну дык...STA — то нет, ибо COM'а нет, приходится самим синхронизировать. Но это же не особенно сложно, точнее вообще особого труда не составляет...Кстати, вот скажи, может знаешь — чем STA с очередью лучше обычного объекта с синхронизацией? Зачем надо было очередь приплетать?


Для того, что бы ты вообще мог забыть про синхронизацию этого комика.
Re[17]: COM vs DLL vs OOP
От: Зимнее Безмолвие Россия  
Дата: 15.03.04 16:31
Оценка:
Здравствуйте, DarkGray, Вы писали:


DG>Гарантия, того что каждый объект работает только в своем потоке. В итоге можно четко локализовать границу взаимодействия нескольких потоков.

DG>пример:
DG>допустим объект A вызывает объект B, который вызывает объект C
DG>объект A живет в другом потоке, чем B и C
DG>с объектом C также работает еще несколько других независимых клиентов

Ну, эта проблема решается за счет того, что к C доступ осуществляется только через B. И синхронизация только для B нужна тогда
Re[18]: COM vs DLL vs OOP
От: Plutonia Experiment Беларусь http://blogs.rsdn.org/ikemefula
Дата: 15.03.04 16:37
Оценка:
Здравствуйте, Зимнее Безмолвие, Вы писали:

DG>>Гарантия, того что каждый объект работает только в своем потоке. В итоге можно четко локализовать границу взаимодействия нескольких потоков.

DG>>пример:
DG>>допустим объект A вызывает объект B, который вызывает объект C
DG>>объект A живет в другом потоке, чем B и C
DG>>с объектом C также работает еще несколько других независимых клиентов

ЗБ>Ну, эта проблема решается за счет того, что к C доступ осуществляется только через B. И синхронизация только для B нужна тогда


Этот случай можно рассматриваь по разному. В самом простом сучае вообще ничего не надо синхронизировать.
Если нужен перформанс — синхронизируй сам.
Все дело в том, что в процессе может быт несколько потоков и разные оъекты будут требовать различного отношения к ним.
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.