Так, главные вопросы опять проигнорированы. Показательно.
LC>>>.NET навязывает всем свою систему типов. НС>>WinRT тоже. LC>Ну почитайте хотя бы какие-то обзорные статьи
Думать, что если кто то с тобой не согласен, потому что он какие то статьи не почитал — это не от большого ума.
LC>Про то, что WinRT предоставляет language independent types.
Давай конкретно — что позволяет система типов WinRT, чего не позволяет CLR (не путать с CLI)?
LC>>>Соответственно, среда должна позволять ручное управление памятью, там, где это нужно. НС>>И CLR (не путать с C#), внезапно это позволяет. LC>А ты знаешь, как оно внутри это работает? Я вот, знаю
Ты, надеюсь, не думаешь что ты такой один?
НС>>Они не просто жабу выбрали, они сваяли уродский недоделанный Далвик. LC>Они написали отличную реализацию Java
Здравствуйте, FR, Вы писали:
НС>>Внутре CLR можно managed кучу и не использовать. FR>И после этого резко ограничить доступные от CLR возможности.
Например?
FR>Хоть массивами то будет возможно пользоваться?
Да чем угодно. WinRT это ж не рантайм, а API. Ровно так же никто не мешает использовать от CLR только компонентную часть. Можно даже было формально отделить ее, чтобы не тащить за собой ненужные вещи (работы было бы сильно меньше, чем добавление поддержки WinRT в один только CLR). Но нет, надо было вместо унификации сделать херовину, не совместимую ни с CLR, ни с СОМ, да еще и с несовместимыми исполняемыми файлами, а потом плодить для нее кучу переходников и перепиливать пачку компиляторов.
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>А дальше — это надо обладать всем массивом информации, которым располагает директорат МС.
Этого недостаточно.
ГВ> Мне это недоступно, звиняй.
О чем тогда ты споришь? О том, что Синовский умеет выпускать очень сложный продукт строго в срок и с приемлемым качеством? Так с этим никто и не спорит.
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>>>С моей колокольни — он выигрышном положении перед Windows, потому что не собирается кардинально меняться ради "выигрывания битв" НС>>Да что ты. В линухах изменений не в пример больше, нежели в винде. Погляди, к примеру, на самый популярный линух — убунту. Одно только юнити перекрывает все нововведения семерки в разы.
ГВ>При чём тут Unity?
При том что это прекрасный пример того, как линух "не собирается кардинально меняться ради "выигрывания битв".
ГВ>Однако, никто же не собирается делать managed-ядро для Линукса
А что, кто то собирается делать managed ядро Windows?
ГВ> и объявлять, скажем, пайпы "устаревшими" и "ну их на фиг". Вроде бы — не собирается.
Ну вот, к примеру, DCOP как, устаревшим не считается?
_>>А то глубоко оно зашло или нет проверял (гусары молчать!) по мультимедиа таймеру КЛ>это как?
А вот так. Ожидалась довольно продолжительная работа, а оно вылетало вместо того с E_NOINTERFACE. Какой интерфейс, кому нужен, зачем — хрен узнаешь. После долгих попыток угадать по астральным картам документации понизил частоту компа, включил таймер, и отключая у себя поддержку всяких IXyz смотрел через сколько оно вылетает с ошибкой. Типа там без IObjectWithSite через 10мс, без какого-то ещё через 12, а с моей проблемой где-то через 18мс. Понятно непредсказуемые разбежки туда-сюда, но локализовать место и проблемный интерфейс всё-таки удалсь.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>>>Внутре CLR можно managed кучу и не использовать. FR>>И после этого резко ограничить доступные от CLR возможности.
НС>Например?
Например без GC мы можем использовать строки, массивы, да и любые объекты?
Подозреваю что нет, остаются только примитивные типы, чем это лучше обычного
нативного ассемблера или низкоуровневой VM типа llvm?
FR>>Хоть массивами то будет возможно пользоваться?
НС>Да чем угодно. WinRT это ж не рантайм, а API. Ровно так же никто не мешает использовать от CLR только компонентную часть. Можно даже было формально отделить ее, чтобы не тащить за собой ненужные вещи
Вот это и нужно было делать сразу 10 лет назад.
Но все равно непонятно как стыковать GC с нативным кодом. Думаю в результате придется и его
отстыковывать и заменять на более автономный вариант, то есть со счетчиком ссылок скорее всего,
в результате получим плюс — минус тот же WinRT.
НС>(работы было бы сильно меньше, чем добавление поддержки WinRT в один только CLR). Но нет, надо было вместо унификации сделать херовину, не совместимую ни с CLR, ни с СОМ, да еще и с несовместимыми исполняемыми файлами, а потом плодить для нее кучу переходников и перепиливать пачку компиляторов.
Тут я не понял WinRT же и с COM и с CLR совместимо.
Здравствуйте, Aлeкceй, Вы писали:
НС>>Прояснится, имхо, где то к весне. Кое что постараюсь узнать на техэде, но вряд ли стоит ожидать какой то конкретики так рано. A>А когда он?
Здравствуйте, FR, Вы писали:
НС>>И много из винды натива успели вытеснить?
FR>Так не осилили
А пытались?
FR>перед выходом висты было море обещаний.
Там не только про managed обещали, только и native фич там тоже из обещанного почти нет.
FR>Но переключив все ресурсы на NET
Это утверждение нуждается в доказательствах.
FR>Притом я считаю что такое развитие натива и для NET было бы очень полезно.
Чем конкретно? Тем что пришлось убухать кучу ресурсов на допиливание почти уже померших компиляторов VB и C# для поддержки WinRT, отняв их у Розлина? Тем, что CLR&Framework team в очередном релизе, вместо кучи важных вещей занималась в основном поддержкой WinRT? Обалденная польза, ничего не скажешь.
Здравствуйте, FR, Вы писали:
FR>Еще я не говорю что NET ненужен
Но подразумеваешь
FR>нужен но для компонентов натив во многих случаях лучше
Для каких компонентов?
FR>, так вот только за то что компоненты как для натива так и FR>для нет должны были бы с самого начала легко делатся как на нативе так и FR>на NET меня записывают в менеджедненавистники
Ты думаешь, что с введениеми WinRT простота создания компонентов на C++/CX станет такой же, как на шарпе?
Здравствуйте, FR, Вы писали:
FR>Например без GC мы можем использовать строки, массивы, да и любые объекты?
Можем, почему нет? С++/CLI очень похож на C++/CX. Но ты в курсе, что, к примеру, строки WinRT ограничены даже больше дотнетных — мало того что они обязательно immutable, так им еще запрещено принимать значение null?
FR>Подозреваю что нет, остаются только примитивные типы, чем это лучше обычного FR>нативного ассемблера или низкоуровневой VM типа llvm?
А WinRT чем лучше?
FR>Но все равно непонятно как стыковать GC с нативным кодом
Что конкретно тебя смущает? GC кучи отдельно, нативные кучи отдельно. Для взаимодействия их между собой есть соответствующие механизмы.
FR>в результате получим плюс — минус тот же WinRT.
За одним исключением — CLR уже есть много лет, ничего принципиально нового изобретать не нужно.
FR>Тут я не понял WinRT же и с COM и с CLR совместимо.
Через переходники. Таким манером и какая нибудь CORBA тоже с ними совместима.
Здравствуйте, Ночной Смотрящий, Вы писали:
FR>>Так не осилили
НС>А пытались?
Судя по шуму вокруг NET и Longhorn ночей не спали все делали
FR>>перед выходом висты было море обещаний.
НС>Там не только про managed обещали, только и native фич там тоже из обещанного почти нет.
Это да.
FR>>Но переключив все ресурсы на NET
НС>Это утверждение нуждается в доказательствах.
Возможно не все, но большую часть, для С++ в VS2003, VS2005 и VS2008 никаких существенных
изменений не было, и я думаю если бы ms не охладел тогда к C++ то вполне возможно у нас новый
стандарт был бы не C++11 а скажем C++08.
FR>>Притом я считаю что такое развитие натива и для NET было бы очень полезно.
НС>Чем конкретно? Тем что пришлось убухать кучу ресурсов на допиливание почти уже померших компиляторов VB и C# для поддержки WinRT, отняв их у Розлина? Тем, что CLR&Framework team в очередном релизе, вместо кучи важных вещей занималась в основном поддержкой WinRT? Обалденная польза, ничего не скажешь.
Я имел ввиду сразу с начала появления NET (> 10 лет назад) сделать так чтобы NET и натив могли
использовать общую компонентную среду с нативным ядром. Сейчас конечно будут проблемы со стыковкой.
Здравствуйте, Ночной Смотрящий, Вы писали:
FR>>Еще я не говорю что NET ненужен
НС>Но подразумеваешь
"Доктор откуда у вас такие картинки"
FR>>нужен но для компонентов натив во многих случаях лучше
НС>Для каких компонентов?
Да хотя бы тот же GUI что ява что нет породили конкретных тормозов.
НС>Ты думаешь, что с введениеми WinRT простота создания компонентов на C++/CX станет такой же, как на шарпе?
Она очень существенно упростится, в сравнении с тем же COM например.
Ну и надо учитывать новый C++11 который делает программирование на C++
намного приятней.
Здравствуйте, FR, Вы писали:
НС>>А пытались? FR>Судя по шуму вокруг NET и Longhorn ночей не спали все делали
Это доподлинно неизвестно, кто и что там делал. По единственному публичному билду Лонгхора, который PDC 2003, я бы не сказал что там прям так много дотнета было.
НС>>Там не только про managed обещали, только и native фич там тоже из обещанного почти нет. FR>Это да.
Следовательно, проблема была явно не в дотнете.
FR>>>Но переключив все ресурсы на NET НС>>Это утверждение нуждается в доказательствах. FR>Возможно не все, но большую часть
Доказательства все равно нужны.
FR>для С++ в VS2003, VS2005 и VS2008 никаких существенных изменений не было
А какие изменения ты ожидал от С++, если там сам язык меняется крайне медленно?
FR>, и я думаю если бы ms не охладел тогда к C++ то вполне возможно у нас новый FR>стандарт был бы не C++11 а скажем C++08.
Это вряд ли.
НС>>Чем конкретно? Тем что пришлось убухать кучу ресурсов на допиливание почти уже померших компиляторов VB и C# для поддержки WinRT, отняв их у Розлина? Тем, что CLR&Framework team в очередном релизе, вместо кучи важных вещей занималась в основном поддержкой WinRT? Обалденная польза, ничего не скажешь. FR>Я имел ввиду сразу с начала появления NET (> 10 лет назад) сделать так чтобы NET и натив могли FR>использовать общую компонентную среду с нативным ядром.
Они и так могут. Среда называется СОМ. Слыхал про такую?
Здравствуйте, FR, Вы писали:
FR>>>нужен но для компонентов натив во многих случаях лучше НС>>Для каких компонентов? FR>Да хотя бы тот же GUI что ява что нет породили конкретных тормозов.
Так и ActiveX, если рукозадость повышенная, тоже тормозов порождает. Никакой особенной специфики у дотнета тут нет. Что же касается джавы, там свои тараканы, с особенностями собственно JVM связанные лишь отчасти.
FR>Ну и надо учитывать новый C++11 который делает программирование на C++ FR>намного приятней.
Здравствуйте, hi_octane, Вы писали:
M>>А в чем собственно hell?
_>В том что эта технология совершенно не ориентирована на программистов, тех кто должен её использовать.
Вот как, на кого же она ориентирована? Ну и перечисли тогда уже технологии ориентированные на программистов, очень интересно послушать.
Успешность технологии зачастую проверяется временем, COM — долгожитель, хорошо зарекомендовавший себя в различных по сложности программах. Это не значит, что его нужно пихать куда только можно, но зачастую решения на базе COM превносят в программу модульность, делают ее менее монолитной, легко масштабируемой + не будем забывать о таких приятных вещах как инкапсуляция кода и возможность взаимодействия с компонентами разработанными на других языках, том же .Net.
_>Абсолютно все ошибки выносятся в рантайм. Вот получил ты IUnknown — что он может — ты не знаешь, документация врёт, автокомплит молчит. Вот пишешь ты реюзабельный компонент, какой IХренЗнаетЧто обязательно поддержать чтобы всё завелось способа узнать нету. А неудачный каст для многих приложений — тупо ошибка в рантайм. Кодами возврата HR пользуются только в самой MS, все остальные только S_OK, и E_FAIL. Стэктрэйса ошибки нету, сиди думай на входе там сфэйлилось, или глубоко зашло. Забытый AddRef — утечка памяти, лишний Release — случайный прострел, с этого момента всё может сыпаться случайным образом, а может и дальше работать.
Много буков, мало смысла
Складывается впечатление, что ты дааааааалек от темы.
1) Что значит "документация врет"? Открой для себя OleView или директиву #import
2) "получил ты IUnknown — что он может — ты не знаешь, ...," — он может вернуть тебе нужный интерфейс
3) "автокомплит молчит" — я чего-то не понял или ты полсыаешь лучи поноса IntelliSense-y
4) "Кодами возврата HR пользуются только в самой MS, все остальные только S_OK, и E_FAIL" — рукалицо) открою тебе страшную тайну, HRESULT предоставляет диапазон для кастомных ошибок, а такие интерфейсы как IErrorInfo... позволяют получить текстовую информацию. (конечно это должно поддерживаться используемым com_объектом). Не нравиться HRESULT юзай _com_ptr_t
5) "Забытый AddRef — утечка памяти" — используй смарт поинтеры и не думай об этом вообще — _com_ptr_t и CComPtr к твоим услугам.
_>Да, когда документация врёт...
Имхо, диагноз такой: ты не разобрался в теме, зато немного понаступав на грабли кричишь громче всех, что COM — гавно. У этой технологии есть болезни, как и у любой другой, но с её помощью уже сделали и продолжают делать сложные и качесвтенные продукты.
Здравствуйте, Ночной Смотрящий, Вы писали:
FR>>Например без GC мы можем использовать строки, массивы, да и любые объекты?
НС>Можем, почему нет? С++/CLI очень похож на C++/CX.
Не вижу такого в С++/CLI там просто обертка + синтаксический сахар над типами CLR.
GC там никак ни отключается.
C++/CX да похож, но по сути это такая же сахарная обертка над COM которая давно
существует для других нативных языков, например для Delphi или VB (не NET).
НС>Но ты в курсе, что, к примеру, строки WinRT ограничены даже больше дотнетных — мало того что они обязательно immutable, так им еще запрещено принимать значение null?
Ну так это же хорошо, я как околофункциональщик null недолюбливаю
FR>>Подозреваю что нет, остаются только примитивные типы, чем это лучше обычного FR>>нативного ассемблера или низкоуровневой VM типа llvm?
НС>А WinRT чем лучше?
Тем что исключает оверхед от виртуальных машин и легче стыкуется с произвольными
нативными языками.
FR>>Но все равно непонятно как стыковать GC с нативным кодом
НС>Что конкретно тебя смущает? GC кучи отдельно, нативные кучи отдельно. Для взаимодействия их между собой есть соответствующие механизмы.
Вот эти механизмы и смущают. Счетчик ссылок позволяет обходится без них.
FR>>в результате получим плюс — минус тот же WinRT.
НС>За одним исключением — CLR уже есть много лет, ничего принципиально нового изобретать не нужно.
Ну так я и говорю сразу надо было делать.
FR>>Тут я не понял WinRT же и с COM и с CLR совместимо.
НС>Через переходники. Таким манером и какая нибудь CORBA тоже с ними совместима.
Так тут не понял, почему тогда пишут что WinRT вызов из NET будет гораздо
дешевле чем более старые методы вызова натива?
Здравствуйте, michae1, Вы писали:
M>Имхо, диагноз такой: ты не разобрался в теме, зато немного понаступав на грабли кричишь громче всех, что COM — гавно. У этой технологии есть болезни, как и у любой другой, но с её помощью уже сделали и продолжают делать сложные и качесвтенные продукты.
а рабы уже построили в Египте классные пирамиды, без всяких экскаваторов. Откажемся от экскаваторов и вернем рабство? Ведь проверенная временем технология
Здравствуйте, Евгений Акиньшин, Вы писали:
ЕА>Здравствуйте, michae1, Вы писали:
M>>Имхо, диагноз такой: ты не разобрался в теме, зато немного понаступав на грабли кричишь громче всех, что COM — гавно. У этой технологии есть болезни, как и у любой другой, но с её помощью уже сделали и продолжают делать сложные и качесвтенные продукты.
ЕА>а рабы уже построили в Египте классные пирамиды, без всяких экскаваторов. Откажемся от экскаваторов и вернем рабство? Ведь проверенная временем технология
Кто знает с помощью чего они их построили А вот то что они развили математику — факт, откажемся от математики и будем делать наглазок?
З.Ы. устаревшее — не значит плохое и невостребованое.
