Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Здравствуйте, Andy77, Вы писали:
A>>Может, и силверлайт восстанет из могилы?
НС>Ну, сервелат только несколько реинкарнировал, принципиальных отличий метрошного UI и того что в винфоне от сервелата нет.
Принципиальное отличие одно, работает только в 8-ке и только на метро стороне, и только через маркет.
Основной кайф от Сильверлайта в том что он кроссплатформенный и легко деплоится, а это ветка развития мало того, что остановилась, так еще и всяко рекомендуется ее не использовать.
Из непринципиальных отличий — многие АПИ, которых долго ждали, откатились опять на уровень 3-го сильверлайта
Мне тоже очень хочется реинкарнации сильверлайта, но вериться слабо
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Так и ActiveX, если рукозадость повышенная, тоже тормозов порождает. Никакой особенной специфики у дотнета тут нет. Что же касается джавы, там свои тараканы, с особенностями собственно JVM связанные лишь отчасти.
Конечно тормоза на чем угодно делаются, но почему-то на практике нативные GUI шустрые.
FR>>Ну и надо учитывать новый C++11 который делает программирование на C++ FR>>намного приятней.
НС>Что, и С++11 без Синовского не появился бы?
Нет просто удачно совпало
Но без него вполне возможно что хоть какая-то поддержка C++11 появилась бы в
каком нибудь VS 2015.
Здравствуйте, Евгений Акиньшин, Вы писали:
ЕА>Из непринципиальных отличий — многие АПИ, которых долго ждали, откатились опять на уровень 3-го сильверлайта
А так оно и будет если вместо нормального WPF изобретать очередной имитатор.
Здравствуйте, FR, Вы писали:
FR>Не вижу такого в С++/CLI там просто обертка + синтаксический сахар над типами CLR. FR>GC там никак ни отключается.
Т.е. между new и gcnew никакой разницы, по твоему, нет?
FR>C++/CX да похож, но по сути это такая же сахарная обертка над COM которая давно FR>существует для других нативных языков, например для Delphi или VB (не NET).
Так C++/CX это и есть тот самый инноваций, который Синовский протолкнул.
НС>>Что конкретно тебя смущает? GC кучи отдельно, нативные кучи отдельно. Для взаимодействия их между собой есть соответствующие механизмы. FR>Вот эти механизмы и смущают. Счетчик ссылок позволяет обходится без них.
Ничего не понял. Тебе никто не мешает внутри CLR использовать твой любимый счетчик ссылок для объектов из нативной кучи.
НС>>Через переходники. Таким манером и какая нибудь CORBA тоже с ними совместима. FR>Так тут не понял, почему тогда пишут что WinRT вызов из NET будет гораздо FR>дешевле чем более старые методы вызова натива?
уважаемый, если все перечисленные вами пункты вам нравятся, и вы с удовольствием
используете COM, то это не значит что у всех есть куча времени бегать по граблям.
COM — неплохая технология для 90х, но для 201х — уже плохая.
кроме того, советую все-таки попробовать пописать многопоточные приложения с обилием COM-а.
Вот вы представляете себе чем threading model 'Free Threaded' отличается от 'Both', и в каких случаях
нужен FreeThreadedMarshaller?
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Здравствуйте, Ночной Смотрящий, Вы писали:
НС>>Но дело, как я уже говорил, вовсе не в WinRT. WinRT сам по себе, в принципе, не так уж и ужасен, хоть и не шедевр. Проблема в другом — Синовский вел себя как носорог — кидался на все, что не соответсвовало его представлениям о прекрасном. Истории с Реем Оззии или совсем свежая с Гатри — ты как, считаешь что это нормально, такое поведение со стороны второго человека в компании? По мне так нет.
ГВ>Что-то у меня складывается обратное впечатление, что он чуть ли не единственный адекватный руководитель в MS:
Да, ладно — может он там классный технарь, но руководитель компании из него хуже некуда. Он за последние пару лет сделал все чтобы уничтожить сообщество лояльных разработчиков МС. История с Сильверлайтом не единственная, но самая показательная — никогда раньше не видел, чтобы компания сама топила новую, феноменально успешную технологию, несмотря на протесты клиентов в угоду личным предпочтениям. Причем делалось это очень демонстративно — типа "а хрен вы куда денетесь". Причем жесткая компания по утоплению сильверлайта началась практически сразу после интервью с Гатри, где он буквально клялся, что все будет развиваться.
По мне так то, что избавились от Синофского, лучшая новость о Микрософте для разработчиков
Здравствуйте, FR, Вы писали:
FR>Конечно тормоза на чем угодно делаются, но почему-то на практике нативные GUI шустрые.
На моей практике почему то шустрость не зависит от нативности.
FR>Но без него вполне возможно что хоть какая-то поддержка C++11 появилась бы в FR>каком нибудь VS 2015.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Здравствуйте, Евгений Акиньшин, Вы писали:
ЕА>>Из непринципиальных отличий — многие АПИ, которых долго ждали, откатились опять на уровень 3-го сильверлайта
НС>А так оно и будет если вместо нормального WPF изобретать очередной имитатор.
Хотя в WPF другая проблема — плохой перфоманс и большая прожорливость на слабых машинах. В WinRT мне хоть и пришлось костылей нагородить, зато даже на совсем слабом железе вполне шустренько все работает
Здравствуйте, Ночной Смотрящий, Вы писали:
FR>>Не вижу такого в С++/CLI там просто обертка + синтаксический сахар над типами CLR. FR>>GC там никак ни отключается.
НС>Т.е. между new и gcnew никакой разницы, по твоему, нет?
И как без gcnew мне сделать экземпляр System.String например?
FR>>C++/CX да похож, но по сути это такая же сахарная обертка над COM которая давно FR>>существует для других нативных языков, например для Delphi или VB (не NET).
НС>Так C++/CX это и есть тот самый инноваций, который Синовский протолкнул.
C++/CX лишь часть притом косметическая, при желании можно и без него под
WinRT писать, хотя с ним конечно намного приятней должно быть, но тут я пока
теоретик больше.
FR>>Вот эти механизмы и смущают. Счетчик ссылок позволяет обходится без них.
НС>Ничего не понял. Тебе никто не мешает внутри CLR использовать твой любимый счетчик ссылок для объектов из нативной кучи.
Мы с разных сторон смотрим. Меня больше интересует удобство использования компонентов
из нативного кода и написание компонентов на нативном коде.
Счетчик ссылок позволяет это делать прозрачно, с GC придется учитывать
кучу особенностей, хотя возможно я недооцениваю сахар из C++/CLI но из
опыта написания расширений к OCaml (язык с GC) на C/C++ есть куча нюансов.
FR>>Так тут не понял, почему тогда пишут что WinRT вызов из NET будет гораздо FR>>дешевле чем более старые методы вызова натива?
НС>Все зависит от того, что это за вызов.
Здравствуйте, Константин Л., Вы писали:
КЛ>Здравствуйте, michae1, Вы писали:
КЛ>[]
КЛ>уважаемый, если все перечисленные вами пункты вам нравятся, и вы с удовольствием КЛ>используете COM, то это не значит что у всех есть куча времени бегать по граблям. КЛ>COM — неплохая технология для 90х, но для 201х — уже плохая.
Вопрос не в том нравиться мне или нет (мне нравиться и у меня нет с COM-м проблем), а в том что аргументы hi_octane необоснованы и смешны. Я попытался обяснить почему.
КЛ>кроме того, советую все-таки попробовать пописать многопоточные приложения с обилием COM-а. КЛ>Вот вы представляете себе чем threading model 'Free Threaded' отличается от 'Both', и в каких случаях КЛ>нужен FreeThreadedMarshaller?
Опыт работы с COM у меня неплохой, но с такими задачами я не сталкивался, хотя спасибо за вопрос — почитал.
Я только не понял, что ж это доказывает и как относиться к теме, что разработка многопоточных приложений сложное занятие? Да, это и так понятно. Или что COM предлагает сложное решение? ну дык и задача непростая. С другой стороны какое альтернативное решение такой задачи (без COM)?
M>Вот как, на кого же она ориентирована? Ну и перечисли тогда уже технологии ориентированные на программистов, очень интересно послушать.
Она ориентирована на кого-то кто заранее знает всё о разрабатываемой системе и не совершает ошибок. Но явно это не программисты. Возможно даже вообще не люди.
M>Успешность технологии зачастую проверяется временем, COM — долгожитель, хорошо зарекомендовавший себя в различных по сложности программах. Это не значит, что его нужно пихать куда только можно, но зачастую решения на базе COM превносят в программу модульность, делают ее менее монолитной, легко масштабируемой + не будем забывать о таких приятных вещах как инкапсуляция кода и возможность взаимодействия с компонентами разработанными на других языках, том же .Net.
Успешность технологии определяется тем насколько быстро её идеи заимствуют другие. То сколько времени технология прожила это скорее к тому насколько качественно MS поддерживает свои API.
_>>Абсолютно все ошибки выносятся в рантайм. Вот получил ты IUnknown — что он может — ты не знаешь, документация врёт, автокомплит молчит. Вот пишешь ты реюзабельный компонент, какой IХренЗнаетЧто обязательно поддержать чтобы всё завелось способа узнать нету. А неудачный каст для многих приложений — тупо ошибка в рантайм. Кодами возврата HR пользуются только в самой MS, все остальные только S_OK, и E_FAIL. Стэктрэйса ошибки нету, сиди думай на входе там сфэйлилось, или глубоко зашло. Забытый AddRef — утечка памяти, лишний Release — случайный прострел, с этого момента всё может сыпаться случайным образом, а может и дальше работать.
M>Много буков, мало смысла
Ну давай по-другому. Смысл каких слов тебе непонятен?
M>Складывается впечатление, что ты дааааааалек от темы.
Чёрт. Я не хотел переводить стрелки на себя.
M>1) Что значит "документация врет"? Открой для себя OleView или директиву #import
Какую-бы директиву открыть, чтобы реализуя IOleClientSite узнать что ещё конкретно должен поддерживать мой IOleContainer когда хостишь IE? А в дизайн-моде?
M>2) "получил ты IUnknown — что он может — ты не знаешь, ...," — он может вернуть тебе нужный интерфейс
Спасибо кэп. А какой интерфейс мне нужен я могу узнать только из документации. Для сравнения — доброй половиной API java, .net, или даже забвенных VB6 или Delphi реально пользоваться вообще имея только поверхностные представления о теме и посматривая на то что предлагает автокомплит.
M>3) "автокомплит молчит" — я чего-то не понял или ты полсыаешь лучи поноса IntelliSense-y
Я посылаю лучи поноса самой идее. А то что потом IntelliSense не работает из-за того что не может найти информацию о фактическом типе объектов ни в компайл-тайме ни в отладчике — это следствие.
M>4) "Кодами возврата HR пользуются только в самой MS, все остальные только S_OK, и E_FAIL" — рукалицо) открою тебе страшную тайну, HRESULT предоставляет диапазон для кастомных ошибок, а такие интерфейсы как IErrorInfo... позволяют получить текстовую информацию. (конечно это должно поддерживаться используемым com_объектом). Не нравиться HRESULT юзай _com_ptr_t
Выделил существенное. Увы люди не идеальны, и если что-то может быть не сделано — сразу готовься к тому что так и будет. В тех же .net-ах, даже словив самый общий Exception я могу хотябы посмотреть откуда оно прилетело и локализовать ошибку.
M>5) "Забытый AddRef — утечка памяти" — используй смарт поинтеры и не думай об этом вообще — _com_ptr_t и CComPtr к твоим услугам.
Ой ли. Кучу раз встречался с однотипной ситуацией — есть иерархия объектов. Умный смартпойнтер делает Release корню, а он грохает всё что в него было вложено игнорируя их счётчики. Логика у иерархии такая, что без корня ничё работать не будет. Люди писали. Всё, крутись как хочешь. Либо ссылку на корень за собой таскай, либо сохрани её в надёжном месте. В итоге вместо облегчения слежения за временем жизни мы получаем усложнение. Формально это проблема библиотеки, но причина её — COM, а решать её мне.
Скажешь не используй кривые библиотеки, а я скажу, ещё года два назад даже MS-овский DirectX 9 при работе с SwapChain именно так себя и вёл. Сейчас как не знаю, потому что другими делами занят, но не думаю что сильно лучше.
_>>Да, когда документация врёт...
M>Имхо, диагноз такой: ты не разобрался в теме, зато немного понаступав на грабли кричишь громче всех, что COM — гавно. У этой технологии есть болезни, как и у любой другой, но с её помощью уже сделали и продолжают делать сложные и качесвтенные продукты.
Обожаю священные войны! И без заглядывания в MSDN ручками, без ATL, через IConnectionPoint событие протяну если дело до писькомера дойдёт Так что разобрался будь здоров. Только вот удовольствия от того что разобрался как-то не получил значит субьективно, для меня, как для программиста, технология хреновая.
Здравствуйте, hi_octane, Вы писали:
M>>Вот как, на кого же она ориентирована? Ну и перечисли тогда уже технологии ориентированные на программистов, очень интересно послушать. _>Она ориентирована на кого-то кто заранее знает всё о разрабатываемой системе и не совершает ошибок. Но явно это не программисты. Возможно даже вообще не люди.
Ни о чем.
Я так понимаю тебе не нравиться необходимость поддержки старых интерфейсов: IMyInterface, IMyInterface2...? Но в этом нет ничего плохого, более того это обязательное условие для любой публичной сущности: библиотеки, API, COM-объекта. Это даёт гаратнии, что через полгода супер-герой не наменяет все и вся и N-е количество программ завязанных на твой объект перестанут рабоать.
Ну а с точки зрения проектирования, COM-объект — черный ящик, предоставляет тебе конкретные интерфейсы, ты же имплементишь взаимодейтвие модулей. Что не так?
M>>Успешность технологии зачастую проверяется временем, ... _>Успешность технологии определяется тем насколько быстро её идеи заимствуют другие. То сколько времени технология прожила это скорее к тому насколько качественно MS поддерживает свои API.
Это скорее успешность идеи, а не технологии. Технология — не зависит от платформы и реализации, она описывает способы взаимодействия и представления, а тех. детали могут отличаться в разных системах. Посмотри на COM, в основе технологии описания посредством интерфейсов, подсчет ссылок, вводиться такое понятие как маршалинг и механизм получения объектов по идентификаторам CLSID... то есть общие понятия, все это вполне реализуемо не только в Windows.
M>>1) Что значит "документация врет"? Открой для себя OleView или директиву #import _>Какую-бы директиву открыть, чтобы реализуя IOleClientSite узнать что ещё конкретно должен поддерживать мой IOleContainer когда хостишь IE? А в дизайн-моде?
Ну открой для себя msdn, stackoverflow, google наконец
Чего пенять на всю технологию, если обжегся на IE? С другой стороны, посмотри на описание объектной модели офиса — все четко описано, пусть и не очень подробно.
M>>2) "получил ты IUnknown — что он может — ты не знаешь, ...," — он может вернуть тебе нужный интерфейс _>Спасибо кэп. А какой интерфейс мне нужен я могу узнать только из документации. Для сравнения — доброй половиной API java, .net, или даже забвенных VB6 или Delphi реально пользоваться вообще имея только поверхностные представления о теме и посматривая на то что предлагает автокомплит.
А как иначе? Откуда прога знает что ты хочешь? Или ты хочешь работать в стиле "дай мне то не знаю что"? так только в сказках
M>>4) "Кодами возврата HR пользуются только в самой MS, все остальные только S_OK, и E_FAIL" — рукалицо) открою тебе страшную тайну, HRESULT предоставляет диапазон для кастомных ошибок, а такие интерфейсы как IErrorInfo... позволяют получить текстовую информацию. (конечно это должно поддерживаться используемым com_объектом). Не нравиться HRESULT юзай _com_ptr_t _>Выделил существенное. Увы люди не идеальны, и если что-то может быть не сделано — сразу готовься к тому что так и будет. В тех же .net-ах, даже словив самый общий Exception я могу хотябы посмотреть откуда оно прилетело и локализовать ошибку.
и что? как недоработка того или иного COM-объекта кидает тень на технологию? Таже ситуация может быть с любой библиотекой.
M>>5) "Забытый AddRef — утечка памяти" — используй смарт поинтеры и не думай об этом вообще — _com_ptr_t и CComPtr к твоим услугам. _>Ой ли. Кучу раз встречался с однотипной ситуацией — есть иерархия объектов. Умный смартпойнтер делает Release корню, а он грохает всё что в него было вложено игнорируя их счётчики. Логика у иерархии такая, что без корня ничё работать не будет. Люди писали. Всё, крутись как хочешь. Либо ссылку на корень за собой таскай, либо сохрани её в надёжном месте. В итоге вместо облегчения слежения за временем жизни мы получаем усложнение. Формально это проблема библиотеки, но причина её — COM, а решать её мне.
Ничего не понял, иерархия чего? Опиши подробней.
M>>Имхо, диагноз такой: ты не разобрался в теме, зато немного понаступав на грабли кричишь громче всех, что COM — гавно. У этой технологии есть болезни, как и у любой другой, но с её помощью уже сделали и продолжают делать сложные и качесвтенные продукты.
_>Обожаю священные войны! И без заглядывания в MSDN ручками, без ATL, через IConnectionPoint событие протяну если дело до писькомера дойдёт Так что разобрался будь здоров. Только вот удовольствия от того что разобрался как-то не получил значит субьективно, для меня, как для программиста, технология хреновая.
Рад за тебя ты — монстр, еще бы IConnectionPoint да еще и без ATL
А удовольствие обычно от результата, может результат неочень?
M>Я так понимаю тебе не нравиться необходимость поддержки старых интерфейсов: IMyInterface, IMyInterface2...? Но в этом нет ничего плохого, более того это обязательное условие для любой публичной сущности: библиотеки, API, COM-объекта. Это даёт гаратнии, что через полгода супер-герой не наменяет все и вся и N-е количество программ завязанных на твой объект перестанут рабоать.
Версионность тут не причём. Люди пишут программы с ошибками. Особенно много ошибок в то время когда программа только разрабатывается. Т.е. человек не знает ещё что он собирается вызывать, ещё не знает что будут вызывать у него, не знает что можно передавать а что нет. И COM только усложняет этот этап. Если бы сразу ввели в стандарт требования на документирование самим IUnknown поддерживаемых им интерфейсов и методов, всё было бы в тысячи раз проще. И Ole Automation изобретать не пришлось бы.
Но если хочется обсудить версионность, то вот выходит новая винда. Я хочу посмотреть что же нового может предложить новый Shell. Без документации не посмотреть IКакой# мне надо создать чтобы получить доступ к новым фичам. И какие это будут фичи тоже не узнать.
M>Ну а с точки зрения проектирования, COM-объект — черный ящик, предоставляет тебе конкретные интерфейсы, ты же имплементишь взаимодейтвие модулей. Что не так?
А то что чёрным ящиком должна быть только реализация. А в случае с COM чёрным ящиком является вообще всё. Что этот объект может, к чему ещё его можно скастить, какие методы у него будут если он успешно скастится к чему-то ещё.
_>>Успешность технологии определяется тем насколько быстро её идеи заимствуют другие. То сколько времени технология прожила это скорее к тому насколько качественно MS поддерживает свои API. M>Это скорее успешность идеи, а не технологии. Технология — не зависит от платформы и реализации, она описывает способы взаимодействия и представления, а тех. детали могут отличаться в разных системах. Посмотри на COM, в основе технологии описания посредством интерфейсов, подсчет ссылок, вводиться такое понятие как маршалинг и механизм получения объектов по идентификаторам CLSID... то есть общие понятия, все это вполне реализуемо не только в Windows.
Ну то есть идея такая плохая что больше никто у себя подобное реализовать не захотел, а технология построенная на этой идее хорошая? А может закономерно — хреновую идею уже никакая реализация не спасёт?
_>>Какую-бы директиву открыть, чтобы реализуя IOleClientSite узнать что ещё конкретно должен поддерживать мой IOleContainer когда хостишь IE? А в дизайн-моде? M>Ну открой для себя msdn, stackoverflow, google наконец
Я понял, да, обязательно. А от себя могу осторожно посоветовать ещё diff между файлами старого и нового SDK, иногда помогает
M>Чего пенять на всю технологию, если обжегся на IE? С другой стороны, посмотри на описание объектной модели офиса — все четко описано, пусть и не очень подробно.
Офис? А видел как оттестированный в ActiveX Control Test Container контрол, ведёт себя совсем по другому в Word, по третьему в Excel, и совсем не позволяет себя вставить в PowerPoint? Ведь тот же COM, что ж опять всё не так-то. А им оказывается какой-то очередной I***Site* понадобился, и на его нехватку они реагируют кто как.
M>А как иначе? Откуда прога знает что ты хочешь? Или ты хочешь работать в стиле "дай мне то не знаю что"? так только в сказках
Да в этом стиле куча народу работает. Надо получить размер окна. Есть объект скажем Window, нажимают ., смотрят — какие методы есть. Вбивают наугад Size, есть — хорошо, попались сразу два ClientSize, OuterSize — выбираем который подходит, нет ни одного — поищем тем же способом что-нибудь с Rect, нашлось — отлично, нет — поищем какой-нить Manager, может он знает, и т.д. А в стиле COM — есть объект IWindow, методов всего пара штук, все остальные описаны у IWindow3 скажем, про IWindow3 ты узнаешь только в документации, если есть. А если метод Size описан у какого-нить ISizeableHostedControl, то простым поиском по Window ты его вообще не найдёшь. Отличная технология для программистов.
M>>>4) "Кодами возврата HR пользуются только в самой MS, все остальные только S_OK, и E_FAIL" — рукалицо) открою тебе страшную тайну, HRESULT предоставляет диапазон для кастомных ошибок, а такие интерфейсы как IErrorInfo... позволяют получить текстовую информацию. (конечно это должно поддерживаться используемым com_объектом). Не нравиться HRESULT юзай _com_ptr_t _>>Выделил существенное. Увы люди не идеальны, и если что-то может быть не сделано — сразу готовься к тому что так и будет. В тех же .net-ах, даже словив самый общий Exception я могу хотябы посмотреть откуда оно прилетело и локализовать ошибку.
M>и что? как недоработка того или иного COM-объекта кидает тень на технологию? Таже ситуация может быть с любой библиотекой.
Это недоработка самой технологии. Типизация объектов подразумевается, но получить информацию о типах нельзя. Возможность ошибок подразумевается, но оставляется возможность для возврата пустого E_FAIL. Версионность подразумевается, но работа с нею отдана на откуп тем же несовершенным людям. Я же говорю — она рассчитана на тех программистов которых нету. Идеальных, всегда точно реализующих и документирующих весь функционал, реализующих все опциональные интерфейсы, ничего не забывающих и поддерживающих документацию в точнейшем соответствии с кодом. Но если сократить это до "не программисты. возможно даже вообще не люди." — то ты сделаешь вид что не в теме и напишешь "ни о чём"
M>>>5) "Забытый AddRef — утечка памяти" — используй смарт поинтеры и не думай об этом вообще — _com_ptr_t и CComPtr к твоим услугам. _>>Ой ли. Кучу раз встречался с однотипной ситуацией — есть иерархия объектов. Умный смартпойнтер делает Release корню, а он грохает всё что в него было вложено игнорируя их счётчики. Логика у иерархии такая, что без корня ничё работать не будет. Люди писали. Всё, крутись как хочешь. Либо ссылку на корень за собой таскай, либо сохрани её в надёжном месте. В итоге вместо облегчения слежения за временем жизни мы получаем усложнение. Формально это проблема библиотеки, но причина её — COM, а решать её мне.
M>Ничего не понял, иерархия чего? Опиши подробней.
Объект, создаёт вложенные объекты, много. Дальнейший алгоритм работает только с вложенными, посему ссылка на корень успешно грохается смарт-пойнтером при выходе, вложенные тут же умирают, потому что по логике реализации библиотеки они не имеют смысла без корня. А корень умирает — потому что COM требует удаления объекта. Все делают свою работу честно, и заметь, даже циклических ссылок нет. А ошибка есть. Посколько крайнего не найти, всё валим на COM
M>А удовольствие обычно от результата, может результат неочень?
А у тебя на что больше времени уходит, на программирование, или на созерцание результата?
Здравствуйте, michae1, Вы писали:
M>Здравствуйте, Константин Л., Вы писали:
КЛ>>Здравствуйте, michae1, Вы писали:
КЛ>>[]
КЛ>>уважаемый, если все перечисленные вами пункты вам нравятся, и вы с удовольствием КЛ>>используете COM, то это не значит что у всех есть куча времени бегать по граблям. КЛ>>COM — неплохая технология для 90х, но для 201х — уже плохая.
M>Вопрос не в том нравиться мне или нет (мне нравиться и у меня нет с COM-м проблем), а в том что аргументы hi_octane необоснованы и смешны. Я попытался обяснить почему.
пока смешно то, что ты пишешь ты.
КЛ>>кроме того, советую все-таки попробовать пописать многопоточные приложения с обилием COM-а. КЛ>>Вот вы представляете себе чем threading model 'Free Threaded' отличается от 'Both', и в каких случаях КЛ>>нужен FreeThreadedMarshaller?
M>Опыт работы с COM у меня неплохой, но с такими задачами я не сталкивался, хотя спасибо за вопрос — почитал.
M>Я только не понял, что ж это доказывает и как относиться к теме, что разработка многопоточных приложений сложное занятие? Да, это и так понятно. Или что COM предлагает сложное решение? ну дык и задача непростая. С другой стороны какое альтернативное решение такой задачи (без COM)?
Здравствуйте, Константин Л., Вы писали:
M>>Вопрос не в том нравиться мне или нет (мне нравиться и у меня нет с COM-м проблем), а в том что аргументы hi_octane необоснованы и смешны. Я попытался обяснить почему.
КЛ>пока смешно то, что ты пишешь ты.
Ну расскажи что тебя так рассмешило? То что c COM-м можно вполне комфортно себя чувствовать, задумайся аж в 2012 году? Блин, мне еще и с++ нравиться, я забыл что у нас 2012 год и это немодно
КЛ>не вижу смысла отвечать
Здравствуйте, michae1, Вы писали:
M>Здравствуйте, Константин Л., Вы писали:
M>>>Вопрос не в том нравиться мне или нет (мне нравиться и у меня нет с COM-м проблем), а в том что аргументы hi_octane необоснованы и смешны. Я попытался обяснить почему.
КЛ>>пока смешно то, что ты пишешь ты.
M>Ну расскажи что тебя так рассмешило? То что c COM-м можно вполне комфортно себя чувствовать, задумайся аж в 2012 году? Блин, мне еще и с++ нравиться, я забыл что у нас 2012 год и это немодно
то, что ты пару раз за карьеру подергал STA объекты, и уже мнишь себя экспертом. а про моду это не ко мне. да, в 2012 RAD и COM друг с другом не уживаются.
если это для тебя новость, советую расширить кругозор
КЛ>>не вижу смысла отвечать
M>было бы что сказать
я уже все сказал. вот когда надо будет написать многопоточный COM-exe сервер с UI из IE/Shell, тогда вспомнишь мои слова.
