Здравствуйте, Eugeny__, Вы писали:

E> Да, обязательно. Бо сравнивать на разных машинах глупо.

скачать

На моей машине твой тест показывает:
Первый запуск:

C:\Trash>java -server Main
54370807
2476508047
535334
838457712

Последующие:

C:\Trash>java -server Main
4461600
2330123940
205333
838457712

E> java -server Main
E> В папке с классом. Не забываем о больших и наленьких буквах — main и Main — это два разных ксласса!

Да, я уже разобрался Передавал имя файла с расширением.

Здравствуйте, dmitry_npi, Вы писали:

_>Здесь будем воевать, а не выяснять по делу, поэтому:
Не, воевать нафиг. Далее в .Net GUI.

Здравствуйте, Ночной Смотрящий, Вы писали:

_>>- кривой вызов системных функций
НС>Что значит кривой?

Через маршалинг.

_>> и невозможность прямого вызова функций из известных C++ библиотек
НС>Это не соответствует действительности. Слинкованные в dll функции вызываются без проблем. Для статической линковки есть МС++.

Ага, поэтому когда захотели сделать биндинг из .Net'а к известной библиотеке C++ пришлось оборачивать её в C вызовы. )))

_>>- невозможность написания низкоуровнего кода
НС>Какого именно?

Например реализовать защиту кода и т.п. Про драйверы и т.п. я вообще молчу уже.

_>>- невозможность написания быстрого (в сравнение с C++ скажем) кода для ряда задач
НС>Ты CLR с конкретными языками не перепутал? Если что, С++ в IL прекрасно компилируется.

Да, слегка некорректно сказал. Имелось в виду "в сравнение с оптимизирующими native языками", типа C++, Фортран, Ассемблер и т.п... Да, а MC++ — это не C++, а насмешка. )))

_>>- сложности с реализацией автоматического RAII.
НС>При чем тут CLR? Это особенности конкретных языков, не более того.

Дааа? ) Т.е. на clr есть язык с поддержкой RAII в стиле C++? )

_>>Жаль только что фанаты иногда пытаются вытащить технологию из своей нищи и распространить куда не надо.
НС>Можно пример?

Собственно MS с появлением .Net пыталась протолкнуть его как универсальную технологию для всего (разве что кроме драйверов). Даже затормозили развитие других своих инструментов. Вроде как только сейчас опомнились и меняют стратегию к норме. И соответственно были толпы народа поддерживающие эту странную идею. Кстати, до некоторых из них похоже и сейчас ещё не дошло... ))) Java прошла тот же путь, но заметно раньше (помню шумиху в 90-ые, типа "вот она серебряная пуля") и теперь уже много лет спокойно царит (всё же .Net тут как догоняющий) в своей нише не вылезая особо в чужие.

Здравствуйте, Ночной Смотрящий, Вы писали:

НС>Здравствуйте, esil, Вы писали:

E>>кто-то уже научился инлайнить функции из скомпилированных разделяемых библиотек?

НС>Да, дотнет.

Т. е. он может заинлайнить например функцию CreateWindow из win32.dll?

Здравствуйте, _d_m_, Вы писали:

E>>Умный человек так и не ответил на поставленный самому себе вопрос: "Зачем распространять скомпилированные программы в виде IL?"

___>Вот эта фраза тебе ни о чем не говорит? :

___>

___>Предположим, у вас есть несколько языков программирования: C#, VB, F#, JScript .NET и т.д. И, предположим, у вас есть m сред времени выполнения: компьютеры с ОС Windows, работающие на процессорах x86 или x64, XBOX 360, телефоны, Silverlight, работающий на Мак-е… и предположим, что мы используем подход с одним компилятором. Какое количество генераторов кода вам придется написать внутри вашего компилятора? Для каждого языка программирования вам придется написать кодогенератор для каждого окружения, в результате, придется написать n x m генераторов.

Ни о чём не говорит, потому что она в принципе не верна. Правильный ответ: вам придётся написать один кодогенератор для каждого окружения, в результате придется написать m генераторов. А не n x m, как говорит автор.

Здравствуйте, esil, Вы писали:

E>>>кто-то уже научился инлайнить функции из скомпилированных разделяемых библиотек?

НС>>Да, дотнет.

