Здравствуйте, Cyberax, Вы писали:
WH>>Надеюсь не надо объяснять что написать нормальный движок СУБД это задача не на один день и даже не на один год. А переписывать то что работает никто не станет. C>Этих лет уже целых 5 прошло. А результата пока маловато. Вон и в Windows Vista которая должна была стать локомотивом .NET после запуска нет работающих .NET-приложений. C>За это время, например, люди полностью успели переписать Firebird с С на С++. Так что портирование базы на C# должно быть вообще беспроблемным.
Для того чтобы кто-то портировал базу данных на C# должны быть какието причины. Пока таких причин вобщем то нет. Однако когда серьезно возьмутся за создание управляемой ОС база данных будет одним из первых приложений которое полностью напишут на управляемом языке.
... << RSDN@Home 1.1.4 beta 6a rev. 436>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, Cyberax, Вы писали:
C>У меня получалось что-то около 6Мб при выкидывании лишнего. Все равно много.
Хм, файл System.Windows.Forms.dll весит 5,07 МБ (.NET FW 2.0.50727 32x). Подчеркиваю: один файл System.Windows.Forms.dll. Несколько библиотек прожорливого Gtk# сожрали на 1 Мб больше. Я умываю руки.
Здравствуйте, VladD2, Вы писали:
C>>Ну так называйте имена. VD>Одного достаточно? Тогда RSDN@Home.
Слово "имена" — множественное число
C>> И цифры распространенности. VD>1, 2, 3.. 295. Подойдут?
Маловато будет.
C>>Во-первых, у меня обычно утиллиты работают очень быстро. VD>У меня тоже. И что?
Потому что на .NET они НЕ написаны.
VD>Используй ngen если уж тебе не втерпежь. К тому же после первого запуска ты вряд ли замешь склько запускается любое дотнетное приложение.
Замечаю, когда .NET не висит в памяти.
VD>И чем же тебя не удовлетворяет удобство использования? И вообще причем тут оно?
В удобство входит скорость запуска и объем занимаемой памяти. А с этим что у .NET, что у Java — проблемы.
C>>Например, возьмите телефон Nokia с Symbian-OSом — для него есть порт C>>Doom на С, но на Java есть только достаточно простые игрушки (которые C>>заметно тормозят). VD>И это доказательство? Это скорее доказательство того, что ты не умешь делать элементарные выводы. Если пользоваться твоей "логикой", то можно сделать вывод, что С++ дерьмо, ведь Дум портирован на С, а не на нем.
Давайте я изменю у файлов расширение с "c" на "cpp" — специально для вас. Ну еще могу где-нибудь добавить std::vector.
VD> А у меня на телефоне есть куча игр на Яве которые отнюдь не тормозят, а на С вообще нет. Так что и С дерьмо ведь у меня на телефоне на них игр нет.
У вас нет BREW на телефоне? Отстойный телефон.
VD>В общем, это несерьезно. Если мы говорим о Яве в кофеварках, то нужно о ней и говорить. У тебя есть претензии по потребительским свойствам кофеварок в которых встроена Ява? Нет? Тогда приходится признать, что твои слова являются мягко говоря голословными.
Я сравнивал быстродействие. При прочих равных С/C++ позволяет достичь на встраиваемых устройсвах значительно больших результатов.
VD>Он на прктике есть на куче девайсов. Не надо говорить заведомую неправду.
.NET? Не CF, а полный .NET и не в Windows (CE — это тоже Windows)?
VD>Для особо уперты повторяю. Скачай Моно. Там реализована базовая часть ВыньФормс. ВыньФормс платформно зависимая библиотека. Чтобы реализовать ВыньФормс на платформе отличной от Выньдовс прийдется эмулировать систему сообщений Виндовс. Но это не явлется непредолоимой проблемой. Например, есть порты MFC на Линукс. К тому же, даже невозможность портирования одной библотеки на другую платформу не говорит о том, что не возможно портировать рантайм.
Ну так наличие огромной стандартной библиотеки является плюсом C#. А тут оказывается, что интерфейсная либа не совсем портируема. И ADO.NET тоже имеет досадные несовместимости, а Web.Forms совсем почти не работают.
Так и пропадает радужная картина кросс-платформенности.
VD>В общем, в очередной раз приходится констатировать, что ты пользущся особо извращенной логикой. И если ее применить к твоим же словам, то оплучится не меньшая фигня. Например, С++ не портируется так как ATL не портирован на другие платформы.
Зато есть wxWidgets, QT, GTK, FLTK. С разными степенями оверхеда (от минимального в случае wxWidgets до максимального в GTK/QT).
VD>Да. Я сохраняю их как файлы и вставляю в Ворд уже готовые файлы. И делаю я это по сображениям надежности и удобста.
И эти люди не дают мне копатсья в носу...
C>>Я вот часто этим пользуюсь. VD>Сочувствую. Лично я сбебе этого позволить не могу, так как проффесионально занимаюсь допечатной подготовкой материлов.
Про функцию "Convert" у OLE-объектов слышали? Советую посмотреть.
VD>Кого нет? OLE 2 — это COM-спецификация! Каждый может реализовать ее.
Не может. Точнее может, но в C# будет требоваться unsafe.
C>> Нет фундаментальных проблем написать C>>Word на brainf**k. VD>Очередной пример передергивания. Если ты проводишь некие аналогии между Брэйнфак и C#, то потрудись вырзить их явно.
Это я к тому, что в теории можно одной левой переписать Word на C#. А вот на практике что-то не сростается.
VD>Пока что я вижу, что ты в очередной раз пользушся весьма странной логикой.
Есть такой литературный прием — называется "гипербола"...
VD>OLE2? Можно ссылкочку? Они как минимум не законны.
Законны. Так как по лицензии от MS. Вот тут DCOM http://www.softwareag.com/corporate/products/entirex/downloads/download_exxdcom.asp . Точную ссылку на OLE лень искать, но у них оно было.
VD>А DCOM никакого отношения к OLE2 не имеет. И его без каких либо трудов можно использовать из C#.
Это я сказал просто чтобы показать, что все COM-технологии есть под Linux.
VD>Да его вообще нет нигде кроме Виндовс. Если есть клоны, то уверен, что они кривые и уж точно есть не везде. А знаешь почему его нет? На фиг не упал.
Ну да, ведь в C# его нет
C>>То что на C# достаточно сложно писать портируемо. VD>Очередная громкие заявления не подтвержденные ничем. Говоря по простоу — треп.
Давайте сравним количество распространенного портируемого софта на С++ и C#? Вот почему такой замечательный RSDN@Home не работает под Линуксом?
VD>Ну, то есть ты согласен, что не везде? Ваши же любимые аргументы про голимые встраиваемые платформы.
Там где есть .NET — С++ точно есть. Обратное неверно.
С++ нет только на самых скромных платформах (типа микроконтроллеров с килобайтами памяти) — там он просто не нужен, все часто на ассемблерах пишут.
C>> Исключения составляют фактически всякие микроконтроллеры. VD>Гы. Дык вы тут постоянно на них киляете как на то где нет дотнета. А оказывается там и С++ нет. Во как?!
Ну вот на HP-UX есть .NET?
VD>Во всех остальных случаях C# не просто принципиально применим но и реально применяется.
Только практических результатов не видно. А 5 лет уже прошло.
VD>Откровенно говоря тратить время на дисксси по столь очевидным вещам бессмысленно. Это вера. Бороться с верой бессмысленно. Так что счасливо оставаться со своей верой на едене.
Почему же, я вот вам привожу пример: нет распространенных end-user'ских настольных приложений на .NET. Хотите доказать обратное? Давайте примеры.
VladD2 wrote: > C>Да ни в чем, в общем-то. Уже 5 лет прошло, а софта на С# не так уж и > C>много для следующей революционной технологии. > Его не много у тех кто намеренно его избегат. У нас на сервере половина > процессов Процесс Эксплорером желтеньким подсвечивается (т.е. содержат > упраляемый код).
У меня на сервере вообще сплошной qmail и Java. И что?
> У меня на машине та же фигня. Под Вистой прямо в > поставке ОС идет куча утилит и приложений написанных на дотенете. > Например следующая версия MMC полностью менедед приложение.
Когда у нас релиз Windows Vista?
Здравствуйте, WolfHound, Вы писали:
WH>Надеюсь не надо объяснять что написать нормальный движок СУБД это задача не на один день и даже не на один год. А переписывать то что работает никто не станет.
СУБД на Яве, кстати, есть. Думаю, что их порты на дотнет тоже существуют. Другое дело, что тут мы сразу же услышим аргументы, что их у них имена не DB2, Oracle или SqlServer.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Cyberax, Вы писали:
C>Этих лет уже целых 5 прошло. А результата пока маловато. Вон и в Windows Vista которая должна была стать локомотивом .NET после запуска нет работающих .NET-приложений.
Заходим сюда Microsoft Management Console 3.0 и читаем список зависимостей... находим в нем Microsoft .NET Framework 2.0
и долго удивляемся.
Потом стоит задуматься над количеством не соотвествующих действительности высказываний которое ты тут наморозил.
C>За это время, например, люди полностью успели переписать Firebird с С на С++.
Остается узнать зачем.
C> Так что портирование базы на C# должно быть вообще беспроблемным.
VladD2 wrote: > C>А JIT кто портировать будет? В режиме интерпретатора использовать .NET > C>невозможно. > А чем отличается портирование джита от портирования компилятора? Тут же > козыряют тем, что видите ли GCC за месяц куда хочешь можно поритровать.
В теории, в Mono могли бы сделать обобщенную модель процессора, как в
GCC. Но не сделали (и пока не собираются), а значит при портировании
сейчас надо переписывать руками значительную часть кодогенератора.
> Может и можно, но не каждому и уж точно так же можно и Моно с Ротором > портировать куда хочешь. Только Ротон на С++ написан, а Моно на С и C#. > Так что это несколько проще.
Ротор запрещен для коммерческого использования.
> C>Ага. А вы не знаете, что C# — это прошлый век. Parrot+Perl6 — рулят. > Тебе хочется об этом поговорить?
Нет. Это ведь каждый знает — в С# ведь нет таких необходимейших вещей
как мультиметоды!
WolfHound wrote: > C>За это время, например, люди полностью успели переписать Firebird с С > на С++. Так что портирование базы на C# должно быть вообще беспроблемным. > Для того чтобы кто-то портировал базу данных на C# должны быть какието > причины. Пока таких причин вобщем то нет. Однако когда серьезно > возьмутся за создание управляемой ОС база данных будет одним из первых > приложений которое полностью напишут на управляемом языке.
По слухам MS почти полностью переписал SQL Server (написаный на С). Но
почему на C# не переписали ядро? Или MS не верит своей же рекламе?
VladD2 wrote: > WH>Надеюсь не надо объяснять что написать нормальный движок СУБД это > задача не на один день и даже не на один год. А переписывать то что > работает никто не станет. > СУБД на Яве, кстати, есть. Думаю, что их порты на дотнет тоже > существуют. Другое дело, что тут мы сразу же услышим аргументы, что их у > них имена не DB2, Oracle или SqlServer.
Существуют, но позиционируются как встраиваемые. Достаточно серьезную
СУБД на Java я знаю только одну.
Я же прошу — десктопные приложения для конечного пользования, а
не серверные. То что .NET/Java прекрасно подходит для серверов я
прекрасно знаю.
Я и не утверждал, что С++ незаменим на сервере. Я говорил про десктоп.
Это вы флейм опять не в ту степь завели.
> C>За это время, например, люди полностью успели переписать Firebird с С > на С++. > Остается узнать зачем.
Просто чтобы сделать более гибкую архитектуру.
> C> Так что портирование базы на C# должно быть вообще беспроблемным. > Зачем?
Ну как зачем?
Ведь будущее за managed-технологиями — рано или поздно все будет
managed, а уже сегодняшнее оборудование спокойно потянет 100%
управляемую среду. Так почему тогда выпускать еще одну итерацию старых,
небезопасных, ненадежных unmanaged-систем??
Здравствуйте, Cyberax, Вы писали:
C>Да ни в чем, в общем-то. Уже 5 лет прошло, а софта на С# не так уж и C>много для следующей революционной технологии. В США востребованы .NET разработчики лично мне это говорит, что эти приложения очень активно пишутся.
Назовите приложения на Smalltalk? А их много, и не только реализации языка.
Назовите приложения использующие ООСУБД (не постреляционные), а их в мире довольно много.
Исторически, на территории бывшего СССР сложилась некоторая монополия C++, которая способствовала росту касты "плюсеров", занимающихся цитированием Языкового Стандарта C++, толкованием кода и изголяющимся в реализации различных концепций/средств на языке, который эти концепции и средства либо слабо поддерживает, либо не поддерживает вообще. Это в основном про Boost. По поводу концепций, приведу цитату Страуструпа об использовании С++ для кодирования идиом из динамических языков, таких как Lisp или Smalltalk:
"Smalltalk — лучший из всех существующих smalltalk-ов."
Данную монополию ничем, кроме советского образа мышления (все ДОЛЖНЫ использовать С++, C++ лучше всех) я объяснить не могу.
Многие не хотят бросать эту монополию, поскольку это ведет к ряду проблем (изменение мышления, изменение профессионального/социального? статуса, существующее legacy etc.)
ЗЫ Целью данного поста не является кого-либо унизить/обидеть/возвысить. Я просто высказал свою точку зрения. Я ни в коем случае не являюсь сторонником какого-либо одного языка.
Здравствуйте, Cyberax, Вы писали:
>> Его не много у тех кто намеренно его избегат. У нас на сервере половина >> процессов Процесс Эксплорером желтеньким подсвечивается (т.е. содержат >> упраляемый код). C>У меня на сервере вообще сплошной qmail и Java. И что?
И то. Смотри выделенное. К тому же Ява есть. Сртранно для такого фаната С++.
>> У меня на машине та же фигня. Под Вистой прямо в >> поставке ОС идет куча утилит и приложений написанных на дотенете. >> Например следующая версия MMC полностью менедед приложение. C>Когда у нас релиз Windows Vista?
Какая разница?
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Cyberax, Вы писали:
VD>>Одного достаточно? Тогда RSDN@Home. C>Слово "имена" — множественное число
Хм. Имена конечно можно назвать. Вопрос толко зачем?
Ты утверждал:
Но серьезных десктопных систем на C# я пока не вижу
Даже одно имя красноречиво показывает, что эти утверждения не больше чем пустопорожений треп.
C>>> И цифры распространенности. VD>>1, 2, 3.. 295. Подойдут? C>Маловато будет.
ОК, 1452345. Это не мало?
C>>>Во-первых, у меня обычно утиллиты работают очень быстро. VD>>У меня тоже. И что? C>Потому что на .NET они НЕ написаны.
Они как раз все как одна написаны на дотнете, так как у меня нет желания убивать время на написание их на С++. Мне их нужно было быстро сделать и забыть.
VD>>Используй ngen если уж тебе не втерпежь. К тому же после первого запуска ты вряд ли замешь склько запускается любое дотнетное приложение. C>Замечаю, когда .NET не висит в памяти.
Ну, так один запуск и он весь "повиснит" в памяти. Ведь это просто набор ДЛЛ-ек.
VD>>И чем же тебя не удовлетворяет удобство использования? И вообще причем тут оно? C>В удобство входит скорость запуска и объем занимаемой памяти. А с этим что у .NET, что у Java — проблемы.
Хм. Мы уже выяснили, что скорость запуска более чем приемлемая. Не говорить же о том, что раз в день приходится подождать пол секунды на перый запуск?
Теперь на счет памяти. Утебя проблемы с ее обхемом? Я вот ни разу не видел, чтобы реальное дотнет-приложение имело какие-то проблемы с ней связанные. Пусть таскменеджер показывает большие цифры на управляемые процессы, но в итоге то какая разница? Особоенно для утилит.
Еще раз могу тынуть на утилиту diff на нашем сервере. Она работает с файлами объемом в несколько гигабайт. И никаких проблем с памятью.
ЖЦ банально эффективнее работает если жрет больше памяти. Таковы алгоритмы.
VD>>И это доказательство? Это скорее доказательство того, что ты не умешь делать элементарные выводы. Если пользоваться твоей "логикой", то можно сделать вывод, что С++ дерьмо, ведь Дум портирован на С, а не на нем. C>Давайте я изменю у файлов расширение с "c" на "cpp" — специально для вас. Ну еще могу где-нибудь добавить std::vector.
Опять треп. Портировать большую С-программу на С++ очень не просто. Если не пробовл, так не трепись почем зря. Да и смысл в таком "портировнии"? Программа все равно останется С-шной. Только увеличатс проблемы с переносимостью.
VD>> А у меня на телефоне есть куча игр на Яве которые отнюдь не тормозят, а на С вообще нет. Так что и С дерьмо ведь у меня на телефоне на них игр нет. C>У вас нет BREW на телефоне? Отстойный телефон.
Значит если на моем телефоне хорошо работает Ява, то он отстойный.
VD>>В общем, это несерьезно. Если мы говорим о Яве в кофеварках, то нужно о ней и говорить. У тебя есть претензии по потребительским свойствам кофеварок в которых встроена Ява? Нет? Тогда приходится признать, что твои слова являются мягко говоря голословными. C>Я сравнивал быстродействие. При прочих равных С/C++ позволяет достичь на встраиваемых устройсвах значительно больших результатов.
Ты сказал, что Ява плохо работает в кофеварках:
> Кстати... а то что жаба работает в кофевырках это нормально? А ведь она
> по прожорлевей...
Плохо оно работает.
Вот и потрудись привести тому подтверждение. Или не трепаться по чем зря.
Что касается прочих равных. Недавно был случай. На КПК АВК нужно было копировать с 256-метровой КомпактФлэш-краты, на SD. Попробывали копировать идущей в поставке (WinCE) утилитой написанной на С++. Получилось ОООЧЕНЬ медленно. Один файл размером около 2.5 метров копировался 3 часа. Ну, что же... Я взял VS 2005 и написал на Компакт Фрэймворке 2.0 утилиту копирующую файлы. Копирование стало занимать пару минут (все флэйшки).
Теперь внимание вопрос, так как после тэтого смотреть на твои голословные утверждения?
VD>>Он на прктике есть на куче девайсов. Не надо говорить заведомую неправду. C>.NET? Не CF, а полный .NET и не в Windows (CE — это тоже Windows)?
А какая разница полный он или CF? В CF точно такой же рантайм как у любого друго фрэймворка. Разница тольк в том, что расходывание памяти в нем производится более экономно и библотеки по скуднее. Первое тебе вообще не должно колыхать. Это просто оптимизация на область применения. А второе... Да что правда, то прада. Библиотека гораздо скуднее. Вот только она в сто раз богаче чем у С++. В его стандартную библиотеку нихрена не входит. Библиотека контейнеров и изумительный набор функций для копирования и сравнения памяти. Ну, а любая программа для CF запускается на полном дотете без проблем. Причем даже без перекомпиляции.
Так что еще раз повторюсь. Преестать говорить откровенную не првду и начни проверять свои утверждения.
VD>>Для особо уперты повторяю. Скачай Моно. Там реализована базовая часть ВыньФормс. ВыньФормс платформно зависимая библиотека. Чтобы реализовать ВыньФормс на платформе отличной от Выньдовс прийдется эмулировать систему сообщений Виндовс. Но это не явлется непредолоимой проблемой. Например, есть порты MFC на Линукс. К тому же, даже невозможность портирования одной библотеки на другую платформу не говорит о том, что не возможно портировать рантайм. C>Ну так наличие огромной стандартной библиотеки является плюсом C#.
Одним из плюсов. К тому же размер библиотеки даже без ВыньФормс поражующи велик по сравнению с тем, что идет в стандартной поставке любого С++-компилятора. Особенно если рассматривать только лекго портируемые библиотеки. Переносимые же библиотеки обычно имеют кучу своих проблем и зависимостей. Тот же GTK большой в принципе, а те только в версии для дотнета.
C> А тут оказывается, что интерфейсная либа не совсем портируема. И ADO.NET тоже имеет досадные несовместимости, а Web.Forms совсем почти не работают.
ADO.NET полностью реализован в Моно. Более того лющи занимающиеся БД зачастую берут их провайдеры для использования под дотнетом.
Мне вот хотелось бы услышать о библиотеки для С++ которая была бы доступна на всех платформах где есть С++ и не имела бы проблем. Из стандартов для доступа к БД на С++ я знаю только ODBC — библиотеку созданную МС. И она имет массу проблем.
C>Так и пропадает радужная картина кросс-платформенности.
Я уж не знаю нафиг тебе лично унжна кросплатформность. Но что то я сомневаюсь, что испльзование КОМ, МФЦ или любой другой библиотеки увеличит кросплатформность. А без непереносимых библиотек разницы нет. Даже дотнетыный код более переносим, так как не имет такой сильной зависимости кода от ОС как это часто бывает в С++-коде. И может переноситься без перекомпиляции.
C>Зато есть wxWidgets, QT, GTK, FLTK. С разными степенями оверхеда (от минимального в случае wxWidgets до максимального в GTK/QT).
Да, ты что? Првда? Тогда зайди сюда http://wxnet.sourceforge.net/
VD>>Да. Я сохраняю их как файлы и вставляю в Ворд уже готовые файлы. И делаю я это по сображениям надежности и удобста. C>И эти люди не дают мне копатсья в носу...
Кто же тебе не дает копаться в носу? Просто козявки после этого не нужно по столу раскладывать.
C>Про функцию "Convert" у OLE-объектов слышали? Советую посмотреть.
Про качество слышал? И вообще, забавно слышать как человек не имеющий отношения к DTP учит того кто этим занимается последние 15 лет.
VD>>Кого нет? OLE 2 — это COM-спецификация! Каждый может реализовать ее. C>Не может. Точнее может, но в C# будет требоваться unsafe.
1. Можно обойтись и без ансэйва.
2. А какая разница? В классе string море ансэйфа, но что то никто не слышит воплей по этому поводу.
C>>> Нет фундаментальных проблем написать C>>>Word на brainf**k. VD>>Очередной пример передергивания. Если ты проводишь некие аналогии между Брэйнфак и C#, то потрудись вырзить их явно. C>Это я к тому, что в теории можно одной левой переписать Word на C#. А вот на практике что-то не сростается.
Покажи мне кто и где тут говорил о том, что написать Ворд — это раз плюнуть? Или ты будешь утверждать, что реализовать поддержку OLE 2 задача по слдожности сопоставимая с созданием полного аналога Ворда?
Еще рез. OLE 2 — это COM-спецификация. Нет никакой разницы на чем ее реализовывать. И она не реализована на 100% на C# только потому, что это никому не нужно. Хотел бы я поглядеть как кто-то реализует OLE 2 без MFC.
VD>>Пока что я вижу, что ты в очередной раз пользушся весьма странной логикой. C>Есть такой литературный прием — называется "гипербола"...
А зачем мне DCOM? DCOM в дотнете поддерживается намного лучше чем в любом линукс-приложении.
C>Точную ссылку на OLE лень искать, но у них оно было.
А, ну, тогда пока ссылки не будет будем считать, что ты снова сказал не подумав.
VD>>А DCOM никакого отношения к OLE2 не имеет. И его без каких либо трудов можно использовать из C#. C>Это я сказал просто чтобы показать, что все COM-технологии есть под Linux.
А об этом тебя никто не просл. Я попросил дать подтверждение твоим словам про OLE2 под Линукс, так как никогда не слышал о таком. Единственное что мне извесно — это что по Линкус есть набор кастрированной поддержки для запуска Виндовс приложений. Но я даже не уверен, что в них действительно поддерживмется OLE2.
VD>>Да его вообще нет нигде кроме Виндовс. Если есть клоны, то уверен, что они кривые и уж точно есть не везде. А знаешь почему его нет? На фиг не упал. C>Ну да, ведь в C# его нет
Тут связь обратная. Его нет в C# так как не сильно нужно. Нельзя объять необъятное.
C>>>То что на C# достаточно сложно писать портируемо. VD>>Очередная громкие заявления не подтвержденные ничем. Говоря по простоу — треп. C>Давайте сравним количество распространенного портируемого софта на С++ и C#?
Сколько лет С++? Вот через 25 лет и сравним. Можно еще задаться вопросмо почему Ворд и Виндовс приемущественно написаны на С, а не на С++. Тоже позновательно.
C> Вот почему такой замечательный RSDN@Home не работает под Линуксом?
Потому, что Линкус на фиг никому не упал. И потому, что Хоум использует С++-ный JET не портируемый на Линукс, и С++-ный же MS IE опять же отсуствующий на Линукс. В остальном портировать было бы можно.
У меня вот есть приложения которые дейсвтвильно без пробелм можно было бы портировать на Линукс, только зачем? Кому они там нужны? Точнее кому этот Линукс нужен? Фанатики обойдутся и тем, что на нем уже есть.
VD>>Ну, то есть ты согласен, что не везде? Ваши же любимые аргументы про голимые встраиваемые платформы. C>Там где есть .NET — С++ точно есть. Обратное неверно.
Хм. И что? Это имеет отношение к обсуждаемым вопросам? Опять же тот же аргумент применим к С/С++. Что же теперь не писать на С?
C>С++ нет только на самых скромных платформах (типа микроконтроллеров с килобайтами памяти) — там он просто не нужен, все часто на ассемблерах пишут.
О. С++ нет очень много где, так как людям просто влом портировать его туда где он на фиг не уперся. А есть даже платформы где он в принципе быть не может. Например, он физически не пригоден в системах с программной изоляцией процесса вроде Сингулярити, Оберон ОС и т.п.
C>Ну вот на HP-UX есть .NET?
Я балдею. Что только не придумашь лиш бы доказать себе какю нибудь глупость.
Есть он на HP-UX http://www.mono-project.com/Supported_Platforms
В виде интерпретатора.
Сразу отвечу почему нет джтита. Нафиг не упал. Портирование компилтора — это работа которую делают только если оно действительно нужно.
VD>>Во всех остальных случаях C# не просто принципиально применим но и реально применяется. C>Только практических результатов не видно. А 5 лет уже прошло.
Значит вопрос о невозможности уже снят? Уже не плохо. Что до результатов... Достаточно того, что их уже не мало. Объем софта создаваемого на пуравляемых языках постоянно растет. Ява уже давно занимает первое места на сорсфордже. Шарп тоже не последнее. У многих на машине по несколько управляемых приложений. Со временим его процент явно будет расти.
Все очевидно. В чем ты тут кого-то хочешь убедить?
VD>>Откровенно говоря тратить время на дисксси по столь очевидным вещам бессмысленно. Это вера. Бороться с верой бессмысленно. Так что счасливо оставаться со своей верой на едене. C>Почему же, я вот вам привожу пример: нет распространенных end-user'ских настольных приложений на .NET. Хотите доказать обратное? Давайте примеры.
Я не хочу тебе что-то даказывать. Тысячи человек пользуются такими продктами как RSDN@Home, RSS/News Reader-ами написанными на C#, VS 2005 и HTML Help 2.0. Все эти продукты используют внутри себя фрэймворк или написаны целиком на дотнете.
Ты же тут споирь не с тем какое количество пользователей считать достаточным для того, чтобы назвать приложение "распространненым", а с самой возможностю создания оных приложений.
Я уже говрил. Ровно одного приложения достаточно чтобы понять можно создавать на чем-то этот класс приложений или нет. Между тем приложений не одно, а десятки. И казалось бы вопрос даже не стоит утверждать, но постяно находятся вот такие как ты упертые личности которые пытаются опровергать казалось бы очевидные вещи.
Что же счастливо продолжать это плодотворное занятие. А мы тем временм посмемся отвечая тебе их тех самых "end-user'ских настольных приложений" кторые по твоим словам вообще невозможно написать на дотнете.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Cyberax, Вы писали:
C>В теории, в Mono могли бы сделать обобщенную модель процессора, как в C>GCC. Но не сделали (и пока не собираются), а значит при портировании C>сейчас надо переписывать руками значительную часть кодогенератора.
The final step: porting the JIT
At this point you'd need to have a more complete code generation header file and you can start writing the machine description file for the monoburg system. This code (jit/tesjit.c) will require some machine specific tweaks, but hopefully all you have to do is create the grammar that emit assembly code from the IR tree. Work is at the early stages also for x86 on this stuff as we are still testing various solutions: you'd want to read about burg-like code-generator generators (the LCC book is a good starting point).
>> C>Ага. А вы не знаете, что C# — это прошлый век. Parrot+Perl6 — рулят. >> Тебе хочется об этом поговорить? C>Нет. Это ведь каждый знает — в С# ведь нет таких необходимейших вещей C>как мультиметоды!
Хм. А в С++ они значит уже есть? Если мультиметоды это критерий отбора, то тебе пора завязывать с плюсами и переходить на CLOS в котором они були с самого начала.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Cyberax, Вы писали:
C>Я же прошу — десктопные приложения для конечного пользования, а C>не серверные. То что .NET/Java прекрасно подходит для серверов я C>прекрасно знаю.
А MMC это по-твоему какое?
>> Остается узнать зачем. C>Просто чтобы сделать более гибкую архитектуру.
Да? И как?
C>Ведь будущее за managed-технологиями — рано или поздно все будет C>managed, а уже сегодняшнее оборудование спокойно потянет 100% C>управляемую среду. Так почему тогда выпускать еще одну итерацию старых, C>небезопасных, ненадежных unmanaged-систем??
Ты когда нибудь писал приложения обемом работ по 10 человеколет и более? Вот приличная БД именно такое прилоежние. И никто ради забавы такие проекты не начинает. И уж темболее никто не будет делать такое приложение чтобы доказать неверующим фомам, что это принципиально возможно. Куда проще назвать хоть один аргумент в пользу того почему это невозможно сделать.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, WolfHound, Вы писали:
WH>Здравствуйте, alexeiz, Вы писали:
Д>>>я раньше тоже думал в точности, как ты A>>Т.е. как конкретно? Ты ещё не выразил своего мнения. Милости просим. WH>Ну примерно так: С++ крут! С++ мега крут! Нет ничего круче С++! Если правильно использовать С++ то все эти новомодные финтифлюшки тапа .NET'а просто ерунда!
Я так не думаю. Почему у тебя появилось такое впечатление?
Здравствуйте, eao197, Вы писали:
E>Здравствуйте, Дарней, Вы писали:
Д>>я тоже когда-то думал, что С++ — это отличный язык высокого уровня, на на котором я решаю свои задачи легко и просто. Д>>вот только потом я понял, что ЭТО — совсем не легко и не просто.
E>Вероятно, в этом все дело. C++ -- это отличный язык. А вот то, что он высокого уровня -- об этом можно поспорить. Имхо, у той же Java или Ruby уровень гораздо выше. И есть масса задач, для которых C++ не является языком, на котором решения строятся легко и просто. Разработка Web-приложений, например.
Я бы вот как раз поспорил с тем, что C++ — не язык высокого уровня. Web приложения на нем писать не легко, только потому, что нет нужных библиотек. Ну и, конечно, нельзя сравнивать со скриптовыми языками, т.к. они в отдельной лиге. Но вот сравнить с Java впольне можно. Попробуй доказать, что на Java можно программировать на таком высоком уровне, что на C++ недоступен. Тогда он будет более высокого уровня. Иначе нет.
Здравствуйте, WolfHound, Вы писали:
E>>* Вычислительные задачи. Прогнозирование погоды, моделирование аэродинамики, термодинамики, имитационное моделирование, компьютерная графика... WH>Гм?... А в чем проблема? WH>Я лично написал бинарный diff который режет многогигабайтные файлы... там вычисления хоть и простые но их много.
Боюсь, что это не то. Есть вычисления, в которых даже compile-time вычисления (хоть я от них и отплевываюсь) начинают играть существенную роль.
Из собственного опыта. В радиолокации используются высчислительные задачи, где требуется перемножать матрицы комплексных чисел большой размерности. Очень ресурсоемкая, надо сказать операция. Да еще не одна и в рилтайме. Для этих целей даже спецвычислители привлекают (иногда встраиваемые в компьютер в виде дополнительных PCI плат). Бодаться со всем этим делом в C++ можно. Привлекать для этого managed языки? А для чего? Весь managed нужно будет отключать либо для обеспечения нужной производительности, либо для обеспечения предсказуемости, либо для эффективной работы с железом.
E>>* Обработка больших объемов данных (статистика, к примеру). Насколько я знаю, ПО для обработки данных для самой большой в мире базы данных BaBar разрабатывается на C++. WH>И? На С++ вобще много чего разрабатывается. И в том числе то что на С++ разрабатывать просто глупо. Что это доказывает то?
Это ничего не доказывает. Я просто привел пример области, где размер имеет значение и работают законы больших цифр. Если на C++ мы изначально ничего не теряем при работе с памятью (нет проверок на выход за диапазон) и в предсказумости (GC в ненужный момент не стартует), то на managed языках об этом нужно думать. И проигрыш managed решения на одной операции в 1-2% в реальных расчетах будут давать часы (если не дни) лишней работы программы.
E>>* Системное ПО (ядра СУБД, к примеру). WH>В чем проблема?
Да проблема в том, что вместо обмена мнениями о том, в каких нишах какой язык сможет себя нормально чувствовать, мы сваливаемся в очередной флейм.
Для меня очевидно, что для многих задач C++ менее пригоден, чем C# или Java. Что из многих областей managed языки C++ вытеснят совсем. Вероятно ты и Дарней как раз в таких областях и работаете, поэтому почувствовали разницу после перехода с C++ на C#. Вот и здорово. Но это одна сторона медали.
Вторая сторона -- за C++ останутся его ниши (часть из них мы с тобой обсудили). И в этих нишах C++ будет отличным языком, сочетающий относительную высокоуровневость с относительной низкоуровневостью. Да, C++ будет продолжать бить по рукам за просчеты. Но на нем станут меньше программировать разные ламеры, которых к C++ подпускать не стоило воовсе (со временем они начнут свое черное дело по отношению к C#). Не будет больших команд, в которых C++ демонстрирует свою недружелюбность к пользователям, зато будут небольшие командочки, которые знают, как им пользоваться. По крайней мере мне хотелось бы видеть такой сценарий развития.
Так вот, в своей нише C++ будет действительно отличным языком. Да он и сейчас такой есть. Просто период, когда на C++ пытались делать все, что ни попадя, завершается. Ну и ладно. Smalltalk, к примеру, отличный язык. Живет себе, smalltalk-ерам дает жить. Или Prolog. Он ведь до сих пор есть, и системы на нем серьезные делают. Вот и на C++ будут делать. Надеюсь, что и я то же.
Жалко, что скоро мы в "Священных воинах" окажемся. alexeiz очень толково высказался
