CS>валидно как в XAML так и в HTML. Куча всяко разных тулкитов используют свои атрибуты вплоть до DSL в своих CS><script type="text/x-my-dsl">...</script> секциях.
Все это здорово и очень круто... Но, как бишь мне банальный рефакторинг переименованя выполнить в JS чтобы потом два часа не сидеть в файрбаге?
Здравствуйте, mrTwister, Вы писали:
S>>>и сохранения ссылки на b, поэтому какой-нибудь "альтернативный" GC тут ничем не поможет. Костыли по ссылки — защита от отдельных одарённых личностей, что не могут усвоить правило "подписался — отпишись".
FR>>Это и есть ручное управление. FR>>Утрированно и RAII в C++ и GC это только защита от отдельных одаренных личностей не способных на каждый malloc вызвать free
T>Масштаб проблемы мягко говоря разный. T>Во-первых, события используются гораздо реже, чем просто выделение нового куска памяти. T>Во-вторых, ситуаций, когда потребитель событий живет меньше источника событий еще меньше. T>В-третьих, самое главное, для поиска таких утечек в управляемом коде даже на продакшене на рабочей системе требуется примерно минута-полторы (столько обычно уходит на запуск windbg и ввод пары-тройки тривиальных команд). То есть в реальной жизни это вообще не проблема.
T>То есть проблема утечек в .NET на событиях — это примерно как проблема медведей в городах России. Для иностранцев выглядит серьезно
Как похоже на аргументацию про утечки памяти в плюсах.
Во-первых, память на вручную выделяется редко — чаще либо на стэке, либо в контейнере через аллокатор, либо как поле в классе.
Во-вторых, ситуаций, когда объект живёт дольше чем его создатель ещё меньше. (как правило отношения владения между объектами очевидны и память управляется умными указателями).
В-третьих, утечки ищутся на раз тем же Valgrind'ом. Или, если среда не настроена, тупым логированием в конструкторах/деструкторах.
Здравствуйте, Mazay, Вы писали:
M>Во-первых, память на вручную выделяется редко — чаще либо на стэке, либо в контейнере через аллокатор, либо как поле в классе.
Тем не менее это на порядки чаще, чем подписка на события
M>Во-вторых, ситуаций, когда объект живёт дольше чем его создатель ещё меньше. (как правило отношения владения между объектами очевидны и память управляется умными указателями). M>В-третьих, утечки ищутся на раз тем же Valgrind'ом. Или, если среда не настроена, тупым логированием в конструкторах/деструкторах.
И что, у кастомеров или на продакшене стоит Valgrind?
Здравствуйте, Mazay, Вы писали:
M>Аналогия про медведей в самый раз.
Ага, в самый раз. Не поверишь, но я вот прямо сейчас сижу в windbg и ковыряюсь в дампе, пришедшего от одного кастомера, у которого наш продукт внезапно начал падать по OutOfMemory. К несчастью, течет одна из неуправляемых куч, при этом я не могу даже разобрать чья эта куча (какому компоненту принадлежит). И ты мне будешь рассказывать про медведей?
Здравствуйте, Mazay, Вы писали:
M>Во-первых, память на вручную выделяется редко — чаще либо на стэке, либо в контейнере через аллокатор, либо как поле в классе. M>Во-вторых, ситуаций, когда объект живёт дольше чем его создатель ещё меньше. (как правило отношения владения между объектами очевидны и память управляется умными указателями).
Вот только такой образцово-показательный код на С++ при работе с памятью сосет как дешевая проститутка, по сравнению с .NET
И чтобы вытянуть производительность приходится прибегать к совсем небезопасным методам работы с памятью, что увеличивает число проблем с утечками, расстрелами памяти итп.
Re[2]: No mention of either Silverlight or .NET on Windows 8
Здравствуйте, Deprivator, Вы писали:
D>Здравствуйте, c-smile, Вы писали:
CS>>HTML/CSS/JS наше всё теперь опять.
D>все-таки надо быть очень нездоровым на голову человеком, чтобы предлагать променять тот же WPF/SilverLight на уродство JS... но с микрософта станется.. D>я всегда был виндовым человеком, но вот сейчас (если это окажется правдой), однозначно перейду, не знаю на что, но перейду. D>маскарад технологий реально уже затрахал. Метания — признак отсутствия стратегии и/или воли и начало конца.
Здравствуйте, Sinix, Вы писали:
nme>>Есть конкретные примеры когда возникают проблемы? S>Для начала — как мы будем их освобождать? Особенно если ресурс помечен x:Shared="false", или на source биндинга никто больше не ссылается, или у нас несколько биндингов по сложному пути (object[0].SomeProp/Prop2).
Подсчет ссылок никто не отменял.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Sinix, Вы писали:
S>Не останется. В unmanaged очень тяжело реализовать большую часть концепций wpf. Как минимум с ресурсами и биндингами будет очень много интересных вопросов.
В unmanaged, а точнее в С++ есть только две проблемы низкий уровень кода и возможность получить AV при любом неосторожном движении. Но за-то можно добиться меньшего потребления памяти, и как следствие, немного более отзывчивый интерфейс. Когда бабла немерено и есть много опытных С++-ников, это оказывается вполне себе решением.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re: No mention of either Silverlight or .NET on Windows 8
Спокойствие, только спокойствие. Почти уверен, что как и всегда это бывает с МС — это все домысли.
Ты очень точно предсказал слив IE, в свое время, но это не тот случай. Винда — это море кода. Переписать его в одночасье не под силу даже МС.
Думаю, что правду нужно читать не в Советских газетах блогах и желтой прессе, а в делах.
На мой взгляд в МС как всегда происходит одно и то же. С одной стороны клановая борьба разных групп разработки, хорошо описанная Роном Барком (бывшим редактором WDJ 10 лет назад):
Скрытый текст
История программных революций от Microsoft, вкратце: Сначала были Windows API и DLL Hell. Революцией №1 было DDE – помните, как ссылки позволили нам создавать статусные строки, отражающие текущую цену акций Microsoft? Примерно тогда же Microsoft создала ресурс VERSION INFO, исключающий DLL Hell. Но другая группа в Microsoft нашла в DDE фатальный недостаток – его писали не они!
Для решения этой проблемы они создали OLE (похожее на DDE, но другое), и я наивно вспоминаю докладчика на Microsoft-овской конференции, говорящего, что скоро Windows API перепишут как OLE API, и каждый элемент на экране будет ОСХ-ом. В OLE появились интерфейсы, исключающие DLL Hell. Помните болезнь с названием «по месту», при которой мы мечтали встроить все свои приложения в один (возможно, очень большой) документ Word? Где-то в то же время Microsoft уверовала в религию С++, возникла MFC решившая все наши проблемы еще раз.
Но OLE не собиралась, сложа руки смотреть на это, поэтому оно заново родилось под именем COM, и мы внезапно поняли, что OLE (или это было DDE?) будет всегда – и даже включает тщательно разработанную систему версий компонентов, исключающую DLL Hell. В это время группа отступников внутри Microsoft обнаружила в MFC фатальный недостаток – его писали не они! Они немедленно исправили этот недочет, создав ATL, который как MFC, но другой, и попытались спрятать все замечательные вещи, которым так упорно старалась обучить нас группа COM. Это заставило группу COM (или это было OLE?) переименоваться в ActiveX и выпустить около тонны новых интерфейсов (включая интерфейсы контроля версий, исключающие DLL Hell), а заодно возможность сделать весь код загружаемым через браузеры, прямо вместе с определяемыми пользователем вирусами (назло этим гадам из ATL!).
Группа операционных систем громким криком, как забытый средний ребенок, потребовала внимания, сказав, что нам следует готовиться к Cairo, некой таинственной хреновине, которую никогда не могли даже толком описать, не то, что выпустить. К их чести, следует сказать, что они не представляли концепции «System File Protection», исключающей DLL Hell. Но тут некая группа в Microsoft нашла фатальный недостаток в Java — её писали не они! Это было исправлено созданием то ли J, то ли Jole, а может, и ActiveJ (если честно, я просто не помню), точно такого же как Java, но другого. Это было круто, но Sun засудило Microsoft по какому-то дряхлому закону. Это была явная попытка задушить право Microsoft выпускать такие же продукты, как у других, но другие.
Помните менеджера по J/Jole/ActiveJ, стучащего по столу туфлей и говорящего, что Microsoft никогда не бросит этот продукт? Глупец! Все это означало только одно – недостаток внимания к группе ActiveX (или это был COM?). Эта невероятно жизнерадостная толпа вернулась с COM+ и MTS наперевес (может, это стоило назвать ActiveX+?). Непонятно почему к MTS не приставили «COM» или «Active» или «X» или «+» – они меня просто потрясли этим! Они также грозились добавить + ко всем модным тогда выражениям. Примерно тогда же кое-кто начал вопить про «Windows DNA» (почему не DINA) и «Windows Washboard», и вопил некоторое время, но все это почило раньше, чем все поняли, что это было.
К этому моменту Microsoft уже несколько лет с нарастающей тревогой наблюдала за интернет. Недавно они пришли к пониманию, что у Интернет есть фатальный недостаток: ну, вы поняли. И это приводит нас к текущему моменту и технологии .NET (произносится как «doughnut (пончик по-нашему)», но по-другому), похожей на Интернет, но с большим количеством пресс- релизов. Главное, что нужно очень четко понимать — .NET исключает DLL Hell.
В .NET входит новый язык, C#, (выясняется, что в Active++ Jspresso был фатальный недостаток, от которого он и помер). .NET включает виртуальную машину, которую будут использовать все языки (видимо, из-за фатальных недостатков в процессорах Интел). .NET включает единую систему защиты (есть все-таки фатальный недостаток в хранении паролей не на серверах Microsoft). Реально проще перечислить вещи, которых .NET не включает. .NET наверняка революционно изменит Windows-программирование... примерно на год.
С другой же стороны давит реальность и обратная совместимость.
С первым фактором все ясно, а вот второй стоит пояснить.
Даже в относительно отдельном продукте вроде Visual Studio много кода и много тех кто использует старые версии продукта. Переписать его в одночасье сложно и это может очень негативно повлиять на тех кто использовал продукт ранее. По сему процесс этот растягивается на долгие годы (а то и десятилетия).
Но процесс таки потихонечку идет. Студия с каждой версией избавляется от С++ заменяя его управляемым кодом. Думаю версии через 2-3 от С++ избавятся во все и после этого порвут со его наследием (совместимостью). COM поможет сгладить этот процесс (сделать обратную совместимость хоть в каком-то виде).
В случае успеха со студией дальше пойдут и другие продукты. К тому времени старая гвардия уйдет на пенсию и все расклады изменятся. Но будет это не скоро.
Теперь что касается Вынь АПИ. Ему вообще ничего не грозит. Винда останется анменеджед и с этим ужасным АПИ еще долгие десятилетия. Возможно будут появляться разные новые АПИ. Возможно что они будут предоставлять более приличный доступ к возможностям винды, но старый добрый CreateWindowEx умрет только с виндовс.
Так что все эти страхи — это всего лишь пурга поднятая разными пиарящимися товарищами.
Ну, будет какой-то новый АПИ на базе HTML 5 и жабастипте. Что это значит? А только то, что группа индусов, разработчиков IE нашла фатальный недостаток в других АПИ. Ну, вы знаете какой! (с)
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[10]: No mention of either Silverlight or .NET on Windows
Здравствуйте, hardcase, Вы писали:
H>Все это здорово и очень круто... Но, как бишь мне банальный рефакторинг переименованя выполнить в JS чтобы потом два часа не сидеть в файрбаге?
Ну, это — покрываешь тестами всю фигню со 100% coverage
Re[2]: No mention of either Silverlight or .NET on Windows 8
... VD>Ну, будет какой-то новый АПИ на базе HTML 5 и жабастипте. Что это значит? А только то, что группа индусов, разработчиков IE нашла фатальный недостаток в других АПИ. Ну, вы знаете какой! (с)
В деталях много чего не так, но принципы описаны правильно.
Re: No mention of either Silverlight or .NET on Windows 8
Silverlight — жив и поддерживает новые фичи Windows 8,
С# и VB — живы,
среды разработки — те же,
Expression Blend научился плюсом к XAML редактировать HTML5.
Re[5]: No mention of either Silverlight or .NET on Windows 8
Здравствуйте, Евгений Акиньшин, Вы писали:
ЕА>Именно так, мотыляния и сгубили. Так о том-то и речь, что микрософт в ту же игру играет:
ЕА>- все делаем на ВинФормз ЕА>- нет винформз устарел не будем его развивать, все делаем на WPF ЕА>- нет ну нафиг WPF, сильверлайт рулит ЕА>- нет сильверлайт забрасываем, "HTML5 is the way to go"
Ну так старые технологии-то остаются. Если они тебе подходят -- юзай. Другое дело, что на рынке востребованы уже другие. Ну так в этом жизнь. В переменах. И если теюе не нравятся перемены, то тебе надо просто немного другую отрасль IT выбрать. Ну, скажем в вычматы уйти и сидеть себе спокойно на фортране...
ЕА>знаю таких не ощутивших, ждавших по несколько лет 64-битный компилятор (выход которого откладывали не знаю сколько раз на моей памяти), а потом переписавших свои приложения на Си++, а также других не ощутивших, которые до сих пор ждут
Дык, это, одна из главных черт программиста -- адекватность в восприятии кода и его авторов. Может мне тоже, хочется, что бы Луна красного цвета была. Сижу вот, жду...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[7]: No mention of either Silverlight or .NET on Windows 8
Здравствуйте, Евгений Акиньшин, Вы писали:
ЕА>не пофигу, платформа должна развиваться и поддерживаться — иначе твое приложение в будущем не сможет использовать какие-нидь плюшки типа тач-скрина или 64бит, а это может быть критично, и заранее этого не предусмотришь, а все переписывать — это очень дорого, а иногда не реально дорого
Вроде как у дотнета нет проблем с интеромпом с нативом и с ОС...
Даже если в MS сойдут с ума и не станут поддерживать тачскрин из дотнета, то тут же кто-то третий напишет библу...
ЕА>ага, не прошло и 10 лет. или прошло
Дык зачем они ждали-то?
ЕА>некоторым по-зарез были нужны — я особо не вникал, но насколько я помню, речь шла о интеграции в експлорер в 64-битной винде и подобных вещах
Ну сделали бы переходник на более рассово-чистом компиляторе...
А разве 64-битный экспорер не умеет вызывать 32-е плагины?..
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[6]: No mention of either Silverlight or .NET on Windows 8
Здравствуйте, Erop, Вы писали:
E>Здравствуйте, Евгений Акиньшин, Вы писали:
ЕА>>Именно так, мотыляния и сгубили. Так о том-то и речь, что микрософт в ту же игру играет:
ЕА>>- все делаем на ВинФормз ЕА>>- нет винформз устарел не будем его развивать, все делаем на WPF ЕА>>- нет ну нафиг WPF, сильверлайт рулит ЕА>>- нет сильверлайт забрасываем, "HTML5 is the way to go"
E>Ну так старые технологии-то остаются. Если они тебе подходят -- юзай. Другое дело, что на рынке востребованы уже другие. Ну так в этом жизнь. В переменах. И если теюе не нравятся перемены, то тебе надо просто немного другую отрасль IT выбрать. Ну, скажем в вычматы уйти и сидеть себе спокойно на фортране...
не, это не по адресу — во-первых я как раз наоборот всегда учу новое, даже когда не надо , а во-вторых я в общем-то давно только руковожу разработкой, а код пишу уже исключительно как хобби
проблема вся в том, что технологии разработки иногда меняются быстрее, чем пишутся приложения, что не очень эффективно с точки зрения рационального использования труда программистов
Здравствуйте, Erop, Вы писали:
E>Вроде как у дотнета нет проблем с интеромпом с нативом и с ОС...
Нету. Интероп в дотнете самый мощный из всего, с чем я когда либо сталкивался.
ЕА>>некоторым по-зарез были нужны — я особо не вникал, но насколько я помню, речь шла о интеграции в експлорер в 64-битной винде и подобных вещах E>Ну сделали бы переходник на более рассово-чистом компиляторе...
расово.
E>А разве 64-битный экспорер не умеет вызывать 32-е плагины?..
Нет вроде.
Re[2]: No mention of either Silverlight or .NET on Windows 8
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Здравствуйте, mtnl, Вы писали:
M>>Silverlight — жив и поддерживает новые фичи Windows 8,
НС>С SL, увы, не все так просто.
А я так не понял, на чем теперь предполагается писать дектопный ГУЙ:
— Silverlight сдох
— WinRT штука классная, но его еще нет, судя повсему он будет поддерживаться только на вин8 и позиционируется только для метро приложений
— Все что на базе Win32 — напрямую сказано что легаси, в новых шелах типа метро поддерживаться не будет
— WPF далеко не универсален (жрет много ресурсов, долго стартует и требует установку 4-го фреймворка, который до сих не часть виндовз) — т.е. не всегда подойдет. Про его развитие не слово не сказали.
