Здравствуйте, Евгений Акиньшин, Вы писали:
ЕА>.net 4.5 так и делает, собирает статистику, а потом в бекграунде ngen-ит, то что часто используется
Это ты про их сервисы типа clr_optimization_vXXXXX ?
Здравствуйте, MxMsk, Вы писали:
MM>Теперь берем WPF. Каждый чекбокс оказывается отдельным контролом. Контрол поддерживает шаблоны, предугадать его внешний вид нереально. Я могу туда хоть таб-контрол запихнуть! Целостной картины тоже нет. Всё это впихнуто в грид, который тоже контрол со своими заморочками. Свободы для оптимизации значительно меньше. Зато фич по кастомизации больше. За них и платим.
O. M. F. G.!
Робяты, вам не кажется что вас где то жестоко нае....?
Вы по сути выкладываете дофига сил на борьбу с "фичами по кастомизации".
Умный человек так и не ответил на поставленный самому себе вопрос: "Зачем распространять скомпилированные программы в виде IL?"
Мистер Кэп подсказывает, что есть общепринятое объяснение — это кроссплатформенность бинарного кода, оптимизации под конкретный процессор (в теории), и profile-based оптимизации.
Вместо этого Умный человек рассказывает про Intermediate Language и разделение на frontend/backend — то, что начали использовать ещё чуть ли не с 60-х годов.
Здравствуйте, Eugeny__, Вы писали:
E__>Даже не в в плохой час упомянутая джава, у которой это и контролы с каждым окошком для каждого(прада, внутренним жабовским, а не нативными, но плюс ли это?), и сложная модель для отрисовки запрашивается каждый раз, и еще и рисуется это на канвасе интерпритатором, без всякого ускорения, на этом если и притормаживает, то только из-за пресловутой отрисовки на канвасе без нативы, точечка-по-точечке в интерпритируемом коде. А то и вовсе не тормозит, смотря какой комп. Чего там напихали в тот ВПФ, у которого отрисовка вообще видеокартой идет, я не знаю.
Мы уже выяснили, что это я пытался бороться с ветрянными мельницами, а их оказывается и нет. В том плане, что когда не фантазируешь, а бацаешь пример, то ничего не тормозит. Поэтому, нужно узнать, что такого специфического сделал автор. Видимо там есть какое-то условие, приводящее к тормозам. Может он эффекты битмэповые накатил — они переводят отрисовку в программную и сейчас уже obsolete. О! Я тут подумал. А может быть у него Binding-и слетели и Студия постоянно пишет об этом сообщения в Trace? Это может вызывать тормоза при отладке, которых в Release, естественно, нет.
Кстати, я вот не однократно замечаю, что многие люди в спорах типа Java или .Net против Native зацикливаются на байткоде. Т.е. одни говорят что это самое классное, а другие на оборот ругают его... В то время как на мой взгляд это вообще ерунда. И кстати появление llvm это только подтверждает. Принципиальное отличие Java и .Net от нативных языков в том, что они по сути испольняются в своей виртуальной машине, которая накладывает огромные ограничения. А вот в каком виде у нас код не имеет особого значения. В отдельных случаях удобнее байткод просто, в каких-то байткод с jit, а в каких-то и машинные коды. И это по идее одинаково должно быть для всех языков и платформ. Просто в зависимости от специализации языка какие-то направления у него могут быть слабее развиты.
Здравствуйте, alex_public, Вы писали:
_>Кстати, я вот не однократно замечаю, что многие люди в спорах типа Java или .Net против Native зацикливаются на байткоде. Т.е. одни говорят что это самое классное, а другие на оборот ругают его... В то время как на мой взгляд это вообще ерунда. И кстати появление llvm это только подтверждает. Принципиальное отличие Java и .Net от нативных языков в том, что они по сути испольняются в своей виртуальной машине, которая накладывает огромные ограничения. А вот в каком виде у нас код не имеет особого значения. В отдельных случаях удобнее байткод просто, в каких-то байткод с jit, а в каких-то и машинные коды. И это по идее одинаково должно быть для всех языков и платформ. Просто в зависимости от специализации языка какие-то направления у него могут быть слабее развиты.
_>Кстати, я вот не однократно замечаю, что многие люди в спорах типа Java или .Net против Native зацикливаются виртуальной машине. Так вот никакой виртуальной машины нет. Байткод компилируется непосредственно в машинный код. Также существует расхожее заблуждение что "виртуальная машина" что-то ограничивает. Но по сути она дает даже больше возможностей. Например генерация типобезопасного кода во время работы программы. Оптимизация динамически типизированного кода. И даже банальную возможность возвращать из функции лямбду с честным замыканием.
Здравствуйте, Kingofastellarwar, Вы писали:
K>Здравствуйте, Uzumaki Naruto, Вы писали:
UN>>Рассмотрим на примере java... все работает прекрасно на всех платформах...
K>прекрасно это как? я лично не видел ни одного приложения на жаве, которое прекрасно работало хотя б под линухом, вендой и макосью.
UN>>Рассмотрим правильное кроссплатформеное программирование под С/C++ — все прекрасно компилируется под любые платформы — от PC до мобильных...
K>ясное дело что оно комплируется, заставить скомпилирвоать можно всё, тока вот писать на таком не тянет совсем.
Я в эклипсе и под виндой и под линуксом работаю. Что не так с ним?
UNIX way — это когда тебе вместо туалетной бумаги дают топор, рубанок и карту близлежащего леса
Server Error in '/' Application.
Runtime Error
Description: An application error occurred on the server. The current custom error settings for this application prevent the details of the application error from being viewed remotely (for security reasons). It could, however, be viewed by browsers running on the local server machine.
Здравствуйте, esil, Вы писали:
E>Здравствуйте, _d_m_, Вы писали:
___>>Не порите чушь, ей больно! ___>>Вот лучше почитай, что умные люди пишут: ___>>http://blogs.msdn.com/b/ruericlippert/archive/2011/12/01/why-il.aspx
E>Умный человек так и не ответил на поставленный самому себе вопрос: "Зачем распространять скомпилированные программы в виде IL?"
Вот эта фраза тебе ни о чем не говорит? :
Предположим, у вас есть несколько языков программирования: C#, VB, F#, JScript .NET и т.д. И, предположим, у вас есть m сред времени выполнения: компьютеры с ОС Windows, работающие на процессорах x86 или x64, XBOX 360, телефоны, Silverlight, работающий на Мак-е… и предположим, что мы используем подход с одним компилятором. Какое количество генераторов кода вам придется написать внутри вашего компилятора? Для каждого языка программирования вам придется написать кодогенератор для каждого окружения, в результате, придется написать n x m генераторов.
Здравствуйте, gandjustas, Вы писали:
G>Здравствуйте, alex_public, Вы писали:
_>Кстати, я вот не однократно замечаю, что многие люди в спорах типа Java или .Net против Native зацикливаются виртуальной машине. Так вот никакой виртуальной машины нет. Байткод компилируется непосредственно в машинный код. Также существует расхожее заблуждение что "виртуальная машина" что-то ограничивает. Но по сути она дает даже больше возможностей. Например генерация типобезопасного кода во время работы программы. Оптимизация динамически типизированного кода. И даже банальную возможность возвращать из функции лямбду с честным замыканием.
Это был бы хороший, годный троллинг, если бы не очевидные ляпы как по форме, так и по содержанию. По форме — ты не снял квотинг (кстати, тут за него начали штрафовать). По содержанию — это грубо неверно. Байткод может не компилироваться в машинный код, а исполняться интерпретатором с выбором ветки на каждый байт. Виртуальная машина действительно ограничивает, даже если даёт больше возможностей на что-то другое. А перечисленные тобой возможности относятся к функциональным дополнениям, которые можно сделать и самому, если машина в принципе это позволяет; это не увеличение набора возможностей, а помощь в реализации существующих.
Здравствуйте, _d_m_, Вы писали:
___>Вот эта фраза тебе ни о чем не говорит? :
___>
___>Предположим, у вас есть несколько языков программирования: C#, VB, F#, JScript .NET и т.д. И, предположим, у вас есть m сред времени выполнения: компьютеры с ОС Windows, работающие на процессорах x86 или x64, XBOX 360, телефоны, Silverlight, работающий на Мак-е… и предположим, что мы используем подход с одним компилятором. Какое количество генераторов кода вам придется написать внутри вашего компилятора? Для каждого языка программирования вам придется написать кодогенератор для каждого окружения, в результате, придется написать n x m генераторов.
Не очень понятно всё же причём тут рассуждения про байткод и вопрос кроссплатформенности. Или вы считаете что наличие возможности компиляции в байткод, единый для разных архитектур, является главным фактором кроссплатформенности? При таком подходе ооооооооооооочень много языков и технологий можно посчитать за кроссплатформенные. Только на практике почему то не так это.
Там про двоичную совместимость вообще ни слова. Хотя, фантазии, заменяющие тебе процесс мышления, никогда не дадаут тебе возможность это увидеть. S>Ты пытаешься свернуть дотнет практически до "это просто язык шарп и куча библиотек, шарп — язык и кроссплатформенность ему ортогональна, а библиотеки это библиотеки, они к языку отношения не имеют"
А что, не так?
Почему-то, когда речь заходит о С++ все так, а тут ВНЕЗАПНО не так.
S>Нет уж, тут котят от котлет не отделишь. Есть дотнет. Есть моно. Это не одно и тоже.
Есть intel c++ compiler, есть gcc, есть microsoft c++ compiler. Это не одно и то же
Есть кроссплатформенный Qt, есть чисто виндовый MFC и чисто линуксовые, скажем, KDE'шные библиотеки. Это тоже не одно и то же.
Но при этом С++, по твоим же уверждениям, кроссплатформенный. Для тебя это нормально.
Как только примняешь ту же логику к .net'у, у тебя моментально включаются двойные стандарты.
Уж сколько раз говорили, что переносимость байт-кода нафиг не вперлась без переносимых абстракций. Без них не получиться писать кроссплатформенный софт, а ожидать таких подвижек от МС это сильно нужно верить в гномов и единорогов. Переносимость же по всея виндоус это просто насмешка над кроссплатформенностью. Почему то весь кроссплатформенный софт, которым я пользуюсь на разных системах написан на С++ и FreePascal, и им нафиг не уперся байт-код — у них есть переносимые абстракции.
Там про двоичную совместимость вообще ни слова. Хотя, фантазии, заменяющие тебе процесс мышления, никогда не дадаут тебе возможность это увидеть.
M> S>Ты пытаешься свернуть дотнет практически до "это просто язык шарп и куча библиотек, шарп — язык и кроссплатформенность ему ортогональна, а библиотеки это библиотеки, они к языку отношения не имеют"
M> А что, не так?
M> Почему-то, когда речь заходит о С++ все так, а тут ВНЕЗАПНО не так.
Мамут, а тебе слово Framework ни о чем не говорит? Я думал, ты это понял, два года назад.
Здравствуйте, gandjustas, Вы писали:
g>Кстати, я вот не однократно замечаю, что многие люди в спорах типа Java или .Net против Native зацикливаются виртуальной машине. Так вот никакой виртуальной машины нет. Байткод компилируется непосредственно в машинный код. Также существует расхожее заблуждение что "виртуальная машина" что-то ограничивает. Но по сути она дает даже больше возможностей. Например генерация типобезопасного кода во время работы программы. Оптимизация динамически типизированного кода. И даже банальную возможность возвращать из функции лямбду с честным замыканием.
Да, кое-какие небольшие плюсы от неё есть. Помню как меня порадовала возможность динамической загрузки классов в программу, когда я впервые стал смотреть на Java. Но все они являются как бы не уникальными — в нейтиве всё тоже самое возможно, просто с помощью отдельных технологий (типа COM например).
А вот ограничения "виртуальной машины" у Java и .Net огромные и главное принципиально не устранимые никакими дополнениями...
Здравствуйте, alex_public, Вы писали:
_>А вот ограничения "виртуальной машины" у Java и .Net огромные и главное принципиально не устранимые никакими дополнениями...
Можно перечислить основные ограничения "виртуальной машины" дотнета?
M>> Почему-то, когда речь заходит о С++ все так, а тут ВНЕЗАПНО не так.
H>Мамут, а тебе слово Framework ни о чем не говорит? Я думал, ты это понял, два года назад.
При таком подходе ооооооооооооочень много языков и технологий можно посчитать за кроссплатформенные. 
