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

P>Народ,
P>я вот задумался тут — следует ли забыть про простые DLL и делать все библиотеки на основе COM? Особенно если мне нужно экспортировать из DLL класс, а не функцию?
P>Спасибо.

Проснулся, блин. Все давно забосили КОМ и переходят на дотенет в котором как раз классы из длл-ек и экспортируются. А ты все думаешь переходить ли на ком.

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

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

Условие задачи необходимо читать тщательнее.
Я специально уточнил, что с C работает не только B, а еще и другие объекты.
В случае MTA, B выполняет запросы A к C в другом потоке.
т.е. для C получается, что с ним тоже работают из нескольких потоков, а значит нужна еще одна синхронизация уже для C.
если C общается с D, то и для D нужна синхронизация. Получается, что добавление к системе одного объекта A, работающего из нескольких потоков, привело к тому, что ко всем объектам системы придется добавлять синхронизацию или опять же делать очередь сообщений.

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

P>я вот задумался тут — следует ли забыть про простые DLL и делать все библиотеки на основе COM? Особенно если мне нужно экспортировать из DLL класс, а не функцию?

В рамках одного компилятора — вполне можно обойтись экспортом не-комовских классов.
Пример — клятые MFC.

Ком имеет свои ограничения, делать из него идола я бы поберёгся.

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

P>Народ,
P>я вот задумался тут — следует ли забыть про простые DLL и делать все библиотеки на основе COM? Особенно если мне нужно экспортировать из DLL класс, а не функцию?
P>Спасибо.

не следует.

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

P>Народ,
P>я вот задумался тут — следует ли забыть про простые DLL и делать все библиотеки на основе COM? Особенно если мне нужно экспортировать из DLL класс, а не функцию?
P>Спасибо.

Если так делать то много гемора будет потом. СОМ не самая лучшая технология. Я бы стал ее использовать только когда надо RPC сервер сделать. И то сначала поискалбы альтернативу

аааааааа
госпада модераторы, перенесите пожалуйста в "межпланетный интернет" :+)

Народ,
я вот задумался тут — следует ли забыть про простые DLL и делать все библиотеки на основе COM? Особенно если мне нужно экспортировать из DLL класс, а не функцию?
Спасибо.

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

P>>я вот задумался тут — следует ли забыть про простые DLL и делать все библиотеки на основе COM? Особенно если мне нужно экспортировать из DLL класс, а не функцию?

K>Если так делать то много гемора будет потом. СОМ не самая лучшая технология. Я бы стал ее использовать только когда надо RPC сервер сделать. И то сначала поискалбы альтернативу

Грамотные люди подумали да так и сделали.
Вот что получилось
http://mozilla.org/projects/xpcom/xpcom-intro/xpcom-intro.htm

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

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

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

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

F>а с чего ты взял что свет нельзя обогнать ? его нельзя обогнать в рамках той модели, в которой мы живем )
F>когда люди будут жить на марсе, я думаю появяться такие технологии, которые будут способны опережать время )
F>если основываться на гипотезе, что есть личности, которые могут читать мысли на растоянии, причем делать это в реалтайме, значит они способны считывать некие атрибуты мгновено ) следовательно опережая время )
F>так что думаю не все так плохо )

И как это относится к мега-изобретению XPCOM ?

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

P>Народ,
P>я вот задумался тут — следует ли забыть про простые DLL и делать все библиотеки на основе COM? Особенно если мне нужно экспортировать из DLL класс, а не функцию?
P>Спасибо.

Указатели на интерфейсы экспортируй, самое оно. Почти COM, но без ненужных наворотов

Вероятно, имеется ввиду не указатели, а просто интерфейсы.
У Страуструпа это вроде называется "программирование через интерфейсный класс".

Я щас так и полюбил делать, но засомневался — типа это же COM в чистом виде. Почему бы тогда не использовать COM явно.

p.s. С удововольствием оценил бы, да не получается. Вероятно потому, что запощено Анонимом

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

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

P>>Народ,
P>>я вот задумался тут — следует ли забыть про простые DLL и делать все библиотеки на основе COM? Особенно если мне нужно экспортировать из DLL класс, а не функцию?
P>>Спасибо.

А>Указатели на интерфейсы экспортируй, самое оно. Почти COM, но без ненужных наворотов

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

P>Вероятно, имеется ввиду не указатели, а просто интерфейсы.
P>У Страуструпа это вроде называется "программирование через интерфейсный класс".

Да, именно это и имеется в виду, очень удобно

P>Я щас так и полюбил делать, но засомневался — типа это же COM в чистом виде. Почему бы тогда не использовать COM явно.

Ну, COM, конечно, только проще гораздо. И можно без реестра обходится, грузить длл через LoadLibrary по относительным от рабочей папке путям, а дальше как в коме. Соответственно, деплоймент упрощается — просто копируем и все. К тому же на одно компе можно иметь сколько угодно версий программы, каждая будет со своими длл-ми работать.

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

P>>Я щас так и полюбил делать, но засомневался — типа это же COM в чистом виде. Почему бы тогда не использовать COM явно.

ЗБ>Ну, COM, конечно, только проще гораздо. И можно без реестра обходится, грузить длл через LoadLibrary по относительным от рабочей папке путям, а дальше как в коме. Соответственно, деплоймент упрощается — просто копируем и все. К тому же на одно компе можно иметь сколько угодно версий программы, каждая будет со своими длл-ми работать.

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

Можно сделать так, как в Акробате — если при запуске нет нужных классов, акробат регистрит свои дллки.

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

PE>Грамотные люди подумали да так и сделали.
PE>Вот что получилось
PE>http://mozilla.org/projects/xpcom/xpcom-intro/xpcom-intro.htm
PE>

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

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

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

