Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Это был намек на твое незнание базовых вещей платформы, а именно на то, что код совершенно не обязан быть safe. Соответственно, маршаллинг, GC, проверки на выход за границы массива и т.п. — тоже не обязательны.
Это действительно так. Но всё дело в том, что если писать ТАКОЙ код, то возникает вопрос: "а зачем нам тут вообще .Net тогда?". Т.е. у нас тут по сути возникает бледная копия нативного C++, но при этом через костыли. При этом мы теряем все преимущества идеи .Net, позволяющей толпам народа бездумно мастерить свои формочки.
B>>Я в эклипсе и под виндой и под линуксом работаю. Что не так с ним?
V>Что под каждую операционку своя специальная инсталляция. Такая мультиплатформенность ничем не лучше сишной.
Там исполняемые файлы — только для удобства. Они устанавливают все нужные пути, и зовут джаву, со стартап классом. Если сравнить инсталляции для разных платформ, то отличаются они только этими файлами.
Новости очень смешные. Зря вы не смотрите. Как будто за наркоманами подсматриваешь. Только тетка с погодой в завязке.
There is no such thing as a winnable war.
Здравствуйте, Трололоша, Вы писали:
E__>>Не, там адский винегрет многолетней давности. Где-то хорошо, где-то плачешь кровавыми слезами. Переписываю на джаве, пишу обвязки с использованием рефлексии и аннотаций, зачастую не самых понятных(бля, ну как можно понять поля, называющиеся в оригинале и в базе как void1, void2 и так далее?)
Т>Сурово.
Зато меня греет мысль, что я делаю мир лучше, избавляя его от такого говна .
А, ну еще цифирки на моем банковском счету.
Новости очень смешные. Зря вы не смотрите. Как будто за наркоманами подсматриваешь. Только тетка с погодой в завязке.
There is no such thing as a winnable war.
Здравствуйте, alex_public, Вы писали:
E__>>Но при этом и дает местами шикарные возможности(та же рефлексия позволяет за счет пары утилитарных классов снижать размер кода в десятки раз, причем если это не берется из конфигов, то тормозит оно ровно до первого прохода jit(ибо реально для каждого случая ровно 1 нить исполнения получается)
_>Про скорость верю (правда опять же после прогона, т.е. для серверного софта скорее). А вот на счёт полезности вообще... Мне на самом деле не часто приходилось видеть красивые и нужные применения рефлексии. Т.е. специально придумать пример под неё — это не проблема естественно. А вот именно что бы из практики пришёл "запрос" и именно только рефлексия давала бы красивое решение...
Все для сервера. Десктопный софт — явно не конек джавы.
E__>>я напишу развернутый пост об этом, ибо как раз сейчас занимаюсь переводом сишного проекта в жабу(100 строк с++ превращаются в 10 жабовских), только как закончу, хоть это и не скоро).
_>Что-то как-то сомнительно. Вообще то как раз Java всегда отличалась многословностью — цена упрощённого синтаксиса. Разве что там какой-то дикий код раньше был. )))
Дикий — не то слово. И древний.
Как раз рефлексией код и сокращается. При получении из базы, после select [100500 полей], например, они одним методом запихиваются в поля класса. Вместо ручного запихивания, которое требует дочерта кода. То же при формировании запроса с кучей параметров.
Новости очень смешные. Зря вы не смотрите. Как будто за наркоманами подсматриваешь. Только тетка с погодой в завязке.
There is no such thing as a winnable war.
Здравствуйте, Трололоша, Вы писали:
Т>Здравствуйте, Eugeny__, Вы писали:
E__>>Угу. А скорение в 100 раз — это миф, да? Т>Ускорение в сравнении с чем? С заведомо плохо соптимизированным JITом жабьим же кодом?
Т>У тебя там кстати не 1000 вызовов а 500. Вот почему: Т>
Т> for(long i = 0; i < 1000; i++) {
Т> result += (Long)method.invoke(coolClassInst, i, i++);
Т> }
Т>
Т>Надо бы на i+1 поменять.
Да, моя ошибка.
Т>Ради интереса прогнал исправленный код на своём компе. Т>
Т>...\jdk1.7.0_03\bin>java.exe -server -cp test Main
Т>4925359
Т>2600712197
Т>62511
Т>1876919424
Т>Пока я вижу что первый проход выполнялся просто из рук вон плохо: 4925.3 нс на вызов. Т>Второй проход стал лучше: 62.5 нс на вызов.
Разница колоссальная.
Т>Ради интереса возьмём С++ код, который будет вызывать такую же функцию из динамически загруженной DLL (LoadLibrary + GetProcAddress). Т>Уж извини, но COM для теста мне писать ну совсем неохота. Поэтому в ближайшем приближении.
Не, давай уж ком замутим. Загружаемый из сети. Заодно глянем на красоту кода этого кома. Ну а там уже и доборемся до того, как это дело без напряга запустить под Линуксом и Маком. В джавовском варианте ничего менять не придется.
Т>Давай теперь заинлайним и там и там: теперь вызываемая функция static и в том же классе.
Т>Результаты С++: 1000000 вызовов, 0.000082465 секунд. Получаем 0.082 нс на вызов. Опять быстрее, в ~34 раза.
Сначала давай вариант с ком. Потом — мультиплатформенный. А вот после этого — посмотрим. А то мы меряем очень разные вещи.
Новости очень смешные. Зря вы не смотрите. Как будто за наркоманами подсматриваешь. Только тетка с погодой в завязке.
There is no such thing as a winnable war.
Здравствуйте, hattab, Вы писали:
E>> Да, обязательно. Бо сравнивать на разных машинах глупо.
H>скачать
А теперь — давай так, чтобы я это смог запустить единым образом под Линухом и Маком!
Новости очень смешные. Зря вы не смотрите. Как будто за наркоманами подсматриваешь. Только тетка с погодой в завязке.
There is no such thing as a winnable war.
Здравствуйте, Eugeny__, Вы писали:
E> E>> Да, обязательно. Бо сравнивать на разных машинах глупо.
E> H>скачать
E> А теперь — давай так, чтобы я это смог запустить единым образом под Линухом и Маком!
Могу собрать еще под Mac OS X, Линукс пока(!) не поддерживается.
Здравствуйте, gandjustas, Вы писали:
K>>а самым реально мультплатфоменнным оказался в итоге Си с С++ом G>Ты хочешь сказать что можно раз скомпилировать код на C\C++ и запускать везде? Что-то я сомневаюсь что у тебя так выйдет.
Это еще зачем?
Почему просто не собрать скомпилировать приложение для целевой платформы из исходников?
G>Для начала сформулируй определение. С этим самые большие проблемы сегодня. G>Например кроссплатформенность в виде "компилируем раз — запускаем везде" не работает нигде. Даже java, изначально заточенная под такой сценарий, так работать не будет.
Именно что. Фейк. Поэтому С/С++ оказались не хуже кроссплатформенны, чем Java. Дотнет вообще ни о чем по этой теме.
G>Второй вариант — "программа под любую платформу собирается из одного набора исходников". Такое похоже на правду, НО есть платформенно-зависимый код, есть UI, который чаще всего надо проектировать под каждую платформу отдельно.
Это если использовать платформенно-зависимые UI библиотеки. Почему бы не взять одну из множества популярных платформенно-независимых UI-библиотек с одним и тем же высокоуровневым АПИ для разных платформ: QT, gtk, webkit, wxWidgets, FLTL, VCF и еще многие десятки попроще?
G>Третий вариант — "программные библиотеки, без UI и платформенно-зависимых вещей собиратся для любой платформы из одного набора исходников".
Да че ты так к UI привязался? Платформенно-независимого UI хоть попой ешь. Проблемы только у конкретно дотнета с их непереносимыми WinForms и WPF, бо в той же Java с кроссплатформенным GUI с рождения никаких проблем не было.
G>Так в этом случае кроссплатформенными являются и Java, и .NET, и C++. G>Причем .NET опережает всех ибо работает на Windows, Linux(Mono), MacOS(Mono), iOS (MonoTouch), Adndroid (MonoDroid), WP7, Web (Silverlight, компиляция в js), XBox, embedded (.NET MicroFramework)
Брехня опять. Моно сильно отличается от версии MS. Для примера, QT для разных платформ имеет одно и то же АПИ. А у меня сходу ни одно приложение для дотнета на Моно не идет. Т.е. это надо забыть про дотнет и разрабатывать под Моно даже на виндах, чтобы получилось кроссплатформенно. Поэтому слово "дотнет" из своего обзора убери. Дотнет НЕ кроссплатформенный ни разу.
Здравствуйте, gandjustas, Вы писали:
_>>Типа гораздо выгоднее разработать отдельное приложение под каждую платформу, да? G>Ну вот производители фотошопа считают так. У них разные билды под разные оси.
Ну и? Сколько платформ, столько раз "build" нажать... Где ты разглядел "отдельные приложения под каждую платформу"?
Здравствуйте, Eugeny__, Вы писали:
E__>Не, давай уж ком замутим. Загружаемый из сети. Заодно глянем на красоту кода этого кома. Ну а там уже и доборемся до того, как это дело без напряга запустить под Линуксом и Маком. В джавовском варианте ничего менять не придется.
Ну замути если есть желание. Потестим.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>А смешанные сборки — это ж Win32 бинарник, никакой кроссплатформенности без всяких вайнов.
Моно смешанные сборки даже на Windows не поддерживает.
Здравствуйте, Eugeny__, Вы писали:
E> Сначала давай вариант с ком. Потом — мультиплатформенный. А вот после этого — посмотрим. А то мы меряем очень разные вещи.
Изначально же речь шла о джитовой оптимизации, причем тут твое желание увидеть мультиплатформу?
G>>Третий вариант — "программные библиотеки, без UI и платформенно-зависимых вещей собиратся для любой платформы из одного набора исходников".
V>Да че ты так к UI привязался? Платформенно-независимого UI хоть попой ешь.
Только от него тянет блевать. Он везде одинаково плохо выглядит.
Кроме того не везде работает, покажешь такую либу чтобы работала в Android, iOS и WP7? Или хотябы в любой паре из них?
V>Проблемы только у конкретно дотнета с их непереносимыми WinForms и WPF, бо в той же Java с кроссплатформенным GUI с рождения никаких проблем не было.
Кроме убогости и ненужности — да, не было.
G>>Так в этом случае кроссплатформенными являются и Java, и .NET, и C++. G>>Причем .NET опережает всех ибо работает на Windows, Linux(Mono), MacOS(Mono), iOS (MonoTouch), Adndroid (MonoDroid), WP7, Web (Silverlight, компиляция в js), XBox, embedded (.NET MicroFramework)
V>Брехня опять. Моно сильно отличается от версии MS.
В каком месте? Ты не забыл что рассматривает не UI и не системно-зависимую часть?
V>Для примера, QT для разных платформ имеет одно и то же АПИ.
Да, детка, покажи мне api для WP7
Здравствуйте, vdimas, Вы писали:
V>Здравствуйте, gandjustas, Вы писали:
_>>>Типа гораздо выгоднее разработать отдельное приложение под каждую платформу, да? G>>Ну вот производители фотошопа считают так. У них разные билды под разные оси.
V>Ну и? Сколько платформ, столько раз "build" нажать... Где ты разглядел "отдельные приложения под каждую платформу"?
Десятая версия для win и mac вышла с разницей в 2 месяца, долго они build жали, тебе не кажется?
Здравствуйте, gandjustas, Вы писали:
G>Только от него тянет блевать. Он везде одинаково плохо выглядит.
Эээм, вообще то как раз у нативных инструментов (в отличие от Java и т.п.) часто используется родной для платформы GUI. Так что имеем кроссплатформенные приложения, при этом выглядящие родными на всех платформах.
G>Кроме того не везде работает, покажешь такую либу чтобы работала в Android, iOS и WP7? Или хотябы в любой паре из них?
Ха, WP7 то никого не волнует пока, т.к. там процент устройств где-то в районе 0...
На iOS нормальные C++ фреймворки работают вообще без вопросов.
Что касается Андроида, то тут всё сложнее. C++ там работает нормально, но только в NDK. Хотя вот в QT вроде сделали хитрую обёртку, которая позволяет по сути писать как обычно и при этом запускаться на Андроиде автоматом. Но сам я её не пробовал.
Да, и что это вы всё про мобильные приложения то? Конечно состояние этого сегмента рынка с неустоявшимися платформами удобно для аргументации в таком споре... Однако по бизнесу очень часто интересны только взрослые платформы (Windows, OS X, Linux), а там с кроссплатформенностью всё давно отлажено.
Здравствуйте, gandjustas, Вы писали:
V>>Очередной отжиг. Вне дотнета жизни нет? G>Если учесть что 90% компов — windows, то можно считать что нету. G>Из оставшихся 10% большая часть маки, там тоже кроссплатформенный софт не жалуют.
Ха, а это кстати ещё один аргумент в пользу разработки с помощью кроссплатформенных инструментов.
Если для того что бы добраться до 10% пользователей надо переписывать приложение целиком, то такое редко может быть оправдано по деньгам. А вот если для этого надо всего лишь перенести исходники на соседний комп (или вообще в виртуальную машину) и нажать там build, то это имеет смысл даже ради 1% пользователей... )))
Где C++ не может использовать какую-то библиотеку или системную функцию, а C может.
.
