[Knott]

Люди почему вы прогаете на всяких Delphi и ВизуалБарсиках? Ладно я понимаю тех кто на С++ прогает. Надо смотреть в будушие. Вот как выйдет Singularity(Ну или её потомок) чего будете делать? Если вы думаете что там будет P-code(родной Visual Basic(Который не .NET)) - нет не будет. А вдруг вы думаете что там будет native код(Delphi, C++,...) - нет она будет написана целиком и полностью на C#. И только несколько мегабайт остального кода, да и то не объектно ориентированого(это через p/Invoke, или его потомок). Язык C# очень элегантен - даже у криворукого программера получится красивый код. Язык C# быстрей чем Delphi и даже С++(Если кто несогласен я вам расскажу много нового ). В нем нет утечек памяти, есть возможность пользоватся указателями, референс типы заместо тех же поинтеров - это делает vс# быстрой - лёгкой - безопасной средой разработки. Xna это надстройка над DirectX 9.0. Она очень легкая и быстродействующая. В ней есть конвейр-контента(!). Ну может сейчас её использовать не стоит - ибо она только бета. Но в рождество будет всё ок.

[Fulcrum]

Что значит "лёгкая и быстродейсвующая"? Молодой человек, XNA ещё очееень далеко до Direct3D 10 и OpenGL 2.0. Может просто С++ выучить не могите? м?

Язык C# быстрей чем Delphi и даже С++(

Всё. Холивар. С++ намного быстрее. На 35%. Это не моя цифра - это microsoft. Учи матчасть %)

Язык C# очень элегантен - даже у криворукого программера получится красивый код

Судя по вашей речи - вы не имеете никакого отношения к программерам. "С++ медленнее С#" - бред! Код исполняемый в интерпритаторе не может быть впринципе быстрее бинарного.

[pokibor]

О, да! Еще один "великий программер" пришел всех учить!
Fulcrum абсолютно прав. Добавлю, что я пробовал писать 3D игру на C#. Результат - проект закрылcя в самом начале. К счастью. Так что я имею представление о быстродействии этого чуда. C# - это язык для написания, возможно, офисных программ, но ни в коем случае не требовательных к ресурсам приложений. Отсутствие заботы о памяти - не достоинство, а недостаток. Из него, а также из использования байт-кода, вытекает жутко медленная скорость работы, а также потребление лишней этой самой памяти - ведь объекты удаляются не сразу, а когда до них дойдет функция очистки. А за это время может еще понадобится наплодить объектов... Да и не будем забывать, что все функции в C# виртуальные! Кроме того, пиша программы на C#, Вы ставите себя в зависимость от Framework'. Если там вдруг будет глюк (что у Майкрософта не редкость) - все, программа накрылась медным тазом.
Если у Вас код на C# оказался быстрее кода на C++... Уж не знаю, что Вы такое сделали, что так могло получится... Бесконечный цикл, что ли, пытались выполнить . Может, просвятите?
Сейчас долго думал, и все же пришел к выводу, что для обучения программированию C# тоже не очень подходит. То же отсутствие заботы о памяти может здорово навредить программисту, если он после C# возьмется осваивать, например, C++...

P.S. А автору темы рекомендую попробовать Prolog или Mercury. Вот уж действительно дружественные к программисту языки! Все подчинено логике, задачи поиска реализуются элементарно, да и все остальные тоже. А если кто-то напишет 3D игру на одном из этих языков (и она будет выдавать больше пары FPS), то напишите мне - любопытно будет посмотреть на это чудо!

[Knott]

Судя по вашей речи - вы не имеете никакого отношения к программерам. "С++ медленнее С#" - бред! Код исполняемый в интерпритаторе не может быть впринципе быстрее бинарного.

Так похоже вы ничего не знаете о платформе .NET.
я сказал же (Если кто несогласен я вам расскажу много нового)
вот начнем.

C#(.NET вообщем) это не ИНТЕРПРЕТИРУЕМАЯ а компилирумая в оптимизизированый к конкретному процесору и памяти, код прямо на машине клиента(Конечного юзера) среда. Есть два вида компиляции.

1) JIT - just-in-time это значит что вся програма компилируется во время выполнения. Вот это и есть ваши "На 35%". Я использую только для дебага.

2) AOT - Ahead-of-time это значит что прога компилируется прямо в нейтивный код во время устоновки. Времени занимает не очень много.Для увесистой проги это секунд 10 на pIII 800 MHz.

"Судя по вашей речи - вы не имеете никакого отношения к программерам."

Я прогаю уже 2 года на уже 4 языках и остановил свой выбор на C#.


Итог - сам учи матчасть

Сообщение от pokibor