E>Т. е. он может заинлайнить например функцию CreateWindow из win32.dll?

Нет, заинлайнить он может только managed функцию, это очевидно.

Здравствуйте, alex_public, Вы писали:

_>>>- кривой вызов системных функций
НС>>Что значит кривой?

_>Через маршалинг.

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

НС>>Это не соответствует действительности. Слинкованные в dll функции вызываются без проблем. Для статической линковки есть МС++.
_>Ага, поэтому когда захотели сделать биндинг из .Net'а к известной библиотеке C++ пришлось оборачивать её в C вызовы. )))

Ну кто ж вам мешал МС++ использовать?

_>>>- невозможность написания быстрого (в сравнение с C++ скажем) кода для ряда задач
НС>>Ты CLR с конкретными языками не перепутал? Если что, С++ в IL прекрасно компилируется.

_>Да, слегка некорректно сказал. Имелось в виду "в сравнение с оптимизирующими native языками", типа C++, Фортран, Ассемблер и т.п...

Ты хвостом не верти. Ты утверждал про ограничения виртуальной машины.

_> Да, а MC++ — это не C++, а насмешка. )))

Оптимизатор там вполне на уровне.

НС>>При чем тут CLR? Это особенности конкретных языков, не более того.
_>Дааа?

Да.

_> ) Т.е. на clr есть язык с поддержкой RAII в стиле C++? )

Да. Называется С++.

_>>>Жаль только что фанаты иногда пытаются вытащить технологию из своей нищи и распространить куда не надо.
НС>>Можно пример?

_>Собственно MS с появлением .Net пыталась протолкнуть его как универсальную технологию для всего

Пример?

_>И соответственно были толпы народа поддерживающие эту странную идею.

Пример?

_> Кстати, до некоторых из них похоже и сейчас ещё не дошло... )))

Пример?

И на исходный вопрос ответа так и нет.

Здравствуйте, Ночной Смотрящий, Вы писали:

НС>Нет, заинлайнить он может только managed функцию, это очевидно.

А причём здесь LTO в GCC и libfoo-1.so (см. ветку выше)?

Здравствуйте, esil, Вы писали:

E>А причём здесь LTO в GCC и libfoo-1.so (см. ветку выше)?

А если еще чуть чуть выше посмотреть, то можно увидеть, что речь вообще то с самого начала была о том, зачем нужен JIT.

Здравствуйте, Ночной Смотрящий, Вы писали:

НС>Так не используй его, если он тебе кривым кажется.

Я то вообще .net не использую ни в каком виде. Но что вы можете предложить взамен тем, кто использует? )

НС>Ну кто ж вам мешал МС++ использовать?

Это не нам, а тем кто делал биндинги. Да, и MC++ — это насмешка над настоящим C++. И кстати, а оно есть на моно? )

НС>Ты хвостом не верти. Ты утверждал про ограничения виртуальной машины.

Про неё и говорю. Ограничения именно виртуальной машины. Т.е. берём любой язык из неё и он будет заметно медленее чем нативный C++ или Фортран и т.п на значительном классе задач..

_>> ) Т.е. на clr есть язык с поддержкой RAII в стиле C++? )
НС>Да. Называется С++.

Т.е. в MC++ временем жизни объектов управлет совсем не GC? )

_>>Собственно MS с появлением .Net пыталась протолкнуть его как универсальную технологию для всего
НС>Пример?

Помнится в начале 2000-ых говорил с Доном Боксом на эту тему — он прямо пылал энтузиазмом. Ну как же, dll hell побеждено — впереди только светлое будщее со сплошным дотнетом.

_>> Кстати, до некоторых из них похоже и сейчас ещё не дошло... )))
НС>Пример?

Ну например часть .Net раздела форума rsdn похоже ещё не может смириться с реальностью...

НС>И на исходный вопрос ответа так и нет.

Ага, ага. Был вопрос про недостатки виртуальный машины .Net. Я привёл список. В итоге часть его скипнута, на часть комментарии типа "ну и не используй это возможность", и на ещё часть демагогия про точность формулировки (хотя все всё поняли прекрасно) с целью замять вопрос.

Здравствуйте, Ночной Смотрящий, Вы писали:

