Просто подтверждает, что для написания быстрых программ на C++ нужен IQ выше среднего, не более того.
Если есть быстрая реализация на C, ВСЕГДА можно создать эквивалентную по производительности на С++. Если авторы этого делать не стали и поюзали std::string, исключения и т.п. где надо и где не надо, это их проблемы...
Здравствуйте, Vamp, Вы писали:
V>Это вряд ли случится.
Ну теоретически это может случиться, если у кого нибудь найдется эдак пара сотен триллионов лишних баксов.
Вот когда случится тогда и будем погребальные оды петь.
А пока на моей машине стоит IA проц и все та же унылая винда с кучей софта на плюсах, с какой-то мизерной долей гуя .NET-овского WinForms-а от которого больше лагов чем пользы.
Яву на своей машине вообще не нашел, хотя на линухе наверно она вместо NET-а.
Где у меня тут всякие эрланги питоны я вообще хз.
И каждую неделю я качаю обновления все тех же плюсовых программ,
ковыряю файлы в плюсовом Far-е,
ползаю в интернете в плюсовых браузерах,
таскаю иконки в плюсовом проводнике,
рисую в плюсовом фотошопе и Xar-е,
слушаю музыку и смотрю фильмы в плюсовых плеерах,
пишу документы в плюсовых редакторах,
строю модели в плюсовом матлабе и maple,
шлю мессаги в плюсовой аське и скайпе,
проверяю файлы плюсовым антивирусом,
пишу плюсовый код и компилю его плюсовым компилятором,
даже играю иногда в плюсовые игры,
и по прежнему ничего не меняется, все так же пишут на кривом и ненужном C++.
Различий между C и C++ я вообще не вижу, второе — это улучшенное первое,
ну да согласен, улучшенное можно в кавычки взять, не удачно вышло, но ниче, привыкли слава богу.
Современная ахритектура IA кстати чем то напоминает улучшенный C
Столь же кривая и изуродованная обратной совместимостью, но и она почему-то прижилась больше остальных.
Мне вообще кажется, что на уродство обречен любой язык или архитектура если они обретают популярность.
Ибо ничто так не уродует архитектуру, как последующее неограниченное расширение с обратной совместимостью.
Давайте выкинем все это нафик и перепишем на новых хороших, правильных и быстрых языках! Да, давайте!
Проект Google Re2 (C++) — успешная попытка [вос]создать промышленный regex движок, свободный от экспоненциальной зависимости от входных данных. Этот проект, выполненный Рассом Коксом (Russ Cox), дал возможность гуглу эффективно выполнять поиск по регулярным выражениям в программном коде, найденном гуглом в интернете...
В сентябре 2010 мир пополнится ещё одним таким must-read ресурсом по регулярным выражениям. Пьеса (!) A Play on Regular Expressions (http://sebfisch.github.com/haskell-regexp/regexp-play.pdf) (via antilamer) описывает создание ленивого, чисто функционального алгоритма, основывающегося на всё том же подходе превращения регулярки в конечный автомат. Описанный в статье алгоритм позволяет строить матчер выражений, поддерживающий любые контекстно-свободные (sic!!) грамматики.
Алгоритм, и соответствующая ему имплементация, Weighted RegExp Matching на простых выражениях обычно медленнее, чем другие библиотеки типа pcre, но у неё асимптотически лучшее поведение: O(nm) от длины входных данных и размера выражения. Пользуясь ленивостью, на некоторых бенчмарках (.*a.{20}a.*) эта Haskell-имплементация обгоняет Re2, описанный выше, по абсолютному времени выполнения.
Самое интересное, что тот же алгоритм был написан ещё и на C++ и Java, и на Java получился в два раза быстрее, несмотря на то, что алгоритм очень хорошо ложится на ОО, и может быть переносим между ОО-языками без особых изменений:
Implementation язык chars/s speedup over pure Python
Pure Python code Python 12'200 1
Python re module C 2'500'000 205
Google's re2 implementation C++ 550'000 45
RPython implementation
translated to C Python 720'000 59
C++ implementation C++ 750'000 61
Java implementation Java 1'920'000 157
RPython implementation
with JIT Python 16'500'000 1352
Это, в частности, подтверждает тезис о том, что C++ не нужен: современные языки с GC и JIT просто уделывают его на традиционных для C/C++ задачах.
Комментарии по ссылке тоже рулят, но, просьба, не набегать туда, а ограничиться КСВ
Здравствуйте, SpaceConscience, Вы писали: SC>Чувак, извини, я же не знал, что у тебя такие серьезные проблемы с мышлением,
Не нужно извинений. Наоборот, это я прошу меня извинить за то, что докучаю вам своими серьезными проблемами с мышлением.
SC>а то я бы не стал писать такое длинное сообщение.
Нет, сообщение явно написано не зря; уверен, что многие прочитают его с огромным удовольствием.
SC>Извини, сочувствую.
Спасибо за сочувствие, надеюсь, что в следующий раз побеседуем так же приятно.
... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>
'You may call it "nonsense" if you like, but I'VE heard nonsense, compared with which that would be as sensible as a dictionary!' (c) Lewis Carroll
Здравствуйте, Mamut, Вы писали:
M>...Это, в частности, подтверждает тезис о том, что C++ не нужен: современные языки с GC и JIT просто уделывают его на традиционных для C/C++ задачах.
Для начала ты начни пользоватся веб браузером, написанном от начала до конца на языке с GC, а потом на нем же пиши посты что c/c++ не нужен.
Здравствуйте, SpaceConscience, Вы писали:
SC>Вот я участвую в разработке программы на C++, а мне говорят, что C++ не нужен.
SC>И что мне теперь делать?
Ничего. На RSDN это "тренд": говорить о ненужности C++. Раньше или позже к таким разговорам привыкаешь, как к снегу зимой. Даже забавно иной раз.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, Mamut, Вы писали: M>Это, в частности, подтверждает тезис о том, что C++ не нужен: современные языки с GC и JIT просто уделывают его на традиционных для C/C++ задачах.
Я так понимаю, у pypy регекспы поддерживаются jit-ом, т.е. конпелируются в машинный код. Наверняка что-то подобное сделано в жаве. А имплементация гугла на плюсах — это интерпретатор. Конпеляция в очередной раз победила интерпретацию. Ура-ура.
Здравствуйте, gandjustas, Вы писали:
MC>>Ах, да. Плюсы, GC, КСВ при чем тут они? G>Да все притом. Подход с компиляцией регэкспов в машинный код на С++ невозможен (или очень проблематичен).
LLVM
Было бы интересно сделать на ней генерацию конечного автомата и посмотреть что получится.
Здравствуйте, CreatorCray, Вы писали:
CC>Здравствуйте, gandjustas, Вы писали:
G>>>>Подход с компиляцией регэкспов в машинный код на С++ невозможен (или очень проблематичен). CC>>>С какого перепугу то? CC>>>Если компиляция в байт код возможна то почему вдруг невозможно сгенерить машинный код? CC>>>Это будет банальный JIT. G>>Ну так напиши. G>>Говорить можно что угодно, а JIT для С++ пока еще никто не изобрел. CC>А нам и не надо JIT для компилируемого языка. Нам надо JIT для байт кода, который сгенерит regex по строке паттерна.
Да пофигу. Даже гугл неспособен такое сделать, не надо мне доказывать что это несложная задача.
Здравствуйте, SpaceConscience, Вы писали:
SC>Вот я участвую в разработке программы на C++, а мне говорят, что C++ не нужен.
На RSDNъ и дня не проходитъ без аналогiчнаго безответствъннаго заявленiя. Неровен час, скоро молодые да раннiя девълоперы начнут говорить, что КОБОЛЪ устарелъ и более не нуженъ.
SC>И что мне теперь делать?
Делай что будетъ — и будетъ как должно!
... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>
'You may call it "nonsense" if you like, but I'VE heard nonsense, compared with which that would be as sensible as a dictionary!' (c) Lewis Carroll
Здравствуйте, Codechanger, Вы писали:
C>C++ перестанет быть нужен, когда на управляемых языках можно будет писать драйвера и другие низкоуровневые штучки-дрючки, т.е. ядро ОС будет написано на управляемом языке.
Если посмотреть выше по теме то там различают Си и С++. Си ближайшие десятилетия точно ничто не грозит
Хотя я думаю C++ за него тоже крепко вцепится
На управляемом языке в ближайшие десяток-другой лет OS кроме нишевых не будет, слишком гигантский объем как самой работы по написанию OS
так и еще на порядки больший существующего прикладного кода, это тысячи человеко лет и десятки миллиардов долларов, просто не окупится.
C>Мнится мне, в ближайшие несколько лет какая-нить из виртуальных машин будет реализована в процессоре на аппаратном уровне.
Игрались и с lisp машинами и forth машинами и java машинами начиная с 60 годов.
В результате по цене/производительности выиграл универсальный процессор + хороший оптимизатор.
Здравствуйте, SpaceConscience, Вы писали:
SC>Вот я участвую в разработке программы на C++, а мне говорят, что C++ не нужен.
SC>И что мне теперь делать?
Скажи работадателю, что С++ не нужен и приведи в качестве аргументов вышеповешенные тесты
Здравствуйте, MxMsk, Вы писали:
MM>Предлагаешь мне выложить сюда все типы из System.Windows.Media.Composition? Полный список смотри Рефлектором, а здесь будь добр, подтверди свои слова о том, что "Все структуры и константы, описывающие примитивы, преобразования и т.д. — напрямую из DirectX"
Раз уж пошла такая пьянка, опять взял в руки шашки, хоть и не люблю WPF.
Да, насчет "всех" погорячился, согласен. Подробно рассматривал WPF в 2006-м, мог детали забыть. Однако, прекрасно помню, что глаз цеплялся за много чего до боли знакомого из DirectX.
Опять же, с чего начался и о чем идет спор? Меня пытались убедить, что низкоуровневый лейаут выполняется в нейтиве. Это не так. Или как минимум путаница терминов. Нейтивный хелпер даже не производит отображение визуального дерева на сцену из DirectX (!!!). Т.е. ни то что лейаутом, он даже рендерингом не занимается (повторюсь, за исключением старой версии Effects, которые выполнялись основным процом, а не видюхой, тут действительно обсуждаемый нейтив-хелпер участвовал, но это скорее минус, чем плюс. )
Ты там говорил что-то о подсчетах размеров геометрий, думая что там причина тормозов. Неграмотно. Эти вещи у глифов подсчитываются лишь однократно и кешируются до изменения самого глифа/шейпа. Опять же, для подсчета размеров глифов используется DirectX (методы типа: GetDesignGlyphMetric()/GetGdiCompatibleGlyphMetrics(), которые соответствуют managed опциям: Ideal/Display). Т.е. нативный хелпер и этим тоже не занимается. Да и не может, ибо у него недостаточно информации, в отличие от драйвера видюхи.
ИМХО, причина создание прослойки-хелпера в в основном в том,чтобы уменьшить кол-во вызовов managed-unmanaged. Ну ты бы хоть посмотрел, как формируется конвеер команд. Там в буфер происходит сериализация следующего вида (один из популярных методов):
strokeWidth/strokeStyle — это описание объекта pen для outline (опционально).
Конечно глаз цепляется за такие вещи при просмотре кода рефлектором, ибо видно соответствие 1:1.
Итого, с managed стороны сериализуется набор команд для рендеринга вида: {cmd, data}, и затем за 1 вызов managed/unmanaged эта сериализованная последовательность "проигрывается" с unmanaged стороны, что в большинстве случаев сводится к вызову указанного в MILCMD соотв. метода из DirectX.
Надеюсь, теперь понятно, почему я говорил, что обсуждаемый нативный хелпер даже не занимается отображением VisualTree на сцену DirectX?
Этим занимается именно managed код, кодируя "отложенные" вызовы DirectX, которые затем весьма тупо проигрываются нативным хелпером. То бишь, при подробном изучении WPF, создается стойкое впечатление, что этот нативный хелпер нужен исключительно затем, чтобы уменьшить кол-во пересечений границ managed/unmanaged при вызовах. Ибо вызовы эти тяжеловаты, из-за маршаллинга данных и организации фреймов стека. Особенно все грустно для COM-интерфейсов в MTA, если сам объект был создан в STA-треде (а оно почти всегда так для GUI-приложений), ибо непонятно за каким чертом, но среда исполнения на каждый вызов запрашивает COM-объект на предмет собственного интерфейса-маршаллера, и эти вызовы получения интерфейсов вовсе не бесплатны. Как буд-то нельзя было вызвать и запомнить? Так что я (и не только) поступаю аналогично в мультимедиа-проектах, пряча COM-интерфейсы за своими прослойками, и заодно повышая уровень абстракции, чтобы за один вызов из managed сделать как можно больше операций.
Понятное дело, что вся схема слегка оптимизирована, то бишь во время того самого обновления лейаута пересоздается сериализованная последовательность команд отрисовки лишь для изменяемых элементов, и затем все эти закодированные последовательности команд проигрываются без участия managed стороны. Вот и получается, что сливать в "бутылочное горлышко", а затем разливать из него эффективнее, чем вызывать последовательность команд для рендеринга напрямую из managed, проходясь по VisualTree.
Так что повторю, с чего начал: из опыта WPF делать на дотнете Word или web-browser было бы глупо, по сегодняшнему состоянию дел.
Здравствуйте, gandjustas, Вы писали:
C>>LLVM C>>Было бы интересно сделать на ней генерацию конечного автомата и посмотреть что получится. G>Кстати как у LLVM с runtime кодогенерацией? И как это можно использовать на C++?
Умм... LLVM — это фреймворк для кодогенерации, в том числе и runtime. И оно как бы на С++ написано и прекрасно с ним интерфейсится.
Здравствуйте, Vamp, Вы писали:
C>>При условии, что виртуальная машина встроена в процессор, С не нужен. Ибо ассемблером будет являться CLR, к примеру, и Жаба какая-нить, или LISP.Спрашивается, если я могу писать на управляемом языке те же вещи, что на неуправляемом, нахрен мне тогда неуправляемый язык? V>Надеюсь, эти времена не наступят никогда. Это было бы началом конца.
Почему?
Новости очень смешные. Зря вы не смотрите. Как будто за наркоманами подсматриваешь. Только тетка с погодой в завязке.
There is no such thing as a winnable war.
Здравствуйте, Mr.Cat, Вы писали:
MC>Здравствуйте, Mamut, Вы писали: M>>Это, в частности, подтверждает тезис о том, что C++ не нужен: современные языки с GC и JIT просто уделывают его на традиционных для C/C++ задачах. MC>Я так понимаю, у pypy регекспы поддерживаются jit-ом, т.е. конпелируются в машинный код. Наверняка что-то подобное сделано в жаве. А имплементация гугла на плюсах — это интерпретатор. Конпеляция в очередной раз победила интерпретацию. Ура-ура.
MC>Ах, да. Плюсы, GC, КСВ при чем тут они?
Да все притом. Подход с компиляцией регэкспов в машинный код на С++ невозможен (или очень проблематичен).
Здравствуйте, Mamut, Вы писали:
M>Это, в частности, подтверждает тезис о том, что C++ не нужен: современные языки с GC и JIT просто уделывают его на традиционных для C/C++ задачах.
Boost.Xpressive?
re2c?
С ними бы сравнить, а то получается сравнение интерпретатора (C++) с компилятором (Java) (да, забавно).
M>Это, в частности, подтверждает тезис о том, что C++ не нужен: современные языки с GC и JIT просто уделывают его на традиционных для C/C++ задачах.
Все это, конечно хорошо, но с каких это пор разбор текстов по гибким правилам стал традиционной для C++ задачей? Для этого другие, более подходящие средства есть.
Здравствуйте, Sheridan, Вы писали:
S>А если серьезно, то c++ переживет все ваши дотнеты, хаскели и прочие эрланги, ибо с++ уже классика. Проверенная временем.
Ага, примерно как фортран и кобол.
Естественно настанет время когда на С++ писать будут единицы, но будут еще мегатонны кода, который еще надо будет саппортить.
Кстати Lisp в этом плане гораздо круче C++. И существует дольше, и развиваться продолжает, и проекты на нем пишутся.
Здравствуйте, Хвост, Вы писали:
Х>Здравствуйте, gandjustas, Вы писали:
G>>Кстати Lisp в этом плане гораздо круче C++. И существует дольше, и развиваться продолжает, и проекты на нем пишутся. Х>С++ тоже развиваться продолжает и проекты на нём пишутся. Получается по-твоему лисп гораздо круче С++ лишь потому что он существует дольше?
У тебя какая-то странная манера читать сообщение. Ты в них видишь исключительно то что хочешь видеть.
Здравствуйте, Ikemefula, Вы писали:
FR>>Если "управляемые языки" это ява/шарп то не сожрут у них уже было море времени для этого однако не осилили. FR>>Си никак ни отжирает C++ скорее наоборот.
I>Ну так и ассемблер с паскалем никто не сожрал. И фортран не сожран.
Их ниша в нуль ушла. Си последние 10 лет не теряет ничего, С++ последние три — пять тоже.
I>Ну ты и загнул то
Это загнул тот кому я отвечал.
I>Зато раньше весь тот софт, который щас пишется на С# и Java писался в основном на C++.
Нет сейчас на C# и яве пишется в основном софт который писался на VB, Delphi, PB и всяких других конструкторах.
Кроме того шарп прилично откусил и от явы. Ну и новые ниши да они вполне занимают.
I>Задним числом легко сказать, что де это была не та ниша.
Задним числом также легко сказать "никто офис переписывать не будет", хотя еще пять лет назад утверждали
обратное.
Здравствуйте, FR, Вы писали:
FR>Нет сейчас на C# и яве пишется в основном софт который писался на VB, Delphi, PB и всяких других конструкторах.
Не было никогда у VB и Дельфи той доли, которая есть сейчас у Джавы и Шарпа.
FR>Кроме того шарп прилично откусил и от явы. Ну и новые ниши да они вполне занимают.
Не только занимают новые, но и откусывают от старых понемногу, например в десктоп приложениях, геймдеве.
I>>Задним числом легко сказать, что де это была не та ниша.
FR>Задним числом также легко сказать "никто офис переписывать не будет", хотя еще пять лет назад утверждали FR>обратное.
И что с того что ктото чтото говорил 5 лет назад, что это меняет ?
Кое что портируется или будет портировано, кое что будет постепенно мигрировать на другую платформу, кое что и через 10 лет останется на С++ том же.
Здравствуйте, Ikemefula, Вы писали:
FR>>Нет сейчас на C# и яве пишется в основном софт который писался на VB, Delphi, PB и всяких других конструкторах.
I>Не было никогда у VB и Дельфи той доли, которая есть сейчас у Джавы и Шарпа.
Это из-за роста популярности веба. Если размер веба тех лет пропорционально увеличить до современного, то в абсолютных лидерах окажется все семейство VB/VBA/VBScript + ASP их использующее.
I>Не только занимают новые, но и откусывают от старых понемногу, например в десктоп приложениях, геймдеве.
Да как-то слабее, чем ожидалось. Джаве более 15-лет, дотнету — 8, это приличный срок для такого ничтожного выхлопа на десктопе. Они вне конкуренции на серверной стороне, это есть. А на клиенте как-то вяло и крайне редко в чистом виде, в основном идут как высокоуровневый "клей" или вместо скриптовых языков в играх. Т.е. практически ничего нового от нейтива не откусывают.
I>Кое что портируется или будет портировано, кое что будет постепенно мигрировать на другую платформу, кое что и через 10 лет останется на С++ том же.
Не кое-что, а очень многое. Быстродействие отдельного ядра проца растет очень медленно за последние годы, а распараллеливание и синхронизация потоков на популярных (и незыблемых в ближайшие десятилетия) архитектурах — очень накладные.
Здравствуйте, master_of_shadows, Вы писали:
E>>Для чего она лучшая? __>Для всего . Для ОС, для программеров, для железячников и, в конечном итоге, для юзера. E>> Почему лучшая? Чем JIT или компилятор снаружи процессора хуже микрокода внутри?.. __>Своим наличием .
Я наверное как-то непонятно сказал. Что от этого улучшится? Что станет быстрее, дешевле, легче, модифицируемие и т. д.?
__>У каждой связки ОС/железо как правило есть системный язык. Сама эта связка затачивается под него, как и язык так же может быть заточен.
IMHO, этот тезис неверен. __>Для Юникса это Си.
Для Юникса -- да, для железа под Юникс ни разу ни Си. Так как были на том же железе ещё и кобол и фортран крайне популярны, например. Ещё Ада где-то по ящикам обтиралась, кстати... __>Для иФона ОбджективСи.
А разве туда нативный код нельзя вставлять? Кроме того, objC -- это всего лишь интерфейс API, и только. Внутри всё те же процы, и всё тот же С, если посмотреть уровнем повыше
__>Для Андроида — джава.
А они ещё не сдались на предмет нативных вставок?
__>Если процессор умеет нативно выполнять системный язык — это просто отлично.
Воот я вижу один очевидный недостаток, по крайней мере. Если ты, грубо говоря, сделаешь проц, который интерпретирует байткод, то ты остановишь прогресс этого твоего "системного языка". И конкурирующие платформы тебя быстренько скушают...
Так что список минусов уже открыт. А плюсы-то в чём?
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, CreatorCray, Вы писали:
CC>Здравствуйте, gandjustas, Вы писали:
G>>Кстати как у LLVM с runtime кодогенерацией? И как это можно использовать на C++? CC>Давай-ка зададим наводящий вопрос: на каком языке написан JIT для C#/Java?
Для C# на Lisp с последующей трансляцией в C++. На java — понятия не имею.
Но вопрос был в том как использовать в C++ результаты runtime кодогенерации, с помощью того же LLVM
Здравствуйте, gandjustas, Вы писали:
C>>И оно как бы на С++ написано и прекрасно с ним интерфейсится. G>Не все что написано на С++ прекрасно с ним интерфейсится. G>Хотелось бы на примеры такого посмотреть.
примеры есть в самом LLVM, скачай и посмотри. Я лично использовал LLVM как jit-кодогенератор для транслятора паскалеподобного языка (интерпретатор написан на С++), лет эдак пять назад. Rocket-science в этом обнаружено не было, осилит любой студент знающий C++ и основы компиляторостроения.
Здравствуйте, CreatorCray, Вы писали:
M>>Это ты про Jazelle так? =) CC>Ну хотя бы его. В каких именно девайсах стоят эти чипы?
Да вроде как дофига где http://en.wikipedia.org/wiki/ARM_architecture#ARM_cores
Я, правда, не в курсе, используется ли технология, иди она там просто "есть" =)
Здравствуйте, gandjustas, Вы писали:
G>>>Кстати как у LLVM с runtime кодогенерацией? И как это можно использовать на C++? CC>>Давай-ка зададим наводящий вопрос: на каком языке написан JIT для C#/Java? G>Для C# на Lisp с последующей трансляцией в C++.
Какой изврат! А что ж сразу на С++ ниасилили? Если странслировать оказалось возможно то и руками написать не проблема.
G>Но вопрос был в том как использовать в C++ результаты runtime кодогенерации, с помощью того же LLVM
Используя VirtualAlloc c PAGE_EXECUTE_READWRITE + переход туда по указателю (aka function pointer)
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
S>Мамут, бросай курить то что куришь, это явно не табак
S>А если серьезно, то c++ переживет все ваши дотнеты, хаскели и прочие эрланги, ибо с++ уже классика. Проверенная временем. А то, что с него уходят, так это просто от того что на новомодных языках можно быстрее нарисовать софт, чем на с++. Все упирается в деньги: быстрее нарисуешь — больше получишь.
Не только быстрее. Часто — и эффективнее. См., например Facebook Chat, ссылки сам найдешь.
Здравствуйте, gandjustas, Вы писали:
G>Кстати Lisp в этом плане гораздо круче C++. И существует дольше, и развиваться продолжает, и проекты на нем пишутся.
С++ тоже развиваться продолжает и проекты на нём пишутся. Получается по-твоему лисп гораздо круче С++ лишь потому что он существует дольше?
G>Естественно настанет время когда на С++ писать будут единицы, но будут еще мегатонны кода, который еще надо будет саппортить.
Это вряд ли случится. Компилятор С можно написать на С. .NET машину нельзя написать на .NET. Следовательно, С не умрет никогда. Ну а формоклепатели и кнопкотаскатели конечно гораздо более заметны, чем тихие харкдорщики.
G>А я и не говорю про C, я говорю про C++.
С++, по крайней мере, С с классами, типизацией и шаблонами, настолько более удобен, чем С, что умрет как раз скорее С, чем С++.
V>>Ну а формоклепатели и кнопкотаскатели конечно гораздо более заметны, чем тихие харкдорщики. G>Смысл этой фразы остался для меня загадкой
Это ничего. "Есть многое на свете, друг Горацио, что и не снилось нашим мудрецам".
HA>http://www.nvidia.ru/object/cuda_finance_ru.html
HA>Вот на чем такое писать??? HA>«Вычисление предполагаемых изменений и спорных моментов для всего рынка опционов на акции США в режиме реального времени»
Здравствуйте, master_of_shadows, Вы писали:
__>Подозреваю, что со стороны "более удобен" его сожрут управляемые языки, а с низкоуровневой стороны Си.
С++ от С при ровных руках и не пустой черепной коробке почти равнозначны. За исключением что С++ всё же поудобнее будет.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, unreg_flex, Вы писали:
_>А пока на моей машине стоит IA проц и все та же унылая винда с кучей софта на плюсах, с какой-то мизерной долей гуя .NET-овского WinForms-а от которого больше лагов чем пользы.
Ну так никто не будет переписывать софт вроде Офиса на дотнет.
_>и по прежнему ничего не меняется, все так же пишут на кривом и ненужном C++.
Основная часть софта, который ты пользуешь, пишется уже не один десяток лет.
_>Давайте выкинем все это нафик и перепишем на новых хороших, правильных и быстрых языках! Да, давайте!
Так делают только идиоты вроде борланда, нетскейпа и других товарищей.
Здравствуйте, vdimas, Вы писали:
V>Низкоуровневый layout и рендеринг, как показал опыт WPF — лучше оставить нативным.
Интересно, а что подразумевается под "низкоуровневым" layout-ом и рендерингом? И как конкретно на это повлиял "опыт WPF"?
V>У меня после рестарта с только что загруженной виндой монстровый Word от Office2010 стартует заметно быстрее, чем простейшее WPF-приложение.
Adobe Photoshop Elements 8 стартует у меня значительно дольше среднего WPF-приложения. Вывод? И потом, не надо забывать, что современный Word — это таки тонны опыта и многие годы оптимизаций (ха-ха). Давайте поглядим, как WPF-приложение будет стартовать лет эдак через 10 (если доживет )
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>На RSDN это "тренд": говорить о ненужности C++. Раньше или позже к таким разговорам привыкаешь, как к снегу зимой.
Даже к разработке программ на C++ можно, раньше или позже, привыкнуть. А уж привыкнуть к разговорам о его ненужности — сущие пустяки.
... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>
'You may call it "nonsense" if you like, but I'VE heard nonsense, compared with which that would be as sensible as a dictionary!' (c) Lewis Carroll
Здравствуйте, vdimas, Вы писали:
V>Взять те же инструменты для разработки БД. У Оракла на жабе, у MS нейтив. На оракловых без матерка никак, а от MS все летает. ИМХО, такие факторы как скорость загрузки и время реакции для клиентских приложений важнее многих остальных, но не обеспечиваются современными управляемыми средами. Обилие библиотек и сотни тысяч типов в них — это, как выяснилось, палка о двух концах. Что-то типа наручных мега-часов с прилагаемым питанием от аккумуляторов в двух чемоданах.
О каких инструментах для разработки БД у МС идёт речь? Уж не о 100% дотнетном ли Enterprise Studio (начиная с версии 2005)?
Здравствуйте, vdimas, Вы писали:
I>>Это чушь. С таким же успехом можно и на винформс написать такое тормозилово, про которое будут ажно легенды слагать.
V>Это так и есть. Насчет winForms — тоже. У MS на сегодня рулят windowless ActiveX controls.
Ничего, скоро их вытеснят дотнет-компоненты.
I>>30мб при среднем объеме оперативы на 2 порядка больше ?
V>Только для чтения с диска нескольких разбросанных файлов общим таким размером может потребоваться более секунды.
С диска грузится на много меньше. Кроме того, если много дотнет приложений запущено, то эти файлы будут уже в кеше.
V>Офисы запускались довольно быстро до выпуска Office 2000, особенно неплох был Office 95. Попробуй найти на досуге и позапускать. Потом что-то "сломалось", и починилось только в 2010-м, по крайней мере Word опять запускается довольно сносно.
Ничего там особо не менлось. Если мерять время от запуска до полной инициализации, когда уже можно чего то руками набивать, то разницы особо не было.
Просто в некоторых версиях инициализация происходила чуток иначе и казалось что быстрее.
I>>А щас вот с приходом WPF оказывается сложно подождать столько же времени, сколько приходилось ждать ранее.
V>Комп мощнее в 10 раз, а приходится ждать в 2-3 раза дольше.
Где ты взял эти 2-3 раза, не ясно. И раньше было вагон приложений, которые запускались десятки секунд.
Здравствуйте, SpaceConscience, Вы писали:
SC>Я именно говорил про обитателей мирка, а не про всех функциональщиков. К функциональщикам в целом у меня никаких претензий нет.
Здравствуйте, rsdntchkru, Вы писали:
R> R>Для начала ты начни пользоватся веб браузером, написанном от начала до конца на языке с GC, а потом на нем же пиши посты что c/c++ не нужен.
А можете привести примеры таких браузеров? С удовольствием гляну.
Здравствуйте, Codechanger, Вы писали:
C>Мнится мне, в ближайшие несколько лет какая-нить из виртуальных машин будет реализована в процессоре на аппаратном уровне.
Зачем?
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, Erop, Вы писали:
E>Здравствуйте, master_of_shadows, Вы писали:
E>>>Зачем? __>>Когда процессор может нативно выполнять системный язык — это наилучшая ситуация.
E>Для чего она лучшая?
Для всего . Для ОС, для программеров, для железячников и, в конечном итоге, для юзера.
E> Почему лучшая? Чем JIT или компилятор снаружи процессора хуже микрокода внутри?..
Своим наличием .
Ещё в том сообщении хотел расписать, да никак не мог сформулировать мысль .
У каждой связки ОС/железо как правило есть системный язык. Сама эта связка затачивается под него, как и язык так же может быть заточен.
Для Юникса это Си.
Для иФона ОбджективСи.
Для Андроида — джава.
Если процессор умеет нативно выполнять системный язык — это просто отлично.
Здравствуйте, Erop, Вы писали:
E>Для чего она лучшая? Почему лучшая? Чем JIT или компилятор снаружи процессора хуже микрокода внутри?..
Программный JIT лучше. Во-первых его легко обновить, во-вторых ему доступно значительно больше памяти чем потенциально внутри процессора, и, в случае прекомпиляции, еще и на порядки больше времени. Единственный потенциальный плюс железного JIT (именно JIT, никто байткод напрямую на железе не выполняет и выполнять не будет) это существенно лучшие показатели ужора электричества.
M>А что делать не с ОСью, а сприложениями в этой ОСи? Со всеми этими дотнетами, джавами, сями, эрлангами, рубями, питонами и т.п.? Или делаем только один убер-язык, а остальные предаем анафеме?
Предложившего этот путь быстрее самого предадут анафеме.
Новости очень смешные. Зря вы не смотрите. Как будто за наркоманами подсматриваешь. Только тетка с погодой в завязке.
There is no such thing as a winnable war.
Здравствуйте, vdimas, Вы писали:
V>Наверно, стоило уточнять, что ты имел ввиду WPF 4.0, сэкономили бы время на пару итераций. Да, там есть некая wpfgfx_v0400.dll, которая используется там, где до этого (WPF в 3.0-3.5) были непосредственные вызовы COM-АПИ DirectX.
Да ладно. Раньше WPF точно также не работал с DirectX напрямую, а использовал milcore.dll.
V>И все равно, извини, отдает полным непониманием происходящего. Да, DirectX был нативный, и сейчас упомянутая более высокоуровневая обертка "wpfgfx" — тоже нативная... Однако, размещение визуальных элементов в "виртуальном" буфере страницы осуществляется по прежнему наследниками элемента Panel (Grid, StackPanel, WrapPanel). И оно по-прежнему 100% managed. Т.е. значения всех bounds вычисляются managed по всему visual tree, сами эти изменения попадают в нативную обертку, которая строит сцену при рендеринге, и т.д. Но это не принципиально, ибо затраты на непосредственное отображение на современных компах не столь значительны (это я из опыта использования 100% Java RDP клиентов). А вот с форматированием, когда счет элементам идет на многие-многие тысячи и есть многоуровневые вложения (взять для примера достаточно большой Word-документ) — это требует определенной шустрости, чтобы не ждать несколько секунд после применения нового стиля к документу, пока оно там "утрясется".
Да что ты привязался к этим панелям В них же простейший код! Тормоза начинаются там, где нужно считать место для геометрий и глифов, в которые в итоге выливаются все элементы. Этим занимается unmanaged.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Опять какие то фантазии. Я имел в виду WPF 1.0. 2006 в url ссылки знаешь что означает?
Ну там вообще все "деревянно", managed 100% лейаут и построение сцены путем непосредственного вызова знакомых ф-ий DirectX. Для далеких от IT, можно сказать, что рендеринг нативный. Но блин, он всегда нативный в конечном итоге, даже в windows.Forms. Короче, филосовская часть вопроса меня не интересует вообще, я достаточно по времени и на достаточно низком уровне работал с DicrectX, так что неплохо представляю себе происходящее.
V>>И все равно, извини, отдает полным непониманием происходящего.
НС>Это точно. Вопрос в том, с чей стороны.
Давай вести разговор двух взрослых дядь более предметно. Если у тебя действительно есть желание, и ты не поленишься вооружишься Рефлектором, то мне не трудно показать, где именно происходят вычисления координат элементов при каждом событии обновления лейаута. ИМХО, там никакой недоступной для понимания магии, т.е. можно обойтись без "чужих мнений" и довериться собственным глазам.
Здравствуйте, vdimas, Вы писали:
V>Все структуры и константы, описывающие примитивы, преобразования и т.д. — напрямую из DirectX. А прослойка эта была связана скорее всего в несовместимостью самого DirectX м/у версиями 9.0 и теми, что выше.
Опять фантазии. Счастливо оставаться со своими заблуждениями, я пас. Реальное положение дел тебе все равно не интересно.
Здравствуйте, vdimas, Вы писали:
V>Здравствуйте, MxMsk, Вы писали:
MM>>Вот и славно! Осталось MS переписать код измерения и компоновки в панелях через unsafe и чудеса — WPF ускорится в 3-5 раз!
V>Да весь код в нейтив переписать придется, ибо начинать надо будет с контейнеров, которые должны будут хранить нейтивные указатели. В общем, WPF вполне подходит для "формочек", но Word, IE И прочее MS упорно переписывает на нейтиве.
Переписывания там очень малая часть. Врядли на каждый релиз хотябы 50% кода переписывается.
V>Причем, с Офиса 2007, насколько я вижу, рендеринг в Word был переделан практически полностью. А ведь WPF уже был достаточно mature на тот момент.
Ага учитывая что WPF появился аж в начале 2007 года, а офис 2007 начали делать гораздо раньше.
V>Странно, что эти "мелочи" усиленно игнорируются оппонентами.
Просто оппоненты понимают что переписывать существующий софт только ради managed смысла нет. Вообще нет.
Вот для VS2010 был смысл, потому что очень хотели модульности и безопасности, получилось. А переписывать word\excel на managed смысла нет, это ничего кроме турдозатрат не даст. Офисные приложения и так умеют запускать addin_ы на управляемом коде, большего от них не требуется. А сам MS совершенно не стесняется писать на .NET тот же самый power pivot для excel.
Здравствуйте, gandjustas, Вы писали: G>Да все притом. Подход с компиляцией регэкспов в машинный код на С++ невозможен (или очень проблематичен).
Логично, что управляемым средам проще — они юзают уже присутствующий в них джит. Но есть же либы для джиттинга. Gnu Lightning например (не юзал).
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, gandjustas, Вы писали:
MC>>>Ах, да. Плюсы, GC, КСВ при чем тут они? G>>Да все притом. Подход с компиляцией регэкспов в машинный код на С++ невозможен (или очень проблематичен). C>LLVM
C>Было бы интересно сделать на ней генерацию конечного автомата и посмотреть что получится.
Кстати как у LLVM с runtime кодогенерацией? И как это можно использовать на C++?
Здравствуйте, gandjustas, Вы писали:
G>Подход с компиляцией регэкспов в машинный код на С++ невозможен (или очень проблематичен).
С какого перепугу то?
Если компиляция в байт код возможна то почему вдруг невозможно сгенерить машинный код?
Это будет банальный JIT.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, gandjustas, Вы писали:
G>Кстати как у LLVM с runtime кодогенерацией? И как это можно использовать на C++?
Давай-ка зададим наводящий вопрос: на каком языке написан JIT для C#/Java?
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, CreatorCray, Вы писали:
CC>Здравствуйте, gandjustas, Вы писали:
G>>Подход с компиляцией регэкспов в машинный код на С++ невозможен (или очень проблематичен). CC>С какого перепугу то? CC>Если компиляция в байт код возможна то почему вдруг невозможно сгенерить машинный код? CC>Это будет банальный JIT.
Ну так напиши.
Говорить можно что угодно, а JIT для С++ пока еще никто не изобрел.
Здравствуйте, gandjustas, Вы писали:
G>>>Подход с компиляцией регэкспов в машинный код на С++ невозможен (или очень проблематичен). CC>>С какого перепугу то? CC>>Если компиляция в байт код возможна то почему вдруг невозможно сгенерить машинный код? CC>>Это будет банальный JIT. G>Ну так напиши. G>Говорить можно что угодно, а JIT для С++ пока еще никто не изобрел.
А нам и не надо JIT для компилируемого языка. Нам надо JIT для байт кода, который сгенерит regex по строке паттерна.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, gandjustas, Вы писали:
C>>>LLVM C>>>Было бы интересно сделать на ней генерацию конечного автомата и посмотреть что получится. G>>Кстати как у LLVM с runtime кодогенерацией? И как это можно использовать на C++? C>Умм... LLVM — это фреймворк для кодогенерации, в том числе и runtime.
Спасибо, КО.
C>И оно как бы на С++ написано и прекрасно с ним интерфейсится.
Не все что написано на С++ прекрасно с ним интерфейсится.
Хотелось бы на примеры такого посмотреть.
Здравствуйте, CreatorCray, Вы писали:
CC>Здравствуйте, gandjustas, Вы писали:
G>>>>Кстати как у LLVM с runtime кодогенерацией? И как это можно использовать на C++? CC>>>Давай-ка зададим наводящий вопрос: на каком языке написан JIT для C#/Java? G>>Для C# на Lisp с последующей трансляцией в C++. CC>Какой изврат!
Нормальная практика создания рабочего прототипа на высокоуровневом языке. А lisp бы выбран просто потому что так захотелось автору.
CC>А что ж сразу на С++ ниасилили? Если странслировать оказалось возможно то и руками написать не проблема.
Наверное если бы сразу стали писать на С++, то .NET появился бы на пару лет позже
Здравствуйте, gandjustas, Вы писали:
C>>И оно как бы на С++ написано и прекрасно с ним интерфейсится. G>Не все что написано на С++ прекрасно с ним интерфейсится. G>Хотелось бы на примеры такого посмотреть. http://github.com/ianloic/llvm-fnmatch — как раз для регэкспов.
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, gandjustas, Вы писали:
C>>>И оно как бы на С++ написано и прекрасно с ним интерфейсится. G>>Не все что написано на С++ прекрасно с ним интерфейсится. G>>Хотелось бы на примеры такого посмотреть. C>http://github.com/ianloic/llvm-fnmatch — как раз для регэкспов.
Здравствуйте, gandjustas, Вы писали:
C>>>>И оно как бы на С++ написано и прекрасно с ним интерфейсится. G>>>Не все что написано на С++ прекрасно с ним интерфейсится. G>>>Хотелось бы на примеры такого посмотреть. C>>http://github.com/ianloic/llvm-fnmatch — как раз для регэкспов. G>А где же там C++?
А на нём всё так же, питоновский API его повторят один-в-один.
CLang можно посмотреть. Из него люди сделали встраиваемый компилятор C++ недавно — это к вопросу о JIT'е для С++
Здравствуйте, gandjustas, Вы писали:
G>>>>>Подход с компиляцией регэкспов в машинный код на С++ невозможен (или очень проблематичен). CC>>>>С какого перепугу то? CC>>>>Если компиляция в байт код возможна то почему вдруг невозможно сгенерить машинный код? CC>>>>Это будет банальный JIT. G>>>Ну так напиши. G>>>Говорить можно что угодно, а JIT для С++ пока еще никто не изобрел. CC>>А нам и не надо JIT для компилируемого языка. Нам надо JIT для байт кода, который сгенерит regex по строке паттерна.
G>Да пофигу. Даже гугл неспособен такое сделать, не надо мне доказывать что это несложная задача.
Подозреваю что им просто нафиг не упало это делать. Для их задач производительности и интерпретируемого regex хватило.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
C++ перестанет быть нужен, когда на управляемых языках можно будет писать драйвера и другие низкоуровневые штучки-дрючки, т.е. ядро ОС будет написано на управляемом языке.
Мнится мне, в ближайшие несколько лет какая-нить из виртуальных машин будет реализована в процессоре на аппаратном уровне.
Мамут, бросай курить то что куришь, это явно не табак
А если серьезно, то c++ переживет все ваши дотнеты, хаскели и прочие эрланги, ибо с++ уже классика. Проверенная временем. А то, что с него уходят, так это просто от того что на новомодных языках можно быстрее нарисовать софт, чем на с++. Все упирается в деньги: быстрее нарисуешь — больше получишь.
S>>Мамут, бросай курить то что куришь, это явно не табак
S>>А если серьезно, то c++ переживет все ваши дотнеты, хаскели и прочие эрланги, ибо с++ уже классика. Проверенная временем. А то, что с него уходят, так это просто от того что на новомодных языках можно быстрее нарисовать софт, чем на с++. Все упирается в деньги: быстрее нарисуешь — больше получишь.
M>Не только быстрее. Часто — и эффективнее. См., например Facebook Chat, ссылки сам найдешь.
Шеридан, ты бы хоть раз в жизни бы почитал то, о чем тебе говорят, хоть бы понял, о чем тебе говорят.
Здравствуйте, gandjustas, Вы писали:
CC>>А нам и не надо JIT для компилируемого языка. Нам надо JIT для байт кода, который сгенерит regex по строке паттерна.
G>Да пофигу. Даже гугл неспособен такое сделать, не надо мне доказывать что это несложная задача.
Ну на джаве же решили? Там же, насколько я понял, тоже генерация байт-кода, а не исходника, как в питоне. Из дотнета для C++ TypeBuilder доступен как COM-объект (вернее, наоборот, этот COM доступен в дотнете как "родной класс", но не суть), в общем точно так же можно его через COM дергать из нейтива для генерации байт-кода. Загрузкой этого байт-кода тоже можно управлять, т.е. затребовать, чтобы определенный метод был заджиттен, получить его слот/адрес — и вперед.
Здравствуйте, Codechanger, Вы писали:
C>C++ перестанет быть нужен, когда на управляемых языках можно будет писать драйвера и другие низкоуровневые штучки-дрючки, т.е. ядро ОС будет написано на управляемом языке. C>Мнится мне, в ближайшие несколько лет какая-нить из виртуальных машин будет реализована в процессоре на аппаратном уровне.
Это давно происходит, например популярны очень-многоядерные Форт-процессоры (заметь, исполнительные модели джавы и дотнета тоже смахивают на форт-машину). Там прикол в том, что у таких "высокоуровневых" процов гораздо большая отдача вычислительной мощности на ватт энергии, чем у традиционных. А с развитием минюатиризации только этот показатель и будет являться решающим/ограничивающим. Т.е. все к этому идет, про что ты говоришь. К тому же, уже сейчас у этих байт-кодов есть возможность оперировать абсолютными адресами, поэтому на них писать драйвера в принципе можно, например, используя C# unsafe, и не пользуясь GC. Запись/чтение портов все-равно будет через некий аналог hal.dll.
Здравствуйте, Vamp, Вы писали:
G>>Естественно настанет время когда на С++ писать будут единицы, но будут еще мегатонны кода, который еще надо будет саппортить. V>Это вряд ли случится. Компилятор С можно написать на С. .NET машину нельзя написать на .NET. Следовательно, С не умрет никогда. Ну а формоклепатели и кнопкотаскатели конечно гораздо более заметны, чем тихие харкдорщики.
При условии, что виртуальная машина встроена в процессор, С не нужен. Ибо ассемблером будет являться CLR, к примеру, и Жаба какая-нить, или LISP.Спрашивается, если я могу писать на управляемом языке те же вещи, что на неуправляемом, нахрен мне тогда неуправляемый язык?
C>При условии, что виртуальная машина встроена в процессор, С не нужен. Ибо ассемблером будет являться CLR, к примеру, и Жаба какая-нить, или LISP.Спрашивается, если я могу писать на управляемом языке те же вещи, что на неуправляемом, нахрен мне тогда неуправляемый язык?
Надеюсь, эти времена не наступят никогда. Это было бы началом конца.
Здравствуйте, vdimas, Вы писали:
V>Это давно происходит, например популярны очень-многоядерные Форт-процессоры (заметь, исполнительные модели джавы и дотнета тоже смахивают на форт-машину).
А можно ткнуть пальцем в железку, где они популярны?
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, Codechanger, Вы писали:
G>>>Естественно настанет время когда на С++ писать будут единицы, но будут еще мегатонны кода, который еще надо будет саппортить. V>>Это вряд ли случится. Компилятор С можно написать на С. .NET машину нельзя написать на .NET. Следовательно, С не умрет никогда. Ну а формоклепатели и кнопкотаскатели конечно гораздо более заметны, чем тихие харкдорщики. C>При условии, что виртуальная машина встроена в процессор
Где на такое можно посмотреть в промышленных (а не кунсткамерных) условиях?
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, Vamp, Вы писали:
G>>Естественно настанет время когда на С++ писать будут единицы, но будут еще мегатонны кода, который еще надо будет саппортить. V>Это вряд ли случится. Компилятор С можно написать на С. .NET машину нельзя написать на .NET. Следовательно, С не умрет никогда.
А я и не говорю про C, я говорю про C++.
V>Ну а формоклепатели и кнопкотаскатели конечно гораздо более заметны, чем тихие харкдорщики.
Смысл этой фразы остался для меня загадкой
Здравствуйте, CreatorCray, Вы писали:
V>>Это давно происходит, например популярны очень-многоядерные Форт-процессоры (заметь, исполнительные модели джавы и дотнета тоже смахивают на форт-машину). CC>А можно ткнуть пальцем в железку, где они популярны?
Целочисленная арифметика со скоростью 26 млрд.оп/сек от батарейного питания.., т.е. эквивалент современного одноядерника, работающего на частоте более 10ГГц. У меня это в голове не очень укладывается, но сие факт.
Здравствуйте, Vamp, Вы писали:
C>>При условии, что виртуальная машина встроена в процессор, С не нужен. Ибо ассемблером будет являться CLR, к примеру, и Жаба какая-нить, или LISP.Спрашивается, если я могу писать на управляемом языке те же вещи, что на неуправляемом, нахрен мне тогда неуправляемый язык? V>Надеюсь, эти времена не наступят никогда. Это было бы началом конца.
Здравствуйте, vdimas, Вы писали:
V>Гуглить "SEAForth processor BMW".
Плохо нагугливается места конкретного применения.
Где они реально в промышленности используются.
V>Целочисленная арифметика со скоростью 26 млрд.оп/сек от батарейного питания.., т.е. эквивалент современного одноядерника, работающего на частоте более 10ГГц. V>У меня это в голове не очень укладывается, но сие факт.
Forty C18 core processors capable of up to 25 billion operations per second
One C18 core executes one ALU operations per 1.5 ns
Эка невидаль. 40 ядер в параллели. Каждое работает на 700MHz. Примитивные арифметические операции занимают 1 такт.
Ты программы для этого чуда видел?
Listing 2.4 Example of a program to blink an LED
$8000 1 >stk \ Initial pulse width to T
: blinkLed ( ? )
$3FE00 # a! \ Mask to control pulse width
begin
620 # for \ Repeat 621 times
30003 # !b \ Drive pins at bits 17 and 1 high
dup for
. . . unext \ Delay
20002 # !b \ Drive pin at bit 1 low
dup not for
. . . unext \ Delay
next
$10000 # . + a@ and \ Increments pulse width & masks with A
| again \ Repeat infinitely
Этож считай грёбаный ассемблер.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, midcyber, Вы писали:
CC>>Где на такое можно посмотреть в промышленных (а не кунсткамерных) условиях? M>Это ты про Jazelle так? =)
Ну хотя бы его. В каких именно девайсах стоят эти чипы?
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, vdimas, Вы писали:
V>Гуглить "SEAForth
цитата с сайта: 64 words RAM / 64 words ROM.
Это несколько ограничивает круг решаемых задач не правда ли ?
Нашим клиентам 128G RAM мало и ждут облизываясь flash хранилищ побольше и подешевле
Здравствуйте, CreatorCray, Вы писали:
CC>Эка невидаль. 40 ядер в параллели. Каждое работает на 700MHz. Примитивные арифметические операции занимают 1 такт.
Дык, а потребление? Фишка в том, что таким макаром, учитывая миниатюризацию, и до 400 ядер на кристалл дойдет аж бегом при питании от батарейки.
CC>Ты программы для этого чуда видел?
CC>
...
CC>
CC>Этож считай грёбаный ассемблер.
Это обычный Форт, один из мощнейших языков своего времени.
Здравствуйте, SleepyDrago, Вы писали:
V>>Гуглить "SEAForth SD>цитата с сайта: 64 words RAM / 64 words ROM. SD>Это несколько ограничивает круг решаемых задач не правда ли ?
Специфика Форта в том, что в сравнении с обычным ассемблером, это примерно 640+640 words, т.е. более чем достаточно для средней подпрограммы.
Понятное дело, что это не совсем проц общего назначения, но что касается алгоритмов обработки сигналов, рендеринга и т.д., или применения в автомобильной электронике, то 64 Forth-words на узел — это более чем достаточно. Воспринимай эту решетку ядер как ПЛИС следующего поколения. Один тот кристалл заменит десяток процов в современном автомобиле, не зря BMW планирует переводить на него свою автомобильную электронику.
SD>Нашим клиентам 128G RAM мало и ждут облизываясь flash хранилищ побольше и подешевле
Дык, внешней памяти RAM/ROM/Flash может быть сколь угодно много, это был указан размер собственной памяти каждого ядра.
Здравствуйте, CreatorCray, Вы писали:
V>>Это давно происходит, например популярны очень-многоядерные Форт-процессоры (заметь, исполнительные модели джавы и дотнета тоже смахивают на форт-машину). CC>А можно ткнуть пальцем в железку, где они популярны?
Здравствуйте, gandjustas, Вы писали:
G>Здравствуйте, Sheridan, Вы писали:
S>>А если серьезно, то c++ переживет все ваши дотнеты, хаскели и прочие эрланги, ибо с++ уже классика. Проверенная временем. G>Ага, примерно как фортран и кобол. G>Естественно настанет время когда на С++ писать будут единицы, но будут еще мегатонны кода, который еще надо будет саппортить.
"...Встроенные возможности работы с C++ и совместимость со средой разработки Visual Studio делают параллельное программирование с Fermi еще проще и позволяют достигать невероятно высокой скорости работы в небывалом числе приложений, включая ..." (далее длинный список)
— unified address space для Global, Shared, Local memory
(т.е. гимора с IPC меньше на 2 порядка)
— Fermi and the PTX 2.0 ISA also add support for C++ virtual functions, function pointers, and
‘new’ and ‘delete’ operators for dynamic object allocation and de-allocation. C++ exception
handling operations ‘try’ and ‘catch’ are also supported.
зы. Для некоторых — а нах "недерминированные финализаторы" на такой архитектуре
Здравствуйте, Codechanger, Вы писали:
C>Здравствуйте, Vamp, Вы писали:
G>>>Естественно настанет время когда на С++ писать будут единицы, но будут еще мегатонны кода, который еще надо будет саппортить. V>>Это вряд ли случится. Компилятор С можно написать на С. .NET машину нельзя написать на .NET. Следовательно, С не умрет никогда. Ну а формоклепатели и кнопкотаскатели конечно гораздо более заметны, чем тихие харкдорщики. C>При условии, что виртуальная машина встроена в процессор, С не нужен. Ибо ассемблером будет являться CLR, к примеру, и Жаба какая-нить, или LISP.Спрашивается, если я могу писать на управляемом языке те же вещи, что на неуправляемом, нахрен мне тогда неуправляемый язык?
а виртуальная машина на чем будет написана? или она будет железная? Неплохой хардкор получатся разрабатывать такие процессоры. А уж как исправлять баги.....
Здравствуйте, Mamut, Вы писали:
HA>>http://www.nvidia.ru/object/cuda_finance_ru.html
HA>>Вот на чем такое писать??? HA>>«Вычисление предполагаемых изменений и спорных моментов для всего рынка опционов на акции США в режиме реального времени»
M>На Erlang + C вестимо.
Здравствуйте, Vamp, Вы писали:
G>>А я и не говорю про C, я говорю про C++. V>С++, по крайней мере, С с классами, типизацией и шаблонами, настолько более удобен, чем С, что умрет как раз скорее С, чем С++.
Подозреваю, что со стороны "более удобен" его сожрут управляемые языки, а с низкоуровневой стороны Си.
Здравствуйте, Codechanger, Вы писали:
C>При условии, что виртуальная машина встроена в процессор, С не нужен. Ибо ассемблером будет являться CLR, к примеру,
Не будет, из-за системы типов CLR, она слишком абстрактна. Даже вызов виртуального метода в байткоде сугубо декларативен. Т.е. байт-код CLR не пригоден для аппаратного исполнения и требует джиттинга в любом случае. Ну разве что можно байт-код такого процессора максимально приблизить к байт-коду CLR, но компиляция всех вызовов, вычисление размеров типов и т.д. — это все лежит на среде исполнения, не на железке.
Здравствуйте, CreatorCray, Вы писали:
CC>Здравствуйте, master_of_shadows, Вы писали:
__>>Подозреваю, что со стороны "более удобен" его сожрут управляемые языки, а с низкоуровневой стороны Си. CC>С++ от С при ровных руках и не пустой черепной коробке почти равнозначны. За исключением что С++ всё же поудобнее будет.
Ну вот, снова сиплюснику мешает чей то мозг и руки
Здравствуйте, FR, Вы писали:
__>>Подозреваю, что со стороны "более удобен" его сожрут управляемые языки, а с низкоуровневой стороны Си.
FR>Если "управляемые языки" это ява/шарп то не сожрут у них уже было море времени для этого однако не осилили. FR>Си никак ни отжирает C++ скорее наоборот.
Ну так и ассемблер с паскалем никто не сожрал. И фортран не сожран.
Ну ты и загнул то
Зато раньше весь тот софт, который щас пишется на С# и Java писался в основном на C++.
Задним числом легко сказать, что де это была не та ниша.
Здравствуйте, FR, Вы писали:
FR>Их ниша в нуль ушла. Си последние 10 лет не теряет ничего, С++ последние три — пять тоже.
Подкинь ссылок на всякие %, если не сложно.
FR>Нет сейчас на C# и яве пишется в основном софт который писался на VB, Delphi, PB и всяких других конструкторах.
Мы сейчас пишем на шарпе то, что раньше писалось (если вообще писалось) на плюсах.
Здравствуйте, master_of_shadows, Вы писали:
FR>>Их ниша в нуль ушла. Си последние 10 лет не теряет ничего, С++ последние три — пять тоже.
__>Подкинь ссылок на всякие %, если не сложно.
FR>>Нет сейчас на C# и яве пишется в основном софт который писался на VB, Delphi, PB и всяких других конструкторах.
__>Мы сейчас пишем на шарпе то, что раньше писалось (если вообще писалось) на плюсах.
А я писал на питоне то что раньше писалось на яве.
Здравствуйте, FR, Вы писали:
I>>Зато раньше весь тот софт, который щас пишется на С# и Java писался в основном на C++.
FR>Нет сейчас на C# и яве пишется в основном софт который писался на VB, Delphi, PB и всяких других конструкторах.
Справедливости ради, еще тот, который писался на MFC.
FR>Задним числом также легко сказать "никто офис переписывать не будет", хотя еще пять лет назад утверждали FR>обратное.
А смысла нет, как выяснилось. Там переписывать особо нечего. Низкоуровневый layout и рендеринг, как показал опыт WPF — лучше оставить нативным. А высокоуровневое доступно через COM-модель + специально заточенные .Net wrappers и так, т.е. переписывание этого "черного ящика", выставляющего COM-интерфейсы, вообще не дает никаких бенефитов ни в прикладном, ни в системном плане. Опять же — скорость загрузки. У меня после рестарта с только что загруженной виндой монстровый Word от Office2010 стартует заметно быстрее, чем простейшее WPF-приложение.
Здравствуйте, SpaceConscience, Вы писали:
SC>Вот я участвую в разработке программы на C++, а мне говорят, что C++ не нужен.
SC>И что мне теперь делать?
Да что и все здесь отмечающиеся: гробить драгоценное время на то, чтобы объяснять оппоненту его неправоту.
Здравствуйте, FR, Вы писали:
FR>Нет сейчас на C# и яве пишется в основном софт который писался на VB, Delphi, PB и всяких других конструкторах.
Ну, вот с моим небольшим опытом, я только на текущем месте работы в первый раз столкнулся с разработкой софта, предыдущая версия которого была написана на Delphi. До Delphi там кажись Плюсы были. Во всех остальных конторах, новые версии прог — это был переход с C++.
Здравствуйте, vdimas, Вы писали:
I>>Не было никогда у VB и Дельфи той доли, которая есть сейчас у Джавы и Шарпа.
V>Это из-за роста популярности веба. Если размер веба тех лет пропорционально увеличить до современного, то в абсолютных лидерах окажется все семейство VB/VBA/VBScript + ASP их использующее.
Я как то не припомню большого кол.ва вакансий на VB. А вот на С++ вакансий было вагоны В т.ч. ASP, COM, DCOM, CORBA и прочая дрянь.
I>>Не только занимают новые, но и откусывают от старых понемногу, например в десктоп приложениях, геймдеве.
V>Да как-то слабее, чем ожидалось. Джаве более 15-лет, дотнету — 8, это приличный срок для такого ничтожного выхлопа на десктопе.
Как ты померял выхлоп ?
>Они вне конкуренции на серверной стороне, это есть. А на клиенте как-то вяло и крайне редко в чистом виде, в основном идут как высокоуровневый "клей" или вместо скриптовых языков в играх. Т.е. практически ничего нового от нейтива не откусывают.
Смотря что с чем сравнивать. Практически все серьезные клиентские продукты стартовали еще до выхода джавы. Е
Здравствуйте, Ikemefula, Вы писали:
V>>Это из-за роста популярности веба. Если размер веба тех лет пропорционально увеличить до современного, то в абсолютных лидерах окажется все семейство VB/VBA/VBScript + ASP их использующее.
I>Я как то не припомню большого кол.ва вакансий на VB. А вот на С++ вакансий было вагоны В т.ч. ASP, COM, DCOM, CORBA и прочая дрянь.
Это по какой стране такая статистика? Кста, на С++ всегда вакансий вагоны, ибо спецов всегда меньше, чем требуется.
I>Как ты померял выхлоп ?
Да по отсутствию дотнетных или жабовых десктопных программ среди популярных. Среди популярных 99.99% плюсы рулят, тем смешнее читать о том, что он не нужен.
>>Они вне конкуренции на серверной стороне, это есть. А на клиенте как-то вяло и крайне редко в чистом виде, в основном идут как высокоуровневый "клей" или вместо скриптовых языков в играх. Т.е. практически ничего нового от нейтива не откусывают.
I>Смотря что с чем сравнивать. Практически все серьезные клиентские продукты стартовали еще до выхода джавы. Е
Ага, и даже cvs/svn, Opera, Google Chrome, WinAMP, Unreal 2/3 Engine, HL2 Engine и т.д. до бесконечности.
Взять те же инструменты для разработки БД. У Оракла на жабе, у MS нейтив. На оракловых без матерка никак, а от MS все летает. ИМХО, такие факторы как скорость загрузки и время реакции для клиентских приложений важнее многих остальных, но не обеспечиваются современными управляемыми средами. Обилие библиотек и сотни тысяч типов в них — это, как выяснилось, палка о двух концах. Что-то типа наручных мега-часов с прилагаемым питанием от аккумуляторов в двух чемоданах.
Здравствуйте, MxMsk, Вы писали:
MM>Здравствуйте, vdimas, Вы писали:
V>>Низкоуровневый layout и рендеринг, как показал опыт WPF — лучше оставить нативным. MM>Интересно, а что подразумевается под "низкоуровневым" layout-ом и рендерингом? И как конкретно на это повлиял "опыт WPF"?
Тормозит лейаут при большом кол-ве элементов. А в программах, типа Word, каждое слово, а иногда и буква — это отдельный визуальный элемент. Если написать на WPF аналог Word-а, на нем работать можно будет только с документами с небольшим числом страниц.
V>>У меня после рестарта с только что загруженной виндой монстровый Word от Office2010 стартует заметно быстрее, чем простейшее WPF-приложение. MM>Adobe Photoshop Elements 8 стартует у меня значительно дольше среднего WPF-приложения. Вывод?
У меня одинаково. Вывод — не засоряйте компьютер плагинами, которые не используете.
MM>И потом, не надо забывать, что современный Word — это таки тонны опыта и многие годы оптимизаций (ха-ха). Давайте поглядим, как WPF-приложение будет стартовать лет эдак через 10 (если доживет )
Еще дольше будет стартовать, так же как WPF сегодня стартует дольше, чем WinForms. Ибо библиотек больше грузится. Через 10 лет еще больше библиотек будет грузиться. Вылечится только тогда, когда типы будут раскиданы по небольшим "тематическим" сборкам, чтобы минимизировать общий размер загружаемых бинарных образов. Ибо сейчас "hello world" на WPF под 30 мег бинарников грузит, а это приговор для десктопа. Даже официальные рекомендации от MS относительно размеров сборок для деплоймента не выдерживают никакой критики. Сборки по 1,5М после ngen будут под 5М, а это полный идиотизм. Для сравнения, большие клиентские приложения на плюсах зачастую имеют довольно компактное ядро, и несколько десятков delay loading DLLs, поэтому стартует все на порядок быстрее.
Здравствуйте, vdimas, Вы писали:
V>Здравствуйте, MxMsk, Вы писали:
MM>>Здравствуйте, vdimas, Вы писали:
V>>>Низкоуровневый layout и рендеринг, как показал опыт WPF — лучше оставить нативным. MM>>Интересно, а что подразумевается под "низкоуровневым" layout-ом и рендерингом? И как конкретно на это повлиял "опыт WPF"?
V>Тормозит лейаут при большом кол-ве элементов. А в программах, типа Word, каждое слово, а иногда и буква — это отдельный визуальный элемент. Если написать на WPF аналог Word-а, на нем работать можно будет только с документами с небольшим числом страниц.
Мне было интересно, что такое "низкоуровневый" layout. А можно пример, где Layout тормозит? Ну и потом, в WPF для работы с текстом используются отдельные средства.
V>>>У меня после рестарта с только что загруженной виндой монстровый Word от Office2010 стартует заметно быстрее, чем простейшее WPF-приложение. MM>>Adobe Photoshop Elements 8 стартует у меня значительно дольше среднего WPF-приложения. Вывод?
V>У меня одинаково. Вывод — не засоряйте компьютер плагинами, которые не используете.
Я не ставил никаких плагинов. Только стандартная поставка.
MM>>И потом, не надо забывать, что современный Word — это таки тонны опыта и многие годы оптимизаций (ха-ха). Давайте поглядим, как WPF-приложение будет стартовать лет эдак через 10 (если доживет )
V>Еще дольше будет стартовать, так же как WPF сегодня стартует дольше, чем WinForms. Ибо библиотек больше грузится. Через 10 лет еще больше библиотек будет грузиться. Вылечится только тогда, когда типы будут раскиданы по небольшим "тематическим" сборкам, чтобы минимизировать общий размер загружаемых бинарных образов. Ибо сейчас "hello world" на WPF под 30 мег бинарников грузит, а это приговор для десктопа. Даже официальные рекомендации от MS относительно размеров сборок для деплоймента не выдерживают никакой критики. Сборки по 1,5М после ngen будут под 5М, а это полный идиотизм. Для сравнения, большие клиентские приложения на плюсах зачастую имеют довольно компактное ядро, и несколько десятков delay loading DLLs, поэтому стартует все на порядок быстрее.
Главное, не забыть через десять лет здесь пересечься
K>Даже к разработке программ на C++ можно, раньше или позже, привыкнуть. А уж привыкнуть к разговорам о его ненужности — сущие пустяки.
Видимо, свербит что-то у обитателей мирка насчет C++. Что-то им все не дает покоя.
Почему программисты C++ не говорят при любой возможности о ненужности хаскеля? Да, видимо, просто им пофиг хаскелисты вместе с хаскелем.
А вот C++ хаскелистам все почему-то не дает покоя.
Почему?
А насчет "привыкания": я тебе могу открыть глаза — есть люди, которые интересуются не только инструментом, но и задачами, которые можно с его помощью решить. Представь себе, можно не только изучать до впадания в маразм все виды отверток и искать отвертку с как можно большим количеством возможностей, а взять и имеющейся отверткой все-таки что-нибудь завинтить, что-нибудь полезное.
Здравствуйте, SpaceConscience, Вы писали:
SC>Видимо, свербит что-то у обитателей мирка насчет C++. Что-то им все не дает покоя.
Лично мне не дает покоя вообще все. Именно C++ среди моих широких интересов совершенно не выделяется и какого-то особого места не занимает.
Кстати, "обитатели мирка" — это кто? Что за "мирок" такой?
SC>Почему программисты C++ не говорят при любой возможности о ненужности хаскеля? Да, видимо, просто им пофиг хаскелисты вместе с хаскелем.
Наверное поэтому вы вдруг, ни с того ни с сего, вспомнили про Хаскель?
SC>А вот C++ хаскелистам все почему-то не дает покоя. SC>Почему?
А что, есть какие-то данные, что не дает? Может быть хаскелисты используют функции, написанные на C++ через FFI, и столкновение с С++ после Хаскеля портит им настроение? Хаскелистов вообще очень мало, как я полагаю. Тут на весь rsdn был, (среди активных авторов, конечно) только один хаскелист. Ну а большинство тех, кого беспокоит C++ и одновременно известно про Хаскель, я так полагаю, пишут на работе на С++, а Хаскель изучают в качестве хобби, для профессионального развития и т.д. Довольно очевидно, почему их беспокоит С++. Они на нем программируют.
SC>А насчет "привыкания": я тебе могу открыть глаза — есть люди, которые интересуются не только инструментом, но и задачами, которые можно с его помощью решить.
Да, это очевидно. Но к чему вы это?
SC> Представь себе, можно не только изучать до впадания в маразм все виды отверток и искать отвертку с как можно большим количеством возможностей, а взять и имеющейся отверткой все-таки что-нибудь завинтить, что-нибудь полезное.
А, т.е. "думать некогда — пилить надо". Ну так на поиск отвертки много времени не требуется. Правда, на работе предлагается на выбор только одна отвертка, да и та — молоток. Как раз это-то от задачи и отвлекает.
... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>
'You may call it "nonsense" if you like, but I'VE heard nonsense, compared with which that would be as sensible as a dictionary!' (c) Lewis Carroll
Здравствуйте, vdimas, Вы писали:
V>Тормозит лейаут при большом кол-ве элементов. А в программах, типа Word, каждое слово, а иногда и буква — это отдельный визуальный элемент. Если написать на WPF аналог Word-а, на нем работать можно будет только с документами с небольшим числом страниц.
Это чушь. С таким же успехом можно и на винформс написать такое тормозилово, про которое будут ажно легенды слагать.
MM>>Adobe Photoshop Elements 8 стартует у меня значительно дольше среднего WPF-приложения. Вывод?
V>У меня одинаково. Вывод — не засоряйте компьютер плагинами, которые не используете.
А если нет никаких плагинов, в чем тогда проблема ?
V>Через 10 лет еще больше библиотек будет грузиться. Вылечится только тогда, когда типы будут раскиданы по небольшим "тематическим" сборкам, чтобы минимизировать общий размер загружаемых бинарных образов.
И ты уверен, что за 10 лет такое не смогут написать ?
>Ибо сейчас "hello world" на WPF под 30 мег бинарников грузит, а это приговор для десктопа.
30мб при среднем объеме оперативы на 2 порядка больше ?
Вот чудеса — прога ест 1% оперативы и это приговор
>Даже официальные рекомендации от MS относительно размеров сборок для деплоймента не выдерживают никакой критики. Сборки по 1,5М после ngen будут под 5М, а это полный идиотизм. Для сравнения, большие клиентские приложения на плюсах зачастую имеют довольно компактное ядро, и несколько десятков delay loading DLLs, поэтому стартует все на порядок быстрее.
Студия во все времена запускалась медленно и ничего. И офисные приложения, и фотошопы. Игрушки так и вовсе обычное дело, приходится ждать.
А щас вот с приходом WPF оказывается сложно подождать столько же времени, сколько приходилось ждать ранее.
K>Кстати, "обитатели мирка" — это кто? Что за "мирок" такой?
Ну как же, это другой мирок, мирок избранных, мирок людей, которые считают, что они нашли панацею в виде того, что они считают функциональным программированием. Для них слово "декларативный" значит "короткий и непонятный". Они считают, что это прикольно, когда программа состоит из шарад, на которые серый 40-тысячный программер смотрит как баран на новые ворота.
SC>>Почему программисты C++ не говорят при любой возможности о ненужности хаскеля? Да, видимо, просто им пофиг хаскелисты вместе с хаскелем. K>Наверное поэтому вы вдруг, ни с того ни с сего, вспомнили про Хаскель? K>Хаскелистов вообще очень мало, как я полагаю.
Это я так обобщенно называю обитателей мирка, имея в виду хаскель в качестве флагмана.
SC>>А вот C++ хаскелистам все почему-то не дает покоя. SC>>Почему? K>А что, есть какие-то данные, что не дает?
SC>Вот я участвую в разработке программы на C++, а мне говорят, что C++ не нужен.
На RSDNъ и дня не проходитъ без аналогiчнаго безответствъннаго заявленiя. Неровен час, скоро молодые да раннiя девълоперы начнут говорить, что КОБОЛЪ устарелъ и более не нуженъ.
SC>И что мне теперь делать?
Делай что будетъ — и будетъ как должно!
Оценить правильность дореволюционной орфографии не могу, так как не владею предметом. Однако заметно, что здесь автор особенно старался, упражняясь в остроумии. Для этого нужна мотивация, хотя для меня происхождение этой мотивации очевидно.
Это ехидство так же нелепо, как поведение рабочего, который в свободное время приходит на завод во фраке и насмехается над своими коллегами, утверждая, что их рабочая униформа некрасива. Он по какой-то причине не понимает, что они надевают униформу не потому, что у них плохой вкус или же они не разбираются в одежде, не говоря уже о том, что он сам носит такую же униформу в рабочее время. Он смехотворный нелепый франт, который считает, что он открыл истину, неведомую другим, этому серому и убогому "большинству".
SC>>А насчет "привыкания": я тебе могу открыть глаза — есть люди, которые интересуются не только инструментом, но и задачами, которые можно с его помощью решить. K>Да, это очевидно. Но к чему вы это?
Да к тому, что обитатели мирка нашли отвертку нового типа, которая, в силу особенности конструкции, достаточно сложна, но при этом забавна в использовании, и теперь изучают на этой отвертке каждый полезный пупырышек, как-то забывая, что отвертки нужны не для того, чтобы из них головоломки складывать, а чтобы шурупы заворачивать, и кто-то даже (вот удивительно) их для этого использует.
Хуже то, что они при этом не упускают случая подразнить остальных рабочих с обычными отвертками, гордо нося свою новую разноцветную многофункциональную отвертку в нагрудном кармане, чтобы остальные могли ее видеть, и отпуская ехидные остроумные замечания в адрес несчастных, которые не смогли освоить замечательную отвертку (наверно, потому что в свободное время они смотрят футбол, ездят на рыбалку или вульгарно напиваются вместо того, чтобы расширять свой кругозор, изучая виды отверток). Правда, когда начинается рабочий день, обладатель чудо-отвертки делается грустным, откладывает чудо-отвертку и достает обычную, потертую и засаленную отвертку, точь в точь как у других, и, вздохнув, приступает к работе.
SC>> Представь себе, можно не только изучать до впадания в маразм все виды отверток и искать отвертку с как можно большим количеством возможностей, а взять и имеющейся отверткой все-таки что-нибудь завинтить, что-нибудь полезное. K>А, т.е. "думать некогда — пилить надо".
Все продумано и перетерто уже сто раз. Здесь опять говорит франт, подразумевающий, что другим не дано понимание, что они по сравнению с ним ущербные.
Есть мирок, а есть унылая сиплюсплюсная и аспнетно-вебенетная говносайтовая реальность.
SC>>Есть мирок, а есть унылая сиплюсплюсная и аспнетно-вебенетная говносайтовая реальность. Т>А нешто тебе никогда не хотелось вырваться из этой говнореальности в дивный новый мирок?
Там речь шла про говносайты, а не про говнореальность. Реальность лишь несколько уныла, но не более того.
Ты ничего не понял, вырываться-то некуда, мирок существует лишь в воображении его обитателей.
Здравствуйте, SpaceConscience, Вы писали:
SC>Ну как же, это другой мирок, мирок избранных, мирок людей, которые считают, что они нашли панацею в виде того, что они считают функциональным программированием. Для них слово "декларативный" значит "короткий и непонятный". Они считают, что это прикольно, когда программа состоит из шарад, на которые серый 40-тысячный программер смотрит как баран на новые ворота.
У вас есть такие знакомые? Лично мне таких не приходилось встречать ни на работе, ни на программистских форумах.
SC>Это я так обобщенно называю обитателей мирка, имея в виду хаскель в качестве флагмана.
Все равно не понимаю, какое отношение имеют эти, по всей видимости, на 90% выдуманные вами люди имеют к Хаскелю?
K>>А что, есть какие-то данные, что не дает? SC>Вот, например: http://www.rsdn.ru/forum/flame.comp/3921725.1.aspx
Т.е. вывод, о том, что каким-то там хаскелистам (причем в каком-то нетрадиционном смысле этого слова для вашего внутреннего употребления) не дает покоя С++ делается по двум моим сообщениям в одной ветке? Во-первых, количество сообщений, которые я пишу о С++ подтверждает мое заявление выше о том, что никакого особого места С++ среди моих интересов не занимает. Во-вторых, не раскрыта моя связь с хаскелистами ни в общепринятом смысле этого слова (я изучаю этот язык для развлечения и собственного развития, но на работе на нем ничего не пишу), ни в вашем персональном смысле — я не имею ничего общего с вышеописанными "обитателями мирка", которые считают что-то панацеей или считают что код должен быть непонятным и которые, по всей видимости, вас чем-то когда-то обидели, а свою душевную боль вы теперь изливаете на меня.
SC>Оценить правильность дореволюционной орфографии не могу, так как не владею предметом. Однако заметно, что здесь автор особенно старался, упражняясь в остроумии.
По-моему, каждый приличный человек доброй воли должен стараться, когда что-то делает. И когда упражняется в остроумии, естественно, тоже. Вы, правда, мне лстите, отмечая какое-то особое старание. К сожалению, я недостаточно трудолюбив и гораздо чаще, чем мне хотелось бы, подхожу к делу спустя рукава. К примеру сообщение с "дореволюционной орфографией" вполне среднее, а первое из обсуждаемых и вовсе написано спустя рукова, что хорошо подтверждается малым числом оценок-улыбок.
SC>Для этого нужна мотивация, хотя для меня происхождение этой мотивации очевидно.
Действительно, моя мотивация на этом форуме очевидо следует из моего никнейма. Каждому ясно, что когда пользователь Клапауций пишет сообщение — им движет желание оказаться в топе РСДН выше, чем пользователь Трурль.
SC>Это ехидство так же нелепо, как поведение рабочего, который в свободное время приходит на завод во фраке и насмехается над своими коллегами, утверждая, что их рабочая униформа некрасива. Он по какой-то причине не понимает, что они надевают униформу не потому, что у них плохой вкус или же они не разбираются в одежде, не говоря уже о том, что он сам носит такую же униформу в рабочее время. Он смехотворный нелепый франт, который считает, что он открыл истину, неведомую другим, этому серому и убогому "большинству".
Мне ваш пост напоминает такую небольшую группу родственных анекдотов, знаете, в которых, например, сосед идет просить у соседа соли или денег взаймы. И по дороге ведет с тем, к кому направляется, такой внутренний, мысленный диалог, все более и более себя накручивая. Ну и, сами понимаете, когда ему открывают дверь — с порога на недоумевающего человека набрасывается. Вот и сейчас я озадачен всем этим гневом и ядом, который на меня, внезапно, выплеснул совершенно незнакомый мне человек. Вы, очевидно, уже зачислили меня в легион (по некоторым признакам я догадываюсь, что это именно легион) ваших врагов и обидчиков, и отклассифицировали меня как злобного хаскелиста, "обитателя мирка" и так дальше; и сделать я уже ничего не могу, но оправдываться все равно хочется. Видите ли, в значительной степени моя ирония направлена как раз против тех, кто вдруг обнаружил, что С++ не нужен, потому что плох. То, что С++ плох, безусловно, ни для кого не секрет. Но С++, разумеется, нужен, хотя в том что он нужен, конечно, нет чего-то особенно хорошего.
SC>Да к тому, что обитатели мирка нашли отвертку нового типа, которая, в силу особенности конструкции, достаточно сложна, но при этом забавна в использовании, и теперь изучают на этой отвертке каждый полезный пупырышек, как-то забывая, что отвертки нужны не для того, чтобы из них головоломки складывать, а чтобы шурупы заворачивать, и кто-то даже (вот удивительно) их для этого использует.
Ну, не знаю. По-моему, программисту, как раз, очень трудно не смотреть на все именно с практической точки зрения. И сильно сомневаюсь в существовании программистов, которые забывают, зачем нужна их отвертка. Точно также и ваши знакомые "хаскелисты", скорее всего, восхищаются в Хаскеле, скорее всего, практическим потенциалом хаскелевских нововведений. (Речь идет именно о потенциале — со зрелыми практичными инструментами дело обстоит, пока что, плохо.) Хотя и забавного там довольно много. Сложность, впрочем, сильно преувеличена.
SC>Хуже то, что они при этом не упускают случая подразнить остальных рабочих с обычными отвертками, гордо нося свою новую разноцветную многофункциональную отвертку в нагрудном кармане, чтобы остальные могли ее видеть, и отпуская ехидные остроумные замечания в адрес несчастных, которые не смогли освоить замечательную отвертку (наверно, потому что в свободное время они смотрят футбол, ездят на рыбалку или вульгарно напиваются вместо того, чтобы расширять свой кругозор, изучая виды отверток).
Не нужно беспокоиться на этот счет. Ваши знакомые "хаскелисты", очевидно, ввели вас в заблуждение. Освоить отвертку легко сможет всякий, кто ее освоить захочет. На базовом уровне, по крайней мере, про более глубокие я сам ничего не знаю. Но понятно, что о какой-либо элитарности после освоения некоего языка говорить не приходится, а действительно хороших специалистов всегда мало и с языком это никак не связано.
SC>Правда, когда начинается рабочий день, обладатель чудо-отвертки делается грустным, откладывает чудо-отвертку и достает обычную, потертую и засаленную отвертку, точь в точь как у других, и, вздохнув, приступает к работе.
Полагаете, незнание сделало бы их счастливее? Вполне возможно, кстати.
SC>Все продумано и перетерто уже сто раз.
Что, вообще все? Когда я не знал об этом, я, пожалуй, был счастливее, прав таки был старина Соломон. Получается, мозг мне и не пригодится больше, раз думать уже не о чем, а три ватта (или сколько там) в среднем так и будет до конца жизни потреблять. Впрочем, остается надежда, что упражнения в остроумии на форумах позволят как-то утилизировать простаивающие мощности.
SC>Здесь опять говорит франт, подразумевающий, что другим не дано понимание, что они по сравнению с ним ущербные.
Вообще, понимание не дают — понимание сами берут все желающие. Поэтому о какой-то ущербности говорить не приходится. Вы поменьше общайтесь со всякими зазнайками-"хаскелистами", такими темпами они из вас мизантропа сделают.
SC>Есть мирок, а есть унылая сиплюсплюсная и аспнетно-вебенетная говносайтовая реальность.
Ну так что? Кто-то попытается скрасить эту реальность, приходя на работу во фраке (это я, в принципе, могу понять), а кто-то ненавидя первых за это и громя мифических шейнфенкелистов-хаскелистов на форумах (это понять уже труднее, но тоже можно).
... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>
'You may call it "nonsense" if you like, but I'VE heard nonsense, compared with which that would be as sensible as a dictionary!' (c) Lewis Carroll
Здравствуйте, Геннадий Васильев, Вы писали:
SC>>И что мне теперь делать?
ГВ>Ничего. На RSDN это "тренд": говорить о ненужности C++. Раньше или позже к таким разговорам привыкаешь, как к снегу зимой. Даже забавно иной раз.
Здравствуйте, Ikemefula, Вы писали:
ГВ>>Ничего. На RSDN это "тренд": говорить о ненужности C++. Раньше или позже к таким разговорам привыкаешь, как к снегу зимой. Даже забавно иной раз.
I>Челы на ассемблере тоже самое говорят.
О, Великий Гуру, ты знаешь ассемблер человеков! Достойны ли мы будем твоего снисходительного рассказа об этом тайном языке?
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, Ikemefula, Вы писали:
V>>Тормозит лейаут при большом кол-ве элементов. А в программах, типа Word, каждое слово, а иногда и буква — это отдельный визуальный элемент. Если написать на WPF аналог Word-а, на нем работать можно будет только с документами с небольшим числом страниц.
I>Это чушь. С таким же успехом можно и на винформс написать такое тормозилово, про которое будут ажно легенды слагать.
Это так и есть. Насчет winForms — тоже. У MS на сегодня рулят windowless ActiveX controls.
MM>>>Adobe Photoshop Elements 8 стартует у меня значительно дольше среднего WPF-приложения. Вывод?
V>>У меня одинаково. Вывод — не засоряйте компьютер плагинами, которые не используете.
I>А если нет никаких плагинов, в чем тогда проблема ?
У фотошопа куча плагинов даже по-умолчанию и все они грузятся сразу. Сравни с подходом COM/ActiveX или delay loading dll.
V>>Через 10 лет еще больше библиотек будет грузиться. Вылечится только тогда, когда типы будут раскиданы по небольшим "тематическим" сборкам, чтобы минимизировать общий размер загружаемых бинарных образов.
I>И ты уверен, что за 10 лет такое не смогут написать ?
Нет, уверен, что смогли бы уже сейчас, но не стали. И через 10 лет не станут, ибо быстродействие носителей на месте не стоит, и 30 мег загрузки бинарников проблемой являться не будет.
>>Ибо сейчас "hello world" на WPF под 30 мег бинарников грузит, а это приговор для десктопа.
I>30мб при среднем объеме оперативы на 2 порядка больше ?
Только для чтения с диска нескольких разбросанных файлов общим таким размером может потребоваться более секунды.
I>Вот чудеса — прога ест 1% оперативы и это приговор
Че-то тебя понесло в степь полнейшего непонимания о чем речь.
>>Даже официальные рекомендации от MS относительно размеров сборок для деплоймента не выдерживают никакой критики. Сборки по 1,5М после ngen будут под 5М, а это полный идиотизм. Для сравнения, большие клиентские приложения на плюсах зачастую имеют довольно компактное ядро, и несколько десятков delay loading DLLs, поэтому стартует все на порядок быстрее.
I>Студия во все времена запускалась медленно и ничего. И офисные приложения, и фотошопы. Игрушки так и вовсе обычное дело, приходится ждать.
Офисы запускались довольно быстро до выпуска Office 2000, особенно неплох был Office 95. Попробуй найти на досуге и позапускать. Потом что-то "сломалось", и починилось только в 2010-м, по крайней мере Word опять запускается довольно сносно.
I>А щас вот с приходом WPF оказывается сложно подождать столько же времени, сколько приходилось ждать ранее.
Комп мощнее в 10 раз, а приходится ждать в 2-3 раза дольше.
И ладно бы речь шла о приложениях типа VS, где уместен довод типа "зато много всякой реал-тайм поддержки со стороны среды разработки", так речь об обычных приложениях, которые с т.з. функциональности и близко не лежат рядом со студиями и фотошопами. Для сравнения, одинаковые по сложности приложения на HTML-layout стартуют просто мгновенно.
Здравствуйте, SpaceConscience, Вы писали:
SC>Видимо, свербит что-то у обитателей мирка насчет C++. Что-то им все не дает покоя.
У нетчиков не меньше свербит насчет C++.
Кстати именно нетчики, а не плюсисты в основном устраивали тут лет пять назад феерические холивары как против функциональщины
так и против динамики и также против C++, даже бедному оберону досталось (хотя его все пинали )
В результате самые злобные нетчики перековались в немерлистов
Так что мирок ждет тебя
SC>Почему программисты C++ не говорят при любой возможности о ненужности хаскеля? Да, видимо, просто им пофиг хаскелисты вместе с хаскелем.
Говорят, вернее говорили и больше нетчики, так как здесь они основной контингент, просто острая фаза дискуссий прошла несколько лет назад.
SC>А вот C++ хаскелистам все почему-то не дает покоя.
Тренд такой пинать C++ этим все, даже сами плюсисты страдают. Во многом заслуженно. Во многом из-за кучи мифов от людей которые плохо осилили C++
и перешли на другие языки.
SC>А насчет "привыкания": я тебе могу открыть глаза — есть люди, которые интересуются не только инструментом, но и задачами, которые можно с его помощью решить. Представь себе, можно не только изучать до впадания в маразм все виды отверток и искать отвертку с как можно большим количеством возможностей, а взять и имеющейся отверткой все-таки что-нибудь завинтить, что-нибудь полезное.
Здравствуйте, SpaceConscience, Вы писали:
K>>Кстати, "обитатели мирка" — это кто? Что за "мирок" такой?
SC>Ну как же, это другой мирок, мирок избранных, мирок людей, которые считают, что они нашли панацею в виде того, что они считают функциональным программированием. Для них слово "декларативный" значит "короткий и непонятный". Они считают, что это прикольно, когда программа состоит из шарад, на которые серый 40-тысячный программер смотрит как баран на новые ворота.
Любая творческая работа требует завышенное ЧСВ.
ФП будучи на гребне хайп волны сильно привлекает таких людей.
То же самое было и с "новым C++" когда Алесандреску выпустил свою книжку.
То же самое было когда ООП входил в массы.
Здравствуйте, SpaceConscience, Вы писали:
SC>Там речь шла про говносайты, а не про говнореальность. Реальность лишь несколько уныла, но не более того.
SC>Ты ничего не понял, вырываться-то некуда, мирок существует лишь в воображении его обитателей.
Здравствуйте, SpaceConscience, Вы писали:
FR>>Мне кажется он существует только в твоей голове.
SC>Да в твоей голове, в твоей. Не я его придумал. И термин не я придумал, а один из "ваших".
Я в первый раз услышал от тебя и в темах которых ты не участвуешь не слышал.
И кстати и не из ваших и не из наших, мне одинаково нравятся C++ питон и окамл.
SC>Для меня его вообще нет, а есть люди, которые думают, что он есть.
Угу "я проскакала много вёрст, чтобы сказать вам, как вы мне безразличны".
FR>Я в первый раз услышал от тебя и в темах которых ты не участвуешь не слышал.
А я услышал, и мне стало смешно, и захотелось постебаться. Но у обитателей мирка нарушено мышление, и они ни хрена адекватно не воспринимают. Оно и понятно.
FR>И кстати и не из ваших и не из наших, мне одинаково нравятся C++ питон и окамл.
Ключевое слово выделено. Я нигде не говорил, что мне С++ нравится. Я просто на нем пишу программы, мог бы и на другом языке, но по ряду объективных причин это в настоящее время невозможно. С++ — это просто инструмент такой для разработки программ, а не объект для обожания.
Говорите сколько угодно, что С++ — язык, обладающий кучей недостатков, и, вообще, хреновый язык. Я под этим подпишусь.
Глупость — это говорить, что С++ не нужен, а также писать оскорбительные насмешливые говнокреативные комментарии.
SC>>Для меня его вообще нет, а есть люди, которые думают, что он есть. FR>Угу "я проскакала много вёрст, чтобы сказать вам, как вы мне безразличны".
Здесь я вообще не понял связи респонса с реквестом.
Короче, ладно, у тебя тоже что-то с четкостью мышления не так, проехали.
Здравствуйте, SpaceConscience, Вы писали:
SC>А я услышал, и мне стало смешно, и захотелось постебаться. Но у обитателей мирка нарушено мышление, и они ни хрена адекватно не воспринимают. Оно и понятно.
Мало кто вообще адекватно воспринимает когда над ними стебутся.
FR>>И кстати и не из ваших и не из наших, мне одинаково нравятся C++ питон и окамл.
SC>Ключевое слово выделено. Я нигде не говорил, что мне С++ нравится. Я просто на нем пишу программы, мог бы и на другом языке, но по ряду объективных причин это в настоящее время невозможно. С++ — это просто инструмент такой для разработки программ, а не объект для обожания.
Можешь заменить "нравятся" на "не нравятся" смысл от этого не изменится.
Ну и для просто инструмента ты слишком эмоционален
SC>Говорите сколько угодно, что С++ — язык, обладающий кучей недостатков, и, вообще, хреновый язык. Я под этим подпишусь.
SC>Глупость — это говорить, что С++ не нужен, а также писать оскорбительные насмешливые говнокреативные комментарии.
Согласен.
SC>>>Для меня его вообще нет, а есть люди, которые думают, что он есть. FR>>Угу "я проскакала много вёрст, чтобы сказать вам, как вы мне безразличны".
SC>Здесь я вообще не понял связи респонса с реквестом.
Ты слишком сильно и слишком эмоционально нападаешь на "мирок" при этом утверждая что он тебе безразличен,
поведение один в один с героиней фильма откуда взята цитата.
SC>Короче, ладно, у тебя тоже что-то с четкостью мышления не так, проехали.
Угу к всех (кроме тебя?) проблемы с четкостью мышления
Здравствуйте, SpaceConscience, Вы писали:
SC>Что за переключения сознания? Странно.
По моему все три одинаково адекватны.
А ты по моему просто опоздал, бои давно отгремели и старые участники давно такие вещи всерьез не воспринимают
Особенно тут в КСВ.
SC>>А я услышал, и мне стало смешно, и захотелось постебаться. Но у обитателей мирка нарушено мышление, и они ни хрена адекватно не воспринимают. Оно и понятно. FR>Мало кто вообще адекватно воспринимает когда над ними стебутся.
Здесь получилось так, что ты как бы произнес остроту, но тот, кого ты пытался ей уязвить, не понял смысла фразы и, вместо того, чтобы стать уязвленным, начал спорить не по теме.
FR>Ну и для просто инструмента ты слишком эмоционален
Я эмоционален не по поводу инструмента, а по поводу того, что кто-то пытается оскорблять то, чем я занимаюсь.
FR>Ты слишком сильно и слишком эмоционально нападаешь на "мирок" при этом утверждая что он тебе безразличен, FR>поведение один в один с героиней фильма откуда взята цитата.
Я нигде не утверждал, что мирок мне безразличен. Напротив, он меня смешит и раздражает.
FR>Угу к всех (кроме тебя?) проблемы с четкостью мышления
Ну я ж не говорил про всех-то — ну вот нет же четкости-то.
Здравствуйте, SpaceConscience, Вы писали:
SC>Здесь получилось так, что ты как бы произнес остроту, но тот, кого ты пытался ей уязвить, не понял смысла фразы и, вместо того, чтобы стать уязвленным, начал спорить не по теме.
Черт эти функциональщики вообще неуправляемые и злобные, особенно хаскелисты.
SC>Я эмоционален не по поводу инструмента, а по поводу того, что кто-то пытается оскорблять то, чем я занимаюсь.
Что не мешает тебе оскорблять то чем занимаются они
SC>Я нигде не утверждал, что мирок мне безразличен. Напротив, он меня смешит и раздражает.
Скорее раздражает, а смех какой-то нервный, на мой взгляд.
FR>>Угу к всех (кроме тебя?) проблемы с четкостью мышления
SC>Ну я ж не говорил про всех-то — ну вот нет же четкости-то.
Конечно, даже функциональщики все-таки люди со всеми присущими этим существам недостатками.
Здравствуйте, Алексей., Вы писали:
А>Здравствуйте, gandjustas, Вы писали:
G>>Для C# на Lisp с последующей трансляцией в C++.
А>Откуда такая информация?
FR>Черт эти функциональщики вообще неуправляемые и злобные, особенно хаскелисты.
Главное, они надменные и насмешливые.
SC>>Я эмоционален не по поводу инструмента, а по поводу того, что кто-то пытается оскорблять то, чем я занимаюсь. FR>Что не мешает тебе оскорблять то чем занимаются они
Дак не получается же, они ж нифига не понимают.
SC>>Я нигде не утверждал, что мирок мне безразличен. Напротив, он меня смешит и раздражает. FR>Скорее раздражает, а смех какой-то нервный, на мой взгляд.
Да, потому что не получилось поиздеваться над обитателями мирка. Туповат я, видимо, остроумия не хватает.
FR>Конечно, даже функциональщики все-таки люди со всеми присущими этим существам недостатками.
Я именно говорил про обитателей мирка, а не про всех функциональщиков. К функциональщикам в целом у меня никаких претензий нет.
Ладно, хрен с ним, в дальнейшем постараюсь не обращать внимания.
Здравствуйте, vdimas, Вы писали:
V>А смысла нет, как выяснилось. Там переписывать особо нечего. Низкоуровневый layout и рендеринг, как показал опыт WPF — лучше оставить нативным.
Не знаю что у тебя там опыт WPF показал, но composition engine, которая собственно рендеринг и "низкоуровневый лейаут" осуществляет, в WPF нативная.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Здравствуйте, vdimas, Вы писали:
V>>Взять те же инструменты для разработки БД. У Оракла на жабе, у MS нейтив.
НС>Фик тебе. У МС дотнет уже несколько версий.
G>>>>>Подход с компиляцией регэкспов в машинный код на С++ невозможен (или очень проблематичен).
[...] G>Да пофигу. Даже гугл неспособен такое сделать, не надо мне доказывать что это несложная задача.
Google в своем движке регулярок для V8 сделал компиляцию в машинный код. Вот статья.
After optimization we generate native machine code which uses backtracking to try different alternatives.
Правда в irregexp автомат обходится все равно backtracking'ом. В гугловском re2 например строится несколько автоматов (DFA для match и фильтрации, NFA для submatching) и backtracking используется только если выражение содержит backreference. Видимо надо эти два подхода скрестить, тогда будет совсем счастье.
Здравствуйте, SV., Вы писали:
R>>Для начала ты начни пользоватся веб браузером, написанном от начала до конца на языке с GC, а потом на нем же пиши посты что c/c++ не нужен. SV.>А можете привести примеры таких браузеров? С удовольствием гляну.
В том то и дело...
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, gandjustas, Вы писали:
G>Кстати Lisp в этом плане гораздо круче C++. И существует дольше, и развиваться продолжает, и проекты на нем пишутся.
Думаешь на С++ уже не пишутся?
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, gandjustas, Вы писали:
V>>Это вряд ли случится. Компилятор С можно написать на С. .NET машину нельзя написать на .NET. Следовательно, С не умрет никогда. G>А я и не говорю про C, я говорю про C++.
Ну в С++ есть некое подмножество, которое однозначно ЛУЧШЕ С...
Просто на С++ в гугле том же пишут несколько оригинально. Так что функциональщина и STLьщина скорее всего отомрёт, уступив более удобным инструментам.
Ну а "С с классами" останется.
Единственное, что, IMHO, может подкосить С++ -- это отказ от современной архитектуры компов. Ну там квантовые компы какие-нибудь заботают, или самонаращивающие мощности или ещё какие...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, master_of_shadows, Вы писали:
E>>Зачем? __>Когда процессор может нативно выполнять системный язык — это наилучшая ситуация.
Для чего она лучшая? Почему лучшая? Чем JIT или компилятор снаружи процессора хуже микрокода внутри?..
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Не знаю что у тебя там опыт WPF показал, но composition engine, которая собственно рендеринг и "низкоуровневый лейаут" осуществляет, в WPF нативная.
Ты наверно не понял о чем речь. Посмотри рефлектором код лейаута различных панелей.
Здравствуйте, Erop, Вы писали:
E>Я наверное как-то непонятно сказал. Что от этого улучшится? Что станет быстрее, дешевле, легче, модифицируемие и т. д.?
Всё. Быстрее, дешевле, легче. И создание железа, и софта, и ОС.
E>Для Юникса -- да, для железа под Юникс ни разу ни Си. Так как были на том же железе ещё и кобол и фортран крайне популярны, например. Ещё Ада где-то по ящикам обтиралась, кстати...
Не придирайся к словам. Если бы проц умел испольнять Си, Юниксу хуже от этого стало бы?
__>>Для иФона ОбджективСи. E>А разве туда нативный код нельзя вставлять? Кроме того, objC -- это всего лишь интерфейс API, и только. Внутри всё те же процы, и всё тот же С, если посмотреть уровнем повыше
И что что можно? А ты в асемблер можеш вставить внутреннюю команду АМД? И как, сильно мешает жить?
__>>Для Андроида — джава. E>А они ещё не сдались на предмет нативных вставок?
То же самое что и выше.
__>>Если процессор умеет нативно выполнять системный язык — это просто отлично. E>Воот я вижу один очевидный недостаток, по крайней мере. Если ты, грубо говоря, сделаешь проц, который интерпретирует байткод, то ты остановишь прогресс этого твоего "системного языка". И конкурирующие платформы тебя быстренько скушают...
Джаву уже съели?
E>Так что список минусов уже открыт. А плюсы-то в чём?
Да во всём плюсы. Если софт пишется на языке который не нативный для ОС и железа — вот это реальные минусы.
Здравствуйте, master_of_shadows, Вы писали:
__>Всё. Быстрее, дешевле, легче.
Что-то как-то мы друг друга похоже не понимаем совсем.
Давай по пунктам разберём?
__>И создание железа,
Создание железа, IMHO, только затруднится, так как надо реализовать в железе виртуальную машину для защищённого кода, GC и много всего ещё. При этом ещё придётся зафиксировать байткод, так что следующую версию проца придётся втискивать в прокрустово ложе старого стандарта...
так что для разработчиков железа, как раз, не понятно откуда облегчение-то придёт.
__>и софта
Опять же не понятно. Не пофигу ли софту JIT там или проц? Наоборот, JIT может прогрессировать быстрее, и иметь инсталляционную базу намного шире, чем конкретная модель проца... Так что для разработчиков ПО либо пофиг, либо минус. __>, и ОС.
Про ОС вообще интересно. Сейчас как ОС на экзотическое железо делают? Ядро линуха или фряхи адаптируют и всё в ажуре. А если надо будет управляемую ОС с нуля писать, то это намного дольше и дороже...
__>Не придирайся к словам. Если бы проц умел испольнять Си, Юниксу хуже от этого стало бы?
Я опять тебя не понимаю. Как ты себе представляешь выделенное?
Типа в проц закачивают исходники С? Если так, то юникс бы никогда не заработал. А если не так, то я не совсем понимаю как...
__>И что что можно? А ты в асемблер можеш вставить внутреннюю команду АМД? И как, сильно мешает жить?
Так это тоже команда ассемблера получается. Просто другого. И всё это входит в "системный язык", выходит...
__>>>Если процессор умеет нативно выполнять системный язык — это просто отлично. E>>Воот я вижу один очевидный недостаток, по крайней мере. Если ты, грубо говоря, сделаешь проц, который интерпретирует байткод, то ты остановишь прогресс этого твоего "системного языка". И конкурирующие платформы тебя быстренько скушают...
__>Джаву уже съели?
В смысле? Я опять тебя не понимаю? Ты имеешь в виду какой-то проц, который явский байткод умеет интерпретировать? IMHO, это просто невозможно... Так что что именно должны были съесть?
__>Да во всём плюсы. Если софт пишется на языке который не нативный для ОС и железа — вот это реальные минусы.
А в чём минусы? Компиляторы, вроде как, давно уже хорошие писать научились...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, Erop, Вы писали:
__>>И создание железа, E>Создание железа, IMHO, только затруднится, так как надо реализовать в железе виртуальную машину для защищённого кода, GC и много всего ещё.
GC в процессоре вообще бессмысленно делать, ничего не даст. Можно сделать низкоуровневые аппаратные хелперы для него. Например неблокирующие счетчики или железную транзакционную память.
__>>Джаву уже съели? E>В смысле? Я опять тебя не понимаю? Ты имеешь в виду какой-то проц, который явский байткод умеет интерпретировать? IMHO, это просто невозможно...
Здравствуйте, Ночной Смотрящий, Вы писали:
E>>В смысле? Я опять тебя не понимаю? Ты имеешь в виду какой-то проц, который явский байткод умеет интерпретировать? IMHO, это просто невозможно...
НС>http://en.wikipedia.org/wiki/Jazelle
А как оно выполняет функциональный вызов-то?
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
E>>Так что список минусов уже открыт. А плюсы-то в чём?
__>Да во всём плюсы. Если софт пишется на языке который не нативный для ОС и железа — вот это реальные минусы.
Да нет там никаких минусов Сейчас единственными «ненативной» для проца является всякая функциональщина, имхо. Всякая императивщина аккуратно ложится на архитетуру проца, и все счастливы.
Более того, какой именно язык, нативный для ОС, ты будешь класть в процессор? С? С++? Prolog? (Тут на форуме пробегала инфа о том, что Винда использует пролог для определения набора драйверов, которые должны ставиться в систему)
А что делать не с ОСью, а сприложениями в этой ОСи? Со всеми этими дотнетами, джавами, сями, эрлангами, рубями, питонами и т.п.? Или делаем только один убер-язык, а остальные предаем анафеме?
__>>Джаву уже съели? E>В смысле? Я опять тебя не понимаю? Ты имеешь в виду какой-то проц, который явский байткод умеет интерпретировать? IMHO, это просто невозможно... Так что что именно должны были съесть?
Новости очень смешные. Зря вы не смотрите. Как будто за наркоманами подсматриваешь. Только тетка с погодой в завязке.
There is no such thing as a winnable war.
E__>>Предложившего этот путь быстрее самого предадут анафеме.
__>Раскажите это Эпл.
А что ей рассказывать? Байткод их процессоры точно не выполняют. Даже в случае с бойкотом сторонних языков, который уже снят, на айфоне работал Objective-C и Javascript, что уже никак нельзя считать одним языком
Здравствуйте, Mamut, Вы писали:
E__>>>Предложившего этот путь быстрее самого предадут анафеме.
__>>Раскажите это Эпл.
M>А что ей рассказывать? Байткод их процессоры точно не выполняют. Даже в случае с бойкотом сторонних языков, который уже снят, на айфоне работал Objective-C и Javascript, что уже никак нельзя считать одним языком
У эппла остались их процессоры?
Расскажите это маньякам, которые запустили на айфоне Убунту.
Новости очень смешные. Зря вы не смотрите. Как будто за наркоманами подсматриваешь. Только тетка с погодой в завязке.
There is no such thing as a winnable war.
Здравствуйте, Ночной Смотрящий, Вы писали:
V>> Посмотри рефлектором код лейаута различных панелей.
НС>Я тебе еще раз повторяю — рендеринг и базовый лейаут выполняется асинхронным нативным движком. А то, что в различных панелях видно рефлектором, это уже не низкоуровневый лейаут, про который ты писал. НС>http://blogs.msdn.com/b/greg_schechter/archive/2006/06/09/623566.aspx
Наверно, стоило уточнять, что ты имел ввиду WPF 4.0, сэкономили бы время на пару итераций. Да, там есть некая wpfgfx_v0400.dll, которая используется там, где до этого (WPF в 3.0-3.5) были непосредственные вызовы COM-АПИ DirectX.
И все равно, извини, отдает полным непониманием происходящего. Да, DirectX был нативный, и сейчас упомянутая более высокоуровневая обертка "wpfgfx" — тоже нативная... Однако, размещение визуальных элементов в "виртуальном" буфере страницы осуществляется по прежнему наследниками элемента Panel (Grid, StackPanel, WrapPanel). И оно по-прежнему 100% managed. Т.е. значения всех bounds вычисляются managed по всему visual tree, сами эти изменения попадают в нативную обертку, которая строит сцену при рендеринге, и т.д. Но это не принципиально, ибо затраты на непосредственное отображение на современных компах не столь значительны (это я из опыта использования 100% Java RDP клиентов). А вот с форматированием, когда счет элементам идет на многие-многие тысячи и есть многоуровневые вложения (взять для примера достаточно большой Word-документ) — это требует определенной шустрости, чтобы не ждать несколько секунд после применения нового стиля к документу, пока оно там "утрясется".
В общем, именно этот момент пока критичный. Не зря браузеры соревнуются по быстродействию именно в этом плане, т.к. операция форматирования, при достаточно сложном visual tree, порой нетривиальная, итеративная, триггерящая многократные проходы.
Я предполагал, что и так достаточно очевидно, на чем именно использование WPF дает преимущество в плане быстродействия — это там, где удается задействовать ресурсы видеоускорителя. Например, из значительных перемен я обнаружил отказ от старых BitmapEffects, которые ранее выглядели скорее как эксперимент, случайно попавший в продакшн. Новые Effects действительно находятся там где надо, и делают свою работу эффективно. Вот это и есть ниша WPF — "богатое" графическое отображение. Но в плане вычисления расположения элементов, никакие видеоускорители, увы, пока что не помощники.
Возможно, что когда-нить задействуют нечто вроде CUDA в WPF, и все станет иначе. Но это не в обозримом будущем, ибо 4.0 вышел недавно, и ему надо прожить достаточно долгую жизнь, чтобы окупить вложения в него.
Здравствуйте, vdimas, Вы писали:
V>Наверно, стоило уточнять, что ты имел ввиду WPF 4.0
Опять какие то фантазии. Я имел в виду WPF 1.0. 2006 в url ссылки знаешь что означает?
V>И все равно, извини, отдает полным непониманием происходящего.
Это точно. Вопрос в том, с чей стороны.
V>В общем, именно этот момент пока критичный. Не зря браузеры соревнуются по быстродействию именно в этом плане, т.к. операция форматирования, при достаточно сложном visual tree, порой нетривиальная, итеративная, триггерящая многократные проходы.
Ага, именно поэтому в IE 9 сделали упор на аппаратную акселерацию рендеринга.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Программный JIT лучше. Во-первых его легко обновить, во-вторых ему доступно значительно больше памяти чем потенциально внутри процессора, и, в случае прекомпиляции, еще и на порядки больше времени. Единственный потенциальный плюс железного JIT (именно JIT, никто байткод напрямую на железе не выполняет и выполнять не будет) это существенно лучшие показатели ужора электричества.
Да как раз байт-код стек-ориентированных VM в железе можно исполнять напрямую, без JIT, из-за его простоты. Если брать конкретный байткод .Net VM, то он не пригоден для непосредственного исполнения железным процом в любом случае, хоть с джитом, хоть без, из-за способа кодирования вызовов, определения размеров объектов, наследования и прочей мета-информации, по которой ни один проц не сможет работать. Но, можно сделать байт-код с минимальным отличием, чтобы эти отличия стоили не дороже, чем работа обычного загрузчика нативного исполняемого файла в современных ОС. И такой бай-код в "реальных" адресах можно было бы исполнять напрямую, без микрокода, ввиду его простоты.
Здравствуйте, vdimas, Вы писали:
V>Да как раз байт-код стек-ориентированных VM в железе можно исполнять напрямую, без JIT
И без оптимизации. Только это интерпретирующее гавно никому не нужно будет.
V>, из-за его простоты. Если брать конкретный байткод .Net VM, то он не пригоден для непосредственного исполнения железным процом в любом случае, хоть с джитом, хоть без, из-за способа кодирования вызовов
Это мелочь, ХЗ чего ты за нее уцепился. Трансляции в микрокод это не помешает.
Здравствуйте, MxMsk, Вы писали:
MM>Да ладно. Раньше WPF точно также не работал с DirectX напрямую, а использовал milcore.dll.
Все структуры и константы, описывающие примитивы, преобразования и т.д. — напрямую из DirectX. А прослойка эта была связана скорее всего в несовместимостью самого DirectX м/у версиями 9.0 и теми, что выше. У меня и в нативной части приложения был некий слой-абстракция, обеспечивающий единый АПИ для разных версий DirectX.
MM>Да что ты привязался к этим панелям В них же простейший код! Тормоза начинаются там, где нужно считать место для геометрий и глифов, в которые в итоге выливаются все элементы. Этим занимается unmanaged.
Это он на первый взгляд простейший, но смотри далее, что скрывается за каждым обновлением. Фишка форматирования в том, что оно может сбрасываться и начинаться заново, и так до полного "утрясания". Это весьма нагрузочный код для большого кол-ва элементов и большой их вложенности. И managed-тормоза тут связаны с медленным проходам по массивам в managed. Я уже приводил тут данные, что числодробильные алгоритмы работают в managed в 3-5 раз медленнее. Что есть числодробильные алгоритмы? Это обычно довольно примитивные вычисления на каждом шаге цикла, но при большом кол-ве итераций. Медленно дотнет итерирует, се ля ви.
Здравствуйте, vdimas, Вы писали:
V>Здравствуйте, MxMsk, Вы писали:
MM>>Да ладно. Раньше WPF точно также не работал с DirectX напрямую, а использовал milcore.dll.
V>Все структуры и константы, описывающие примитивы, преобразования и т.д. — напрямую из DirectX.
В силу того, что я не являюсь знатоком DirectX, я просто с ходу приведу тебе несколько структур, и надеюсь ты напишешь, к какой части DirectX они относятся. Вот, например, MILCMD_GUIDELINESET, MIL_SEGMENT_POLY и MILCMD_ELLIPSEGEOMETRY.
V>А прослойка эта была связана скорее всего в несовместимостью самого DirectX м/у версиями 9.0 и теми, что выше. У меня и в нативной части приложения был некий слой-абстракция, обеспечивающий единый АПИ для разных версий DirectX.
Что значит "была связана", когда она так и осталась. Почитай уже хоть Википедию что-ли.
MM>>Да что ты привязался к этим панелям В них же простейший код! Тормоза начинаются там, где нужно считать место для геометрий и глифов, в которые в итоге выливаются все элементы. Этим занимается unmanaged.
V>Это он на первый взгляд простейший, но смотри далее, что скрывается за каждым обновлением. Фишка форматирования в том, что оно может сбрасываться и начинаться заново, и так до полного "утрясания". Это весьма нагрузочный код для большого кол-ва элементов и большой их вложенности. И managed-тормоза тут связаны с медленным проходам по массивам в managed. Я уже приводил тут данные, что числодробильные алгоритмы работают в managed в 3-5 раз медленнее. Что есть числодробильные алгоритмы? Это обычно довольно примитивные вычисления на каждом шаге цикла, но при большом кол-ве итераций. Медленно дотнет итерирует, се ля ви.
Вот и славно! Осталось MS переписать код измерения и компоновки в панелях через unsafe и чудеса — WPF ускорится в 3-5 раз!
E__>>>>Предложившего этот путь быстрее самого предадут анафеме.
__>>>Раскажите это Эпл.
M>>А что ей рассказывать? Байткод их процессоры точно не выполняют. Даже в случае с бойкотом сторонних языков, который уже снят, на айфоне работал Objective-C и Javascript, что уже никак нельзя считать одним языком
E__>У эппла остались их процессоры?
Я имел в виду, процессоры, что используются в их продуктах
MM>Вот и славно! Осталось MS переписать код измерения и компоновки в панелях через unsafe и чудеса — WPF ускорится в 3-5 раз!
Да весь код в нейтив переписать придется, ибо начинать надо будет с контейнеров, которые должны будут хранить нейтивные указатели. В общем, WPF вполне подходит для "формочек", но Word, IE И прочее MS упорно переписывает на нейтиве. Причем, с Офиса 2007, насколько я вижу, рендеринг в Word был переделан практически полностью. А ведь WPF уже был достаточно mature на тот момент. Странно, что эти "мелочи" усиленно игнорируются оппонентами.
Здравствуйте, MxMsk, Вы писали:
MM>В силу того, что я не являюсь знатоком DirectX, я просто с ходу приведу тебе несколько структур, и надеюсь ты напишешь, к какой части DirectX они относятся. Вот, например, MILCMD_GUIDELINESET, MIL_SEGMENT_POLY и MILCMD_ELLIPSEGEOMETRY.
Здравствуйте, vdimas, Вы писали:
V>Здравствуйте, MxMsk, Вы писали:
MM>>В силу того, что я не являюсь знатоком DirectX, я просто с ходу приведу тебе несколько структур, и надеюсь ты напишешь, к какой части DirectX они относятся. Вот, например, MILCMD_GUIDELINESET, MIL_SEGMENT_POLY и MILCMD_ELLIPSEGEOMETRY.
V>А это полный список? Лень посмотреть остальное?
Предлагаешь мне выложить сюда все типы из System.Windows.Media.Composition? Полный список смотри Рефлектором, а здесь будь добр, подтверди свои слова о том, что "Все структуры и константы, описывающие примитивы, преобразования и т.д. — напрямую из DirectX"
Здравствуйте, vdimas, Вы писали:
V>Да весь код в нейтив переписать придется, ибо начинать надо будет с контейнеров, которые должны будут хранить нейтивные указатели. В общем, WPF вполне подходит для "формочек", но Word, IE И прочее MS упорно переписывает на нейтиве.
MM>Да что ты привязался к этим панелям В них же простейший код! Тормоза начинаются там, где нужно считать место для геометрий и глифов, в которые в итоге выливаются все элементы. Этим занимается unmanaged.
Кстати говоря, как выяснилось, та же нехалтурная отрисовка шрифтов из managed нехило жрет процессор...
Новости очень смешные. Зря вы не смотрите. Как будто за наркоманами подсматриваешь. Только тетка с погодой в завязке.
There is no such thing as a winnable war.
V>>Да весь код в нейтив переписать придется, ибо начинать надо будет с контейнеров, которые должны будут хранить нейтивные указатели. В общем, WPF вполне подходит для "формочек", но Word, IE И прочее MS упорно переписывает на нейтиве. G>Переписывания там очень малая часть. Врядли на каждый релиз хотябы 50% кода переписывается.
Да нет, если сохраненить как формат предыдущих версий Word, то плывет форматирование даже в простейших случаях, когда используются просто абзацы текста, набранные одним и тем же шрифтом. Налицо изменение алгоритмов лейаута в новых офисах. Зато, после сохранения документа как HTML вид стал меняться не так сильно, как раньше. Подозреваю, что в этой причине и зарыта собака.
V>>Причем, с Офиса 2007, насколько я вижу, рендеринг в Word был переделан практически полностью. А ведь WPF уже был достаточно mature на тот момент. G>Ага учитывая что WPF появился аж в начале 2007 года, а офис 2007 начали делать гораздо раньше.
В ноябре 2006-го. И подозреваю, что делать начали гораздо раньше. И контора, вроде, та же самая.
G>Просто оппоненты понимают что переписывать существующий софт только ради managed смысла нет. Вообще нет.
А как же разрекламировананя легкость добавления сомна новых фич?
Но на самом деле тут дело немного в другом. Покажи-ка мне адекватный OLE-клиент и OLE-сервер на дотнете?
Я в упор не понимаю, почему MS их не сделало. Делал когда-то сам OLE-клиент, так там работы — замахаешься, несколько десятков COM-интерфейсов пришлось реализовать/поддержать/интероперировать. От мысли реализовать OLE-сервер я просто отказался. Ибо в простом режиме неинтересно, а в windowless (офигенная фича OLE/ActiveX, если честно) не умеет работать Windows.Forms, как бы я ее уже не хакал. Настолько жесткая завязка на HWND, что попахивает инженерным идиотизмом, особенно при наличии уже около 15-ти лет хорошей иерархии интерфейсов OLE/ActiveX, которые прекрасно от конкретного экземпляра HWND абстрагируются.
V>>>Причем, с Офиса 2007, насколько я вижу, рендеринг в Word был переделан практически полностью. А ведь WPF уже был достаточно mature на тот момент. G>>Ага учитывая что WPF появился аж в начале 2007 года, а офис 2007 начали делать гораздо раньше.
V>В ноябре 2006-го. И подозреваю, что делать начали гораздо раньше. И контора, вроде, та же самая.
G>>Просто оппоненты понимают что переписывать существующий софт только ради managed смысла нет. Вообще нет.
V>А как же разрекламировананя легкость добавления сомна новых фич?
Это ты сам придумал?
V>Но на самом деле тут дело немного в другом. Покажи-ка мне адекватный OLE-клиент и OLE-сервер на дотнете? V>Я в упор не понимаю, почему MS их не сделало. Делал когда-то сам OLE-клиент, так там работы — замахаешься, несколько десятков COM-интерфейсов пришлось реализовать/поддержать/интероперировать. От мысли реализовать OLE-сервер я просто отказался. Ибо в простом режиме неинтересно, а в windowless (офигенная фича OLE/ActiveX, если честно) не умеет работать Windows.Forms, как бы я ее уже не хакал. Настолько жесткая завязка на HWND, что попахивает инженерным идиотизмом, особенно при наличии уже около 15-ти лет хорошей иерархии интерфейсов OLE/ActiveX, которые прекрасно от конкретного экземпляра HWND абстрагируются.
Это ты вообще к чему все привел? Померяться фичами?
Покажи SOAP или Odata клиент или сервер на unmanaged...
WWS появился только около года назад и то с довольно хреновой лицензионной политикой, а ручками там писать ого-го. Не дай бог никому работать с soap из umanaged через сокеты\wininet.
Что касается интерфейса, то политика MS очевидна в этом вопросе: забить на Winforms (windows контролы)\activex и использовать WPF. Возможно мы в скором времени увидим unmanaged WPF работающий на том же нэйтивном движке. Winforms\activex саппортятся только для обратной совместимости, еще много кто по историческим причинам их использует.
Здравствуйте, gandjustas, Вы писали:
V>>А как же разрекламировананя легкость добавления сомна новых фич? G>Это ты сам придумал?
Ты действительно проспал все здешние обсуждения native vs managed?
V>>Но на самом деле тут дело немного в другом. Покажи-ка мне адекватный OLE-клиент и OLE-сервер на дотнете? V>>Я в упор не понимаю, почему MS их не сделало. Делал когда-то сам OLE-клиент, так там работы — замахаешься, несколько десятков COM-интерфейсов пришлось реализовать/поддержать/интероперировать. От мысли реализовать OLE-сервер я просто отказался. Ибо в простом режиме неинтересно, а в windowless (офигенная фича OLE/ActiveX, если честно) не умеет работать Windows.Forms, как бы я ее уже не хакал. Настолько жесткая завязка на HWND, что попахивает инженерным идиотизмом, особенно при наличии уже около 15-ти лет хорошей иерархии интерфейсов OLE/ActiveX, которые прекрасно от конкретного экземпляра HWND абстрагируются.
G>Это ты вообще к чему все привел? Померяться фичами? G>Покажи SOAP или Odata клиент или сервер на unmanaged... G>WWS появился только около года назад и то с довольно хреновой лицензионной политикой, а ручками там писать ого-го. Не дай бог никому работать с soap из umanaged через сокеты\wininet.
Но при чем тут серверные технологии при обсуждении взаимодействия клиентов? Все-равно стоимость сетевых вызовов на порядки больше стоимости managed, поэтому я как-то непонятно, с какого боку и что с чем тут сравнивать.
G>Что касается интерфейса, то политика MS очевидна в этом вопросе: забить на Winforms (windows контролы)\activex и использовать WPF.
Уже 4 года прошло с выхода WPF, уже Висту сменила Win7, но никакой очевидности. Из какого пальца ты это высасываешь?
Не вижу аналога GUI OLE-сервера на дотнете, коими являются приложения офиса, autocad и т.д. И, похоже, ты не понимаешь, о чем речь.
G>Возможно мы в скором времени увидим unmanaged WPF работающий на том же нэйтивном движке.
Ключевое выделил. Это пять!!! Все-таки, ты страшно далек от темы.
Здравствуйте, vdimas, Вы писали:
V>Здравствуйте, gandjustas, Вы писали:
V>>>А как же разрекламировананя легкость добавления сомна новых фич? G>>Это ты сам придумал?
V>Ты действительно проспал все здешние обсуждения native vs managed?
Я не пойму как легкость добавления новых фич связана с языком\платформой. Думаешь добавить фичу это всего лишь закодить её?
При этом надо не забывать о полном переписывании на managed для получения непонятно каких преимуществ.
G>>Что касается интерфейса, то политика MS очевидна в этом вопросе: забить на Winforms (windows контролы)\activex и использовать WPF.
V>Уже 4 года прошло с выхода WPF, уже Висту сменила Win7, но никакой очевидности. Из какого пальца ты это высасываешь?
Ты время разработки оцениваешь? Виста вышла 30 ноября 2006 года. Семерка начала разрабатываться примерно в это время, при этом ничего кардинально нового в семерке нет. Просто допилили висту до адекватного состояния. откуда там взяться WPF?
V>Не вижу аналога GUI OLE-сервера на дотнете, коими являются приложения офиса, autocad и т.д. И, похоже, ты не понимаешь, о чем речь.
А я не вижу в unmanaged коде работы с вебом, и похоже ты не понимаешь о чем речь.
G>>Возможно мы в скором времени увидим unmanaged WPF работающий на том же нэйтивном движке. V>Ключевое выделил. Это пять!!! Все-таки, ты страшно далек от темы.
От какой темы? Ты пытаешься сравнивать исключительно UI десктопных приложений. Во-первых это сильно застойная область, во-вторых далеко не самая большая. При этом ты почему-то пытаешься делать выводы о всем .NET и его применимости. Ну это как минимум неправильно.
G>>>Возможно мы в скором времени увидим unmanaged WPF работающий на том же нэйтивном движке. V>>Ключевое выделил. Это пять!!! Все-таки, ты страшно далек от темы. G>От какой темы? Ты пытаешься сравнивать исключительно UI десктопных приложений. Во-первых это сильно застойная область, во-вторых далеко не самая большая. При этом ты почему-то пытаешься делать выводы о всем .NET и его применимости. Ну это как минимум неправильно.
Дык, речь именно и шла в этой подветке о применимости дотнета на клиенте. Я где-то выше сам же выразил мнение, что дотнет/явы весьма удобны на серверной стороне, но это не имет отношение к обсуждаемому.
Здравствуйте, vdimas, Вы писали:
V>Здравствуйте, gandjustas, Вы писали:
G>>>>Возможно мы в скором времени увидим unmanaged WPF работающий на том же нэйтивном движке. V>>>Ключевое выделил. Это пять!!! Все-таки, ты страшно далек от темы. G>>От какой темы? Ты пытаешься сравнивать исключительно UI десктопных приложений. Во-первых это сильно застойная область, во-вторых далеко не самая большая. При этом ты почему-то пытаешься делать выводы о всем .NET и его применимости. Ну это как минимум неправильно.
V>Дык, речь именно и шла в этой подветке о применимости дотнета на клиенте. Я где-то выше сам же выразил мнение, что дотнет/явы весьма удобны на серверной стороне, но это не имет отношение к обсуждаемому.
Здравствуйте, gandjustas, Вы писали:
V>>Дык, речь именно и шла в этой подветке о применимости дотнета на клиенте. Я где-то выше сам же выразил мнение, что дотнет/явы весьма удобны на серверной стороне, но это не имет отношение к обсуждаемому.
G>VS2010 тебе контрпример.
Редактор текста там разве дотнетный? А компиляторы?
Из дотнетного я вижу пока только GUI, но! Это же специальный тул для специальных людей, готовых идти на компромиссы в целях разработки.
Опять же, речь шла о больших документах со сложным форматированием. Где ты видел, чтобы студия оперировала большими документами?
Здравствуйте, vdimas, Вы писали:
V>Здравствуйте, gandjustas, Вы писали:
V>>>Дык, речь именно и шла в этой подветке о применимости дотнета на клиенте. Я где-то выше сам же выразил мнение, что дотнет/явы весьма удобны на серверной стороне, но это не имет отношение к обсуждаемому.
G>>VS2010 тебе контрпример.
V>Редактор текста там разве дотнетный?
Да
V>А компиляторы?
Нет, они отдельными программами сделаны. В самой студии парсеры есть на .NET для intellisence.
V>Из дотнетного я вижу пока только GUI, но!
Так как раз не .NETого очень мало.
V>Это же специальный тул для специальных людей, готовых идти на компромиссы в целях разработки.
Да ну?
V>Опять же, речь шла о больших документах со сложным форматированием. Где ты видел, чтобы студия оперировала большими документами?
"Большие документы со сложным форматированием" это word? Какие еще программы есть, подходящие под это определение?
Здравствуйте, gandjustas, Вы писали:
V>>Опять же, речь шла о больших документах со сложным форматированием. Где ты видел, чтобы студия оперировала большими документами? G>"Большие документы со сложным форматированием" это word? Какие еще программы есть, подходящие под это определение?
Да не собирался тут спорить никто о применимости дотнета в общем. Тем более это было бы смешно с моей стороны становится оппонентом в этом споре, коль сам активно его юзаю с 2003-го. Речь шла о вполне конкретном применении.
Здравствуйте, Ikemefula, Вы писали:
I>Если точнее, то никто это не переписывает.
Не согласен. Бета 2010-го ворда грузила документы страшно долго, а теперь просто летает, даже в сравнении с предыдущими версиями. "Само по себе" так не бывает.
Здравствуйте, vdimas, Вы писали:
I>>Если точнее, то никто это не переписывает.
V>Не согласен. Бета 2010-го ворда грузила документы страшно долго, а теперь просто летает, даже в сравнении с предыдущими версиями. "Само по себе" так не бывает.
Так что я (и не только) поступаю аналогично в мультимедиа-проектах, пряча COM-интерфейсы за своими прослойками, и заодно повышая уровень абстракции, чтобы за один вызов из managed сделать как можно больше операций. 
.