О, да! Еще один "великий программер" пришел всех учить!
Fulcrum абсолютно прав. Добавлю, что я пробовал писать 3D игру на C#. Результат - проект закрылcя в самом начале. К счастью. Так что я имею представление о быстродействии этого чуда. C# - это язык для написания, возможно, офисных программ, но ни в коем случае не требовательных к ресурсам приложений. Отсутствие заботы о памяти - не достоинство, а недостаток. Из него, а также из использования байт-кода, вытекает жутко медленная скорость работы, а также потребление лишней этой самой памяти - ведь объекты удаляются не сразу, а когда до них дойдет функция очистки. А за это время может еще понадобится наплодить объектов... Кроме того, пиша программы на C#, Вы ставите себя в зависимость от Framework'. Если там вдруг будет глюк (что у Майкрософта не редкость) - все, программа накрылась медным тазом.
Если у Вас код на C# оказался быстрее кода на C++... Уж не знаю, что Вы такое сделали, что так могло получится... Бесконечный цикл, что ли, пытались выполнить . Может, просвятите?
Сейчас долго думал, и все же пришел к выводу, что для обучения программированию C# тоже не очень подходит. То же отсутствие заботы о памяти может здорово навредить программисту, если он после C# возьмется осваивать, например, C++...

Про бесконечный цикл спасиб . Я же написал что этот байт код компилируется в найтив в стартапе (AOT). И значит никакого байт кода. Ну если только метаданные да и только если вас вдруг приспичит юзать
System.Reflection

[pokibor]

Два года????
О, ну тогда не нам, жалким ламерам, программирующим по восемь лет, Вас учить! Не подскажите, какой институт окончили, или Вы еще в школе?
А теперь о том, почему C# в принципе не может быть быстрее кода на C++:
1) Уборка памяти: как может код, который постоянно обходит все объекты и проверяет, не достигло ли количество ссылок на них 0, может быть быстрее кода, этого не делающего?
2) Как может код, компилирующийся во время выполнения (почти интерпритация!) может быть быстрее кода, этого не делающего?
3) Как может код, в котором все функции виртуальные, быстрее кода, в котором это не так?
4) Да, и еще вопрос вдогонку: как вообще может программа, использующая куда больше библиотек, чем c-шная, быть быстрее ее?

[Knott]

Сообщение от pokibor

ДВА ГОДА????
О, ну тогда не нам, жалким ламерам, программирующим по восемь лет, Вас учить! Не подскажите, какой институт окончили, или Вы еще в школе?
А теперь о том, почему C# в принципе не может быть быстрее кода на C++:
1) Уборка памяти: как может код, который постоянно обходит все объекты и проверяет, не достигло ли количество ссылок на них 0, может быть быстрее кода, этого не делающего?
2) Как может код, компилирующийся во время выполнения (почти интерпритация!) может быть быстрее кода, этого не делающего?
3) Как может код, в котором все функции виртуальные, быстрее кода, в котором это не так?

Ну два года я просидел по 12 часов в день за клавой.

1) Ну почему так сразу, ты слыхал про такую штуку как оптимизация.
Для .NET она тоже сушествует. Надо соблюдать её и всё будет ок.

2) Ты слыхал про утилиту ngen.exe? NativeGENERATOR переводится. Она делает очень быстрые native'ные файлы. Хотите сравнить две анологичные проги на C# и на С++ - ок я могу это устроить. Да и ктомуже если вы не поняли я хочу подметить что С# код оптимизируется под машину юзера - он будет использовать(Я имею ввиду код) проц на полную. Он учитывает начиная от разрядности до дополнительного набора инструкций. А теперь про С++. Интересно можно ли на С++ сделать такойже оптимизированый код как на С#. Мне интересно кто это будет делать на конечной машине - млжет юзер или святой дух?

3) Ты хоть понял что сам сказал ?

ЗЫ. Возраст и образование не имеет значения - слыхали про 16 летнего подростка который выпустил свой LiveCD Linux дистрибутив.
ЗЫЫ. С++ я знаю, но не имею большого опыта
ЗЫЫЫ. Вы сказали что XNA очень далеко до DirectX 10 и OpenGL 2.0. Да до ОпенЖеЛе 2.0 ему еше очень далеко - не думаю что
Microsoft опустится до такого . А что касается DirectX 10 то я вам напомню что Xna строится на DirectX

[pokibor]

Сообщение от Knott

1) Ну почему так сразу, ты слыхал про такую штуку как оптимизация.
Для .NET она тоже сушествует. Надо соблюдать её и всё будет ок.

Да ну? В таком случае, эта оптимизация должна не просто сводить количество дополнительных действий к нулю, а делать его отрицательным!

Сообщение от Knott