Ну, насчет многопоточности не совсем понял — чем ей отсутствие COM'а помешает? Она и без него неплохо себя чувствует. А по поводу автоматизации и скриптов, ну, если понадобится, можно же обертку сделать. Я-то говорю про внутреннюю логику, так сказать. Зачем все наружу выносить? Просто не хочется все в одном проекте делать, а так получается очень удобное разбиение по модулям.

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

PE>Можно сделать так, как в Акробате — если при запуске нет нужных классов, акробат регистрит свои дллки.
Можно, конечно. Можно все, просто проще делать через экспорт интерфейсов...ну, в принципе тут все от задачи зависит

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

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

ЗБ>Ну, насчет многопоточности не совсем понял — чем ей отсутствие COM'а помешает? Она и без него неплохо себя чувствует. А по поводу автоматизации и скриптов, ну, если понадобится, можно же обертку сделать. Я-то говорю про внутреннюю логику, так сказать. Зачем все наружу выносить? Просто не хочется все в одном проекте делать, а так получается очень удобное разбиение по модулям.

Это понятно. Но обертки писать дело нелагодарное, если модель изменяется. С многопоточностью тоже есть проблемы — маршалинг придется самому выдумывать.

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

А как ты будеш это делать, если загружаешь модели чз. LoadLibrary ? У нас наример вооще все одинаково для любых плагинов. А ез кома приходится писать базовые механизмы вручную.

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

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

PE>>Грамотные люди подумали да так и сделали.
PE>>Вот что получилось
PE>>http://mozilla.org/projects/xpcom/xpcom-intro/xpcom-intro.htm
PE>>

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

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

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

PE>Это понятно. Но обертки писать дело нелагодарное, если модель изменяется. С многопоточностью тоже есть проблемы — маршалинг придется самому выдумывать.

Ну, для внешних сообщений можно использоавть Remoting, соответственно два уровня интерфейсов, первый используется внутри процесса для сишных модулей, второй применяется для внешних связей, причем они абсолютно независимы.

PE>А как ты будеш это делать, если загружаешь модели чз. LoadLibrary ? У нас наример вооще все одинаково для любых плагинов. А ез кома приходится писать базовые механизмы вручную.

Два разных механизма, один для неуправляемого кода, один для управляемого.

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


PE>Это понятно. Но обертки писать дело нелагодарное, если модель изменяется. С многопоточностью тоже есть проблемы — маршалинг придется самому выдумывать.

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

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

PE>>Это понятно. Но обертки писать дело нелагодарное, если модель изменяется. С многопоточностью тоже есть проблемы — маршалинг придется самому выдумывать.

ЗБ>Ну, для внешних сообщений можно использоавть Remoting, соответственно два уровня интерфейсов, первый используется внутри процесса для сишных модулей, второй применяется для внешних связей, причем они абсолютно независимы.

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


PE>>А как ты будеш это делать, если загружаешь модели чз. LoadLibrary ? У нас наример вооще все одинаково для любых плагинов. А ез кома приходится писать базовые механизмы вручную.

ЗБ>Два разных механизма, один для неуправляемого кода, один для управляемого.

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

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

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

Я виде много проектов, где люи говрили, что COM это фигня и можно без него.
Люди изоретают все механизмы COM, даже не зная об этом.

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

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

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

Хорошо, когда это понятно. А то фанатичные вопли,что "здесь лучше, чем в IE" просто смешны.

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

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

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

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

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

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

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

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


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

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

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

PE>>Я про то и говрю, зачем писать эти механизмы, а не использовать готовые ?
А>Несколько строчек кода. Тем более, зачем NET c COM спрягать?

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

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

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

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

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

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

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

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

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

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

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

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

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

Тут же на лицо банальное воровство идей с заменой названия. По сути описанное и есть КОМ, но под другим названием.

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

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

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

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

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

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

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

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

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

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

Пара строчек

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

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

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

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

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

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

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

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

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


PE>>А как вы нет подключали без COM?
ЗБ>Через MC++, гораздо удобнее, чем через COM

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

Здравствуйте, 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));

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

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

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

PE>>>А как вы нет подключали без COM?
ЗБ>>Через MC++, гораздо удобнее, чем через COM

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

он самый

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

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

Так с этого и начинать то надо.

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

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

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

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

PE>>MC++ — это managed c++ что ли ?
ЗБ>он самый

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

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

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

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

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

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

Кхм...что-то подумалось, что это само-собой разумеется — если есть нет и нативные библиотеки, то нужен MC++ обязательно для связи. Не подумал что-то, что можно и подругому

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

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

В Sta проще решается проблема Deadlock-ов.

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

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

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

Для того, что бы ты вообще мог забыть про синхронизацию этого комика.

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


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

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

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

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

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

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

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



DG>Условие задачи необходимо читать тщательнее.

Условие задачи я понял прекрасно, я его просто изменил.

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


ЗБ>Условие задачи я понял прекрасно, я его просто изменил.

Если мы взаимодействие осуществляем через, скажем так, абстрактный класс (ну, через класс C), и только через него, то добавление в систему любого количества классов не приводит к необходимости добавлять синхронизацию и для них

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



ЗБ>Если мы взаимодействие осуществляем через, скажем так, абстрактный класс (ну, через класс C), и только через него, то добавление в систему любого количества классов не приводит к необходимости добавлять синхронизацию и для них

что-то я не то пишу, читать так:

ЗБ>Если мы взаимодействие осуществляем через, скажем так, абстрактный слой (ну, через класс B), и только через него, то добавление в систему любого количества классов не приводит к необходимости добавлять синхронизацию и для них