НС>А если еще чуть чуть выше посмотреть, то можно увидеть, что речь вообще то с самого начала была о том, зачем нужен JIT.

Вообще то изначально в теме речь шла о кроссплатформенности, к которой вопросы jit и т.п. имеют весьма косвенное отношение. На что автору темы уже неоднократно намекнули.

Здравствуйте, alex_public, Вы писали:

_>Здравствуйте, Ночной Смотрящий, Вы писали:

НС>>А если еще чуть чуть выше посмотреть, то можно увидеть, что речь вообще то с самого начала была о том, зачем нужен JIT.

_>Вообще то изначально в теме речь шла о кроссплатформенности, к которой вопросы jit и т.п. имеют весьма косвенное отношение. На что автору темы уже неоднократно намекнули.

косвенное оно сейчас, а тогда на заре это была первая из причин для создания управляемых языков и сред исполнения

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

Здравствуйте, Kingofastellarwar, Вы писали:

_>>Вообще то изначально в теме речь шла о кроссплатформенности, к которой вопросы jit и т.п. имеют весьма косвенное отношение. На что автору темы уже неоднократно намекнули.
K>косвенное оно сейчас, а тогда на заре это была первая из причин для создания управляемых языков и сред исполнения
K>всё остальное можно было легко реализовать на нативных языках и синтаксис, и библиотеки, и рефлекшон, и объекты по сети.

Вы сейчас видимо имели в виду саму идею байткода, а не jit, т.к. допустим в Java jit появился только со временем...

Да, я согласен что для бинарной кроссплатформенности необходим байткод (хотя вообще то не забываем ещё и про интерпретаторы!). Но именно такая кроссплатформенность в большинстве случаев не требуется. И соответственно вопрос байткода (а с ним jit и всего остального) уходят далеко в сторону по сравнению с вопросами поддержки функций платформы и наличия нужных библиотек.

Здравствуйте, alex_public, Вы писали:

_>Вы сейчас видимо имели в виду саму идею байткода, а не jit, т.к. допустим в Java jit появился только со временем...

_>Да, я согласен что для бинарной кроссплатформенности необходим байткод (хотя вообще то не забываем ещё и про интерпретаторы!). Но именно такая кроссплатформенность в большинстве случаев не требуется. И соответственно вопрос байткода (а с ним jit и всего остального) уходят далеко в сторону по сравнению с вопросами поддержки функций платформы и наличия нужных библиотек.

точно, об этом и тема, о том, что ни байткод, ни жит не нужны для решения "вопросов поддержки функций платформы и наличия нужных библиотек."

Здравствуйте, alex_public, Вы писали:

_>Помнится в начале 2000-ых говорил с Доном Боксом на эту тему — он прямо пылал энтузиазмом. Ну как же, dll hell побеждено — впереди только светлое будщее со сплошным дотнетом.

Так вот кто повинен в появлении SxS Hell!!! Сжечь еретика!!!!!

Здравствуйте, Kingofastellarwar, Вы писали:

K>точно, об этом и тема, о том, что ни байткод, ни жит не нужны для решения "вопросов поддержки функций платформы и наличия нужных библиотек."

Так я согласен. Но народ тут увлёкся как раз всякими jit, а я пытаюсь вернуть к теме.

Так вот. Если говорить о наличие библиотек и поддержке платформ, то очевидно что C++ тут безусловный лидер.

Однако так уж вышло, что главный системный язык является далеко не самым простым и безопасным. Соответственно пользоваться им допустим в классическом корпоративном сегменте (где толпы малоквалифицированных программистов пишут горы простейшего кода) — это что-то из области обезьяны с гранатой. Вот тут и выступают на сцену Java (в первую очередь), .Net и т.п. Здесь они на своём месте.

Кстати, вот если бы Питон (напомню, что это не только язык, но и своя огромная кроссплатформенная библиотека и свой байткод) был бы статически типизированым и не таким тормозным, то по идее он мог бы потеснить Java и .Net. А так он пока замечателен в основном для скриптов.

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

Здравствуйте, alex_public, Вы писали:

НС>>Так не используй его, если он тебе кривым кажется.

_>Я то вообще .net не использую ни в каком виде.

Заметно.

_> Но что вы можете предложить взамен тем, кто использует? )