2) Ты слыхал про утилиту ngen.exe? NativeGENERATOR переводится. Она делает очень быстрые native'ные файлы. Хотите сравнить две анологичные проги на C# и на С++ - ок я могу это устроить. Да и ктомуже если вы не поняли я хочу подметить что С# код оптимизируется под машину юзера - он будет использовать(Я имею ввиду код) проц на полную. Он учитывает начиная от разрядности до дополнительного набора инструкций.

О! Оптимизирующийся под машину юзера код. Смешно . Во-первых, мне крайне интересно, что он вообще может использовать, кроме количества ядер процессора. А использование количества ядер процессора требует распараллеливание. А распараллеливание - штука черезвычайно сложная, на должном уровне ее только человек может сделать. Набор интструкций, кстати, у современных процессоров почти одинаков. И еще мне интересно, откуда эта утилита будет узнавать о выходе новых процессоров - получается, что она устареет сразу после своего выхода. А ведь на ее переписывание при появленнии новой модели тоже время нужно. Кстати, откуда эта утилита будет знать, а нужна ли вообще юзеру такая "оптимизация"? К примеру, хочу ли я, чтобы архивирующийся WinRAR жрал ресурсы с обоих ядер моего двухядерника, или я на втором проце в кваку поиграть хочу? Так что такая утилита должна быть не просто "умной" - она должна чуть ли не сильным AI быть! Что-то я не слышал про получение первой премии Тьюрига...
Про использовании разрядности процессора: оно приносит пользу только в специфических задачах, и их вполне можно изначально скомпилить в двух вариантах. К тому же я не совсем понимаю, как вообще можно написать, например, сетевое приложение, не зная, сколько в каком типе бит у тебя будет. Будешь слать по сети вроде 32-х битное число, а оно - опа! - 64-х битным станет. А откуда компилятору знать, что в нем у тебя не может быть числа, больше чем 1000000, чисто по конструкции программы?

Сообщение от Knott

А теперь про С++. Интересно можно ли на С++ сделать такойже оптимизированый код как на С#. Мне интересно кто это будет делать на конечной машине - млжет юзер или святой дух?

Оптимизация кода на машине юзера теряет смысл хотя бы потому, что ее конфигурация не постоянна. Регулярно меняются драйверы, устройства, ОС, наконец! Такая программа перед каждым запуском должна перекомпилироваться, да и во время работы тоже, потому что постоянно меняется окружение, другие программы и т.п., и это много на что влияет. Да, C++-код оптимизироваться на машине юзера не может, но его, во-первых, можно изначально скомпилировать под различные конфигурации, и ставить юзеру в зависимотсти от его конфигурации соответствующий экзешник, а во-вторых, такую оптимизацию на должном уровне написать практически невозможно по причинам, указаным выше.
Кстати, оптимизация C++ - программ во многом базируется на вещах, с которыми в C# играться нельзя - например, на адресной арифметике.

Сообщение от Knott

3) Ты хоть понял что сам сказал ?

А ты хоть знаешь, что такое виртуальная функция? Судя по всему, нет.

Сообщение от Knott

ЗЫ. Возраст и образование не имеет значения - слыхали про 16 летнего подростка который выпустил свой LiveCD Linux дистрибутив.
ЗЫЫ. С++ я знаю, но не имею большого опыта

Возраст - да. Образование - нет. Гении всегда есть, но их мало, и не надо приводить единичные примеры. И на вопрос об образовании ты не ответил.

[Knott]

Набор интструкций, кстати, у современных процессоров почти одинаков. И еще мне интересно, откуда эта утилита будет узнавать о выходе новых процессоров - получается, что она устареет сразу после своего выхода.

Чет ты гониш. Я же не сказал что под конкретную модель подстраивается. Эт происходит так:

Win32: я загружаю ехе, тут флаги клр есть.
CLR: это флаги джита
JIT: нашли самого левого. О юзера 32 risc проц есть SSE,SSE2,MMX,3DNOW! итд. Буду оптимизить под нехо.

"Набор интструкций, кстати, у современных процессоров почти одинаков."

не спорю - а как насчет расширений? Как об этом узнает прога на С++?

"Оптимизация кода на машине юзера теряет смысл хотя бы потому, что ее конфигурация не постоянна. Регулярно меняются драйверы, устройства, ОС, наконец!"

Драйверы тут не причем, устройства тоже, и вообще что мешает сделать так что-бы при изменении конфигурации, прога меняла свою нативный образ? Да и почему ты не упомянул статический C++?

"Такая программа перед каждым запуском должна перекомпилироваться, да и во время работы тоже, потому что постоянно меняется окружение, другие программы"

Другие программы - нет, дригие либы - да. Только есть одно но - либы в .net на много отличаются от с++.

