Здравствуйте, Дарней, Вы писали:
Д>я тоже когда-то думал, что С++ — это отличный язык высокого уровня, на на котором я решаю свои задачи легко и просто. Д>вот только потом я понял, что ЭТО — совсем не легко и не просто.
Вероятно, в этом все дело. C++ -- это отличный язык. А вот то, что он высокого уровня -- об этом можно поспорить. Имхо, у той же Java или Ruby уровень гораздо выше. И есть масса задач, для которых C++ не является языком, на котором решения строятся легко и просто. Разработка Web-приложений, например.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, WolfHound, Вы писали:
WH>1)Ядро ОС WH>2)Драйверы WH>3)Жесткое реальное время WH>Я ничего не забыл?
* Вычислительные задачи. Прогнозирование погоды, моделирование аэродинамики, термодинамики, имитационное моделирование, компьютерная графика...
* Обработка больших объемов данных (статистика, к примеру). Насколько я знаю, ПО для обработки данных для самой большой в мире базы данных BaBar разрабатывается на C++.
* Системное ПО (ядра СУБД, к примеру).
Может еще чего забыл.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
VladD2 wrote: > C>Не знаю. Но серьезных десктопных систем на C# я пока не вижу. Софт для > C>разработчиков — не в счет. > Сильно старашся не замаечать. Так будет вернее.
Ну так называйте имена. И цифры распространенности.
>> > C>2. Небольшие быстрые утилиты. >> > Бинарный diff шенкующий 4х гигабайтные файлы подойдет? > C>Запускающийся за сотые доли секунды? > Зачем программе работающей по 10 минут загружаться за сотые доли > секнуны? Хотя в общем-то запускается она точно меньше десятых долей > секунды, так как заметить на глаз ее запуск вряд ли получится.
Во-первых, у меня обычно утиллиты работают очень быстро. Во-вторых,
время запуска .NET-программ вполне заметно.
> К твоему сведению, утилита о которой идет речь уже более года бэкапит > данные на нашем сервере. Причем данные измеряются гигабайтами.
Да я верю, что C# может работать с гигабайтами. Сам писал на Java
программы, которые с гигабайтами работали.
Меня больше интересует удобство использования.
>> > Кстати... а то что жаба работает в кофевырках это нормально? А ведь она >> > по прожорлевей... > C>Плохо оно работает. > Потрудсь подтвердить свои слова фактами, или не бросаться ими как попало.
Например, возьмите телефон Nokia с Symbian-OSом — для него есть порт
Doom на С, но на Java есть только достаточно простые игрушки (которые
заметно тормозят).
>> > C>4. Приложения для систем без .NET Framework. >> > Надеюсь ты понимаешь что нет никаких теоритических препядствий >> > портированию .NET практически куда угодно. > C>Я практик, а не теоретик. > Это переход на личности, не будем обсуждать вопрос о том кто ты.
Я говорю, что в теории .NET Framework _можно_ портировать хоть на тостер
и холодильник, но на _практике_ он полностью есть только в Windows.
> C>Да, и как вы собираетесь портировать функции типа PreProcessMessage у > C>Control, например? > А что какие-то проблемы? Скачай Mono погляди как там это сделано.
Ну да, есть маленькая проблема — нужно полностью реализовать Win32
Common Controls В Mono на это забили, хотя до этого пытались
использовать Wine. Если поискать, то таких мест в .NET еще можно найти.
>> > C>5. Приложения для OLE2. >> > Ну и нафига этот OLE2 нужен? > C>Cut&paste из Visio в Word, например. > Я вот пользуюсь и Visio, и Word, а OLE 2 не ползуюсь.
То есть не вставляете диаграммы из Visio в Word? Я вот часто этим пользуюсь.
> К тому же можно объяснить, что за непреодалимые пробелмы в реализации > OLE 2 на дотнете?
То что его нет, и не планируется. Нет фундаментальных проблем написать
Word на brainf**k.
> И кстати, очень интересен следующий вопрос... Вот в Линукс в принципе > невозможно использовать OLE 2.
Ну во-первых, под Линукс есть по крайней мере две реализации OLE2 и DCOM
> Стало быть на С++ нельзя написать OLE 2, > а программы поддерживающие OLE 2 не пререносимы и стало быть > С++-программы тоже не все переносимы.
Примерно. OLE2 непереносим — на других платформах нет такого мощного
cut&paste-механизма.
> программой на дотнете и С++-программой? Если программа использует > платформно-зависимую библиотеку, то она принципиально не переносима.
То что на C# достаточно сложно писать портируемо.
>> > Почему? > C>Он пока дааааалеко не везде работает. > А что С++-код везде работает? А если С++-компилятора нет?
С++ есть уже почти везде. Исключения составляют фактически всякие
микроконтроллеры.
> Или код цепляет тот же OLE 2?
Это да.
VladD2 wrote: > C>Портировать GCC на новую платформу — задача на месяц (если платформа > C>вообще способна поднять C/С++). > Зашибись. А в чем проблема за тот же месяц скомпилировать код Моно? Он > же ведь просто С-код! А уж С куда более распространен.
А JIT кто портировать будет? В режиме интерпретатора использовать .NET
невозможно.
> Факт же в том, что для большинства задач системы вроде дотнета более чем > подходят. И единственная причина по которой люди по старинке пишут на > С/С++ — это косность мышление и недальновидность.
Ага. А вы не знаете, что C# — это прошлый век. Parrot+Perl6 — рулят.
VladD2 wrote: > Система интеграции с платформно-зависимым МС Аутлуком пишется на С++ > чтобы выпячивать кросплатформность.
Все просто — хранилище написано на кросс-платформенном С++. Интерфейсом
с Актглюком занимается сравнительно небольшая прослойка.
> А вот этот перл мне больше всего понравился: > Использование C++ *гарантирует корректную* и экономную *работу с > памятью*, а также высокую скорость работы.
Нет. Просто в .NET _намного_ сложнее экономно работать с памятью.
C>Потому как реально с Mono одни проблемы. Например, Windows Forms глючит C>жутко и надо использовать что-то типа GTK.NET. А это мегабайты C>дополнительного мусора и т.п.
А WinForms, вы хотите сказать, гораздо меньше чем Gtk# места в памяти занимает?
Крутил я Gtk#, весьма понравилось, даже немного больше WinForms (layout и всё такое), а для мусора — "сборщик мусора" или вы о каком-то другом мусоре? Поподробнее, пожалуйста, про "мегабайты дополнительного мусора".
VladGalkin wrote: > C>Потому как реально с Mono одни проблемы. Например, Windows Forms глючит > C>жутко и надо использовать что-то типа GTK.NET. А это мегабайты > C>дополнительного мусора и т.п. > А WinForms, вы хотите сказать, гораздо меньше чем Gtk# места в памяти > занимает?
Меньше, по крайней мере на Windows, так как являются обертками на Win32.
> Крутил я Gtk#, весьма понравилось, даже немного больше WinForms (layout > и всё такое), а для мусора — "сборщик мусора" или вы о каком-то другом > мусоре? Поподробнее, пожалуйста, про "мегабайты дополнительного мусора".
Просто о мусоре — все DLLки для Gtk# занимают что-то около 8 мегабайт. А
это достаточно много.
Здравствуйте, eao197, Вы писали:
E>* Вычислительные задачи. Прогнозирование погоды, моделирование аэродинамики, термодинамики, имитационное моделирование, компьютерная графика...
Гм?... А в чем проблема?
Я лично написал бинарный diff который режет многогигабайтные файлы... там вычисления хоть и простые но их много. E>* Обработка больших объемов данных (статистика, к примеру). Насколько я знаю, ПО для обработки данных для самой большой в мире базы данных BaBar разрабатывается на C++.
И? На С++ вобще много чего разрабатывается. И в том числе то что на С++ разрабатывать просто глупо. Что это доказывает то? E>* Системное ПО (ядра СУБД, к примеру).
В чем проблема?
... << RSDN@Home 1.1.4 beta 6a rev. 436>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, Дарней, Вы писали:
Д>я тоже когда-то думал, что С++ — это отличный язык высокого уровня, на на котором я решаю свои задачи легко и просто. Д>вот только потом я понял, что ЭТО — совсем не легко и не просто.
Просто интересная цитата по теме:
"Я придумал термин "объектно-ориентированный", и вот что я вам скажу, я не имел ввиду С++."
-- Алан Кей, OOPSLA '97
Здравствуйте, Cyberax, Вы писали:
C>Меньше, по крайней мере на Windows, так как являются обертками на Win32.
Вот именно, т.е. требуют загрузки еще целого ряда DLL (не только kernel32.dll и user32.dll).
C>Просто о мусоре — все DLLки для Gtk# занимают что-то около 8 мегабайт. А C>это достаточно много.
Ключевое слово: ВСЕ, а там их немало, всё тянуть не надо.
WolfHound wrote: > E>* Системное ПО (ядра СУБД, к примеру). > В чем проблема?
Да ни в чем, в общем-то. Уже 5 лет прошло, а софта на С# не так уж и
много для следующей революционной технологии.
Здравствуйте, Cyberax, Вы писали:
>> C>Не знаю. Но серьезных десктопных систем на C# я пока не вижу. Софт для >> C>разработчиков — не в счет. >> Сильно старашся не замаечать. Так будет вернее. C>Ну так называйте имена.
Одного достаточно? Тогда RSDN@Home.
C> И цифры распространенности.
1, 2, 3.. 295. Подойдут?
>>> > C>2. Небольшие быстрые утилиты. >>> > Бинарный diff шенкующий 4х гигабайтные файлы подойдет? >> C>Запускающийся за сотые доли секунды? >> Зачем программе работающей по 10 минут загружаться за сотые доли >> секнуны? Хотя в общем-то запускается она точно меньше десятых долей >> секунды, так как заметить на глаз ее запуск вряд ли получится. C>Во-первых, у меня обычно утиллиты работают очень быстро.
У меня тоже. И что?
C> Во-вторых, C>время запуска .NET-программ вполне заметно.
Используй ngen если уж тебе не втерпежь. К тому же после первого запуска ты вряд ли замешь склько запускается любое дотнетное приложение.
В общем, как и все остальные аргументы — это очередрая некулюжая отмазка.
>> К твоему сведению, утилита о которой идет речь уже более года бэкапит >> данные на нашем сервере. Причем данные измеряются гигабайтами. C>Да я верю, что C# может работать с гигабайтами. Сам писал на Java C>программы, которые с гигабайтами работали.
C>Меня больше интересует удобство использования.
И чем же тебя не удовлетворяет удобство использования? И вообще причем тут оно?
>>> > Кстати... а то что жаба работает в кофевырках это нормально? А ведь она >>> > по прожорлевей... >> C>Плохо оно работает. >> Потрудсь подтвердить свои слова фактами, или не бросаться ими как попало. C>Например, возьмите телефон Nokia с Symbian-OSом — для него есть порт C>Doom на С, но на Java есть только достаточно простые игрушки (которые C>заметно тормозят).
И это доказательство? Это скорее доказательство того, что ты не умешь делать элементарные выводы. Если пользоваться твоей "логикой", то можно сделать вывод, что С++ дерьмо, ведь Дум портирован на С, а не на нем. А у меня на телефоне есть куча игр на Яве которые отнюдь не тормозят, а на С вообще нет. Так что и С дерьмо ведь у меня на телефоне на них игр нет.
В общем, это несерьезно. Если мы говорим о Яве в кофеварках, то нужно о ней и говорить. У тебя есть претензии по потребительским свойствам кофеварок в которых встроена Ява? Нет? Тогда приходится признать, что твои слова являются мягко говоря голословными.
C>Я говорю, что в теории .NET Framework _можно_ портировать хоть на тостер C>и холодильник, но на _практике_ он полностью есть только в Windows.
Он на прктике есть на куче девайсов. Не надо говорить заведомую неправду.
>> А что какие-то проблемы? Скачай Mono погляди как там это сделано. C>Ну да, есть маленькая проблема — нужно полностью реализовать Win32 C>Common Controls В Mono на это забили, хотя до этого пытались C>использовать Wine. Если поискать, то таких мест в .NET еще можно найти.
Для особо уперты повторяю. Скачай Моно. Там реализована базовая часть ВыньФормс. ВыньФормс платформно зависимая библиотека. Чтобы реализовать ВыньФормс на платформе отличной от Выньдовс прийдется эмулировать систему сообщений Виндовс. Но это не явлется непредолоимой проблемой. Например, есть порты MFC на Линукс. К тому же, даже невозможность портирования одной библотеки на другую платформу не говорит о том, что не возможно портировать рантайм.
В общем, в очередной раз приходится констатировать, что ты пользущся особо извращенной логикой. И если ее применить к твоим же словам, то оплучится не меньшая фигня. Например, С++ не портируется так как ATL не портирован на другие платформы.
>> Я вот пользуюсь и Visio, и Word, а OLE 2 не ползуюсь. C>То есть не вставляете диаграммы из Visio в Word?
Да. Я сохраняю их как файлы и вставляю в Ворд уже готовые файлы. И делаю я это по сображениям надежности и удобста.
C>Я вот часто этим пользуюсь.
Сочувствую. Лично я сбебе этого позволить не могу, так как проффесионально занимаюсь допечатной подготовкой материлов.
>> К тому же можно объяснить, что за непреодалимые пробелмы в реализации >> OLE 2 на дотнете? C>То что его нет, и не планируется.
Кого нет? OLE 2 — это COM-спецификация! Каждый может реализовать ее.
C> Нет фундаментальных проблем написать C>Word на brainf**k.
Очередной пример передергивания. Если ты проводишь некие аналогии между Брэйнфак и C#, то потрудись вырзить их явно.
Пока что я вижу, что ты в очередной раз пользушся весьма странной логикой.
>> И кстати, очень интересен следующий вопрос... Вот в Линукс в принципе >> невозможно использовать OLE 2. C>Ну во-первых, под Линукс есть по крайней мере две реализации OLE2 и DCOM
OLE2? Можно ссылкочку? Они как минимум не законны.
А DCOM никакого отношения к OLE2 не имеет. И его без каких либо трудов можно использовать из C#.
>> Стало быть на С++ нельзя написать OLE 2, >> а программы поддерживающие OLE 2 не пререносимы и стало быть >> С++-программы тоже не все переносимы. C>Примерно. OLE2 непереносим — на других платформах нет такого мощного C>cut&paste-механизма.
Да его вообще нет нигде кроме Виндовс. Если есть клоны, то уверен, что они кривые и уж точно есть не везде. А знаешь почему его нет? На фиг не упал.
C>То что на C# достаточно сложно писать портируемо.
Очередная громкие заявления не подтвержденные ничем. Говоря по простоу — треп.
>>> > Почему? >> C>Он пока дааааалеко не везде работает. >> А что С++-код везде работает? А если С++-компилятора нет? C>С++ есть уже почти везде.
Ну, то есть ты согласен, что не везде? Ваши же любимые аргументы про голимые встраиваемые платформы.
C> Исключения составляют фактически всякие микроконтроллеры.
Гы. Дык вы тут постоянно на них киляете как на то где нет дотнета. А оказывается там и С++ нет. Во как?!
>> Или код цепляет тот же OLE 2? C>Это да.
Та что? Признаем С++ непереносимым или C# переносимым? Иначе у нас получается какое-то противоричие.
ЗЫ
Подитожу.
Итак C# принципиально позволяет писать любой код. Это язык общего назначения позволяющий присать лбой императивный код. Дотнет как управляемая среда не позволяет его использовать в таких областях как ядро ОС, но уже есть компиляторы C# позволяющие делать и это. Еще одной областью где пока не работает дотнет — это системы реального времени. Обусловлено это тем, что в дотнете используется основанный на иделогии поколений GC, а эта иделогия принципиально не рассчитана на реальное время. Опять же в Сингулярити ядро отвечает требованиям SRT-систем так как применяет соотвествующих инкрементальный GC.
Во всех остальных случаях C# не просто принципиально применим но и реально применяется.
Все ваши слова явлются выдачей желаемого (причем только вам) за действительное. А все разговоры о переносимости, ресурсоемкости и т.п. являются всего лишь попытками опровергнуть очевидные факты.
Откровенно говоря тратить время на дисксси по столь очевидным вещам бессмысленно. Это вера. Бороться с верой бессмысленно. Так что счасливо оставаться со своей верой на едене.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
VladGalkin wrote: > C>Меньше, по крайней мере на Windows, так как являются обертками на Win32. > Вот именно, т.е. требуют загрузки еще целого ряда DLL (не только > kernel32.dll и user32.dll).
Я слабо себе представляю ситуацию, когда библиотека common controls не
будет уже загружена в память
> C>Просто о мусоре — все DLLки для Gtk# занимают что-то около 8 мегабайт. А > C>это достаточно много. > Ключевое слово: ВСЕ, а там их немало, всё тянуть не надо.
У меня получалось что-то около 6Мб при выкидывании лишнего. Все равно много.
Здравствуйте, Cyberax, Вы писали:
>> E>* Системное ПО (ядра СУБД, к примеру). >> В чем проблема? C>Да ни в чем, в общем-то. Уже 5 лет прошло, а софта на С# не так уж и много для следующей революционной технологии.
Надеюсь не надо объяснять что написать нормальный движок СУБД это задача не на один день и даже не на один год. А переписывать то что работает никто не станет.
... << RSDN@Home 1.1.4 beta 6a rev. 436>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
>>> E>* Системное ПО (ядра СУБД, к примеру). >>> В чем проблема? C>>Да ни в чем, в общем-то. Уже 5 лет прошло, а софта на С# не так уж и много для следующей революционной технологии. WH>Надеюсь не надо объяснять что написать нормальный движок СУБД это задача не на один день и даже не на один год. А переписывать то что работает никто не станет.
Этих лет уже целых 5 прошло. А результата пока маловато. Вон и в Windows Vista которая должна была стать локомотивом .NET после запуска нет работающих .NET-приложений.
За это время, например, люди полностью успели переписать Firebird с С на С++. Так что портирование базы на C# должно быть вообще беспроблемным.
Здравствуйте, Cyberax, Вы писали:
C>А JIT кто портировать будет? В режиме интерпретатора использовать .NET C>невозможно.
А чем отличается портирование джита от портирования компилятора? Тут же козыряют тем, что видите ли GCC за месяц куда хочешь можно поритровать. Может и можно, но не каждому и уж точно так же можно и Моно с Ротором портировать куда хочешь. Только Ротон на С++ написан, а Моно на С и C#. Так что это несколько проще.
>> Факт же в том, что для большинства задач системы вроде дотнета более чем >> подходят. И единственная причина по которой люди по старинке пишут на >> С/С++ — это косность мышление и недальновидность. C>Ага. А вы не знаете, что C# — это прошлый век. Parrot+Perl6 — рулят.
Тебе хочется об этом поговорить?
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Cyberax, Вы писали:
C>Все просто — хранилище написано на кросс-платформенном С++. Интерфейсом C>с Актглюком занимается сравнительно небольшая прослойка.
И что эта система кода нибудь понадобится на Линукс? Нехре на вам эта кросплатформность?
>> А вот этот перл мне больше всего понравился: >> Использование C++ *гарантирует корректную* и экономную *работу с >> памятью*, а также высокую скорость работы. C>Нет. Просто в .NET _намного_ сложнее экономно работать с памятью.
А ты спросил у своего заказчика, что ему вожнее та самая "гарантированно корректная" работа с памтью, или ее небольшой перерасход?
Учитывая, что ты тут так сильно акцентируешь то, что продукт серверный, то вообще смешно слышать о перерасходе памяти и том, что С++ "гарантирует корректную работу с памтью". Один ваш Фаерберд сожрет памяти не соизмеримо больше чем дотнетное приложение. И будет прав, так как для это единственно разумное решение для ускорения работы с большим объемом данных.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Cyberax, Вы писали:
C>WolfHound wrote: >> E>* Системное ПО (ядра СУБД, к примеру). >> В чем проблема? C>Да ни в чем, в общем-то. Уже 5 лет прошло, а софта на С# не так уж и C>много для следующей революционной технологии.
Его не много у тех кто намеренно его избегат. У нас на сервере половина процессов Процесс Эксплорером желтеньким подсвечивается (т.е. содержат упраляемый код). У меня на машине та же фигня. Под Вистой прямо в поставке ОС идет куча утилит и приложений написанных на дотенете. Например следующая версия MMC полностью менедед приложение.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
