Прочитал случайно про WinFX и что майкрософт собирается заменить им WinAPI в будущем. Скачал какой-то betta release WinFX SDK. Посмотрел что он там умеет и......ничего не нашёл, кроме какой-то XAML попсы для интерфейсов. А найти я там хотел какое-ньть подобие на WinAPI, ну хотя б ту же функцию FindWindow. Вот тут и вопрос возникает, что они себе там думают и как писать системное ПО в .NET? На managed C++?
Я изъездил эту страну вдоль и поперек, общался с умнейшими людьми и я могу вам ручаться в том, что обработка данных является лишь причудой, мода на которую продержится не более года. (с) Эксперт, авторитет и профессионал из 1957 г.
Здравствуйте, King of a Stellar War, Вы писали:
KOA>Прочитал случайно про WinFX и что майкрософт собирается заменить им WinAPI в будущем. Скачал какой-то betta release WinFX SDK. Посмотрел что он там умеет и......ничего не нашёл, кроме какой-то XAML попсы для интерфейсов. А найти я там хотел какое-ньть подобие на WinAPI, ну хотя б ту же функцию FindWindow. Вот тут и вопрос возникает, что они себе там думают и как писать системное ПО в .NET? На managed C++?
Нда. Много еще прйдется сломать стереотипов. Ну, да ладно. Так как времени на ломку нет, то по верхам:
1. ВыньАПИ не отменяется. Весь софт написанный ранее будет пазать как часы. Просто его больше не будут особо развивать. Открою один сикрет. Его практически не развивают с времен NT 3.51. Ну, там КОМ/ДКОМ/СОМ+ появился, но они в общем-то к ВыньАПИ отношение не имеют. Так что по мелочи АПИ конечно развиваться будет и дальше, но и только.
2. Новый АПИ просто позволит писать программы быстрее, проще и с большим количеством финтифлюшек. Например, Авалон позволит делать динамические ГУИ круче чем во Флэше от Макромедии.
3. Новых АПИ будт три: а) Аэро/Авалон — 3D-ГУИ плюс иерархия компонетов/контролв созданная чисто на дотнете, б) Индиго — комуникации (КОМ+/МСМКЮ и т.п. не отменяются, но по будет и новый менеджед-АПИ который позволит наладить комуникацию и без них, но и их задействовать мозволит), в) WinFS — объектно-ориентированная файловая система (она будет позже и будет являться чем-то вроде O/R Maping-а).
4. Новый АПИ уже есть. Основа WinFX — это банальный .Net Framwork следующих версий. Просто маркитологи из МС не могут не обойтись без супер-сенсаций. Сенсации эти в основном рассчитаны на юзыерей, а приличному программисту покупаться на них является не очень разумно . Для программистов сделан вот этот ресурс: http://WinFX.msdn.microsoft.com/
5. Надо отучаться от стериотипов, что:
* АПИ должно быть на С.
* ГУИ дожно состаять из окон.
Теперь АПИ — это просто ОО-библиотека. Окон в Авалоне нет, хотя они и могут использоваться для совместимости со старыми контролами, например, WinForms-овыми.
Испоьзовать новые АПИ можно будет из любого языка программирования способного породить управляемый код. Проще всего конечно это будет делать из C# или VB.Net, но можно и из МС++. В общем-то разница не вилека. Чуть больше шума.
... << RSDN@Home 1.1.4 beta 3 rev. 279>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
1. Насколько я помню когда читал документацию по WinFX единицей управления графическими объектами остаётся окно с его HWND. Просто предоставляются боле высокоуровневые механизмы управления, например logic tree.
2. Допустим Avalon с XAML и 3D таки выйдет в свет. Наверняка соответствующим образом озменится Explorer. Так вот, через какие вызовы/классы эксплорер сможет управлять всеми объектами на экране, если Avalon (вроде) такой функциональности не предоставляет? В WinAPI это было просто, например для перескакиваня по окнам — EnumWindows + ShowWindow, а в Avalone на .NET как можно реализовать подобный механизм?
Я изъездил эту страну вдоль и поперек, общался с умнейшими людьми и я могу вам ручаться в том, что обработка данных является лишь причудой, мода на которую продержится не более года. (с) Эксперт, авторитет и профессионал из 1957 г.
Здравствуйте, VladD2, Вы писали:
VD>5. Надо отучаться от стериотипов, что: VD>* АПИ должно быть на С.
Действительно, с чего бы это... то что сама операционка написана на C и у большинства программистов, пишущих под неё основным языком является C — это типа ещё не показатель...
VD>Теперь АПИ — это просто ОО-библиотека.
Ну и что? В соляре гуя тоже объектно-ориентированная, но это не мешает использовать её из множества языков...
VD>Испоьзовать новые АПИ можно будет из любого языка программирования способного породить управляемый код. Проще всего конечно это будет делать из C# или VB.Net, но можно и из МС++.
Вот-вот... Похоже в майкрософт нашли фатальный недостаток во всех языках программирования — их придумали не они! Вместо того чтобы наконец-то правильно реализовать компилятор того же C++, они просто решили убить этот язык (я за одно и все остальные) — браво! Вот интересно, как будет выглядеть реализация meneged Fortran-90...
Когда M$ насаждала мне под какую ОС писть — я терпел, когда она насаждала мне технологии которыми пользоваться — я терпел, когда она насаждала мне свои стандарты — я тоже терпел, но теперь она пытается заставить меня писать на том языке, который удобен ей — извинте, но терпение кончается!
Вообще всё это похоже на попытку отпилить сук на котором сидишь... Я вот не думаю, что вся армия Win-программистов выстроиться по струнке и как послушные собачки перейдут на C#, потому что так хочет Билли Ворота — читать здесь! Я скорее переориентируюсь под WEB или уйду в Unix — это будет проще, по крайней мере язык переучивать не надо будет. Технологии в Longhorn`е всё равно новые для всех будут, а под Unix я хоть чуть-чуть да писал когда-то...
Компьютер сделает всё, что вы ему скажете, но это может сильно отличаться от того, что вы имели в виду.
Здравствуйте, Mr. None, Вы писали:
MN>Когда M$ насаждала мне под какую ОС писть — я терпел, когда она насаждала мне технологии которыми пользоваться — я терпел, когда она насаждала мне свои стандарты — я тоже терпел, но теперь она пытается заставить меня писать на том языке, который удобен ей — извинте, но терпение кончается!
Какой милый религиозный фанатизм!
А чем C# не устроил? C++ хорош, но компилятор для него хороший создать — задача более, чем нетривиальная Кроме того, под дотъ-нэтъ масса языков есть, помимо упомянутых Владом...
Mr. None,
> VD> Испоьзовать новые АПИ можно будет из любого языка программирования способного породить управляемый код. Проще всего конечно это будет делать из C# или VB.Net, но можно и из МС++.
> Вот-вот... <...>
Не заводись Влад (осознанно, или нет) преувеличивает: из C++/CLI использовать новые API .Net будет по меньшей мере в той же степени удобно, как и из C# или VB.Net.
> Похоже в майкрософт нашли фатальный недостаток во всех языках программирования — их придумали не они! Вместо того чтобы наконец-то правильно реализовать компилятор того же C++, они просто решили убить этот язык <...>
Не надо так эмоционально. Факт жизни состоит в том, что на деле MS делает для C++ достаточно много, чтобы сказать им за это спасибо. Да, еще достаточно недавно это было не так, но времена быстро меняются, и, имхо, это сложно не заметить.
> Когда M$ насаждала мне под какую ОС писть — я терпел, когда она насаждала мне технологии которыми пользоваться — я терпел, когда она насаждала мне свои стандарты — я тоже терпел, но теперь она пытается заставить меня писать на том языке, который удобен ей — извинте, но терпение кончается!
Cool it Нравится писать на C++ — пиши на C++, не нравится — подбери себе язык по вкусу из доступных под .Net — благо, недостатка не видно, и чем дальше, тем больше. В частности, чтобы сделать удобной разработку под .Net на C++, команда VC++ потратила как минимум целый цикл разработки своего продукта. Ребята вложились от души, enjoy.
> Вообще всё это похоже на попытку отпилить сук на котором сидишь...
Это хорошо согласуется с тем, что они сами говорят. Именно поэтому MS этого не сделает
Posted via RSDN NNTP Server 1.9
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Здравствуйте, Павел Кузнецов, Вы писали:
ПК>Не заводись ПК>Не надо так эмоционально.
Самое смешное, что тут действительно больше эмоций, чем прагматичекой логики . Просто меня немного раздражает, когда люди начинают заявлять: типа через пару лет будет один .NET и все будут писать на шарпе ! Не будет и не будут. Я прекрасно понимаю, что M$ никогда (по крайней мере в ближайшие лет 5 — 10 точно) не сможет перевести полностью весь АПИ на .NET и при этом оставить обратную совместимость со всем, что было. А раз не смогут, то им будут продолжать пользоваться по крайней мере те, которым в силу особенности языка не удобно использовать .NET и менеджед расширения. И трюк, который МС провернула для замены Win16 на Win32 не пройдёт — тогда она не предлагали сотням тысяч программеров сменить основной язык, на котором они пишут...
ПК>Cool it Нравится писать на C++ — пиши на C++, не нравится — подбери себе язык по вкусу из доступных под .Net — благо, недостатка не видно, и чем дальше, тем больше.
А если идеология языка не совпадает с идеологией .NET?
- И все будут жить счастливыми!
— А если кто-то не захочет жить счастилвым?
— Тогда он умрёт — все желания должны исполняться.
"Формула Любви".
Или будет как с OpenGL? Идеология OpenGL не совпадала с идеологией Windows в области графики и не совпадала с идеологией маркетингового отдела MS, которому больше нравился свой стандарт — Direct 3D. Но поддерживать OpenGL надо было, потому как иначе некузяво и решение было найдено — реализовать OpenGL как надстройку над Direct 3D и не важно, что "летающий" под Unix`ом OpenGL под Windows стал тормознее моей первой реализации алгоритма заливки методом Гуро. Итог, кто теперь использует OpenGL под Windows там, где нужна действительно быстрая графика?
ПК>В частности, чтобы сделать удобной разработку под .Net на C++, команда VC++ потратила как минимум целый цикл разработки своего продукта. Ребята вложились от души, enjoy.
А вот я слышал и этот слух ни как не опровергается отделом маркетинга MS (но надо отдать должное и не подтверждается — в духе совесткой дипломатии времён Карибского кризиса ), что MC++ в дальнейшем не будет ни развиваться, ни поддерживаться, и нужен он только для того, чтобы программисты пишушие на C++ легко перешли на .NET и в дальнейшем на C#... Типа demo-версия возможностей .NET для плюсов...
Компьютер сделает всё, что вы ему скажете, но это может сильно отличаться от того, что вы имели в виду.
Mr. None пишет:
> Или будет как с OpenGL? Идеология OpenGL не совпадала с идеологией > Windows в области графики и не совпадала с идеологией маркетингового > отдела MS, которому больше нравился свой стандарт — Direct 3D. Но > поддерживать OpenGL надо было, потому как иначе некузяво и решение > было найдено — реализовать OpenGL как надстройку над Direct 3D и не > важно, что "летающий" под Unix`ом OpenGL под Windows стал тормознее > моей первой реализации алгоритма заливки методом Гуро. Итог, кто > теперь использует OpenGL под Windows там, где нужна действительно > быстрая графика?
Софтовый OpenGL в винде тормозил из-за того, что использовал GDI.
Аппаратные реализации OpenGL для Винды сейчас так же быстро работают,
как и DX.
Здравствуйте, Mr. None, Вы писали:
MN>Или будет как с OpenGL? Идеология OpenGL не совпадала с идеологией Windows в области графики и не совпадала с идеологией маркетингового отдела MS, которому больше нравился свой стандарт — Direct 3D. Но поддерживать OpenGL надо было, потому как иначе некузяво и решение было найдено — реализовать OpenGL как надстройку над Direct 3D и не важно, что "летающий" под Unix`ом OpenGL под Windows стал тормознее моей первой реализации алгоритма заливки методом Гуро. Итог, кто теперь использует OpenGL под Windows там, где нужна действительно быстрая графика?
Вот не надо OpenGL работает также быстро как Д3Д если драйверы на видюху поставить. Причина тут в другом... дело в том что с OpenGL таже фигня что и с С++... Как нет двух одинаковых С++ компиляторов так и нет двух одинаковых OpenGL под разные видюхи... Загляни в тотже boost как там его учат работать с разными компиляторами... а потом вспомни что различных видюх гораздо больше чем С++ компиляторов...
... << RSDN@Home 1.1.4 beta 3 rev. 185>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
WH>Здравствуйте, Mr. None, Вы писали:
WH>Вот не надо OpenGL работает также быстро как Д3Д если драйверы на видюху поставить.
Тогда объясните мне, почему под тем же Linux`ом со скоростью у него всегда было всё впорядке, даже пошустрее Д3Д был. И реализации первые у него были софтовые, а не аппаратные. Даже игры полностью на нём пишут... А под виндой драйвера нужны, аппаратная поддержка, а если нет ни того ни другого — пожалуйста юзай как прослойку над Д3Д или вообще GDI...
Это сейчас он может быстро работает, если есть аппаратная поддержка, а когда я его впервые использовал (5 лет назад) — тормоза аткие были, что просто атас!
Компьютер сделает всё, что вы ему скажете, но это может сильно отличаться от того, что вы имели в виду.
Здравствуйте, Cyberax, Вы писали:
C>Софтовый OpenGL в винде тормозил из-за того, что использовал GDI. C>Аппаратные реализации OpenGL для Винды сейчас так же быстро работают, C>как и DX.
См. в ответе WolfHound`у
Компьютер сделает всё, что вы ему скажете, но это может сильно отличаться от того, что вы имели в виду.
Mr. None пишет:
> WH>Здравствуйте, Mr. None, Вы писали: > WH>Вот не надо OpenGL работает также быстро как Д3Д если драйверы на > видюху поставить. > Тогда объясните мне, почему под тем же Linux`ом со скоростью у него > всегда было всё впорядке, даже пошустрее Д3Д был. И реализации первые > у него были софтовые, а не аппаратные. Даже игры полностью на нём > пишут... А под виндой драйвера нужны, аппаратная поддержка, а если нет > ни того ни другого — пожалуйста юзай как прослойку над Д3Д или вообще > GDI...
Потому что первые версии OpenGL работали еще в Win3.11, в которой не
было нормального прямого доступа к видеопамяти (типа поверхностей DX).
Причем OpenGL без проблем интероперирует с GDI в Винде, так как
создавался не для игр, а для качественной 3D-графики.
> Это сейчас он может быстро работает, если есть аппаратная поддержка, а > когда я его впервые использовал (5 лет назад) — тормоза аткие были, > что просто атас!
Mr. None,
> ПК> Cool it Нравится писать на C++ — пиши на C++, не нравится — подбери себе язык по вкусу из доступных под .Net — благо, недостатка не видно, и чем дальше, тем больше.
> А если идеология языка не совпадает с идеологией .NET?
А если удачно совместить?
> ПК> В частности, чтобы сделать удобной разработку под .Net на C++, команда VC++ потратила как минимум целый цикл разработки своего продукта. Ребята вложились от души, enjoy.
> А вот я слышал и этот слух ни как не опровергается отделом маркетинга MS (но надо отдать должное и не подтверждается — в духе совесткой дипломатии времён Карибского кризиса ), что MC++ в дальнейшем не будет ни развиваться, ни поддерживаться, и нужен он только для того, чтобы программисты пишушие на C++ легко перешли на .NET и в дальнейшем на C#... Типа demo-версия возможностей .NET для плюсов...
Не надо путать MC++ и C++/CLI. По поводу отношения MS к своему детищу ссылки уже приводились
. C++/CLI позиционируется компанией Microsoft как системный язык для .Net. Напротив, от перехода на C#, если нравится С++, мягко, но регулярно отговаривают:
In the years since the .NET Framework, the CLR, and C# were announced, many developers have wondered about Microsoft's plans for C++. Some have speculated that C# is a replacement for C++, but it most certainly is not. C# is a language that is easier to learn than C++, and provides access to the functionality of the CLR. For those who already know C++, there's no need to learn anything to gain access to the functionality of the CLR, and C++ has features that are not in C#, so moving would actually involve giving up some power.
Intel тоже принимает посильное участие в продвижении C++/CLI:
Finally, perhaps the most important reason for a .NET programmer to learn C++/CLI is the observation with which this article began: no language is mentioned more in job ads than C++. Knowledge of C++ opens up the broadest range of programming positions on the broadest range of platforms. C++/CLI, which allows one to defer tackling the complexities of memory management while enjoying the powerful and familiar libraries of .NET, may be the ideal stepping-stone into this common language of professional software development.
В той же статье есть интересное наблюдение о том, что IBM также является членом технической группы ECMA, работающей над спецификацией C++/CLI, что дает серьезные основания подозревать их в наличии практического интереса к данному языку.
Ща в меня справедливо полетят помидоры за ссылки на откровенно маркетинговые статьи; оправданием мне служит то, что речь как раз и идет о маркетинге
Posted via RSDN NNTP Server 1.9
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
P.S.
ПК>В той же статье есть интересное наблюдение о том, что IBM также является членом технической группы ECMA, работающей над спецификацией C++/CLI, что дает серьезные основания подозревать их в наличии практического интереса к данному языку.
Еще интереснее взглянуть на сам список компаний, пожелавших участвовать в работе TC39-TG5 (группа ECMA, занимающаяся C++/CLI):
Borland
Dinkumware
Edison Design Group
Hitachi
IBM
Indiana University
Intel
Microsoft
Plum Hall
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
MN>Самое смешное, что тут действительно больше эмоций, чем прагматичекой логики . Просто меня немного раздражает, когда люди начинают заявлять: типа через пару лет будет один .NET и все будут писать на шарпе !
Самое смешное, что совсем недавно тоже самое говорили программисты на асм про с/с++ и другие не асм языки
... <<silent RSDN@Home 1.1.4 beta 4 [303] Windows XP 5.1.2600.0 >>
DEMON HOOD,
> MN> Самое смешное, что тут действительно больше эмоций, чем прагматичекой логики . Просто меня немного раздражает, когда люди начинают заявлять: типа через пару лет будет один .NET и все будут писать на шарпе !
> Самое смешное, что совсем недавно тоже самое говорили программисты на асм про с/с++ и другие не асм языки
Здравствуйте, tarkil, Вы писали:
T>Здравствуйте, Mr. None, Вы писали:
MN>>Когда M$ насаждала мне под какую ОС писть — я терпел, когда она насаждала мне технологии которыми пользоваться — я терпел, когда она насаждала мне свои стандарты — я тоже терпел, но теперь она пытается заставить меня писать на том языке, который удобен ей — извинте, но терпение кончается!
T>Какой милый религиозный фанатизм!
T>А чем C# не устроил? C++ хорош, но компилятор для него хороший создать — задача более, чем нетривиальная
Помнится, Влад тут с пеной у рта доказывал, что, С# отпарсить куда сложнее, чем C++.
Ну а если серьёзно -- простота компилятора практически автоматически означает низкую выразительную силу языка, т.е. больше работы программисту потом.
T>Кроме того, под дотъ-нэтъ масса языков есть, помимо упомянутых Владом...
Ты не поверишь, но до появления дот-нета языков программирования было гораздо больше, чем тех, для которых есть дот-нет реализация сейчас.
Здравствуйте, Cyberax, Вы писали:
C>Потому что первые версии OpenGL работали еще в Win3.11, в которой не C>было нормального прямого доступа к видеопамяти (типа поверхностей DX). C>Причем OpenGL без проблем интероперирует с GDI в Винде, так как C>создавался не для игр, а для качественной 3D-графики.
А под Unix`ом их (поверхностей DX) вообще не было и работал он там прекрасно в теже самые времена. И использовался он там в том числе и для игр (все версии Quake под Unix`ом работают на OpenGL).
>> Это сейчас он может быстро работает, если есть аппаратная поддержка, а >> когда я его впервые использовал (5 лет назад) — тормоза аткие были, >> что просто атас!
C>Из-за GDI.
И никакой GDI под Unix`ом ему не мешал...
Из всего этого можно сделать один вывод — OpenGL по каким-то причинам не удобен M$ (он содержит фатальный недостаток — его придумали не они!), поэтому его реализации под Windows неудобны и неконкурентно способны с аналогичными технологиями от самой MS (DirectX, GDI и пр.). Вот как бы не случилось тоже под .NET с языками программирования, которые придумал не Майкрософт и идеология которых идёт в разрез с идеологией .NET...
Компьютер сделает всё, что вы ему скажете, но это может сильно отличаться от того, что вы имели в виду.
Здравствуйте, Павел Кузнецов, Вы писали:
>> ПК> Cool it Нравится писать на C++ — пиши на C++, не нравится — подбери себе язык по вкусу из доступных под .Net — благо, недостатка не видно, и чем дальше, тем больше.
>> А если идеология языка не совпадает с идеологией .NET?
ПК>А если удачно совместить?
Это не всегда возможно...
Пример. Фортран: основная идеология и достоинство — очень быстрые вычисления. Все его внутренние библиотеки и компиляторы оптимизированы именно на это. Ради этого выкидывается всё, что может затормозить — проверки, универсальность; он даже динамическую память не поддерживает (по крайней мере до Фортран-80 было именно так... что там с Фортран-90 не знаю — с ним уже не работал), как следствие в нём нет понятий указателей, ссылок, объектов, классов и т.д. и т.п. Вот скажите как удачно совместить его с .NET не разрабатывая спецификацию нового языка, как в случае с VB .NET и сохранить основное достоинство — быстрые вычисления (скажем любая проверка на выход за границы массива уже противоречит этой идеологии).
>> А вот я слышал и этот слух ни как не опровергается отделом маркетинга MS (но надо отдать должное и не подтверждается — в духе совесткой дипломатии времён Карибского кризиса ), что MC++ в дальнейшем не будет ни развиваться, ни поддерживаться, и нужен он только для того, чтобы программисты пишушие на C++ легко перешли на .NET и в дальнейшем на C#... Типа demo-версия возможностей .NET для плюсов...
ПК>Не надо путать MC++ и C++/CLI. По поводу отношения MS к своему детищу ссылки уже ПК> ...
Вы меня успокоили, спасибо
Компьютер сделает всё, что вы ему скажете, но это может сильно отличаться от того, что вы имели в виду.
Mr. None пишет:
> C>Потому что первые версии OpenGL работали еще в Win3.11, в которой не > C>было нормального прямого доступа к видеопамяти (типа поверхностей DX). > C>Причем OpenGL без проблем интероперирует с GDI в Винде, так как > C>создавался не для игр, а для качественной 3D-графики. > А под Unix`ом их (поверхностей DX) вообще не было и работал он там > прекрасно в теже самые времена. И использовался он там в том числе и > для игр (все версии Quake под Unix`ом работают на OpenGL).
Во времена Win3.11 Юниксы с OGL были только на дорогущих рабочих
станциях, на которых он реализовывался с помощью прямого доступа к
видеопамяти из графического драйвера.
В Win3.11 такой роскоши не было, т.к. ядро было 16-битным, так что OGL
работал просто как клиент GDI. В Win9x/NT (и в Win32s) возможность
прямого доступа к поверхностям появлась сначала в виде WinG, а потом и
DirectDraw. На а Direct3D был вполне логичным шагом развития после
DirectDraw. OGL так и не стали апгрейдить (а зачем?) — не нужно было.
Кстати, Quake под Линуксом использует не только OGL, а еще и софтовый
рендерер для Xов и фреймбуффера.
> C>Из-за GDI. > И никакой GDI под Unix`ом ему не мешал...
Потому как в Unix'ах другая ахитектура системы. Там OGL'ю мешал
X-протокол
> Из всего этого можно сделать один вывод — OpenGL по каким-то причинам > не удобен M$ (он содержит фатальный недостаток — его придумали не > они!), поэтому его реализации под Windows неудобны и неконкурентно > способны с аналогичными технологиями от самой MS (DirectX, GDI и пр.).
OpenGL сейчас вполне живет и здравствует под Виндой, аппаратное
ускорение для него работает без проблем и с GDI его использовать — одно
удовольствие. Вот прямо сейчас пишу софт для визуализации, использующий OGL.
Шахтер wrote: > Здравствуйте, tarkil, Вы писали: > > T>Здравствуйте, Mr. None, Вы писали: > > MN>>Когда M$ насаждала мне под какую ОС писть — я терпел, когда она насаждала мне технологии которыми пользоваться — я терпел, когда она насаждала мне свои стандарты — я тоже терпел, но теперь она пытается заставить меня писать на том языке, который удобен ей — извинте, но терпение кончается! > > T>Какой милый религиозный фанатизм! > > T>А чем C# не устроил? C++ хорош, но компилятор для него хороший создать — задача более, чем нетривиальная > > Помнится, Влад тут с пеной у рта доказывал, что, С# отпарсить куда сложнее, чем C++. > > Ну а если серьёзно -- простота компилятора практически автоматически означает низкую выразительную силу языка, т.е. больше работы программисту потом.
Знатоки Lisp/Smalltalk в этом месте ехидно улыбаются...
> > T>Кроме того, под дотъ-нэтъ масса языков есть, помимо упомянутых Владом... > > Ты не поверишь, но до появления дот-нета языков программирования было гораздо больше, чем тех, для которых есть дот-нет реализация сейчас.
Здравствуйте, King of a Stellar War, Вы писали:
KOA>Здравствуйте, VladD2.
KOA>1. Насколько я помню когда читал документацию по WinFX единицей управления графическими объектами остаётся окно с его HWND. Просто предоставляются боле высокоуровневые механизмы управления, например logic tree.
Бэты уже доступны для скачивания с МСДН, так что допускать ничего не дано. Это факт.
KOA> Наверняка соответствующим образом озменится Explorer. Так вот, через какие вызовы/классы эксплорер сможет управлять всеми объектами на экране, если Avalon (вроде) такой функциональности не предоставляет?
У эксплорера есть своя объектная модель. В Лонгхорне эта модель выражена в виде дотнетной сборки.
Авалон никаких специальных средств для этого не предоставляет. Но контролы Авалона — это дотнет-контролы и с ними можно работать через их публичный интерфейс или рефлекшон.
KOA> В WinAPI это было просто, например для перескакиваня по окнам — EnumWindows + ShowWindow, а в Avalone на .NET как можно реализовать подобный механизм?
Я ни разу не видел, чтобы с Эксплорером кто-то возился на уровне окон. Это довольно бессысленно. Современный Эксплорер автоматизируется через свою объектную модель основанную на КОМ-е. Новый эксплорер будет автоматизироваться в том числе и на базе дотнета (думаю старый механизм тоже останется).
Кстати, в версии Лонгхорна которую видел я очень многие елементы эксплорера были сделаны на ВыньАПИ. Например, все навигационные части состояли из окон имевших класс "Button" и "Static". Но многие элементы, например, реализация поиска уже была на Авалоне. Я не знаю что будет к релизу, но ориентироваться на окна точно не стоит.
... << RSDN@Home 1.1.4 beta 3 rev. 279>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Mr. None, Вы писали:
VD>>5. Надо отучаться от стериотипов, что: VD>>* АПИ должно быть на С. MN>Действительно, с чего бы это... то что сама операционка написана на C
Это заблуждение. Кое что даже на VB6 написано. А теперь очень не хилая часть будет на дотнете.
MN> и у большинства программистов, пишущих под неё основным языком является C — это типа ещё не показатель...
А это просто неправда. Пишут на чем угодно. И как раз С самый редко всречающийся случай. На Дельфи и то намного чаще пишут.
VD>>Теперь АПИ — это просто ОО-библиотека. MN>Ну и что?
Ну, и ничено.
MN>В соляре гуя тоже объектно-ориентированная, но это не мешает использовать её из множества языков...
И тут мешать не будет. Ограничение толкь одно. Языки должны быть управляемыми.
MN>Вот-вот... Похоже в майкрософт нашли фатальный недостаток во всех языках программирования — их придумали не они!
Видимо по этому они сделали МС++ и сейчас делают C++/CLI.
MN> Вместо того чтобы наконец-то правильно реализовать компилятор того же C++, они просто решили убить этот язык (я за одно и все остальные) — браво!
Правильность реализации компилятора С++ тут не причем. Да и с версии 7.1 он у них очень даже правильный.
MN> Вот интересно, как будет выглядеть реализация meneged Fortran-90...
Скачай погляди.
MN>Когда M$ насаждала мне под какую ОС писть — я терпел,
А зря. Перешел бы на Линукс и терпел бы его. Воплей было бы может и не меньше, но точно не здесь.
MN> когда она насаждала мне технологии которыми пользоваться — я терпел,
Опять зря. Даже под Виндовс прекрасно работают куча многоплатформных библиотек. Используй их.
MN> когда она насаждала мне свои стандарты — я тоже терпел,
Опять зря. Есть куча не ее стандартов. Кстати, тебя не задевает, что МС навязывает и не свои стандарты? Ну, тот же ХМЛ...
MN> но теперь она пытается заставить меня писать на том языке, который удобен ей — извинте, но терпение кончается!
Где? Ты можешь вообще оставаться в каменном веке или использовать один из кучи совместмых с дотнетом языков. Хот тот же С++.
MN>Вообще всё это похоже на попытку отпилить сук на котором сидишь...
Уверяю тебя у МС с прагматичностью все ОК. Они никогда не сделают что-то, что уменьшит их доходы. Ну, по крайней мере по своей воли.
MN> Я вот не думаю, что вся армия Win-программистов выстроиться по струнке и как послушные собачки перейдут на C#, потому что так хочет Билли
Дык конечно нет. На C# перейдут разумные людю умеющие ценить нове. Кто-то воспользуется МС++, ВБ или другим совместимым с донетом язык. А кто-то посчитает, что ему достаточно старых технологий. Еще раз повторюсь, ВыньАПИ никто не отменяет. Просто будет еще один АПИ. Он боудет лучше, чем старый, но он не будет единственно возможным вариантом.
Я вот почему-то никак не могу помнять почему дотнет и ВиндвсФормс не раздражает борцов с МС, а ВинФХ раздражает. Вроде такая же библиотека только большая. Почему МС должен подстаиваться под разных догматиков. Они считают, что дотнет лучше подходит для этих библиотек и делают их на нем. Старый АПИ тоже сохраняют. Так в чем проблема?
MN>Ворота — читать здесь!
Ну, Джоэль все больше и больше становится ретраградом. Раньше он поспевал за новыми технологиями, но всему приходит конец. Стареет.
MN>Я скорее переориентируюсь под WEB или уйду в Unix — это будет проще,
Дык, это... Коммон! Дверь открыта. Думаю, ни МС, ни мы этого даже не заметим. К тому же стаким настроением лучше действительно поискть альтернативу. Потом, кстати, сможешь поделиться впечатлениями об безоблочной жизни в на передовом фронте.
MN> по крайней мере язык переучивать не надо будет.
Ну, да. Русский он и в Африке русский.
MN> Технологии в Longhorn`е всё равно новые для всех будут, а под Unix я хоть чуть-чуть да писал когда-то...
Дык! Логично. Новый технологии это только геморрой и лишние заботы. Командная строка живет вот уже 30 лет и ее отмены явно не планируется. Приложения для ее можно конечно и на XAML-е писать, но можно и по старинке на С с printf-ом. Только что ты это нам тут раскаазывашь? Ты лучше действуй!
... << RSDN@Home 1.1.4 beta 3 rev. 279>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Павел Кузнецов, Вы писали:
ПК>Не заводись Влад (осознанно, или нет) преувеличивает: из C++/CLI использовать новые API .Net будет по меньшей мере в той же степени удобно, как и из C# или VB.Net.
Да ничего я не преувеличиваю. О МС++ я уже говорил. Использовать можно и из него. Чуть мене удобно (шуму больше лишнего). Но в общем-то один хрен. Я это вроде сказал.
ПК>Не надо так эмоционально. Факт жизни состоит в том, что на деле MS делает для C++ достаточно много, чтобы сказать им за это спасибо. Да, еще достаточно недавно это было не так, но времена быстро меняются, и, имхо, это сложно не заметить.
Сдается мне, что для С++ МС ничего специально не делает. Просто — это коммерческая контора и она как и все кммерческие конторы работает на рынок. Короче С++ нужен МС так же как МС С++-у. Это нормальные рыночные взаимоотноешения.
ПК>Cool it Нравится писать на C++ — пиши на C++, не нравится — подбери себе язык по вкусу из доступных под .Net — благо, недостатка не видно, и чем дальше, тем больше. В частности, чтобы сделать удобной разработку под .Net на C++, команда VC++ потратила как минимум целый цикл разработки своего продукта. Ребята вложились от души, enjoy.
Да мужику дотнет явно не нравится. Даже используя C++/CLI ты будешь вынужден изучать новые подходы, АПИ и т.п. А это же ужасно! Это же посигательство на старческий маразм и другие возростные заслуги.
... << RSDN@Home 1.1.4 beta 3 rev. 279>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Mr. None, Вы писали:
MN>Самое смешное, что тут действительно больше эмоций, чем прагматичекой логики . Просто меня немного раздражает, когда люди начинают заявлять: типа через пару лет будет один .NET и все будут писать на шарпе ! Не будет и не будут. Я прекрасно понимаю, что M$ никогда (по крайней мере в ближайшие лет 5 — 10 точно) не сможет перевести полностью весь АПИ на .NET и при этом оставить обратную совместимость со всем, что было. А раз не смогут, то им будут продолжать пользоваться по крайней мере те, которым в силу особенности языка не удобно использовать .NET и менеджед расширения. И трюк, который МС провернула для замены Win16 на Win32 не пройдёт — тогда она не предлагали сотням тысяч программеров сменить основной язык, на котором они пишут...
Не, ну, это клиника. Ему говорят:
ВыньАПИ не отменяется.
А он:
...раздражает, когда люди начинают заявлять: типа через пару лет будет один .NET и все будут писать на шарпе...не удобно использовать .NET...
Да ради бога. Можешь писать без .NET или с .NET, но не на Шарпе. Если тебе религия не позволяет, так вообще вопросов нет. Колхох дело добровоельное. (с)
Я высказал простую вещь — хочешь новых технологий? Прийдется учеть дотнет. А пересев на дотнет Шарп просто на просто становится самым разумным выбором так как заточен под полатформу. Никто не заставляет. Это твой выбор. Большинство сделат выбор о котором я сказал (причем, это всего илшь мое предречение). Но если не хочется, то пути есть.
MN>Или будет как с OpenGL? Идеология OpenGL не совпадала с идеологией Windows в области графики и не совпадала с идеологией маркетингового отдела MS, которому больше нравился свой стандарт — Direct 3D. Но поддерживать OpenGL надо было, потому как иначе некузяво и решение было найдено — реализовать OpenGL как надстройку над Direct 3D и не важно, что "летающий" под Unix`ом OpenGL под Windows стал тормознее моей первой реализации алгоритма заливки методом Гуро.
Эту инсинуацию ты повторяешь уже постоянно. Это бред сивой кобылы! Даже я, человек очень долекий от 3D-графики прекрасно знаю, что OpenGL в видовс реализован в виде opengl32.dll и идеолокии инсталлируемых драйверо OpenGL:
installable client driver (ICD)
An OpenGL driver model in which the driver is responsible for implementing the entire OpenGL pipeline. Intended for high-end graphics cards that implement most of the OpenGL pipeline in hardware.
После создания этой библиотеки (лицензированной, кстати, у Силикон Графикс), МС вообще болше никакого отношения к нему не имела. Драйверы пишутся конторами производителями видио-коарт. Они же создают расширения OpenGL которые и привели на сегодня к несовместимости между реализациями OpenGL от NVidia и ATI.
Так что в ситуации с OpenGL (хреновой надо сказать) МС виноват толко в том, что не узурпировал право на стандартизацию расширений и не заставил всех плясать под свою дудку.
Ну, а пропреитаный стантдарт DirectX пройдя через ряд эволюциооных изменений стал на сегодня очень даже привлекательным АПИ. И народ с удовольствием использует его при проиводстве игр. Я лично уверен, что если бы МС реализовал DirectX для PS2, то OpenGL давно бы сдох.
MN>Итог, кто теперь использует OpenGL под Windows там, где нужна действительно быстрая графика?
Да действительно? Почти никто. DOOM3, Хроники райдека, HL2, FarCry. DOOM вообще ничего кроме OpenGL не понимают, остальные поддерживают и OpenGL и DirectX. Правда, некторые (FarCry) в OpenGL выгядят заметно хуже (блеклей и глючнее), но DOOM Хроники райдека исползуют OpenGL по умолчению и показывают FPS выше чем аналогичные игры для которых DirectX является первичным движком. Ну, еще DirectX — это не только Direct3D и тот же Ку задействовал другие подсистемы DirectX. Но уж тормознутость OpenGL в следствии эмуляции на DirectX — это бред сивой кобылы и не стоит повторять его как попка.
MN>А вот я слышал и этот слух ни как не опровергается отделом маркетинга MS (но надо отдать должное и не подтверждается — в духе совесткой дипломатии времён Карибского кризиса ), что MC++ в дальнейшем не будет ни развиваться, ни поддерживаться, и нужен он только для того, чтобы программисты пишушие на C++ легко перешли на .NET и в дальнейшем на C#... Типа demo-версия возможностей .NET для плюсов...
Странный ты человек. Если МС создаст язык, то поддерживать она будет обязана его в любом случае. Ну, а дальеше все зависит от спроса. Если народу приглянется МС++ в новой реинкорнации (на старый все уже давно забили толстый член), то зачем же МС будет губить выгоревшее дело? Все же они фанатов на робуту не берут. Там слава богу решают не программисты или маркетологи, а совет директоров и финансовый отдел.
... << RSDN@Home 1.1.4 beta 3 rev. 279>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, WolfHound, Вы писали:
WH>Вот не надо OpenGL работает также быстро как Д3Д если драйверы на видюху поставить. Причина тут в другом... дело в том что с OpenGL таже фигня что и с С++... Как нет двух одинаковых С++ компиляторов так и нет двух одинаковых OpenGL под разные видюхи... Загляни в тотже boost как там его учат работать с разными компиляторами... а потом вспомни что различных видюх гораздо больше чем С++ компиляторов...
Почти так. Но не совсем так. OpenGL один, так как это стандарт. Но OpenGL давно морально устарел и каждый передовой разработчик железа придумывает свои расширения к нему. Именно эти расширения и не совместимы.
... << RSDN@Home 1.1.4 beta 3 rev. 279>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Mr. None, Вы писали:
MN>Здравствуйте, WolfHound, Вы писали:
WH>>Здравствуйте, Mr. None, Вы писали:
WH>>Вот не надо OpenGL работает также быстро как Д3Д если драйверы на видюху поставить. MN>Тогда объясните мне, почему под тем же Linux`ом со скоростью у него всегда было всё впорядке, даже пошустрее Д3Д был.
Класс! Д3Д под Линукс! Супер.
Кочай бредить и зпусти тот же FarCry в OpenGL и Direct3D режимах. Уверяю тебя, что ты не заметишь разницу в скорости. Мне лично даже временами казалось, что OpenGL чуть быстрее. Но как потом оказаолось (по тестам), что это иллюзия.
MN> И реализации первые у него были софтовые, а не аппаратные.
У кгого? Ни OpenGL, ни Direct3D не могут с приемлемой скоростью работать в софтверном режиме. Сфтового режима хватает разве что для скринсейверов.
К тому же OpenGL и Direct3D просто не поддерживают многие функции если нет аппаратного ускорения. Да и создавались они оба в рассчете на железо. OpenGL был разработан как раз конторой поставщиком железа. Про Силикон Графикс слышал? Вот она его из изобрела для своих рабочих станций предназначенных для 3D-визуализации.
MN> Даже игры полностью на нём пишут...
Можно пример хотя бы одно такой полноценной?
MN> А под виндой драйвера нужны, аппаратная поддержка, а если нет ни того ни другого — пожалуйста юзай как прослойку над Д3Д или вообще GDI...
Да нет никакой прослойки. Просто кто-то написал драйвер транслирующий OpenGL в Direct3D. Сделано это было явно для пурощения себе жизни. Но насколько я знаю, ни АТИ, ни НВидиа такого не делали. А родной вариант исключительно софтверный. Никакие игры на нем не пойдут.
MN>Это сейчас он может быстро работает, если есть аппаратная поддержка, а когда я его впервые использовал (5 лет назад) — тормоза аткие были, что просто атас!
Очередной бред. 5 лет назад был 2000 год и железа было море. Появилась opengl32.dll в NT 4.51 в 95 году (если не ошибаюсь). Тогда о Direct3D даже слухов не ходило, но появился opengl32.dll имено как софтверная реализация. И сделали ее как я понимаю спецы из Силикона.
ЗЫ
В общем, бредовейшие наезды в стиле "почему МС не делает так как я хочу?", или "МС козлы все опошлили".
В общем, сваливай на Линукс. Там трова зеленее и небо голубее. А главное там не накого валить. Даже если ты придумашь очередную сказку, то всем будет хэть бы потому как все фо-фан и всем не тебя плевать.
... << RSDN@Home 1.1.4 beta 3 rev. 279>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, DEMON HOOD, Вы писали:
DH>Самое смешное, что совсем недавно тоже самое говорили программисты на асм про с/с++ и другие не асм языки
Логично, блин. Ситуация то один в один. И что характино писать программы на асме можно до сих пор. И люди это стараются не делать исклчительно по соображениям лени.
... << RSDN@Home 1.1.4 beta 3 rev. 279>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
AndrewVK,
> Ш> Помнится, Влад тут с пеной у рта доказывал, что, С# отпарсить куда сложнее, чем C++.
> Он утверждал что грамматика сложнее, а не что отпарсить сложнее.
Если под сложностью понимать класс грамматики по Хомскому, то в подавляющем количестве случаев это одно и то же.
Posted via RSDN NNTP Server 1.9
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Здравствуйте, Павел Кузнецов, Вы писали:
ПК>Если под сложностью понимать класс грамматики по Хомскому, то в подавляющем количестве случаев это одно и то же.
Да нет. Ту как минимум еще фигурирует разрешение ссылок, а вот в этом С++ на порядок сложнее шарпа.
Здравствуйте, Павел Кузнецов, Вы писали:
ПК>Если под сложностью понимать класс грамматики по Хомскому, то в подавляющем количестве случаев это одно и то же.
Я все жду когда ты начнешь понимать слова буквально не доводя их до состояния вакумсферокоников.
Сложнее граматика, значит сложнее граматика. Значи, что у нее больше объем и больше деталей. Я никогда не утверждал, что C# проще парсить чем С++. Шахтер просто как всегда в своем репертуаре. Впрочем как и ты.
... << RSDN@Home 1.1.4 beta 3 rev. 279>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Cyberax, Вы писали:
C>В Win3.11 такой роскоши не было, т.к. ядро было 16-битным, так что OGL C>работал просто как клиент GDI. В Win9x/NT (и в Win32s) возможность C>прямого доступа к поверхностям появлась сначала в виде WinG, а потом и C>DirectDraw. На а Direct3D был вполне логичным шагом развития после C>DirectDraw. OGL так и не стали апгрейдить (а зачем?) — не нужно было.
Блни, прототип OpenGL был разработан SGI (Silicon Graphics) исключительно для свого железа! OpenGL был разработан на его базе и предоставлял так же софтверную эмуляцию. Именно вариант софтверной эмуляции и был включен в виндовс в начале девяностых. Причем большинство приложений ни тогда, ни теперь не могли/могут работать на базе софтверной версии. Ну, а сегодня уже прктически не осталось видио карт для который не было разработано ICD-драйверов.
Здравствуйте, VladD2, Вы писали:
VD>Сложнее граматика, значит сложнее граматика. Значи, что у нее больше объем и больше деталей. Я никогда не утверждал, что C# проще парсить чем С++. Шахтер просто как всегда в своем репертуаре. Впрочем как и ты.
Воздержись от личных оценок pls. Особенно от столь категоричных.
AndrewVK,
> ПК> Если под сложностью понимать класс грамматики по Хомскому, то в подавляющем количестве случаев это одно и то же.
> Да нет. Ту как минимум еще фигурирует разрешение ссылок, а вот в этом С++ на порядок сложнее шарпа.
Сложность в компиляцию C++ привносит не само по себе разрешение имен, а его влияние на разбор (равно как и аналогичное взаимодействие других аспектов языка с разбором). Собственно, это и означает изменение класса грамматики, а именно невозможность описания синтаксиса C++ контекстно-свободными грамматиками. По-моему у меня deja vu: мы это уже подробно обсуждали
Posted via RSDN NNTP Server 2.0 alpha
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, Павел Кузнецов, Вы писали:
ПК>>Если под сложностью понимать класс грамматики по Хомскому, то в подавляющем количестве случаев это одно и то же.
VD>Я все жду когда ты начнешь понимать слова буквально не доводя их до состояния вакумсферокоников.
VD>Сложнее граматика, значит сложнее граматика. Значи, что у нее больше объем и больше деталей. Я никогда не утверждал, что C# проще парсить чем С++. Шахтер просто как всегда в своем репертуаре. Впрочем как и ты.
Здравствуйте, Шахтер, Вы писали:
VD>>Сложнее граматика, значит сложнее граматика. Значи, что у нее больше объем и больше деталей. Я никогда не утверждал, что C# проще парсить чем С++. Шахтер просто как всегда в своем репертуаре. Впрочем как и ты.
Ш>Это что, оговорка по Фрейду?
Ну, в общем, это я тоже не утверждал.
... << RSDN@Home 1.1.4 beta 3 rev. 279>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Почти так. Но не совсем так. OpenGL один, так как это стандарт. Но OpenGL давно морально устарел и
стандарт OpenGL 2.0 видели?
VD>каждый передовой разработчик железа придумывает свои расширения к нему.
Лучше уж так, чем ждать пока MS "разродится" на новую версию Direct3D.
VD>Именно эти расширения и не совместимы.
Для этого и есть ARB, которая так сказать "сертифицирует" расширения и стандартизирует их в виде GL_ARB_xxx
Здравствуйте, Павел Кузнецов, Вы писали:
ПК>Сложность в компиляцию C++ привносит не само по себе разрешение имен, а его влияние на разбор (равно как и аналогичное взаимодействие других аспектов языка с разбором).
Это уже не важно. Я не о грамматике говорил, а о том что то в чем Влада обвинили он не говорил.
ПК>По-моему у меня deja vu: мы это уже подробно обсуждали
Здравствуйте, VladD2, Вы писали:
VD>Не, ну, это клиника. Ему говорят: VD>
ВыньАПИ не отменяется.
VD>А он: VD>
...раздражает, когда люди начинают заявлять: типа через пару лет будет один .NET и все будут писать на шарпе...не удобно использовать .NET...
Народ просто путает .НЕТ и язык программирования.
кричит Винапи — рулез, Винапи — рулез. А чем винапи отличается от .НЕТ? по большому счёту ничем — и то и другое набор функций (подпрограмм/библиотек итп) для управления ОС и компьютером.
... <<silent RSDN@Home 1.1.4 beta 4 [303] Windows XP 5.1.2600.0 >>
Здравствуйте, DEMON HOOD, Вы писали:
DH>Народ просто путает .НЕТ и язык программирования. DH>кричит Винапи — рулез, Винапи — рулез. А чем винапи отличается от .НЕТ? по большому счёту ничем — и то и другое набор функций (подпрограмм/библиотек итп) для управления ОС и компьютером.
Вообще то, это называется WMI. А WinApi и .NET — несколько другие вещи
Здравствуйте, ZayatsZ, Вы писали:
ZZ>стандарт OpenGL 2.0 видели?
Нет.
VD>>каждый передовой разработчик железа придумывает свои расширения к нему. ZZ>Лучше уж так, чем ждать пока MS "разродится" на новую версию Direct3D.
Нет уж. Лучше вообще никак, чем так. К тому же МС как раз очень оперативно выпускает подверсии. Тот же 9.0c был одновремнно с 6-ыми Джифорсами.
Проблема только в том, что стандарт не многоплатфрмный и основан на КОМ.
ZZ>Для этого и есть ARB, которая так сказать "сертифицирует" расширения и стандартизирует их в виде GL_ARB_xxx
В итоге многие разработчики просто забивают на OpenGL и выбирают Direct3D в качестве основного движка.
Стандарты должны быть не посфактом, а опережать железячников. Это прогрмаммисты должны делать стандарт (что им нужно), а не железячники узаконивать пропроитарные фичи.
Тот же Кармак (оголтелый поборник OpenGL) в последнее время все больше и больше сетует на слишком большую разницу между фичами поддерживаемыми производителями.
... << RSDN@Home 1.1.4 beta 3 rev. 279>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Mika Soukhov, Вы писали:
DH>>Народ просто путает .НЕТ и язык программирования. DH>>кричит Винапи — рулез, Винапи — рулез. А чем винапи отличается от .НЕТ? по большому счёту ничем — и то и другое набор функций (подпрограмм/библиотек итп) для управления ОС и компьютером.
MS>Вообще то, это называется WMI. А WinApi и .NET — несколько другие вещи
тьфу ты!
мне нужно отобразить обычное окно с заголовком. Как? —
1. Рисовать самому.
2. Взять ф-ю из винапи
3. Взять ф-ю из .нет
WMI это также часть винапи, или нет?
в чём разница WinApi и .NET ?
... <<silent RSDN@Home 1.1.4 beta 4 [303] Windows XP 5.1.2600.0 >>
Здравствуйте, Mika Soukhov, Вы писали:
MS>Это как, фломастером по монитору?
DH>>в чём разница WinApi и .NET ? MS>Первая — это набор функций. Вторая — среда... Вообще, я думал Влад уже всем давно объяснил, что такое .NET, а тут еще работать да работать
по большому счёту (если не вдаваться в детали) и то и другое набор функций.
... <<silent RSDN@Home 1.1.4 beta 4 [303] Windows XP 5.1.2600.0 >>
Здравствуйте, DEMON HOOD, Вы писали:
DH>>>в чём разница WinApi и .NET ? MS>>Первая — это набор функций. Вторая — среда... Вообще, я думал Влад уже всем давно объяснил, что такое .NET, а тут еще работать да работать
DH>по большому счёту (если не вдаваться в детали) и то и другое набор функций.
Здравствуйте, Mr. None, Вы писали:
MN>Это не всегда возможно... MN>Пример. Фортран: основная идеология и достоинство — очень быстрые вычисления. Все его внутренние библиотеки и компиляторы оптимизированы именно на это. Ради этого выкидывается всё, что может затормозить — проверки, универсальность; он даже динамическую память не поддерживает (по крайней мере до Фортран-80 было именно так... что там с Фортран-90 не знаю
в 90-ом есть дин.память
MN> как следствие в нём нет понятий указателей,
ну в общем есть (с 90)
MN>классов
есть в 2003
MN> сохранить основное достоинство — быстрые вычисления (скажем любая проверка на выход за границы массива уже противоречит этой идеологии).
кстати, в последних интеловских фортранах есть ключ -CB (array bounds checking), так что...
мне кажется, что мы друг друга не понимаем. попытаюсь пояснить, что я имел в виду на следующем примере —
сравним мушкет и автомат Калашникова, сравнивать их по большому счёту бесполезно — они значительно разняться (по внешнему виду, принципу работы, и т.д.), однако есть один показател который их обьеденяет — и то и другое это огнестрельное оружие.
... <<silent RSDN@Home 1.1.4 beta 4 [303] Windows XP 5.1.2600.0 >>
Здравствуйте, DEMON HOOD, Вы писали:
DH>Здравствуйте, Mika Soukhov, Вы писали:
DH>мне кажется, что мы друг друга не понимаем. попытаюсь пояснить, что я имел в виду на следующем примере — DH>сравним мушкет и автомат Калашникова, сравнивать их по большому счёту бесполезно — они значительно разняться (по внешнему виду, принципу работы, и т.д.), однако есть один показател который их обьеденяет — и то и другое это огнестрельное оружие.
Да понял я тебя, понял. Просто без шуток на такие топики отвечать не могу
В первый раз я сказал, что .NET — это среда. Одой из ее составляющей является FCL (framework common library). Вот ее можно сравнивать с WinApi, но не весь .NET. Представь себе такую ситуацию. Есть двухмерный вектор, а есть трехмерный. Каким образом их можно сравнивать (например, умножать)? Да никак.
Теперь насчет названия данного топика. WinFX — это новый API, но написанный на .NET. Как теперь сравнивать инструмент и изделие, изготвленное с помощью данного инструмента? Опять же — никак.
. Для программистов сделан вот этот ресурс: http://WinFX.msdn.microsoft.com/
! Не будет и не будут. Я прекрасно понимаю, что M$ никогда (по крайней мере в ближайшие лет 5 — 10 точно) не сможет перевести полностью весь АПИ на .NET и при этом оставить обратную совместимость со всем, что было. А раз не смогут, то им будут продолжать пользоваться по крайней мере те, которым в силу особенности языка не удобно использовать .NET и менеджед расширения. И трюк, который МС провернула для замены Win16 на Win32 не пройдёт — тогда она не предлагали сотням тысяч программеров сменить основной язык, на котором они пишут...
), что MC++ в дальнейшем не будет ни развиваться, ни поддерживаться, и нужен он только для того, чтобы программисты пишушие на C++ легко перешли на .NET и в дальнейшем на C#... Типа demo-версия возможностей .NET для плюсов...