"а, C++-код оптимизироваться не может, но его, во-первых, можно изначально скомпилировать под различные конфигурации, и ставить юзеру в зависимотсти от его конфигурации соответствующий экзешник, а во-вторых, такую оптимизацию на должном уровне написать практически невозможно по причинам, указаным выше."

Вот вот оптимизироватся неможет... Хош сказать что ты должен сделать
столько версий что-бы удолетворяло обсолютно всем конфигурациям?

Да и ктому же про конфигурации. Где ещё как не .net ты можеш одну прогу запускать как на Linux так и на Windows. Да и ктомуже как ты будеш давать всем свои "разные конфигурации" разным пользователям если твоя прога распростроняется посредством диска. Кстати ты смотрел на размер ексешника .NET? Так вот посмотрите.

"А ты хоть знаешь, что такое виртуальная функция? Судя по всему, нет."

- Судя по всему, нет - это судя по чему?

В .NET не так всё "виртулизировано" как кажется.

"Кстати, оптимизация C++ - программ во многом базируется на вещах, с которыми в C# играться нельзя - например, на адресной арифметике."

В С# можно игратся с адресной арфмитикой. Читай доки

[pokibor]

Во-первых, пользуйся цитатой! Невозможно понять, где цитата, а где ответ на нее!

Сообщение от Knott

Чет ты гониш. Я же не сказал что под конкретную модель подстраивается. Эт происходит так:

Win32: я загружаю ехе, тут флаги клр есть.
CLR: это флаги джита
JIT: нашли самого левого. О юзера 32 risc проц есть SSE,SSE2,MMX,3DNOW! итд. Буду оптимизить под нехо.

не спорю - а как насчет расширений? Как об этом узнает прога на С++?

Эти расширения есть почти на каждом современном проце. Что же касается различий - их использование можно зашить в DLL библиотеки, так как они узкоспециализированны. По той же причине не надо оптимизировать C++-программу под все возможные конфигурации - достаточно скомпилить несколько вариантов DLL-библиотек. Для того их и придумывали.

Сообщение от Knott

Драйверы тут не причем, устройства тоже, и вообще что мешает сделать так что-бы при изменении конфигурации, прога меняла свою нативный образ?

То есть оптимизация идет только под процессор? И не важно, как и чем он забит помимо программы?
Как я уже говорил, такую оптимизацию сделать нереально хотя бы потому, что эта задача почти приравнивается к искуственному интеллекту. Такие ходы, как при оптимизации на C++, ни одна автоматическая система не повторит.

Сообщение от Knott

Другие программы - нет, дригие либы - да. Только есть одно но - либы в .net на много отличаются от с++.

Только если в сторону тормознутости. Не забывай, .NET исполняется Framework'ом, а Framework на чем написан? На C++ или другом полностью компилируемом языке. И как могут его либы быть качественнее C'шных?

Сообщение от Knott

Вот вот оптимизироватся неможет... Хош сказать что ты должен сделать
столько версий что-бы удолетворяло обсолютно всем конфигурациям?

Как уже писал выше, достаточно использовать разные библиотеки. Кстати, такую систему вполне реально реализовать в отрыве от C# для C++.

Сообщение от Knott

Да и ктому же про конфигурации. Где ещё как не .net ты можеш одну прогу запускать как на Linux так и на Windows. Да и ктомуже как ты будеш давать всем свои "разные конфигурации" разным пользователям если твоя прога распростроняется посредством диска. Кстати ты смотрел на размер ексешника .NET? Так вот посмотрите.

Размер екзешника такой как раз потому, что программа на C# тормознутие программы на C++ и требует выполнения байт-кода Framework'ом. Касательно Framework на Linux: многое, доступное под Windows, под ним работать не будет. К тому же, если программа пишется грамотно на C++, то она будет компилироваться как под Linux, так и под Windows, почти без изменений в коде.

Сообщение от Knott

В .NET не так всё "виртулизировано" как кажется.

Интересно, как это - при наличии только виртуальных функций "не все виртулизировано"?
Да, и тут еще один вопросец назрел:
Программа на C# компилируется в байт-код. Даже если он будет у юзера на машине компилироваться в двоичный код, все равно юзеру ты даешь байт-код. А теперь внимание, вопрос:
Что мешает юзеру оказаться хакером, перегнать твой байт-код назад в C# (по ассемблерному коду код на C++ восстановить практически нереально, а по байт-коду код на исходном языке - элементарно) и посмотреть в нем все твои программистские секреты, отключить любую самую хитрую регистрационную систему и защиту от копирования, да и просто найти твои ошибки, наконец? И использовать все это в своих грязных целях, бесповоротно запоров твою программу? Взломав компьютеры всех юзеров, ею пользующихся? За пару часов написав кряк? Вставив в нее вирус? Так что программа в байт-коде - мечта хакера. Не нужно часами копаться в ассемблере и ловить прерывания! Пара секунд - и программа предстает перед ним в своем исходном виде, готовая к любому вмешательству!