Те, кто использует, те обычно от маршаллинга не страдают. Ну а те, которые страдают, те могу маршаллинг не использовать и звать нативные функции напрямую.

НС>>Ну кто ж вам мешал МС++ использовать?

_>Это не нам, а тем кто делал биндинги. Да, и MC++ — это насмешка над настоящим C++.

Современный вариант С++ для IL (который C++/CLI) вполне себе полноценный С++, дополненный конструкциями вроде gcnew.

_> И кстати, а оно есть на моно? )

Полностью управляемые сборки работают и на Моно рантайме. Смешанные сборки, насколько я знаю, Моно не поддерживает, что логично как раз ввиду кроссплатформенности его. Только ты уходишь от темы.

НС>>Ты хвостом не верти. Ты утверждал про ограничения виртуальной машины.

_>Про неё и говорю. Ограничения именно виртуальной машины. Т.е. берём любой язык из неё и он будет заметно медленее чем нативный C++

С++ есть под CLR, если ты еще не понял. Так что сравнение С++ с CLR ...

НС>>Да. Называется С++.

_>Т.е. в MC++ временем жизни объектов управлет совсем не GC? )

Тех, которые обычным new созданны — нет, не GC. Да и для GC объектов, реализующих IDisposable, там кое что в плане автоматики имеется.

_>>>Собственно MS с появлением .Net пыталась протолкнуть его как универсальную технологию для всего
НС>>Пример?

_>Помнится в начале 2000-ых говорил с Доном Боксом на эту тему — он прямо пылал энтузиазмом.

У Бокса профессия такая — пылать энтузиазмом. По любому поводу.

_> Ну как же, dll hell побеждено — впереди только светлое будщее со сплошным дотнетом.

Так где про универсальность?

_>>> Кстати, до некоторых из них похоже и сейчас ещё не дошло... )))
НС>>Пример?

_>Ну например часть .Net раздела форума rsdn похоже ещё не может смириться с реальностью...

Пример будет наконец?

НС>>И на исходный вопрос ответа так и нет.

_>Ага, ага. Был вопрос

Я про пример "фанаты иногда пытаются вытащить технологию из своей нищи и распространить куда не надо". Которого до сих пор нет.

_>Я привёл список.

И в нем ни одного реального недостатка, одно твое незнание. Нет, кое какие ограничения таки в CLR имеются, только ты ни одного из них не упомянул. Что я и хотел продемонстрировать.

_>на часть комментарии типа "ну и не используй это возможность"

Это был намек на твое незнание базовых вещей платформы, а именно на то, что код совершенно не обязан быть safe. Соответственно, маршаллинг, GC, проверки на выход за границы массива и т.п. — тоже не обязательны.

_>, и на ещё часть демагогия про точность формулировки (хотя все всё поняли прекрасно) с целью замять вопрос.

Не понимаю о чем ты.

Здравствуйте, Трололоша, Вы писали:

Т>С моно не работает.

С Моно не работает старый MС++ и смешанные сборки. Новый, который C++/CLI, работает. А смешанные сборки — это ж Win32 бинарник, никакой кроссплатформенности без всяких вайнов.

НС>>Ты CLR с конкретными языками не перепутал? Если что, С++ в IL прекрасно компилируется.

Т>Процессор IL выполнять не умеет.

Спасибо, КО.

Т> А JIT по качеству оптимизаций до промышленных C++ компиляторов не дотягивает.

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

Здравствуйте, alex_public, Вы писали:

_>Так вот. Если говорить о наличие библиотек и поддержке платформ, то очевидно что C++ тут безусловный лидер.

С. Без всяких ++.

_>Но если же мы говорим о максимальной кроссплатформенности (а это значит в том числе и использование всех возможностей платформы) и написание кода профессионалами, то тут нет ни малейших поводов отказываться от самого мощного инструмента — C++.

Мощность, она от критериев зависит.

Здравствуйте, Ночной Смотрящий, Вы писали:

_>>Так вот. Если говорить о наличие библиотек и поддержке платформ, то очевидно что C++ тут безусловный лидер.
НС>С. Без всяких ++.
C++ может использовать все библиотеки на С, но при этом имеет ещё достаточно много именно С++-ных библиотек.