Итог: программа на C# медленне программы на C++ хотя бы в силу своей конструкции. Оптимизация не может ничего дать, кроме незначительного выигрыша, из-за сложности самой задачи. Программа на C# практически элементарно взламывается и модифицируется (и я не говорю уже про Framework - т.е. систему с закрытыми исходниками - от которого все зависит! Если в нем будет закладка, баг, дыра - конец всем C#-программам!
Вывод: ты можешь быть прав только в случае, если Майкрософт заставит всех писать только под .NET, и не найдется никого, решившегося реализовать похожие возможности для C++ (для которого они реализуются проще). Надеюсь, что этого не случится.

Сообщение от Knott

В С# можно игратся с адресной арфмитикой.

Да ладно? В языке без возможности работы с памятью? Мы точно об одном и том же говорим?

[Knott]

"То есть оптимизация идет только под процессор? И не важно, как и чем он забит помимо программы?
Как я уже говорил, такую оптимизацию сделать нереально хотя бы потому, что эта задача почти приравнивается к искуственному интеллекту. Такие ходы, как при оптимизации на C++, ни одна автоматическая система не повторит."

Оптимизация зависит от памяти, от проца, и не много от ОС. Там оптимизация зависит какбы от контрольных точек.
Допустим тебе надо перемножить флоаты. Если SSE будет то код будет вместе с этими SSE.

Только если в сторону тормознутости. Не забывай, .NET исполняется Framework'ом, а Framework на чем написан? На C++ или другом полностью компилируемом языке. И как могут его либы быть качественнее C'шных?

А теперь скажи на чем написан твой C++ компилятор

Как уже писал выше, достаточно использовать разные библиотеки. Кстати, такую систему вполне реально реализовать в отрыве от C# для C++.

Ладно можно но сложнее чем для С#

Программа на C# компилируется в байт-код. Даже если он будет у юзера на машине компилироваться в двоичный код, все равно юзеру ты даешь байт-код. А теперь внимание, вопрос:
Что мешает юзеру оказаться хакером, перегнать твой байт-код назад в C# (по ассемблерному коду код на C++ восстановить практически нереально, а по байт-коду код на исходном языке - элементарно) и посмотреть в нем все твои программистские секреты, отключить любую самую хитрую регистрационную систему и защиту от копирования, да и просто найти твои ошибки, наконец?

а ты слашал про Obfuscator'ы?
[quote]Вывод: ты можешь быть прав только в случае, если Майкрософт заставит всех писать только под .NET, и не найдется никого, решившегося реализовать похожие возможности для C++ (для которого они реализуются проще). Надеюсь, что этого не случится.[/qoute]
Ты хоть слышал про Singularity - нет? почитай. Про баг в .net framework, это странно но ещё не одного бага с framework'ом небыло.

Да ладно? В языке без возможности работы с памятью? Мы точно об одном и том же говорим?

Да ты уверен? А про unsafe код не слыхал, или вот это не видел.
using System;
namespace Knott.Benchmark
{
internal unsafe class Program
{
private unsafe static void Main(string[] args) {
DataHolder holder = new DataHolder();
for (int i = 0; i < 128 / 4; i += 4) {
DataStruct str = new DataStruct();
str.Offset = i;
str.Location = holder.Array;
str.Data = i * 10;
}
}
}
public unsafe struct DataHolder
{
public fixed byte Array[128];
}
public struct DataStruct
{
public int Offset;
public unsafe void* Location;
public unsafe int Data {
get { int* dataLocation = (int*)((byte*)Location + Offset); return *dataLocation; }
set { int* dataLocation = (int*)((byte*)Location + Offset); *dataLocation = value; }
}
}
}
Я не уверен что этот код работет правильно - но дело в том что поинтеры там есть.

[Fulcrum]

Да до ОпенЖеЛе 2.0 ему еше очень далеко - не думаю что
Microsoft опустится до такого

Ась? о_О Чики - пуки. Бубль - гум. OpenGL теперь оказывается ламерский продукт. Надо известить моего закодычного дружбана Джонни. Который Кармак. А то этот ламер совсем обнаглел - использует понимаешь ли опенгл... Ты парень чего "того"? Самый быстрый апи называть опущением? о_О

Да ты уверен? А про unsafe код не слыхал, или вот это не видел.

pokibor в отличие от тебя программист и высказывает факты, а ты нахватался зивини меня дешёвых статей с сомнительных сайтов и пытаешься до всех донести...

А что касается DirectX 10 то я вам напомню что Xna строится на DirectX

Значит он медленнее директа по определению. Вотттактавот.

[pokibor]

Сообщение от Knott

Оптимизация зависит от памяти, от проца, и не много от ОС. Там оптимизация зависит какбы от контрольных точек.

Допустим тебе надо перемножить флоаты. Если SSE будет то код будет вместе с этими SSE.

Я и говрю: все это сводится к написанным под тот или иной вариант функциям. Так на любом языке писать можно. И получится, кстати, быстрее, потому как там будет все с умом сделано под конкретный случай, а не под общий, как тут.

Сообщение от Knott

А теперь скажи на чем написан твой C++ компилятор

Это ты к чему? Ты утверждал, что C#'е либы быстрее C'шных. Я опроверг это. Ты мне в ответ какой-то глупый вопрос задал. C++'е компиляторы пишутся, как ни странно, на том же C++. Также как, например, Паскаль: спера был написан его компилятор (на чем-то, от Паскаля отличном), потом переписан на самом Паскале и скомпилирован этим компилятором - это обычная практика - писать компилятор на самом языке. Но вот для C# она не проходит, т.к. он компилирует в промежуточный код... То есть компилятор C#, конечно, можно переписать на C#, а вот .NET - бессмысленно. И потому либы .NET в приципе не могут быть быстрее C'шных.

Сообщение от Knott

Ладно можно но сложнее чем для С#

Не-а. Проще. Так как имеем дело с ассемлерными инструкциями, а не с байт-кодом. Ассемблер - самый простой язык, на нем писать медленнее, а не труднее...

Сообщение от Knott

а ты слашал про Obfuscator'ы?

Не забывай, у нас этот байт-код будет компилировать FrameWork. Соответственно, как бы там все не было запутано, оно в равной мере отразится как на хакере, так и на Framework, причем в равной мере. Возможно, Obfuscator'ы замедлят появление дизассемблера, но ненадолго. А ведь их применение еще более замедляет выполнение кода.

Сообщение от Knott

Ты хоть слышал про Singularity - нет? почитай.

Читал. И мне смешно. Это с какой же скоростью это чудо будет работать? Да не особо быстрый Windows по сравнению с этой ОС будет как заяц по сравнению с черепахой! Microsoft опять пытается выехать на своем монополизме на рынке ОС, но вовсе не факт, что у нее получится. Во-первых, подходит Google со своей бесплатной осью, которая базируется на Windows, а не начинает все с чистого листа, во-вторых, вряд ли пользователи, если они не дураки, захотят замедлить свой комп и сделать его уязвимым для хакерских атак (байт-код!) непонятно ради чего, в-третьих это чудо выйдет непонятно когда. Похоже, что ты начитался рекламных статеек от Майкрософта и начинаешь кричать всем, что "давайте поддержим дядю Билли!", хотя его за такие дела пора заставить на ассемблере программировать для стиральных машин!

Сообщение от Knott

Про баг в .net framework, это странно но ещё не одного бага с framework'ом небыло.

Это не значит, что их там нет. Впрочем, с такой открытостью кода проще искать баги в программах, чем в Framework.

Сообщение от Knott

Да ты уверен? А про unsafe код не слыхал, или вот это не видел.

Слыхал. Только смысла в нем? Его использование превращает язык в C++ с чуть другим синтаксисом и более тормознутым выполнением. И все. Ты, помнится, отсутствие необходимости работы с памятью выводил в преимущесива. Вот и не противоречь себе же.

Сообщение от Knott

Я не уверен что этот код работет правильно - но дело в том что поинтеры там есть.

Работает - не работает - не важно. Важно то, что с их использованием язык перестает быть собой и становится очевидно хуже C++. Так что их в расчет не берем.

[Knott]

Ты мне в ответ какой-то глупый вопрос задал. C++'е компиляторы пишутся, как ни странно, на том же C++.

Я да я знаю. Не ты мне сказал что Framework написан на С++. А ведь C++ компилятор тоже написан на С++. И в чем разница?

Не-а. Проще. Так как имеем дело с ассемлерными инструкциями, а не с байт-кодом. Ассемблер - самый простой язык, на нем писать медленнее, а не труднее...

Да на асм писать легко, но это-же дело вкуса. Например мне нравится IL Asm.

Не забывай, у нас этот байт-код будет компилировать FrameWork. Соответственно, как бы там все не было запутано, оно в равной мере отразится как на хакере, так и на Framework, причем в равной мере. Возможно, Obfuscator'ы замедлят появление дизассемблера, но ненадолго. А ведь их применение еще более замедляет выполнение кода.

Так если не ошибаюсь Dotfuscator был разработан припомоши МС.Надо его юзать.

Читал. И мне смешно. Это с какой же скоростью это чудо будет работать?

Эх читать до конца никто не учил? Этот код будет компилироватся во время установки. Да это займёт время. Компилятор называется Bartok.

Да не особо быстрый Windows по сравнению с этой ОС будет как заяц по сравнению с черепахой!

А ты читай http://blogs.zdnet.com/Murphy/index.php?p=459

свой комп и сделать его уязвимым для хакерских атак (байт-код!)

Да не хрена - байт-код байт-код читай выше

хотя его за такие дела пора заставить на ассемблере программировать для стиральных машин!

Это точно.

Ты, помнится, отсутствие необходимости работы с памятью выводил в преимущесива. Вот и не противоречь себе же.

Да приводил, и я не противоречю себе. Необходимости нет - возможность есть.

Работает - не работает - не важно. Важно то, что с их использованием язык перестает быть собой и становится очевидно хуже C++. Так что их в расчет не берем.

А в делфи тоже есть поинтеры.

[pokibor]

Сообщение от Knott

Я да я знаю. Не ты мне сказал что Framework написан на С++. А ведь C++ компилятор тоже написан на С++. И в чем разница?

Да на асм писать легко, но это-же дело вкуса. Например мне нравится IL Asm.

Ты что-то уже совсем потерял нить нашей дискуссии. Это ты вообще к чему? Я все упомянутые примеры приводил в доказательство того, что C# в приницпе не может работать быстрее C++, ты какой-то оффтоп начал писать.

Сообщение от Knott

Так если не ошибаюсь Dotfuscator был разработан припомоши МС.Надо его юзать.

И чем это поможет? Опять никаких противоречий со сказанным мною нет. Как замедлял работу, так и будет замедлять. Как код был прост ко взлому хакерами, так и останется.

Сообщение от Knott

Эх читать до конца никто не учил? Этот код будет компилироватся во время установки. Да это займёт время. Компилятор называется Bartok.

Никогда не поверю, что Micro$oft, известная своей любовью к закрытым исходникам, будет поставлять ОС пусть даже в байт-коде! А если и вправду будет, то ой как хакеры порадуются!

Сообщение от Knott

А ты читай http://blogs.zdnet.com/Murphy/index.php?p=459

"Вы все еще не в белом? Тогда мы идем к Вам!" - вот что-то вроде этого. Больше походит на громкое реламное сообщение.

Сообщение от Knott

Да не хрена - байт-код байт-код читай выше

Вот именно что читай выше - как не запутай байт-код, он байт-кодом останется. Так что - ломаем, братцы! А написаная таким образом система будет медленной потому, что C# медленнее C++, чего ты так и не опроверг.

Сообщение от Knott

Да приводил, и я не противоречю себе. Необходимости нет - возможность есть.

А в делфи тоже есть поинтеры.

Опять бессмысленные сообщения. В компилируемых в двоичный код языках ссылки и адресная арифметика - основа динамичекого выделения памяти, в C# - абсолютно чуждый элемент, использование которого начисто убивает смысл C#.

P.S. Хотя, если все сказанное Knott и представителями мелкомягких правда, похоже, Microsoft отказалась от изначальной идеи Windows в пользу Linux! Ведь если не брать в рассмотрение язык - действительно получается система с практически открытыми исходниками, которую компилирует сам пользователь. И по сути единственным слабым местом становится как раз медлительность языка (что, впрочем, скорее реверанс в сторону неопытных программистов), причем оно вполне может быть преодолено поставкой с сисемой, кроме компилятора C#, нормального компилятора C++ в двоичный код (а какая разница - из байт-кода или из исходного компилировать программу)? Вот только, похоже, при обновлении чего-то в компьютере (а то и просто при появлении нового драйвера) систему придется перекомпилять заново (а как еще - она же "оптимизируется" как-то. Правда, непонятно, как.)...
Впрочем, в любом случае профессиональные программы как на C/C++ писались, так и будут продолжать писаться. Ибо в них обычно задействуются такие ресурсы, что малейшее замедление из-за сомнительных достоинств смерти подобно.
В общем, на революцию (а тем более в игростроении - отрасли, в которой конкуренция по ресурсам наиболее жесткая) не тянет. Совмещение идей Java и Linux - еще куда ни шло, но не более.

[pokibor]

Вот письмо, присланное в нашу студенческую рассылку человеком по имени Алексей Лебедев. Отличный ответ на приведенное в начале этой темы высказывание:

Сообщение от Алексей Лебедев

А вы были на домашней страничке Бьярна Страуструпа?

Мне показался очень интересным раздел "Bjarne Straustrup's FAQ":
http://www.research.att.com/~bs/bs_faq.html

В частности:

Q: Что бы думаете о C#?
A: По поводу C# как языка -- без коментариев. Меня придется долго
убеждать в том, что миру нужен ещё один проприетарный язык (yet another
proprietary language -- YAPL). Особенно трудно будет меня убедить в том,
что миру нужен язык, тесно интергрированный с конкретной проприетарной
операционной системой.
Если хотите писать исключительно для платформы .Net, то C# -- не
худший вариант, но помните, что C++ -- хорошо поддерживаемая, хотя и не
такая раздутая, альтернатива.

Q: Почему Вы так ревностно относитесь к переносимости?
A: Успешные программные проекты живут долго. Нередко в течение
нескольких десятилетий. Хорошая программа часто переживает железо, для
которого она была создана, операционную систему, для которой она была
написана, СУБД, которую она использовала, и т. д. Часто хорошие куски
программ переживают компании, предоставляющие основные технологии,
используемые для их создания.
Часто пользователи успешних программных продуктов предпочитают
различные платформы. Множесто предпочитаемых платформ меняется вместе с
изменением людей. Привязываться к одной платфоме или поставщику означает
ограничивать потенциальное использование программы.
Очевидно, полная независимость от платфомы несовместима с возможностью
использовать удобства конкретной платфомы. Тем не менее, часто можно
достич платфоменной независимости используя для каждой платформы "тонкий
интерфейс", реализованный в виде библиотеки.

Q: Почему в C++ нет сборшика мусора?
A: Если вам нужна автоматическая сборка мусора, то для C++ есть много
хороших комерческих, а также свободно распространяемых сборщиков мусора.
Для приложений, где предпочтительно использование сборщика мусора, C++
-- это отличный язык с поддержкой сборки мусора и с производительностью,
которая хорошо соотноситься с производительстью языков со встроенной
сборкой мусора. По поводу дискуссий о сборке мусора в C++ можете
обратиться к книге The C++ Programming Language (3rd Edition).
Кроме того, C++ поддерживает техники программирования, которые
позволяют сделать управление памятью безопастным и прозрачным без
использоваиня сборщика мусора
(http://www.research.att.com/~bs/bs_f...l#memory-leaks)

Q: Почему для C++ нет графическго интерфейса (GUI)?
A: Для C++ есть множество комерческих и поставляемых с исходным кодом
графических интерфейсов (Gtkmm, SmartWin++, V C++ GUI, FLTK и Qt). В
частности, постовщик каждой платфомы предоставляет C++-библиотеку, для
доступа к графическому интерфейсу. Проблема в том, что не существует
стандартного графического интерфейса, а это, действительно, большая
проблема.
Заметте, что предоставление GUI -- это как техническая, так и
политическая проблема. Существует множество графических интерфейсов и
множество пользователей, и, как правило, им бы не понравилось, если бы
какой-то не их графический интерфейс был бы объявлен стандартом.
Как бы ни было, у комитетов по стандартизации недостаточно ресурсов для
создания нового и лучшего графического интерфейса.

И ещё много-много интересных вопросов-ответов.

Жаль, что Knott покинул форум. Было бы очень интересно узнать, что он может возразить Страуструпу...

[PlagueMen]

Знаю С++ 8лет, а С# 4,5 года, спор о производительности ваш для меня кажется странным. В больших проектах типа 1С:Бухгалтерия и т.п. написанных на ++ все равно используется автоматическая уборка мусора и быстродействие этих языков выравнивается. С# ускоряет разработку программ за счет простоты. О быстродействии могу сказать что в ближайшем будущем процессоры будут использовать НЕ команды Assembler в нынешнем виде, а микрокоманды которые не учитывают специфику расположения регистров и т.д. то есть будет использоваться высокоуровневый ассемблер типа MSIL. Microsoft ввела Framework ещё и потому, что ей проще стабилизировать 20 мегабайт кода Framework, чем 600 MB dll-библиотек которые используются сейчас в Windows сейчас. Мой вывод: Framework имеет будущее, он наверняка будет перенесён и на другие операционные системы (уже есть MONO Framework), и программисту не нужно будет задумываться под какую ОС он пишет программу, в перспективе код MSIL или подобный ему будет поддерживаться процессором НАПРЯМУЮ.

[lorin]

ага, тогда или фрэймворк, или виндоус Им двоим тесно в 1 системе

[Knott]

Прашол гот.... С тех пор йа много понил/узнал/прочёл...

НУ ТИПЕРЬ КТО НА МИНЯ?????

[pokibor]

Сообщение от Knott

Прашол гот.... С тех пор йа много понил/узнал/прочёл...

... кроме учебника по русскому языку.
Использование подобного диалекта Вас не красит как профессионала, а именно таким Вы себя стараетесь выставить.

Сообщение от Knott

НУ ТИПЕРЬ КТО НА МИНЯ?????

Эм... на Вас по-прежнему Страуструп, тремя постами выше. Знаете, кто это? Впрочем, в любом случае можете попробовать ему возражать.

[razor21]

Ну что, друзья, подождем еще годик?