Здравствуйте, Kingofastellarwar, Вы писали: K>да, различия платформ все равно придется учитывать в коде, но код на 98% будет компилируем без переделок и будет работать везде на максимуме скорости и без ЖИТ тормозов.
А вот тут и собака порылась. Проблема не в кроссплатформенности, платформу как раз заменить не проблема. Проблема в том, что современные устройства требуют написания разного софта. Нельзя приложение для десктопа тупо скомпилить на смартфоне. И "чуть-чуть переделать" не выход, практически все приложение придется писать с нуля. Истинно кросплатформенный HTML это показал во всей красе -- на десктоп один сайт, на смартфон другой, на планшет третий. Кроссплатформенность потеряла смысл. Вообще. Нельзя написать софт с одинаковым сценарием использования на такие разные устройства.
Всё, что нас не убивает, ещё горько об этом пожалеет.
рассмотрим на примере только дотнета, я его лучше всего знаю, а проблемы у его собратьев такие же.
изначальная идея "компилируем раз — запускаем везде" давала надежду, но не только по маркитенговым, но и техническим причинам оказалось, что
приемлемом уровне это сделать сложно, в итоге все жавы и дотнеты оказались очень даже одно платформенными.
а самым реально мультплатфоменнным оказался в итоге Си с С++ом
тогда нафига весь этот огород?
а если просто представить, что не нада было заморачиваться платформонезависимостью, но реализовать лучшие наработки в области сематники и базовых либ?
код запускался бы сразу без JIT компиляции и тормозов с ней связанной и можно было бы делать реальную оптимизацию кода компилятором выжимать максимум.
а мультиплатформеность достигнуть посредством просто написания соот-щего компилятора под то, что нужно, сохранив максимум совместимости на уровне базовых библиотек.
да, различия платформ все равно придется учитывать в коде, но код на 98% будет компилируем без переделок и будет работать везде на максимуме скорости и без ЖИТ тормозов.
конечно с костылями это можно и сейчас достигнуть, типа С/С++ и буст или С/С++ и скрипты, но это всё извраты и многом ограниченные по функционалу.
мож нада было идти этим путем? а не жертвовать многим ради платформонезависисмости которая в итоге недостижима оказалась.
Я изъездил эту страну вдоль и поперек, общался с умнейшими людьми и я могу вам ручаться в том, что обработка данных является лишь причудой, мода на которую продержится не более года. (с) Эксперт, авторитет и профессионал из 1957 г.
Здравствуйте, Kingofastellarwar, Вы писали:
K>рассмотрим на примере только дотнета, я его лучше всего знаю, а проблемы у его собратьев такие же.
Рассмотрим на примере java... все работает прекрасно на всех платформах...
Рассмотрим правильное кроссплатформеное программирование под С/C++ — все прекрасно компилируется под любые платформы — от PC до мобильных...
Каждый язык имеет свою нишу и применение... настоящему программисту все равно на каком языке писать, под какую платформу и архитектуру — ибо принципы программирования идентичные для всех языков и отличаются только синтаксисом, а базовые технологии есть во всех платформах, а отличия в архитекторах нивелируются едиными типами данных... Так что вся статья — то маркетинговый берд направленный на продвижение своих продуктов...
Здравствуйте, Kingofastellarwar, Вы писали:
K>рассмотрим на примере только дотнета, я его лучше всего знаю, а проблемы у его собратьев такие же.
Кросплатформенность .NET — это не иллюзия, а тупое нежелание MS переносить код на другие платформы. Mono прекрасно работает и на линуксе и на андроиде. Никаких проблем с этим нет.
Почему MS не желает заниматься другими платформами для меня совершенно непонятно. В результате на сегодняшний день наблюдается стойкая тенденция не только написания сервернго кода на Java, но и переписывания существующего .NET кода на Java. Можно сказать, что рынок серверного софта в банках на сегодня для .NET потерян. Удивляет то, что для одной и тоже же большой системы UI делается на .NET, Web на .NET, а сервер на Java.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, Kingofastellarwar, Вы писали:
K>прекрасно это как? я лично не видел ни одного приложения на жаве, которое прекрасно работало хотя б под линухом, вендой и макосью.
Странно, а я видел. И не одно, и не два. Наоборот трудно вспомнить те, что не могут работать под ними всеми.
М>>сильно. а какое отношение это имеет к JIT и прочим умным словам? Ф>это имеет отношение к .Net.
создание 400х чекбоксов в гриде? помилуйте. давайте использовать инструменты по назначению. какие проблемы реализовать _один_ элемент управления самостоятельно? совсем уже обленились. тут же тривиально все. будет летать на любой платформе. давайте я вам не буду объяснять сколько ресурсов кушает один элемент управления?
Ф> вторая по сточёт тормозная GUI-библтиотека, притом ещё более тормозная, чем перваяю.
если писать в таком стиле -- чего удивляться?!
Ф> именно библиотеки хорошо характеризуют платформу, на которой они написаны
создание 400х чек-боксов показывает, что программисты совсем разучились думать и хотят готовых _стандартных_ компонентов под нестандартную задачу, хотя она на чем угодно реализуется элементарно и без тормозов и без ограничения на кол-во элементов в гриде. хоть миллион на миллион. ловим событие "щелчок", смотрим где мыша, вычисляем позицию верхнего левого угла элемента, из битового массива берем его состояние, меняем на противоположное и рисуем либо галку либо пустое место.
где тут может тормозить? разве что при инициализации. ну так рисуем в памяти, а затем выводим всю картинку за один вызов библиотечной функции рисования.
вы бы еще создали 400 потоков и сказали, что система -- фуфло
americans fought a war for a freedom. another one to end slavery. so, what do some of them choose to do with their freedom? become slaves.
Здравствуйте, Sheridan, Вы писали:
S>Ничего подобного. Я даже и не пытаюсь. Просто говорю то, что вижу в силу своей незашоренности окнами или там маковыми полями.
Как насчёт зашоренности незашоренностью?
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, Eugeny__, Вы писали:
IT>>Но ведь зависят же. Все рабочие станции в банках — Windows, а основной рабочий софт — MS Office. Сервера в сравнении с этим — это капля в море. E__>Ну вот, кстати, у того же Приватбанка(самый крупный коммерческий банк Украины) все рабочие станции в отделениях на линухе...
А, так вот почему у них никогда ничего не работает...
Здравствуйте, Uzumaki Naruto, Вы писали:
UN>Рассмотрим на примере java... все работает прекрасно на всех платформах...
прекрасно это как? я лично не видел ни одного приложения на жаве, которое прекрасно работало хотя б под линухом, вендой и макосью.
UN>Рассмотрим правильное кроссплатформеное программирование под С/C++ — все прекрасно компилируется под любые платформы — от PC до мобильных...
ясное дело что оно комплируется, заставить скомпилирвоать можно всё, тока вот писать на таком не тянет совсем.
Я изъездил эту страну вдоль и поперек, общался с умнейшими людьми и я могу вам ручаться в том, что обработка данных является лишь причудой, мода на которую продержится не более года. (с) Эксперт, авторитет и профессионал из 1957 г.
Здравствуйте, gandjustas, Вы писали:
G>>>Третий вариант — "программные библиотеки, без UI и платформенно-зависимых вещей собиратся для любой платформы из одного набора исходников".
V>>Да че ты так к UI привязался? Платформенно-независимого UI хоть попой ешь. G>Только от него тянет блевать. Он везде одинаково плохо выглядит.
Ох и нубство... особенно сравнивать с твоим WinForms или тормозным WPF.
Вот и выросло поколение, ни одного контрола лично не написавшее...
Понимаешь... Нет такой либы, где бы нельзя было кастомизировать внешний вид любого контрола. И никакими тормозами, как в WPF, за это платить не надо. Поэтому пытаться обсуждать внешний вид GUI вместо архитектуры/возможностей — это надо быть максимально далеким от предмета обсуждения.
G>Кроме того не везде работает, покажешь такую либу чтобы работала в Android, iOS и WP7? Или хотябы в любой паре из них?
Т.е. гугле таки забанили?
Везде, где доступен компилятор C++, доступны библиотеки на нем. Например, для iOS вовсю уже активно юзают GCC, бо Objective-C тот еще уродец. QT работает на Mac OS X без проблем, так же как в iOS. Для android наконец вышел Android NDK, на котором уже собрали QT.
Т.е. проблема-то была не в обсуждаемых либах ни разу, а в неготовности самих платформ запускать сторонние нейтивные приложения. Поддержка нейтивных вещей в Android была сыроватой для активного публичного использования в первых версиях, кишки операционки еще активно дорабатывалась, поэтому и стала популярна Java-песочница на старте проекта. Сейчас внутренности Android немного устаканились и можно "отливать из бетона" публичное нейтивное АПИ.
Для WP7 — тоже самое. Нейтивные приложения писать-то можно, игры так и будут написаны, куда они нафик денутся. А в играх должен быть GUI, угу. Например, популярен для DirectX или OpenGL кроссплатформенная либа контролов SDL. В играх-то тоже контролы бывают, ты как думал?
Но слухи насчет недоступности простым смертным публичных заголовков или lib-файлов, скорее окажутся правдой. Это новая и совершенно сырая еще система. Им просто деваться некуда — если что-то навсегда зафиксировать в нейтивном АПИ, потом сложно будет переделать. Возможно, что будет как в Андроиде — пока система будет сырая, нейтивные SDK будут доступны не публично, а по специальным процедурам доступа к ним.
V>>Проблемы только у конкретно дотнета с их непереносимыми WinForms и WPF, бо в той же Java с кроссплатформенным GUI с рождения никаких проблем не было. G>Кроме убогости и ненужности — да, не было.
Обосновать сможешь? Или ругань вместо технических деталей — это твой любимый способ сливания?
V>>Брехня опять. Моно сильно отличается от версии MS. G>В каком месте? Ты не забыл что рассматривает не UI и не системно-зависимую часть?
С какой радости? Нахрена мне система без системы?
Сосредоточься плиз на приводимых фактах: Моно является кроссплатформенным. И даже в системных вещах. И даже в GUI. Бо есть бинды QT, GTK и многих других либ.
Дотнет — нет, не кроссплатформенный ни разу. У него прямо в частоиспользуемых либахх торчат подробности WinAPI, поэтому-то Моно и отличается от дотнета многими местами на сегодня, помимо твоего GUI.
Да и вообще, упоминание системных вещей смешнее всего. Например, ACE/boost/libevent/ptlib и еще куче других либ пофиг тонкости отличий АПИ операционнок, а вот "кроссплатформенному" дотнету (С) — не пофиг. Цирк как он есть.
Просто не надо додумывать за MS лишнего. Кроссплатформенности никто не обещал, разве что в отдаленной перспективе (кроссплатформенность со слов MS приводилась как потенциальное преимущество)... т.е. ты непонятно о чем тут вообще споришь.
V>>Для примера, QT для разных платформ имеет одно и то же АПИ. G>Да, детка, покажи мне api для WP7
Ох и нубство дремучее... В MSDN тебя тоже забанили? Дай мне любой бинарник для WP7, я тебе список импортируемых символов оттуда распечатаю, если сам не умеешь, детка. И по каждому символу дам ссылку на MSDN. Там такое же обычное WinAPI, за исключением user32... если тебе это что-то говорит. И DirectX тоже есть, напомню и под DirectX/OpenGL есть кроссплатформенные GUI-библиотеки, так же напомню.
Здравствуйте, Sheridan, Вы писали:
S>Покажи мне как из исходников, требующих дотнет, соберется приложение под линух+моно.
4 ASP.NET сайта, аудитами которых я занимался, крутились под линуксом. На гитхабе и гуглокоде (поиск в помощь) есть приложения и одинаково хорошо собирающиеся под обоими платформами и бинарно-совместимые с ними. Упомянутый тобой ravendb вполне себе кроссплатформен. В настоящий момент, в свободное от работы время, я занимаюсь разработкой двух .NET-приложений, собирающихся под обоими платформами. Одно консольное — интерпретатор специализированного DSL'я для работы с HTTP пакетами, второе гуевое (WinForms), ближайшими аналогами которого являются явовские OWASP Zap и Burp Suite. Бету первого планирую положить на гитхаб на следующей неделе. Оба приложения, кстати, бинарно-совместимы не только с линухом, но и с макосью. И это именно приложения, требующие дотнет, я разрабатываю их под виндой, где у меня моно отродясь не было. Nemerle после исправления досадного бага в mono'вской реализации reflection, отлично собирается под этой платформой, а бинарно совместим с ней был вообще всегда. Проблемы кроссплатформенности можно и на яве, и на питоне и даже на яваскрипте отгребсти, это вообще не говорит о кросс-платформенности платформы в принципе.
Разница между .net и mono составляет ровно 4 буквы, все остальное — детали реализации и попытки играть в большую политику. Для тех, кому это надо, кросс-компиляция и бинарная совместимость там есть, было бы желание разрабатывать под эту платформу.
Здравствуйте, Михаил Романов, Вы писали:
IT>>Почему MS не желает заниматься другими платформами для меня совершенно непонятно. МР>А как оно будет зарабатывать на .Net на других платформах? За счет средств разаработки?
А как можно заработать на разработке серверного софта, полностью отдав его в руки линукс и java? Для начала этот рынок нужно захватить и возглавить, а уже потом на нём зарабатывать. С точки зрения разработки серверного софта java ничем не привлекательнее .NET, а линукс ничем не лучше Windows, но есть один аргумент, который с успехом используется в этой игре линукстоидами — многоплатформенность. Аргумент, нужно признать, притянутый за уши, но он есть и с ним приходится считаться. Всё, что нужно сделать — это устранить этот аргумент. И завтра в половине банков на серверах появится .NET, а послезавтра вместо линукса появится Windows и вместо Oracle — Sql Server.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, Kingofastellarwar, Вы писали:
WH>>Ты серьезно думаешь, что JIT-компилер нужен только для мультиплатформенности? K>а для чего еще? K>ну только не смешите меня песнями про оптимизацию под платформу, это беда жит, а не его достоинство. K>или для динамической компиляции? а кто ее использует?
Для контроля выполнения и уборки мусора. Все остальное -- неизбежное следствие.
_>А ещё сейчас похоже появляется новый игрок в связи с попытками перевода всего в web. Html5, jquery фреймворки с полноценными GUI контролами и т.п... Посмотрим в ближайшем будущем что это, очередная временная мода или реальный конкурент.
Скриптовый язык без типов данных, глобальные переменные, крайне низкий уровень разработчиков (включая и тех из них, кто вроде сидит под линухом, но на самом деле ничему новому учиться не хочет), а если вместо jQuery рассмотреть ExtJS версии 4.x, то...
...становится понятно, что этот "игрок" — тот же MS Access и Borland Paradox по сути своей.
Он же dBase, Turbo Vision, VCL и т.п. монолитное-всё-в-одном.
Здравствуйте, Cadet, Вы писали:
C> H>Да я более чем внятно все объяснял, даже ссылку на вики давал (поверь, там описано все очень внятно). Я думаю тут есть явное нежелание сторонников дотнета признать тот простой факт, что он не кроссплатформенен
C> Так все же, давай выясним какая часть некросплатформенна-то?
Да что же вас тянет поделить его на части... Как по мне так все очень просто: вот есть Microsoft .NET Framework включающий в себя среду исполнения и кучу библиотек. То есть, все это и есть Microsoft .NET Framework, без какого то бы ни было деления.
C> А то вот я сейчас напишу на шарпе программу, и под линухом и под виндами ее скомпилю и запущу.
Никто не отрицает, что возможности MS. NET пересекаются с некоторым подмножеством Mono, и если писать софт пользующийся только этим подмножеством, он вероятно (в случае если в Mono используемая функциональность не реализована криво) будет кроссплатформенным.
C> Что мы имеем в виду под кроссплатформенностью? Кроссплатформенность на уровне сырцов, бинарей или еще чего-то?
Вообще, от платформы с байт-кодом ожидается бинарная кроссплатформенность т.е. переносимость исполняемых файлов. Это логично.
C> Плюсовый вот на уровне сырцов кроссплатформенный, частично правда, так же как и шарповый код. Тока тут под платформой следует понимать скорее не windows/linux, в .net/mono. При соблюденнии определенных правил и использовании определенных либ шарповый код переносим между .net и моно платформами, следовательно будет работать везде, где будет одна из этих платформ. Найдите отличия от джавы или плюсов.
С++ не является средством кроссплатформенной разработки, но, парадокс, большинство кроссплатформенных решений выполнено именно на на нем. Такая возможность обеспечивается наличием компиляторов и больших качественных библиотек.
Здравствуйте, Kingofastellarwar, Вы писали:
K>точно, об этом и тема, о том, что ни байткод, ни жит не нужны для решения "вопросов поддержки функций платформы и наличия нужных библиотек."
Так я согласен. Но народ тут увлёкся как раз всякими jit, а я пытаюсь вернуть к теме.
Так вот. Если говорить о наличие библиотек и поддержке платформ, то очевидно что C++ тут безусловный лидер.
Однако так уж вышло, что главный системный язык является далеко не самым простым и безопасным. Соответственно пользоваться им допустим в классическом корпоративном сегменте (где толпы малоквалифицированных программистов пишут горы простейшего кода) — это что-то из области обезьяны с гранатой. Вот тут и выступают на сцену Java (в первую очередь), .Net и т.п. Здесь они на своём месте.
Кстати, вот если бы Питон (напомню, что это не только язык, но и своя огромная кроссплатформенная библиотека и свой байткод) был бы статически типизированым и не таким тормозным, то по идее он мог бы потеснить Java и .Net. А так он пока замечателен в основном для скриптов.
Но если же мы говорим о максимальной кроссплатформенности (а это значит в том числе и использование всех возможностей платформы) и написание кода профессионалами, то тут нет ни малейших поводов отказываться от самого мощного инструмента — C++.
Здравствуйте, Eugeny__, Вы писали:
E__>Вот чего я не понимаю, так это то, какого хрена в жабу никак не добавят using. Простая же штука, по сути — это банальный синтаксический сахар над try-finally.
Здравствуйте, Mamut, Вы писали:
M>Который jQuery, тупое создание 400 чекбоксов с максимально тупым назначением событий каждому чекбоксу... И не тормозит. Более того, создание аналогичного в каком-нить ExtJS тоже не будет тормозить. M>Но нет, в WPF это низзя ни в коем случае, вы шо. Нужно в обязательном порядке делать собственный контрол на каждый чих? Где эти чихи начинаются? На 20 чекбоксах? На 30?
Потому что WPF плохо работает в таких сценариях. Никто же не говорит, что это панацея на все случаи жизни. Надо понимать, нужны ли тебе бенефиты WPF (шаблоны, масштабируемость, биндинги, эффекты). Если нужны, то придется учиться пользоваться технологией, что включает и умение выкручиваться в тормозных ситуациях. Вот у нас на проекте первоначальный вариант рисования сложного графика тратил на рендеринг около 10 секунд. Сейчас уходит меньше секунды притом, что количество данных только возросло. Потому что научились. Потому что нужны были другие фичи WPF, такие, например, как подстройка DPI.
У нас есть и другой проект, вебовский, с тем же Ext-ом. Там сначала тоже всё было быстро в GUI, но начали наворачивать и пошли тормоза. И веб-разработчики тоже стали искать пути оптимизаций.
Уж сколько раз говорили, что переносимость байт-кода нафиг не вперлась без переносимых абстракций. Без них не получиться писать кроссплатформенный софт, а ожидать таких подвижек от МС это сильно нужно верить в гномов и единорогов. Переносимость же по всея виндоус это просто насмешка над кроссплатформенностью. Почему то весь кроссплатформенный софт, которым я пользуюсь на разных системах написан на С++ и FreePascal, и им нафиг не уперся байт-код — у них есть переносимые абстракции.
Не очень понял почему в качестве примера кроссплатформенности привели пример .Net. Он же самими создателями позиционировался как только под Windows. Тот же Mono создан по сути независимо. Про другие платформы вообще молчу. Так что никакой кроссплатформенности никто и не обещал — откуда иллюзии то?
А получились Java на JVM и C# на .Net (последнее возникло просто как конкурент первому, когда стал ясен масштаб ниши) для написания большого количества корпоративного софта низкоквалифицированными (и соответственно хорошо заменяемыми) программистами. Оказалось что это очень нужный рынок — в мире больше не IT Компаний всё же. )))
Конечно у авторов технологий появялись и всякие наполеоновские планы по переводу всей разработки на это дело, но они быстро пропадали столкнувшись с реальностью. У Java это произошло раньше — теперь она спокойно царит в своём мирке и нелезет особо никуда. А у MS вроде бы как раз только закончился такой период, когда они временно не развивали C++ и делали на упор в .Net везде. Но сейчас и у них идёт откат.
А ещё сейчас похоже появляется новый игрок в связи с попытками перевода всего в web. Html5, jquery фреймворки с полноценными GUI контролами и т.п... Посмотрим в ближайшем будущем что это, очередная временная мода или реальный конкурент.
Здравствуйте, vsb, Вы писали:
vsb>>>А вы можете продемонстрировать тормоза Java
Let's combat begin!
Выбирайте компилятор жабы, сударь. В качестве C++ компилятора я беру ICC. Далее пишем тестовый код на С++ и идентичный ему на жабе. Собираем, выкладывая опции командной строки. Выкладываем бинарники сочуствующим, но ленящимся. И меряемся письками скоростью. Прогнозирую слив жабы по скорости минимум в 5(!) раз.
Здравствуйте, Eugeny__, Вы писали:
E__>Что касается написания высоконагруженных вещей на сервере(да тот же сервер БД) — ему нет равных. В написании логики в условиях постоянного "нада на вчера" — он сосет по полной. Инструмент подходит для того, для чего сделан. Можно шурупы забивать молотком — держаться будут, но, во-первых, хреново, а во-вторых, автоматическим шуруповертом это в разы проще(принять усилие и кнопочку нажать). А вот гвоздь забить лучше молотком — держится хорошо, но вот автоматизация молотка сложна и громоздка как в разработке, так и в использовании. Сами решите, что в этой аналогии молоток, а что шуруповерт .
Здравствуйте, NikeByNike, Вы писали:
NBN>>> Отсутствие кроссплатформенности. H>>Виртуальная машина, как раз таки, вполне себе переносима NBN>С++ в теории тоже хорош.
С++ в теории как раз плох, а вот на практике — хорош.
Здравствуйте, quwy, Вы писали:
Q>Для контроля выполнения и уборки мусора. Все остальное -- неизбежное следствие.
так для этого жит компиляция не нужна
Я изъездил эту страну вдоль и поперек, общался с умнейшими людьми и я могу вам ручаться в том, что обработка данных является лишь причудой, мода на которую продержится не более года. (с) Эксперт, авторитет и профессионал из 1957 г.
Здравствуйте, Kingofastellarwar, Вы писали:
Q>>Для контроля выполнения и уборки мусора. Все остальное -- неизбежное следствие. K>так для этого жит компиляция не нужна
Можно и интерпретатором, только это еще хуже.
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, Uzumaki Naruto, Вы писали:
K>>>рассмотрим на примере только дотнета, я его лучше всего знаю, а проблемы у его собратьев такие же. UN>>Рассмотрим на примере java... все работает прекрасно на всех платформах... C>Кроме iPhone.
Продукцию Apple не воспринимаю всерьез... рассчитываю что в течении 5 лет исчезнит как реликт...
UN>>Рассмотрим правильное кроссплатформеное программирование под С/C++ — все прекрасно компилируется под любые платформы — от PC до мобильных... C>Кроме WinPhone.
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, Kingofastellarwar, Вы писали:
K>>рассмотрим на примере только дотнета, я его лучше всего знаю, а проблемы у его собратьев такие же.
IT>Кросплатформенность .NET — это не иллюзия, а тупое нежелание MS переносить код на другие платформы. Mono прекрасно работает и на линуксе и на андроиде. Никаких проблем с этим нет.
Ходят слухи, что не так уж и прекрасно.
IT>Почему MS не желает заниматься другими платформами для меня совершенно непонятно.
Это желание, стоя на Луне, притянуть к себе Землю.
IT>В результате на сегодняшний день наблюдается стойкая тенденция не только написания сервернго кода на Java, но и переписывания существующего .NET кода на Java. Можно сказать, что рынок серверного софта в банках на сегодня для .NET потерян.
Думаю, такая картина наблюдается не только в банках. Нужно быть очень чудаковатым человеком, чтобы решиться писать сервер на .NET.
IT>Удивляет то, что для одной и тоже же большой системы UI делается на .NET, Web на .NET, а сервер на Java.
С окончательным становлением HTML5 .NET будет выпилен и оттуда. Уже сейчас на центральное место выходят java-фреймворки, позволяющие писать html/js/ajax приложения на 100% java, причем как на клиентской (gwt), так и чисто серверной стороне (то есть весь UI-код — описание UI и обработка событий — крутится а сервере, на клиент отправляются изменения аяксом).
Социализм — это власть трудящихся и централизованная плановая экономика.
Здравствуйте, IT, Вы писали:
IT>>>Почему MS не желает заниматься другими платформами для меня совершенно непонятно. LP>>Это желание, стоя на Луне, притянуть к себе Землю.
IT>Это ты так пошутил? Понял. Смешно.
Зачем нам предоставлять инструментарий для других платформ, пусть те, кто хочет использовать наши средства, ставит винду. Такова политика МС и именно ее я сравнил с попыткой притянуть Землю, стоя на Луне. По-моему, сравнение весьма уместное.
IT>>>В результате на сегодняшний день наблюдается стойкая тенденция не только написания сервернго кода на Java, но и переписывания существующего .NET кода на Java. Можно сказать, что рынок серверного софта в банках на сегодня для .NET потерян. LP>>Думаю, такая картина наблюдается не только в банках. Нужно быть очень чудаковатым человеком, чтобы решиться писать сервер на .NET.
IT>Ой, да ладно. Нормально всё пишется. Тоже мне рокет саинс. Тупее софта, чем серверный не бывает. Прочитал из базы, переложил в объект. Может по пути ещё чего-ниубдь умножил на два. А если на полтора, то это уже проблема. А наша java так не умеет. Может вы там у себя на клиенте на .NET это на полтора сумеете? Конечно сумеем, маленький, не плач. И на полтора сумеем, да и на два тоже, какие проблемы? Так постепенно и переезжает вся логика на клиента, а сервер в результате тупой конекшин к БД.
Разработчику банковских систем должно быть известно, что логика на клиенте — это дыра в безопасности системы. Далее, совершенно очевидно, что чем толще клиент, тем меньше диапазон устройств, на которых он может работать (это перпендикулярно кросплафторменности — речь идет о ресурсах). Вот буквально недавно забраковали таких вот любителей толстенького — клиент выжирал до полугига оперативы и работал, мягко говоря, не быстро, причем это было обусловлено объективными причинами (то есть не было следствием кривой реализации), в результате из мобильных девайсов пользоваться им было невозможно. Заменили реализацию на 100% сервер сайд, теперь крутится везде, где есть браузер.
IT>>>Удивляет то, что для одной и тоже же большой системы UI делается на .NET, Web на .NET, а сервер на Java. LP>>С окончательным становлением HTML5 .NET будет выпилен и оттуда. Уже сейчас на центральное место выходят java-фреймворки, позволяющие писать html/js/ajax приложения на 100% java, причем как на клиентской (gwt), так и чисто серверной стороне (то есть весь UI-код — описание UI и обработка событий — крутится а сервере, на клиент отправляются изменения аяксом).
IT>You wish! Пока вы там фреймворки разрабатываете энтерпрайз аккуратненько ASP.NET MVC и Silverlight осваивает.
Фреймворки уже давно готовы, цветут и пахнут, в отличие от вашего Сильверлайта. Его как, похоронили уже, или до сих пор выдерживают в гробу?
Социализм — это власть трудящихся и централизованная плановая экономика.
Здравствуйте, Kingofastellarwar, Вы писали:
K>рассмотрим на примере только дотнета, я его лучше всего знаю, а проблемы у его собратьев такие же.
дотнет это ни разу не мультиплатформа, ибо официально поддерживается только венда, да и то не всех версий. так что даже в рамках венды это не мультиплатформа.
K>изначальная идея "компилируем раз — запускаем везде" давала надежду, но не только по маркитенговым, K>но и техническим причинам оказалось, что приемлемом уровне это сделать сложно, в итоге все жавы K>и дотнеты оказались очень даже одно платформенными.
пишу программу для отлова малвари. пишу под винду, но она работает на маке с никсами. случайно проверил на андроиде, который был у коллеги. она и на андроиде работает. и это не моя заслуга, а платформы. ее и компилировать не надо.
K>а самым реально мультплатфоменнным оказался в итоге Си с С++ом
а какой у вас опыт работы с си и плюсами и на каких платформах?
K> а если просто представить, что не нада было заморачиваться платформонезависимостью, K> но реализовать лучшие наработки в области сематники и базовых либ? K> код запускался бы сразу без JIT компиляции и тормозов с ней связанной
применительно к дотнету -- согласен. но что делать с зоопарком остальных архитектур?!
K> конечно с костылями это можно и сейчас достигнуть, типа С/С++ и буст или С/С++ и скрипты, K> но это всё извраты и многом ограниченные по функционалу.
зачем извраты, если есть java? кстати, основная идея java это не только кросс-платформ, но и безопасность. в теории, java-апплет не может повредить ваш девайс. на практике -- даже с учетом дыр java все же лучше, чем ActiveX, который не только не кросс-платформ, но и вообще не контролируется в принцие. а сишный код это сплошные ошибки, ведущие к возможности захвата контроля. потому AcrobatX использует "песочницу", изолируя львиную часть кода от операционного окружения, что выглядит как нелепый костыль.
K> мож нада было идти этим путем? а не жертвовать многим ради K> платформонезависисмости которая в итоге недостижима оказалась.
многим жертвовали в си, в котором нету кучи фич, т.к. их не поддерживает "контроллер лифта" -- мифическое устройство под которое сишники пишут кросс-платформ. а чем пожертвовали в дот-нете? за какие тормоза вы говорите?
americans fought a war for a freedom. another one to end slavery. so, what do some of them choose to do with their freedom? become slaves.
Здравствуйте, alex_public, Вы писали:
_>Здравствуйте, gandjustas, Вы писали:
G>>Ага, запусти на мобилке то что написано для десктопа.
_>И что будет? )
Ничего, даже если запустится, то работать будет невозможно.
G>>>>Второй вариант — "программа под любую платформу собирается из одного набора исходников". Такое похоже на правду, НО есть платформенно-зависимый код, есть UI, который чаще всего надо проектировать под каждую платформу отдельно. _>>>Не надо, если выбрать правильные библиотеки. У нас вот кроссплатформенный продукт и "платформенных ifdef'ов" там на весь проект пара штук. G>>Это будет третий вариант
_>Это не третий вариант, во всяком случае в озвученном виде. Мы пишем программы (а не библиотеки) на C++ с GUI и они работают на множестве платформ простой перекомпиляцией.
Какие платформы входят в это множество?
G>>А потому что кроссплатформенность нафиг никому не упала. G>>Это тупо флаг, которым размахивают вендоры. Реальная польза от кроссплатформенности для конечного пользователя нулевая, если не отрицательная.
_>Пользователю конечно пофиг написана программа с помощью кроссплатформенных инструментов или же нет. А вот производителю это очень важно — меньше расходов.
M>>Это все — демагогия, пытающаяся прикрыть отмазки, пытающиеся прикрыть кривизну реализации. Ничего из описанного даже близко не объясняет, почему грид с 20x20 чекбоксами тормозит. MM>Блин, а я старался. Ну, хорошо, демагогия так демагогия.
А ты сам этого не видишь? Понимаешь, 20x20 чекбоксов, как их ни рисуй — это настолько мизер, что даже удивительно, что торможение грида пытаются объхяснить чем угодно, лишь бы не кривизной фреймворка.
M>> H>Да я более чем внятно все объяснял, даже ссылку на вики давал (поверь, там описано все очень внятно). Я думаю тут есть явное нежелание сторонников дотнета признать тот простой факт, что он не кроссплатформенен
M>> дотнет — это три разные сущности, какую из них ты имеешь в виду (и да, то, что МС называет эти три сущности одним именем, делу не помогает)
H>Я не говорю о частностях, я о целом.
Не получится. Потому что из этого целого некроссплатформенна только часть.
Здравствуйте, alex_public, Вы писали:
_>Так вот. Если говорить о наличие библиотек и поддержке платформ, то очевидно что C++ тут безусловный лидер.
С. Без всяких ++.
_>Но если же мы говорим о максимальной кроссплатформенности (а это значит в том числе и использование всех возможностей платформы) и написание кода профессионалами, то тут нет ни малейших поводов отказываться от самого мощного инструмента — C++.
Здравствуйте, Ночной Смотрящий, Вы писали:
_>>Так вот. Если говорить о наличие библиотек и поддержке платформ, то очевидно что C++ тут безусловный лидер. НС>С. Без всяких ++.
C++ может использовать все библиотеки на С, но при этом имеет ещё достаточно много именно С++-ных библиотек.
Здравствуйте, vdimas, Вы писали:
V>Понимаешь... Нет такой либы, где бы нельзя было кастомизировать внешний вид любого контрола. И никакими тормозами, как в WPF, за это платить не надо. Поэтому пытаться обсуждать внешний вид GUI вместо архитектуры/возможностей — это надо быть максимально далеким от предмета обсуждения.
Слушай, ты уже обосрался с тормозами WPF. В одной из тем кто-то просто прогнал профайлером и посмотрел где там тормоза. Отнюдь не в отрисовке
Заканчивай.
G>>Кроме того не везде работает, покажешь такую либу чтобы работала в Android, iOS и WP7? Или хотябы в любой паре из них?
V>Т.е. гугле таки забанили? V>Везде, где доступен компилятор C++, доступны библиотеки на нем. Например, для iOS вовсю уже активно юзают GCC, бо Objective-C тот еще уродец. QT работает на Mac OS X без проблем, так же как в iOS. Для android наконец вышел Android NDK, на котором уже собрали QT.
Не размазывай сопли, просто дай ссылку на GUI либу, которая работает на Android, iOS и WP7.
V>>>Проблемы только у конкретно дотнета с их непереносимыми WinForms и WPF, бо в той же Java с кроссплатформенным GUI с рождения никаких проблем не было. G>>Кроме убогости и ненужности — да, не было. V>Обосновать сможешь? Или ругань вместо технических деталей — это твой любимый способ сливания?
Это правда жизни, скриншоты прислать?
V>>>Брехня опять. Моно сильно отличается от версии MS. G>>В каком месте? Ты не забыл что рассматривает не UI и не системно-зависимую часть?
V>Сосредоточься плиз на приводимых фактах: Моно является кроссплатформенным. И даже в системных вещах. И даже в GUI. Бо есть бинды QT, GTK и многих других либ.
Это смотря что считать кроссплатформенностью. Еще раз напомню про Android, iOS и WP7. Их пересечение существует в маленьком подмножестве .NET, не Java и не C++.
V>Да и вообще, упоминание системных вещей смешнее всего. Например, ACE/boost/libevent/ptlib и еще куче других либ пофиг тонкости отличий АПИ операционнок, а вот "кроссплатформенному" дотнету (С) — не пофиг. Цирк как он есть.
Оно заработает на Android, iOS и WP7? (Каждом, а не любом из трех)
V>>>Для примера, QT для разных платформ имеет одно и то же АПИ. G>>Да, детка, покажи мне api для WP7
V>Ох и нубство дремучее... В MSDN тебя тоже забанили? Дай мне любой бинарник для WP7, я тебе список импортируемых символов оттуда распечатаю, если сам не умеешь, детка. И по каждому символу дам ссылку на MSDN. Там такое же обычное WinAPI, за исключением user32... если тебе это что-то говорит. И DirectX тоже есть, напомню и под DirectX/OpenGL есть кроссплатформенные GUI-библиотеки, так же напомню.
Не умничай, просто покажи api QT для WP7.
Здравствуйте, gandjustas, Вы писали:
V>>Ну и? Сколько платформ, столько раз "build" нажать... Где ты разглядел "отдельные приложения под каждую платформу"? G>Десятая версия для win и mac вышла с разницей в 2 месяца, долго они build жали, тебе не кажется?
Ты таки думаешь что всегда дело только в компилябельности и работоспособности? Может они фишки, специфические для макоси наверчивали, коих хватает, начиная от принциповразмещения меню, до однокнопочной мыши или мультитача. Не факт, что эти фишки обязательные для работоспособности общей части кода, но факт, что желательные для флагмана в этой нише. Тем более, что мак именно у дизайнеров и популярен.
Мне вообще надо было эти банальности рассказывать или как? Ведь это те вещи, которые выпадают из обсуждения, бо требовали бы индивидуального подхода в случае любой самой кроссплатформенной ГУИ-либы... т.е. эта та самая "постоянная составляющая" в обсуждении, которая паразитная. И ты за нее постоянно цепляешься от недостатка фантазии.
Здравствуйте, Kingofastellarwar, Вы писали: K>или для динамической компиляции? а кто ее использует?
Чуть более, чем все. Весь интернет — это либо чудовищный тормоз интерпретации (читай PHP, ASP), либо динамическая компиляция (ASP.NET, JSP). Вообще, там, где она доступна, динамическая компиляция используется в полный рост — те же регекспы очень сильно от неё выигрывают.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, MxMsk, Вы писали:
MM>Здравствуйте, Mamut, Вы писали:
M>>А ты сам этого не видишь? Понимаешь, 20x20 чекбоксов, как их ни рисуй — это настолько мизер, что даже удивительно, что торможение грида пытаются объхяснить чем угодно, лишь бы не кривизной фреймворка. MM>Вот здесь
очень правильный камент. Не фига непонятно из примера, что там тормозит. Я пробовал прикинуть, что может создавать нагрузку с учетом архитектуры WPF, а сейчас накидал грид 20 x 20 и не тормозит чего-то. Что делать, теперь не знаю.
Здравствуйте, Eugeny__, Вы писали:
E__>Я вам хуже скажу. В джаве можно получить вообще неизвестный класс черти откуда(тупым потоком байт из сети загрузить кастомным класслоадером как Object, но можно придумать и более изощренный сценарий), создать экземпляр(или же вызывать статику — неважно), проверить его на наличие нужного нам метода, и часто вызывать его через рефлексию, даже не кастуя ни к какому известному интерфейсу. И... Внезапно по нему пройдется джит, увидит, что вызываемый метод у класса есть, и его имя в программе статическая строка(т.е. оно выполняется, и будет всегда выполняться именно так). И он его заинлайнит, убрав рефлексию, плюс скомпилит в нативу. Очень прошу примера, как такое возможно в нативе. Это немного похоже на ком(тоже слепой вызов), вот только ком объект не инлайнится никогда. Ваш выход, господа.
Нет, JIT такую магию не умеет.
Там всё проще, java.lang.reflect.Method#invoke(obj, args) делегирует вызов через интерфейс MethodAccessor. Насколько я помню, первые сколько-то вызовов испоьзуется стандартная реализация интерфейса, которая делает вызов используя внутренние методы JVM. После какого-то количества вызовов, генерируется специальная реализация MethodAccessor.invoke(obj, args) { return (TargetObject) obj.targetMethod((Type0) arg0, ...) }, которая впоследствии и используется. Т.е рефлексивный вызов становится обычным вызовом через интерфейс + пара кастов. Вот после этого-то как раз и вступает в работу JIT, и уже тогда он может что-то куда-то заинлайнить.
Попробуй сделать целевой метод приватным, по идее тогда эта оптимизация не должна сработать и вызов будет всегда идти через внутренние методы JVM.
Здравствуйте, Sheridan, Вы писали:
S>Здравствуйте, мыщъх, Вы писали:
М>>Здравствуйте, Kingofastellarwar, Вы писали:
K>>>рассмотрим на примере только дотнета, я его лучше всего знаю, а проблемы у его собратьев такие же. М>>дотнет это ни разу не мультиплатформа, ибо официально поддерживается только венда, да и то не всех версий. так что даже в рамках венды это не мультиплатформа.
S>Слушай, видимо у меня карма такая, что я говорю в принципе те-же слова, а в меня начинают mono тыкать и переводить разговор на "так ведь шарп же кроссплатформа!!"
карма у нас общая. с таким же успехом можно говорить, что ms-dos это кросс-платформа, поскольку практически под всеми платформами есть неофициальные эмуляторы, которые даже геймы с бластером тянут.
попытка собрать несколько программ на шарпе (парсеров) под Mono закончилась неудачей. а еще у меня есть виндовый клиент на шарпе под одну очень нестандартную базу данных. попытка портировать его на линух так же проварилась (в mono не нашлось нужных библиотек для аутентификации).
в общем, мне известно очень мало программ на шарпе, которые работали бы и на никсах с маком. на жабе, наоборот, мне известно очень мало приложений 'windows only' и при декомпиляции там вылезают конструкции вида 'start cmd /c xxxx', т.е. жаба тут ни при чем.
americans fought a war for a freedom. another one to end slavery. so, what do some of them choose to do with their freedom? become slaves.
M>>Хотя, как оказалось, RavenDB вполне себе бегает на Mono, то есть никаких препятствий к тому, чтобы его можно бло собирать под Mono, нет. И какой-то скрипт все же существует. S>Я взял первый попавшийся проект, наугад. Или ты будешь возражать что найдутся дотнет проекты не собирающиеся под моно и наоборот?
Ты будешь возражать, что найдутся проекты, которые не собираются под gcc, но собирающиеся под Microsoft C++ compiler и наоборот?
Здравствуйте, NikeByNike, Вы писали:
NBN>>> С++ в теории тоже хорош.
H>>Практика показывает, что он даже лучше
NBN>Для мобильной области и геймдева — однозначно
NBN>Хз на счёт серверной
Что касается написания высоконагруженных вещей на сервере(да тот же сервер БД) — ему нет равных. В написании логики в условиях постоянного "нада на вчера" — он сосет по полной. Инструмент подходит для того, для чего сделан. Можно шурупы забивать молотком — держаться будут, но, во-первых, хреново, а во-вторых, автоматическим шуруповертом это в разы проще(принять усилие и кнопочку нажать). А вот гвоздь забить лучше молотком — держится хорошо, но вот автоматизация молотка сложна и громоздка как в разработке, так и в использовании. Сами решите, что в этой аналогии молоток, а что шуруповерт .
Новости очень смешные. Зря вы не смотрите. Как будто за наркоманами подсматриваешь. Только тетка с погодой в завязке.
There is no such thing as a winnable war.
Здравствуйте, Mamut, Вы писали:
M>>>Это все — демагогия, пытающаяся прикрыть отмазки, пытающиеся прикрыть кривизну реализации. Ничего из описанного даже близко не объясняет, почему грид с 20x20 чекбоксами тормозит. MM>>Блин, а я старался. Ну, хорошо, демагогия так демагогия.
M>А ты сам этого не видишь? Понимаешь, 20x20 чекбоксов, как их ни рисуй — это настолько мизер, что даже удивительно, что торможение грида пытаются объхяснить чем угодно, лишь бы не кривизной фреймворка.
забавно другое, что адепты дотнетов и жав когда описывали их преимущества использовали лозунги типа "теперь программисту не нада думать об этих мелочах! даже кухарка сможет теперь писать программы!"
а теперь оказывается, что 400 чекбоксов запихнуть это неправильно и нада думать как сделать правильно, т.е. оказывается что думать, как правильно сделать, всё равно приходится.
Я изъездил эту страну вдоль и поперек, общался с умнейшими людьми и я могу вам ручаться в том, что обработка данных является лишь причудой, мода на которую продержится не более года. (с) Эксперт, авторитет и профессионал из 1957 г.
Здравствуйте, vdimas, Вы писали:
V>Здравствуйте, мыщъх, Вы писали:
М>>лис, хром -- у всех них довольно жесткие требования к компиляторам. сборка новых версий это как бы не проблема (раз смогли собрать они -- смогу и я). а вот если хочешь собрать какую-то древность -- то нужной версии компилятора не найти, особенно если это не gcc, а коммерческий компилятор.
V>Эээ.. пролема обычно ровно наоборот, более новую версию невозможно собрать на более старом компиляторе.
так это как раз не проблема. во всяком случае для меня как сотрудника коммерческой компании. а вот в бытность свою фрилансером очень раздражало, что "каждой программее -- по компилятору".
V> Но это, ИХМО, нормально: новые версии разрабатываются на новых инструментах, т.е. хочешь всё новое — переходи на новое.
рабочая среда для разработки ПО должна быть предсказуема и крайне нежелательно переходить на новый компилятор в процессе "пусконаладки" текущего проекта. а под виндой нет легальных средств ставить зоопарк компиляторов. "нелегально" у меня от ms vc 6 до последних версий. но ставил "руками" и там не обошлось без махинаций и хакерства. можно, конечно, юзать виртуалки, но это ж какую производительность иметь надо
V>А насчет давности: все старые ходовые версии gcc вроде как доступны.
про gcc я и писал, что доступны. как на счет того, чтобы найти багдад или ms? конкретный пример -- стоит задача собрать firefox версий раньше чем 2.х (надо для секьюрных экспериментов). ms vc 6 выдает "внутреннюю ошибку компиляции", ms vc 9 выдает просто ошибки компиляции. ну ладно, проехали (выкинув часть функционала, который не копилировался). оказывается еще masm нужен. причем новые версии ему не нравятся, а старые (найденные на файлопомойках) они как бы _слишком_ старые, а истории масма ms не ведет и получить нужную версию было возможно только потому что я работаю в большой компании у которой в заначках можно и черта найти.
вот как собирать старые приложения, а? так что никакой это не кросс-платформ...
недавно базарил с одним PhD из штатовского универа. мы оба сокрушались о том как мало людей знают ANSI C. в универе дают плюсы с питоном, про си -- ни слова. но все выпускники пишут си/си++. один такой кадр на вопрос написать простую программу на си написал bool foo(). а на вопрос -- что это за хпуе с горы дите ответило -- а що, не компилируется? мы с Ph.D должны были его собеседовать, но между нами вспыхнула драмма. PhD -- ну с C99 вообще-то есть. я -- во-первых, оно там через stdbool, который тут отсутствует. во-вторых, на фига юзать такую фичу C99, отсекая кучу компиляторов? чем int не устроил? дите -- но ведь компилируется!!! мы (хором) мальчик, не встревай в разговоры взрослых.
но это мелочи по сравнению с тем как я писал свою первую программу на жабе. программа -- чуть сложнее "привет, люди". я же win guy. скачал JDK, собрал, запустил (а там консольный вывод один), убедился, что работает и заюзал на линухе. а на линухе оно не работает. выдает кучу исключений в самых непонятных местах. конечно, это я во всем виноват. собирал 1.7, а на линухе стояла 1.6, но помилуй боже, за что мне такие кары?! я ж никаких фич 1.7 не юзал. самая простая программа.
про руби -- это вообще песня. меня на него коллеги пытаются посадить, чтобы ехать со свистом на рельсах. только на моей винде эти рельсы нихрена не едут и мне быстрее работать на уровне SQL запросов, чем пытаться заставить эту муть работать под виндами. а переходить на линух как на основное средство разработки -- не предлагать, ибо слишком много привычек придется менять.
питон тоже ни фига не совместим. как глянул в стандартные библиотеки (в частности, в HTMLParser.unescape) так и ужоснулся и пришлось самому писать, потому как оно даже документированные особенности не учитывает и работает только в самых тривиальных случаях. такой подлости я не ожидал. тем более, что библиотека поставляется вместе с языком, а, значит, должна быть крепка как фундамент. ну или хотя бы явно указывать на то, что она чисто для красоты.
что там у нас осталось-то? нету у нас кросс-платформенных языков. в JavaScript -- это вообще песня олега. попробуйте выполнить следующее eval("var super = 'super';") под виндой и никсами. о результатах можно не докладывать -- я их знаю. и это относится к ядру языка, так сказать к ECMAScripting, в который DOM модель не входит.
разве что в AS пока не нашел больших различий на разных платформах, но его и не копал глубоко...
americans fought a war for a freedom. another one to end slavery. so, what do some of them choose to do with their freedom? become slaves.
Здравствуйте, WarHog, Вы писали:
WH>Ты серьезно думаешь, что JIT-компилер нужен только для мультиплатформенности?
а для чего еще?
ну только не смешите меня песнями про оптимизацию под платформу, это беда жит, а не его достоинство.
или для динамической компиляции? а кто ее использует?
Я изъездил эту страну вдоль и поперек, общался с умнейшими людьми и я могу вам ручаться в том, что обработка данных является лишь причудой, мода на которую продержится не более года. (с) Эксперт, авторитет и профессионал из 1957 г.
Здравствуйте, Kingofastellarwar, Вы писали:
K>а для чего еще? K>ну только не смешите меня песнями про оптимизацию под платформу, это беда жит, а не его достоинство. K>или для динамической компиляции? а кто ее использует?
Здравствуйте, Kingofastellarwar, Вы писали:
K>рассмотрим на примере только дотнета, я его лучше всего знаю, а проблемы у его собратьев такие же.
K>изначальная идея "компилируем раз — запускаем везде" давала надежду, но не только по маркитенговым, но и техническим причинам оказалось, что K>приемлемом уровне это сделать сложно, в итоге все жавы и дотнеты оказались очень даже одно платформенными.
K>а самым реально мультплатфоменнным оказался в итоге Си с С++ом
Ты хочешь сказать что можно раз скомпилировать код на C\C++ и запускать везде? Что-то я сомневаюсь что у тебя так выйдет.
Для начала сформулируй определение. С этим самые большие проблемы сегодня.
Например кроссплатформенность в виде "компилируем раз — запускаем везде" не работает нигде. Даже java, изначально заточенная под такой сценарий, так работать не будет.
Второй вариант — "программа под любую платформу собирается из одного набора исходников". Такое похоже на правду, НО есть платформенно-зависимый код, есть UI, который чаще всего надо проектировать под каждую платформу отдельно.
Третий вариант — "программные библиотеки, без UI и платформенно-зависимых вещей собиратся для любой платформы из одного набора исходников".
Так в этом случае кроссплатформенными являются и Java, и .NET, и C++.
Причем .NET опережает всех ибо работает на Windows, Linux(Mono), MacOS(Mono), iOS (MonoTouch), Adndroid (MonoDroid), WP7, Web (Silverlight, компиляция в js), XBox, embedded (.NET MicroFramework)
Здравствуйте, Eugeny__, Вы писали:
E__>Мухи — отдельно, котлеты — отдельно. Дотнет писан МС-ом, и реальная мультиплатформенность им не нужна. Жаба очень даже мультиплатформенна, и проектов на ней, где это пригождается очень и очень много. В основном это энтерпрайз, но все-таки.
а зачем энтерпрайзу мультиплатформенность?
Я изъездил эту страну вдоль и поперек, общался с умнейшими людьми и я могу вам ручаться в том, что обработка данных является лишь причудой, мода на которую продержится не более года. (с) Эксперт, авторитет и профессионал из 1957 г.
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, Sheridan, Вы писали:
S>>В принципе отчасти ты прав. В силу своей кроссплатформенности моно несколько более жив, чем дотнет. Но до тогоже ц++ далеко обоим.
IT>Твои попытки потролить .NET ничтожны.
Ничего подобного. Я даже и не пытаюсь. Просто говорю то, что вижу в силу своей незашоренности окнами или там маковыми полями.
Здравствуйте, Иван Дубров, Вы писали:
K>>код запускался бы сразу без JIT компиляции и тормозов с ней связанной и можно было бы делать реальную оптимизацию кода компилятором выжимать максимум.
ИД>Чем позже делается компиляция -- тем больше возможностей для оптимизации. Не зря в GCC LTO придумали.
LTO не имеет никакого отношения к "Чем позже делается компиляция -- тем больше возможностей для оптимизации".
Здравствуйте, Иван Дубров, Вы писали:
E>>LTO не имеет никакого отношения к "Чем позже делается компиляция -- тем больше возможностей для оптимизации".
ИД>А к чему это имеет отношение? Это способ делать некоторые оптимизации в момент, когда становится доступна некоторая информаци. Вот, прям с их wiki:
>>Link Time Optimization (LTO) gives GCC the capability of dumping its internal representation (GIMPLE) to disk, so that all the different compilation units that make up a single executable can be optimized as a single module. This expands the scope of inter-procedural optimizations to encompass the whole program (or, rather, everything that is visible at link time).
LTO — это способ выполнять межпроцедурные оптимизации на всей программе (а не по-модульно). Именно это и сказано у них в wiki. Фраза "делать компиляцию как можно позже" — это спекуляция, потому что на самом деле компиляция делается не раньше и не позже, она просто делается на всей программе, а не на каждом модуле отдельно.
ИД>Это способ отложить часть компиляции (некоторые оптимизации) до момента, когда у тебя будет необходимая информация. Например, совсершенно никак нельзя заинлайнить некую тривиальную функцию из libfoo-1.0.0.so во время сборки проекта, потому что при запуске у клиента может оказаться libfoo-1.0.1.so. Делая оптимизацию во время линковки ты уже совершенно точно знаешь, какой именно код стоит за libfoo и можешь проводить такие оптимизации.
кто-то уже научился инлайнить функции из скомпилированных разделяемых библиотек?
Здравствуйте, Uzumaki Naruto, Вы писали:
UN>Каждый язык имеет свою нишу и применение... настоящему программисту все равно на каком языке писать, под какую платформу и архитектуру — ибо принципы программирования идентичные для всех языков и отличаются только синтаксисом, а базовые технологии есть во всех платформах, а отличия в архитекторах нивелируются едиными типами данных... Так что вся статья — то маркетинговый берд направленный на продвижение своих продуктов...
Настоящему хирургу все равно, каким ножом резать, на каком органе и при какой болезни — ибо принципы медицины идентичны для всех болезней и отличаются только диагнозом, а базовые технологии есть в любой операционной, а отличия в архитектуре нивелируются хорошей анестезией
Здравствуйте, LaPerouse, Вы писали:
IT>>Кросплатформенность .NET — это не иллюзия, а тупое нежелание MS переносить код на другие платформы. Mono прекрасно работает и на линуксе и на андроиде. Никаких проблем с этим нет. LP>Ходят слухи, что не так уж и прекрасно.
Слухи в топку. Например, ходят слухи, что java сама по себе редкое убожество.
IT>>Почему MS не желает заниматься другими платформами для меня совершенно непонятно. LP>Это желание, стоя на Луне, притянуть к себе Землю.
Это ты так пошутил? Понял. Смешно.
IT>>В результате на сегодняшний день наблюдается стойкая тенденция не только написания сервернго кода на Java, но и переписывания существующего .NET кода на Java. Можно сказать, что рынок серверного софта в банках на сегодня для .NET потерян. LP>Думаю, такая картина наблюдается не только в банках. Нужно быть очень чудаковатым человеком, чтобы решиться писать сервер на .NET.
Ой, да ладно. Нормально всё пишется. Тоже мне рокет саинс. Тупее софта, чем серверный не бывает. Прочитал из базы, переложил в объект. Может по пути ещё чего-ниубдь умножил на два. А если на полтора, то это уже проблема. А наша java так не умеет. Может вы там у себя на клиенте на .NET это на полтора сумеете? Конечно сумеем, маленький, не плач. И на полтора сумеем, да и на два тоже, какие проблемы? Так постепенно и переезжает вся логика на клиента, а сервер в результате тупой конекшин к БД.
IT>>Удивляет то, что для одной и тоже же большой системы UI делается на .NET, Web на .NET, а сервер на Java. LP>С окончательным становлением HTML5 .NET будет выпилен и оттуда. Уже сейчас на центральное место выходят java-фреймворки, позволяющие писать html/js/ajax приложения на 100% java, причем как на клиентской (gwt), так и чисто серверной стороне (то есть весь UI-код — описание UI и обработка событий — крутится а сервере, на клиент отправляются изменения аяксом).
You wish! Пока вы там фреймворки разрабатываете энтерпрайз аккуратненько ASP.NET MVC и Silverlight осваивает.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, igna, Вы писали:
IT>>В результате на сегодняшний день наблюдается стойкая тенденция не только написания сервернго кода на Java, но и переписывания существующего .NET кода на Java. I>Надо же, а вроде ты где-то год тому назад говорил, что в банках .NET везде, нет?
На клиенте и в Web везде. Мы у себя и серверный софт на .NET пишем. Никаки проблем. Но у нас сервера свои и нам не надо никого спрашивать. А народ жалуется, что в некоторых местах пробить тупизну админов, уцепившихся за линукс просто не возможно. Для них же это погибель, нафига их столко, чтобы администрировать Windows? Вот и получается, раз линукс, значит java, т.к. MS альтернативы не предоставила.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, igna, Вы писали:
IT>>Пока вы там фреймворки разрабатываете энтерпрайз аккуратненько ASP.NET MVC и Silverlight осваивает. I>Да ведь как теперь верить-то тебе, глядишь, через год опять какие-нибудь злые админы набегут и затопчут этот ASP.
Ну прямо Красная Шапочка и Сервый Волк. А линуксоидные админы — это видимо охотники, которые тебя с бабушкой в конце сказки выковыривают из чрева злодея?
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, LaPerouse, Вы писали:
LP>Зачем нам предоставлять инструментарий для других платформ, пусть те, кто хочет использовать наши средства, ставит винду. Такова политика МС и именно ее я сравнил с попыткой притянуть Землю, стоя на Луне. По-моему, сравнение весьма уместное.
Т.е. не пошутил.
LP>Разработчику банковских систем должно быть известно, что логика на клиенте — это дыра в безопасности системы.
Не вижу здесь логики.
LP>Далее, совершенно очевидно, что чем толще клиент, тем меньше диапазон устройств, на которых он может работать (это перпендикулярно кросплафторменности — речь идет о ресурсах). Вот буквально недавно забраковали таких вот любителей толстенького — клиент выжирал до полугига оперативы и работал, мягко говоря, не быстро, причем это было обусловлено объективными причинами (то есть не было следствием кривой реализации), в результате из мобильных девайсов пользоваться им было невозможно. Заменили реализацию на 100% сервер сайд, теперь крутится везде, где есть браузер.
У вас трейдеры прямо с собственных телефонов торгуют? Впервые слышу. Что касается браузеров, то тут java точно не нужна. Это ошибка, переходите срочно на ASP.NET MVC.
IT>>You wish! Пока вы там фреймворки разрабатываете энтерпрайз аккуратненько ASP.NET MVC и Silverlight осваивает. LP>Фреймворки уже давно готовы, цветут и пахнут, в отличие от вашего Сильверлайта. Его как, похоронили уже, или до сих пор выдерживают в гробу?
Жив дурилка. И все ваши пахнущие фреймворки переживёт.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, Eugeny__, Вы писали:
E__>Ну вот, кстати, у того же Приватбанка(самый крупный коммерческий банк Украины) все рабочие станции в отделениях на линухе...
Поздравляю. А может ты с DOS перепутал?
Если нам не помогут, то мы тоже никого не пощадим.
E__>>Ну вот, кстати, у того же Приватбанка(самый крупный коммерческий банк Украины) все рабочие станции в отделениях на линухе...
IT>Поздравляю. А может ты с DOS перепутал?
Точно нет. Там вполне себе графический ASP Linux с гномом. Перепутать его с дос довольно трудно. Чтобы увидеть, достаточно зайти в любое отделение, и попросить, ну, скажем, рассказать про банковские карты. Тебя проводят в зал, где на компах операционистов все видно. Что стоит у кассиров, не знаю(кто ж меня туда пустит), но скорее всего то же самое.
Новости очень смешные. Зря вы не смотрите. Как будто за наркоманами подсматриваешь. Только тетка с погодой в завязке.
There is no such thing as a winnable war.
Здравствуйте, LaPerouse, Вы писали:
LP>Признай наконец, что ляпнул чушь.
Давай так. Ты выключишь свою демагогию, а я свою включать не буду. Договорились? Вот и славненько.
LP>Если логика вынесена на клиент, существует возможность замены это логики путем изменения клиента. Если логика на сервере, то на нее можно влиять только подбором входных данных; верификация эти данных на стороне сервера способно устранить большинство проблем.
Я не знаю в каком окружении вы работаете и какой у вас уровень доверия к пользователям, но у нас описываемые тобой проблемы отсутствуют как класс.
IT>>Так ты про энергенику. А мы тут всё больше про банки. LP>Не знаю про что вы говорите, я говорю о .net и java.
Юлишь. То ты про то, что должно быть известно разработчику банковских систем. Потом вдруг сразу "Какие еще трейдеры?". А теперь оказывается ты не знаешь про что вы говорите
LP>На RSDN была новость о том, что команду разработчиков разогнали, оставив лишь двоих для выпуска последней версии. Вот я и спрашиваю, кто же прав, о каком переходе на личности ты говоришь?
Мало ли кто где кого разогнал и по каким причинам? Ты прямо такой доверчивый, что веришь любой новости на RSDN.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, igna, Вы писали:
IT>>Я вляются и что? Boss of my boss of my boss является руководителем, но уже такого уровня, что понятиями java и .net не заморачивается. У него своих проблем выше крыши. I>Ты зубы-то не заговаривай.
Опять началось А без хамства уже никак не обойтись?
I>Суть в том, что тот, кто выбирает между Java и .NET или между MS Ofiice и, скажем, OpenOffice, знает Office по крайней мере на уровне среднего пользователя, а программирование на уровне среднего программиста — далеко не всегда.
Этот человек не занимается решением подобных вопросов. Для этого у него есть специалисты, которые предоставят ему всю информацию и все за и против.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, Философ, Вы писали:
Ф>ответил
Слабовато как-то. Ты бы хоть примерчик накидал. Если че, Windows Forms — простой враппер над WinAPI. Непонятно, чего ему быть медленнее MFC.
Про WPF даже спорить не буду. Надоело что-то объяснять "идейным".
M>>Который jQuery, тупое создание 400 чекбоксов с максимально тупым назначением событий каждому чекбоксу... И не тормозит. Более того, создание аналогичного в каком-нить ExtJS тоже не будет тормозить. M>>Но нет, в WPF это низзя ни в коем случае, вы шо. Нужно в обязательном порядке делать собственный контрол на каждый чих? Где эти чихи начинаются? На 20 чекбоксах? На 30? MM>Потому что WPF плохо работает в таких сценариях. Никто же не говорит, что это панацея на все случаи жизни. Надо понимать, нужны ли тебе бенефиты WPF (шаблоны, масштабируемость, биндинги, эффекты).
Стопстопстоп. Отрисовка грида с 20x20 чекбоксов — это настолько сложня задача, что вся выделенная хрень не может с этим справится?
Здравствуйте, Mamut, Вы писали:
M>>>Который jQuery, тупое создание 400 чекбоксов с максимально тупым назначением событий каждому чекбоксу... И не тормозит. Более того, создание аналогичного в каком-нить ExtJS тоже не будет тормозить. M>>>Но нет, в WPF это низзя ни в коем случае, вы шо. Нужно в обязательном порядке делать собственный контрол на каждый чих? Где эти чихи начинаются? На 20 чекбоксах? На 30? MM>>Потому что WPF плохо работает в таких сценариях. Никто же не говорит, что это панацея на все случаи жизни. Надо понимать, нужны ли тебе бенефиты WPF (шаблоны, масштабируемость, биндинги, эффекты). M>Стопстопстоп. Отрисовка грида с 20x20 чекбоксов — это настолько сложня задача, что вся выделенная хрень не может с этим справится?
Не понял. А причем здесь влияние "выделенной хрени"? Биндинги к рендерингу вообще никак не относятся... Ладно, давай по другому напишу. Когда ты создаешь чекбоксы средствами HTML, то по сути ты говоришь браузеру отрендерить чекбоксы. Причем набор вариантов ограничен допустимыми значениями тега type и слабыми возможностями влияния на внешний вид чекбокса. В результате браузеру не нужно особо напрягаться. Он видит всю картину — столько-то чекбоксов на такой-то площади экрана. Он заранее знает, как это оптимизировать, ведь внешний вид вполне себе фиксирован... Теперь берем WPF. Каждый чекбокс оказывается отдельным контролом. Контрол поддерживает шаблоны, предугадать его внешний вид нереально. Я могу туда хоть таб-контрол запихнуть! Целостной картины тоже нет. Всё это впихнуто в грид, который тоже контрол со своими заморочками. Свободы для оптимизации значительно меньше. Зато фич по кастомизации больше. За них и платим.
Здравствуйте, Mamut, Вы писали:
M>Это все — демагогия, пытающаяся прикрыть отмазки, пытающиеся прикрыть кривизну реализации. Ничего из описанного даже близко не объясняет, почему грид с 20x20 чекбоксами тормозит.
Блин, а я старался. Ну, хорошо, демагогия так демагогия.
Здравствуйте, Sheridan, Вы писали:
F>>легко собирается, если нет привязок к винде или не-дотнет штукам.. F>>даже я писал на шарпах под линухом, а потом запускался под виндами.. S>А наоборот?
а разница? ты хочешь докопаться до мелкомягкой реализации, мол она всякий левый шлак пихает в бинарник?
наоборот тоже работает..
M>>>>Ты будешь возражать, что найдутся проекты, которые не собираются под gcc, но собирающиеся под Microsoft C++ compiler и наоборот? S>>>Нет
M>>Так в чем вопрос? Mono и MS .net Framework реализуют один и тот же стандарт. В MS .net Framework просто дополнительные windows-зависимые библиотеки. Так же, как есть платформо-зависимые библиотеки для С++
M>>Но я повторяюсь. Это все было пройдено два-три года тому назад.
S>И тогда же мы выяснили что моно — кроссплатформенен, а дотнет — нет.
Это выяснил ты. Но то, что выясняют для тебя твои фантазии, ничего общего с реальностью не имеет. Это мы тоже выяснили. Более того, уже в этом топике тебе несколько человек написало примеры, что твои фантазии ничего общего с реальностью не имеют, я в очередной раз по кругу написал тебе, что ситуация ничем не отличается от С++, но ты, судя по всему, так и не вылазишь с ех маковых полей, которые ты так упорно всем приписываешь.
Умный человек так и не ответил на поставленный самому себе вопрос: "Зачем распространять скомпилированные программы в виде IL?"
Мистер Кэп подсказывает, что есть общепринятое объяснение — это кроссплатформенность бинарного кода, оптимизации под конкретный процессор (в теории), и profile-based оптимизации.
Вместо этого Умный человек рассказывает про Intermediate Language и разделение на frontend/backend — то, что начали использовать ещё чуть ли не с 60-х годов.
Кстати, я вот не однократно замечаю, что многие люди в спорах типа Java или .Net против Native зацикливаются на байткоде. Т.е. одни говорят что это самое классное, а другие на оборот ругают его... В то время как на мой взгляд это вообще ерунда. И кстати появление llvm это только подтверждает. Принципиальное отличие Java и .Net от нативных языков в том, что они по сути испольняются в своей виртуальной машине, которая накладывает огромные ограничения. А вот в каком виде у нас код не имеет особого значения. В отдельных случаях удобнее байткод просто, в каких-то байткод с jit, а в каких-то и машинные коды. И это по идее одинаково должно быть для всех языков и платформ. Просто в зависимости от специализации языка какие-то направления у него могут быть слабее развиты.
Ты пойми, совершенно фиолетово, что там стандартизировано, а чего нет. Когда речь идет о переносимости фреймвока так и нужно говорить о фреймвоке, а не той его части на которую распространяется стандарт. Иначе ваши слова есть ни что иное как лукавство.
M> Осталось понять, что имеет в виду Шеридан, когда говорит «дотнет». Дальше — по ссылке
Ой, да перестань. Не нужно делать вид, будто ты не понимаешь, что когда говорят .NET имеется ввиду платформа Microsoft .NET, с её полным названием Microsoft .NET Framework.
_>Да, кое-какие небольшие плюсы от неё есть. Помню как меня порадовала возможность динамической загрузки классов в программу, когда я впервые стал смотреть на Java. Но все они являются как бы не уникальными — в нейтиве всё тоже самое возможно, просто с помощью отдельных технологий (типа COM например).
Ну, ставить com и динамическую подгрузку классов в жабе(а там еще и класслоадер можно заменить — иногда это такие возможности дает) — это глупость. Ком — это действие вслепую, и вообще дикий костыль.
Новости очень смешные. Зря вы не смотрите. Как будто за наркоманами подсматриваешь. Только тетка с погодой в завязке.
There is no such thing as a winnable war.
.
M> M>> H>Ой, да перестань. Не нужно делать вид, будто ты не понимаешь, что когда говорят .NET имеется ввиду платформа Microsoft .NET, с её полным названием Microsoft .NET Framework.
M> M>> Нет, не понимаю.
M> H>Тяжело тебе...
M> Тяжело вам, что вы не можете внятно объяснить, что вы хотите, и что вам нужно.
Да я более чем внятно все объяснял, даже ссылку на вики давал (поверь, там описано все очень внятно). Я думаю тут есть явное нежелание сторонников дотнета признать тот простой факт, что он не кроссплатформенен (хотя чего в этом страшного мне не понятно С++ вот тоже не, но плюсистам лабающим кросс на это пох)
НС>In addition to this tracking and updating mechanism, NGen now also supports deferred commands. This means that if you want to use NGen with a large application (which may take a significant amount of time to complete), you can queue this command to be completed by the new NGen service. The NGen service is a true Windows® service process that runs in the background and waits for idle time on the machine, at which point it will complete any outstanding compilation jobs that have been waiting in the queue.
Я такие сервисы убиваю нвсегда по обнаружении. А также всякие updater, cache и прочую ересь. И тех, кто их не спросив разрешения у юзера ставит считаю ярчайшими представителями сексуальных меньшинств в плохом смысле.
Здравствуйте, Ночной Смотрящий, Вы писали:
_>>- кривой вызов системных функций НС>Что значит кривой?
Через маршалинг.
_>> и невозможность прямого вызова функций из известных 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, как говорит автор.
Здравствуйте, 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 для разных платформ имеет одно и то же АПИ. А у меня сходу ни одно приложение для дотнета на Моно не идет. Т.е. это надо забыть про дотнет и разрабатывать под Моно даже на виндах, чтобы получилось кроссплатформенно. Поэтому слово "дотнет" из своего обзора убери. Дотнет НЕ кроссплатформенный ни разу.
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
Здравствуйте, gandjustas, Вы писали:
G>>>Кроссплатформенность нужна исчезающе малому проценту вендоров ПО. V>>Очередной отжиг. Вне дотнета жизни нет? G>Если учесть что 90% компов — windows, то можно считать что нету.
Дык, и на windows дотнета нету фактически. Тебе просто из подвала не видно. Он есть только в небольшой части внутри небольшого сегмента сугубо заказного ПО.
G>Из оставшихся 10% большая часть маки, там тоже кроссплатформенный софт не жалуют.
Ага, и >60% серверов на юниксах... Выбери синюю или красную и проснись, наконец.
Здравствуйте, vdimas, Вы писали:
V>Здравствуйте, gandjustas, Вы писали:
G>>>>Кроссплатформенность нужна исчезающе малому проценту вендоров ПО. V>>>Очередной отжиг. Вне дотнета жизни нет? G>>Если учесть что 90% компов — windows, то можно считать что нету. V>Дык, и на windows дотнета нету фактически. Тебе просто из подвала не видно. Он есть только в небольшой части внутри небольшого сегмента сугубо заказного ПО.
И что? Поставить проблема?
G>>Из оставшихся 10% большая часть маки, там тоже кроссплатформенный софт не жалуют. V>Ага, и >60% серверов на юниксах... Выбери синюю или красную и проснись, наконец.
А накой там кроссплатформенность?
Здравствуйте, gandjustas, Вы писали:
G>Здравствуйте, vdimas, Вы писали:
V>>Здравствуйте, gandjustas, Вы писали:
G>>>>>Кроссплатформенность нужна исчезающе малому проценту вендоров ПО. V>>>>Очередной отжиг. Вне дотнета жизни нет? G>>>Если учесть что 90% компов — windows, то можно считать что нету. V>>Дык, и на windows дотнета нету фактически. Тебе просто из подвала не видно. Он есть только в небольшой части внутри небольшого сегмента сугубо заказного ПО. G>И что? Поставить проблема?
При чём тут поставить, когда его не использует разработчик ПО?
G>>>Из оставшихся 10% большая часть маки, там тоже кроссплатформенный софт не жалуют. V>>Ага, и >60% серверов на юниксах... Выбери синюю или красную и проснись, наконец. G>А накой там кроссплатформенность?
В Unix мире кроссплатформенность — норма. Типичный софт рассчитывается как минимум на Linux, Solaris и FreeBSD.
V>>Потому что кривая либа. Потому что "изкаробки" работает плохо. Не умеет, не предусмотрено, не учли и т.д. V>>На самом деле для WPF достаточно лишь представлять себе внутренний поток событий, в первую очередь событий лейаута, сериализацию его для проигрывания на нейтивной стороне, чтобы заведомо знать, что стоит на WPF делать, а чему лучше поискать альтернативу. Там же можно захостить обычное WinForms-окошко а на нем DirectX. А рисовать графики в DirectX всяко не сложнее, чем в WPF, скорее наоборот. Т.е. это уже какая-то косность мышления, похоже... MM>В последнем нашем споре о WPF оказалось, что, хотя ты и весь из себя такой инженер, но легко забиваешь на факты, делая выводы, основанные на незнании
Давай конкретно, что там не так? Если ты про то, что по памяти перепутал public/protected в той ветке, то это что в том споре не принципиально, что в этом (тем более, что даже если бы это было так, то это легко обыгрывается, в отличие от остального).
MM>Также и сейчас ты пытаешься сыграть аналогично, сказав "бла-бла-бла, всё проще делать на DirectX". При этом тебя, вроде бы инженера, почему-то не волнуют ни требования, которые я привел выше, ни проблемы интеграции WinForms и DirectX с WPF, ни поддержка этих решений, как с точки зрения наличия программистов со знанием DirectX, так и наличия соответствующего DirectX на ОС заказчика.
Ну тогда и я предположу, что всё что ты тут разводишь сейчас — это бла-бла от незнания. Вернее, от банальной лени и нежелания посмотреть по сторонам, даже в рамках самого дотнета... бо WPF требует вполне конкретную версию DirectX. И ровно эта же версия DirectX обернута через DirectX managed и вы можете включать этот модуль в инсталляцию. И ровно эта же версия DirectX стоит у заказчика обязательно, просто потому что идет вместе с осью, начиная с WinXP и ее современными сервис-паками. Ну и должно было хватить начальной эрудиции чтобы вспомнить, что COM тоже через интерфейсы умеет отвязываться от конкретной реализации и конкретного положения либ на машине заказчика, т.е. даже имея тонну различных минорных версий 9-го DirectX у различных заказчиков, вас это беспокоить было ничуть не должно.
И да, если DirectX идет как дотнетная либа со всей документацией в MSDN (MSDN — лучшая дока в мире де-факто), то какое именно знание DirectX еще требуется? Вы вообще разработчики или погулять вышли?
MM>Так что, я думаю, поставь-ка ты мне снова минус-рожицу, и разговор можно считать закрытым.
Эээ... да у тебя каждый разговор так. Даже по ссылке по предмету обсуждения (обсуждалась сложность расширения инфраструктуры) тебе не удалось возразить по приведенным фактам. Ну и мой ответ там тебе вполне в тему, ознакомься.
Просто ты непроизвольно в каждом обсуждении пытаешься скатываться на одну и ту же мантру, что мол в WPF "изкаробки всё есть". А это невозможно принципиально ни для какой библиотеки/фреймфорка, вот и приходится одергивать. ИМХО, важнее для либ-фреймворков возможность/трудоемкость самостоятельного расширения функциональности... И если спустя столько лет нечего возразить по этому вопросу, то зачем же снова и снова с завидной регулярностью пишешь свои заклинания: "просто его надо хорошо знать". Конечно надо знать, с чем работаешь, что за банальности? Но верно и другое: надо знать, какие либы/технологии для чего нужны, тем более, что это уже не раз обсуждалось т.е. инфы полно. Форум "Мультимедиа" читаешь? Нет? (судя по реакции на "DirectX") А стоило бы разработчику WPF, бо WPF именно что претендует на мультимедиа-задачи...
В общем, это я и имел ввиду насчет косности мышления: выучили одну либу из донета и пихаем ее куда надо и куда не надо, мужественно преодолевая трудности. Зачем?
Здравствуйте, MxMsk, Вы писали:
MM>с точки зрения наличия программистов со знанием DirectX
Пардон, освоить сабсет функций DX, нужный для рисования графиков, можно за день.
MM> так и наличия соответствующего DirectX на ОС заказчика.
На винде начиная с WXP стоит DX 9.0
Все старшие версии включают поддержку младших.
В DX 10,11 для рисования графиков нет ничего революционно нового.
В чём проблема то?
Здравствуйте, Трололоша, Вы писали:
MM>>с точки зрения наличия программистов со знанием DirectX Т>Пардон, освоить сабсет функций DX, нужный для рисования графиков, можно за день.
Прикинул, в принципе я тоже могу выучить наизусть 10 функций из любого API за один день. Жаль, что этого недостаточно для качественный разработки.
MM>> так и наличия соответствующего DirectX на ОС заказчика. Т>На винде начиная с WXP стоит DX 9.0 Т>Все старшие версии включают поддержку младших. Т>В DX 10,11 для рисования графиков нет ничего революционно нового. Т>В чём проблема то?
Если эта оценка, как и предыдущая, сделана "за 1 день", то наверняка по факту траблов хватит. Но можешь вычеркнуть.
Здравствуйте, alex_public, Вы писали:
_>Так RAII то нужен везде, а не в одном узком месте. В том смысле что должна формироваться (автоматических, без работы программиста) цепочка деструкторов сквозь всё приложение, а не один маленький unsafe класс.
Серъёзно что ли? А мне вот как раз кажется, что детерминистическая финализация мало где нужна. _>Да и другие вещи типа работы с памятью и вызова системных функций тоже обычно не в одном месте требуются.
Ну, вот как раз работа с памятью в управляемой среде сделана хорошо. RAII нужен там, где в дотнете применяют IDisposable. А его по факту очень немного. И как раз для его упрощения в MC++ сделано вполне всё по уму.
_>Конечно если заниматься только рисованием формочек (хотя как выяснилось в этой теме, тут тоже не всё так просто — 20х20 чекбоксов уже не тянем ), то совсем другое дело — тут можно обойтись только safe кодом.
Впрочем, как сразу же выяснилось в этой же теме, 20x20 чекбоксов вполне себе тянем — тормоза воспроизвести в студии не удалось.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Eugeny__, Вы писали:
E__>JNI там и в помине не было. Устройства подключаются к ком порту, и открываешь его просто как файл. Причем единообразно в винде и линухе(кроссплатформенные дрова получились, хехе). Ну или usb, но с эмуляцией ком порта(отличается только тем, что нужно открыть не /dev/ttySх, а /dev/ttyUSBx, в винде просто номер кома 10+). Ком-порт, если что, до сих пор стандарт в области всяких финансовых девайсов(и слава яйцам).
Ну так значит драйвер тут у нас в самой ОС есть — ничего писать не надо. А пишем обычную прикладную программу. Если там нет больших потоков данных (ну собственно т.к. ком-порт, то уже понятно что нет), то без разницы на чём писать. Что на C++, что на Java, что на Питоне. Точнее всё зависит от квалификации сотрудников. )))
Здравствуйте, Eugeny__, Вы писали:
E__>Ну, программу, которая общается с устройством на уровне специфического бинарного протокола, я бы не назвал прикладной.
Ну, тут можно развести полемику, но это всё равно не драйвер.
Здравствуйте, gandjustas, Вы писали:
V>>>>Да че ты так к UI привязался? Платформенно-независимого UI хоть попой ешь. G>>>Только от него тянет блевать. Он везде одинаково плохо выглядит. N>>Критерии плохости в студию, пожалуйста. G>Несоответствие гайдлайнам интерфейсов системы.
Интересно, почему это у тебя всего лишь несоответствие гайдлайнам сразу вызывает желание блевать? Меня скорее на такое потянет из-за конкретного стиля интерфейса (как происходит, например, в случае Aero, Metro, Unity и вообще этой странной новой волны), но не просто из-за несоответствия.
N>>И критерии ненужности — сюда же. G>Несоответствие гайдлайнам интерфейсов системы.
Это критерий ненужности?
G>Неиспользование возможностей системы (таскбар в Win7 напрмиер)
Я не знаю, чем в ней taskbar отличается от других, хотя бы от XP, так что прошу рассказать. А с другой стороны, нужно ли его как-то явно использовать? Чем плохи те средства, что работали раньше?
И почему ты в таком случае не обрушиваешься на программы, написанные для XP или 2000? Они кошерные по определению?
G>>>Да, детка, покажи мне api для WP7 N>>А она кому-то реально нужна? G>Нужна. Люди то покупают. Процент WP7 на рынке телефонов больше чем процент никсов на рынке десктопов
А вот соседи по теме говорят, что этот процент (WP7) исчезающе мал. В то время как Unix-системы на десктопах — обычная ситуация в ряде корпораций, в университетах... то есть по крайней мере у них есть устойчивая ниша, которая ещё долго будет жить даже если развалится (ой не верю).
И количество средств под неё — не кроссплатформенных! — например, зрелых и пригодных к работе window managers — достаточно, чтобы не верить в её отсутствие. Вон даже мой любимый wmaker после почти 10 лет застоя (когда он был полностью пригоден к работе и без проблем, просто не было причины развивать!) начал развиваться на свежие фичи...
N>>Я бы ещё понял запрос на что-то с поддержкой одновременно Android, Windows 8 и iPad'овскую ось (не помню, как зовётся), но WP7 — это за гранью разумного со всех сторон... G>Тем не менее на .NET можно написать код, который после компиляции одинаково заработает на всех указанных платформах. На других языках это невозможно.
И что, он одним и тем же кодом будет работать, например, с таскбаром Win7 и треем wmaker'а или гнома?
G>Полезность этого кода под вопросом конечно, но самой возможности это не отменяет.
Ты сам сверху вспоминал про "неиспользование возможностей" и приплёл таскбар Win7. Если написать на дотнете код, который "после компиляции одинаково заработает на всех указанных платформах", то он в принципе будет неспособен использовать тот же таскбар. И в чём разница?
Здравствуйте, netch80, Вы писали:
n> H>Эт почему? У меня с 3G-модемом общается вполне себе прикладная софтина, уж точно не драйвер нихрена
n> Драйвер — её компонент. n> Драйвер не обязан быть ядерным. Во многих случаях (как USB) в разы проще делать драйвер в userland.
Драйвер обеспечивает функционирование устройства (и никакого отношения к софтине не имеет вообще), а прикладуха общается с девайсом для своих чисто утилитарных нужд. Какой же она драйвер...
Здравствуйте, Ночной Смотрящий, Вы писали:
E__>>>JNI там и в помине не было. Устройства подключаются к ком порту, и открываешь его просто как файл. Т>>Нууу. Это сложно назвать драйвером. НС>Точно. Крутые перцы, они из кернелмоды не вылазят. А обезьянки драйверов не могут, да.
Дело не в кернелмоде. Тут путаница понятий между прикладной программой и драйвером.
Т>>Настоящий дравер там сидит ниже НС>Ага, точно.
Еслиб он вешался сверху на порт и наружу выставлял бы в паблик какой либо более высокоуровневый API то да, был бы драйвер. А так получается просто какой то wrapper над протоколом для конкретного приложения.
Здравствуйте, Ночной Смотрящий, Вы писали:
V>>Можно, но ведь не берут, бо как-то не сложилась дотнетная культура НС>Или потому что не особо нужно. Там где таки нужно — берут.
А какой критерий нужности-то? Ведь дотнетного легаси кода считай что и нет еще, т.е. нужность/ненужность одинаковая для любых платформ. В общем, для новых разработок любое решение в плане их выбора всегда волевое на чьей-то ответственности. В плане GUI в т.ч.
НС>Все общие библиотеки по АПИ идентичны. Если есть расхождение — это бага.
V>>Список отличий трекается и постоянно обновляется.
НС>Все действительно серьезные и частые проблемы уже вычистили.
Давно? Еще года три назад не было многих библиотек или частей библиотек, даже некоторых частей System.dll. Например, SocketAsyncEventArgs уже работает?
V>> Если ориентируемся на меньшее подмножество АПИ, то значит именно под него ведем разработку. НС>У меня есть весьма большие проекты, где никто ни на какое подмножество никогда не ориентировался. Тем не менее на Моно спортировалось без урезания функционала и переписывания больших кусков.
И? Я вежливо проигнорировал в прошлый раз, не заметил?
Большие-небольшие понятие условное с т.з. задействованных технологий. Бухгалтерские системы тоже очень большие порой, а набор используемых технологий `уже некуда вдоль всей системы.
Конкретно мне пришлось переделывать сетевую часть (вернее, писать свою).
V>> Т.е. Visual Studio выступает уже не как целевой tool-chain, а как удобный редактор кода.
НС>Все там нормально со студией. Для Моно студия по прежнему остается основной IDE. Потому что, во-первых, никто не обязывает использовать моновские компиляторы, а во-вторых и для моновского компилятора есть интеграция в студию (см. Mono tools for VS).
Ага, пару лет назад выпустили... Так я этих вещей и не дождался. А сейчас уже не принципиально, бо хватает уже других зрелых IDE под C# или плагинов под известные IDE.
Здравствуйте, Cadet, Вы писали:
C>Так все же, давай выясним какая часть некросплатформенна-то? А то вот я сейчас напишу на шарпе программу, и под линухом и под виндами ее скомпилю и запущу. Что мы имеем в виду под кроссплатформенностью? Кроссплатформенность на уровне сырцов, бинарей или еще чего-то? Плюсовый вот на уровне сырцов кроссплатформенный, частично правда, так же как и шарповый код. Тока тут под платформой следует понимать скорее не windows/linux, в .net/mono. При соблюденнии определенных правил и использовании определенных либ шарповый код переносим между .net и моно платформами, следовательно будет работать везде, где будет одна из этих платформ. Найдите отличия от джавы или плюсов.
Ооо, всё очень просто. Дело в том что системы типа Java, .Net и т.п. работают через своебразную виртуальную машину. Соответственно им кроме "кроссплатформенности кода" (как в C++) требуется дополнительное условие — наличие на целевой платформе движка этой виртуальной машины.
Кстати, у Java это условие выполняется для очень многих платформ.
Ну и есть ещё отдельный интересный нюанс с GUI — многим не нравится когда у ПО не родной интерфейс платформы. Соответственно тут надо ещё договориться что называть кроссплатформенным: то что просто работает везде или то что согласны принимать пользователи везде. )))
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>>>Тем не менее он лидер. V>>Исторически. НС>Ну то есть таки я прав?
Для относительно новых разработок — конечно нет. Относительно новые, это которым порядка 10-15 лет или менее. С++ уже давно в лидерах среди таких проектов.
Здравствуйте, Kingofastellarwar, Вы писали:
K>тогда нафига весь этот огород? K>а если просто представить, что не нада было заморачиваться платформонезависимостью, но реализовать лучшие наработки в области сематники и базовых либ? K>код запускался бы сразу без JIT компиляции и тормозов с ней связанной и можно было бы делать реальную оптимизацию кода компилятором выжимать максимум.
Ты серьезно думаешь, что JIT-компилер нужен только для мультиплатформенности?
Здравствуйте, Kingofastellarwar, Вы писали:
K>ну только не смешите меня песнями про оптимизацию под платформу, это беда жит, а не его достоинство.
Я так думаю, что именно для этого она и задумывалась — типа компиляция для того проца, который сейчас установлен. Однако, практика показала, что решения без JIT быстрее, а там, где нужна оптимизация под проц, она делается руками.
K>или для динамической компиляции? а кто ее использует?
а вот про динамическую компиляцию — зря, ибо хорошая штука.
однако всё запихивать под JIT — глупо.
Всё сказанное выше — личное мнение, если не указано обратное.
Здравствуйте, Uzumaki Naruto, Вы писали:
K>>рассмотрим на примере только дотнета, я его лучше всего знаю, а проблемы у его собратьев такие же. UN>Рассмотрим на примере java... все работает прекрасно на всех платформах...
Кроме iPhone.
UN>Рассмотрим правильное кроссплатформеное программирование под С/C++ — все прекрасно компилируется под любые платформы — от PC до мобильных...
Кроме WinPhone.
Здравствуйте, Kingofastellarwar, Вы писали:
UN>>Рассмотрим на примере java... все работает прекрасно на всех платформах... K>прекрасно это как? я лично не видел ни одного приложения на жаве, которое прекрасно работало хотя б под линухом, вендой и макосью.
Показать?
Здравствуйте, quwy, Вы писали:
Q>>>Для контроля выполнения и уборки мусора. Все остальное -- неизбежное следствие. K>>так для этого жит компиляция не нужна Q>Можно и интерпретатором, только это еще хуже.
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, Uzumaki Naruto, Вы писали:
K>>>рассмотрим на примере только дотнета, я его лучше всего знаю, а проблемы у его собратьев такие же. UN>>Рассмотрим на примере java... все работает прекрасно на всех платформах... C>Кроме iPhone.
Здравствуйте, Kingofastellarwar, Вы писали:
K>код запускался бы сразу без JIT компиляции и тормозов с ней связанной и можно было бы делать реальную оптимизацию кода компилятором выжимать максимум.
Чем позже делается компиляция -- тем больше возможностей для оптимизации. Не зря в GCC LTO придумали.
Здравствуйте, Философ, Вы писали:
K>>ну только не смешите меня песнями про оптимизацию под платформу, это беда жит, а не его достоинство.
Ф>Я так думаю, что именно для этого она и задумывалась — типа компиляция для того проца, который сейчас установлен. Однако, практика показала, что решения без JIT быстрее, а там, где нужна оптимизация под проц, она делается руками.
Если брать ту же Java, проблема её производительности, я думаю, совсем не из-за байткода. Вон тот же LLVM с правильно выбранным языком генерирует вполне нормальный код (ну, пока отстаёт местами от GCC, но сколько лет LLVM, а сколько GCC?). Проблема в том, что JVM задаёт очень фиксированную модель выполнения, на которую прикладные задачи накладываются не оптимально. Добавь сюда ещё проверки в рантайме и жор памяти для поддержки всей этой системы и получишь тормоза.
K>>а самым реально мультплатфоменнным оказался в итоге Си с С++ом
G>Ты хочешь сказать что можно раз скомпилировать код на C\C++ и запускать везде? Что-то я сомневаюсь что у тебя так выйдет.
Ну с LLVM вполне реально, пока скорее в теории, на практике только недостаток библиотек не дает.
Здравствуйте, Uzumaki Naruto, Вы писали:
K>>>>рассмотрим на примере только дотнета, я его лучше всего знаю, а проблемы у его собратьев такие же. UN>>>Рассмотрим на примере java... все работает прекрасно на всех платформах... C>>Кроме iPhone. UN>http://iphoneroot.com/RU/tutorial-install-java-on-the-iphone/
Это не нормальная Java.
UN>>>Рассмотрим правильное кроссплатформеное программирование под С/C++ — все прекрасно компилируется под любые платформы — от PC до мобильных... C>>Кроме WinPhone. UN>Си-код компилируется в llvm байткод с помощью clang (это полноценный С/С++ компилятор, совместимый по ключам с gcc).
И причём тут WinPhone?
Взломанные телефоны не считаются. Мы же говорим об установке нашего софта у пользователя, а не у себя.
C>>Кроме WinPhone.
UN>Си-код компилируется в llvm байткод с помощью clang (это полноценный С/С++ компилятор, совместимый по ключам с gcc).
Эммм, и что нам делать с llvm кодом на winphone? )
Здравствуйте, gandjustas, Вы писали:
G>Ты хочешь сказать что можно раз скомпилировать код на C\C++ и запускать везде? Что-то я сомневаюсь что у тебя так выйдет.
Ну в данный момент нет. Но если допустим на каждой платформе будет стоять исполнитель llvm кода, то и C++ может стать похожим на Яву. ))) Хотя не факт что оно нужно.
G>Например кроссплатформенность в виде "компилируем раз — запускаем везде" не работает нигде. Даже java, изначально заточенная под такой сценарий, так работать не будет.
Да вроде работает. ))) Хотя и тормознуто и с кривым интерфейсом.
G>Второй вариант — "программа под любую платформу собирается из одного набора исходников". Такое похоже на правду, НО есть платформенно-зависимый код, есть UI, который чаще всего надо проектировать под каждую платформу отдельно.
Не надо, если выбрать правильные библиотеки. У нас вот кроссплатформенный продукт и "платформенных ifdef'ов" там на весь проект пара штук.
G>Третий вариант — "программные библиотеки, без UI и платформенно-зависимых вещей собиратся для любой платформы из одного набора исходников".
G>Так в этом случае кроссплатформенными являются и Java, и .NET, и C++.
G>Причем .NET опережает всех ибо работает на Windows, Linux(Mono), MacOS(Mono), iOS (MonoTouch), Adndroid (MonoDroid), WP7, Web (Silverlight, компиляция в js), XBox, embedded (.NET MicroFramework)
G>>Например кроссплатформенность в виде "компилируем раз — запускаем везде" не работает нигде. Даже java, изначально заточенная под такой сценарий, так работать не будет. _>Да вроде работает. ))) Хотя и тормознуто и с кривым интерфейсом.
Ага, запусти на мобилке то что написано для десктопа.
G>>Второй вариант — "программа под любую платформу собирается из одного набора исходников". Такое похоже на правду, НО есть платформенно-зависимый код, есть UI, который чаще всего надо проектировать под каждую платформу отдельно. _>Не надо, если выбрать правильные библиотеки. У нас вот кроссплатформенный продукт и "платформенных ifdef'ов" там на весь проект пара штук.
Это будет третий вариант
G>>Третий вариант — "программные библиотеки, без UI и платформенно-зависимых вещей собиратся для любой платформы из одного набора исходников". G>>Так в этом случае кроссплатформенными являются и Java, и .NET, и C++. G>>Причем .NET опережает всех ибо работает на Windows, Linux(Mono), MacOS(Mono), iOS (MonoTouch), Adndroid (MonoDroid), WP7, Web (Silverlight, компиляция в js), XBox, embedded (.NET MicroFramework) _>Ага, только оно такое не нужно никому. )))
А потому что кроссплатформенность нафиг никому не упала.
Это тупо флаг, которым размахивают вендоры. Реальная польза от кроссплатформенности для конечного пользователя нулевая, если не отрицательная.
Здравствуйте, Kingofastellarwar, Вы писали:
K>рассмотрим на примере только дотнета, я его лучше всего знаю, а проблемы у его собратьев такие же.
K>изначальная идея "компилируем раз — запускаем везде" давала надежду, но не только по маркитенговым, но и техническим причинам оказалось, что K>приемлемом уровне это сделать сложно, в итоге все жавы и дотнеты оказались очень даже одно платформенными.
Мухи — отдельно, котлеты — отдельно. Дотнет писан МС-ом, и реальная мультиплатформенность им не нужна. Жаба очень даже мультиплатформенна, и проектов на ней, где это пригождается очень и очень много. В основном это энтерпрайз, но все-таки.
Новости очень смешные. Зря вы не смотрите. Как будто за наркоманами подсматриваешь. Только тетка с погодой в завязке.
There is no such thing as a winnable war.
M>>Брось и не начинай. Это уже было пройдено по кругу минимум два раза.
S>Покажи мне как из исходников, требующих дотнет, соберется приложение под линух+моно. Например вот тебе хоть ВороньяБД
Покажи мне, как из "кроссплатформенного" Qt соберется даже простейшее приложение под Windows или МакОС, если следовать, например, туториалу. Ну или приложение типа такого, такого или такого.
Здравствуйте, Sheridan, Вы писали:
S>В принципе отчасти ты прав. В силу своей кроссплатформенности моно несколько более жив, чем дотнет. Но до тогоже ц++ далеко обоим.
Твои попытки потролить .NET ничтожны.
Если нам не помогут, то мы тоже никого не пощадим.
M>>Брось и не начинай. Это уже было пройдено по кругу минимум два раза.
S>Покажи мне как из исходников, требующих дотнет, соберется приложение под линух+моно. Например вот тебе хоть ВороньяБД
Здравствуйте, Mamut, Вы писали:
M>>>Брось и не начинай. Это уже было пройдено по кругу минимум два раза.
S>>Покажи мне как из исходников, требующих дотнет, соберется приложение под линух+моно. Например вот тебе хоть ВороньяБД
M>Покажи мне, как из "кроссплатформенного" Qt соберется даже простейшее приложение под Windows или МакОС, если следовать, например, туториалу. Ну или приложение типа такого, такого или такого.
Ты сравниваешь зеленое с громким. Я говорю о том что моно != дотнет и в качестве примера привожу сырец на дотнет, предлагая его собрать под моно.
Ты отчегото, видимо устав за день головой, предлагаешь мне зачемто собрать под виндами приложения, заточенные под линух. Ибо ввиндах нет понятия "сменить dm", не нужен вайн.
К тому же YaRock скорее всего соберется ибо пхонон это чать кутэ а не чтото внешнее. Впрочем, оно еще хочет libtag1 — лень смотреть в нее, есть вероятность что все получится.
Кстати, Antico тоже скорее всего соберется, ибо кроме кутэ ничего больше не хочет в зависимости.
M>Хотя твой ответ, безусловно, предсказуем.
Не спеши.
S>Ты сравниваешь зеленое с громким. Я говорю о том что моно != дотнет и в качестве примера привожу сырец на дотнет, предлагая его собрать под моно. S>Ты отчегото, видимо устав за день головой, предлагаешь мне зачемто собрать под виндами приложения, заточенные под линух. Ибо ввиндах нет понятия "сменить dm", не нужен вайн.
Тогда почему же ты предлагаешь мне скомпилировать приложение, заточенное под винду?
Хотя, как оказалось, RavenDB вполне себе бегает на Mono, то есть никаких препятствий к тому, чтобы его можно бло собирать под Mono, нет. И какой-то скрипт все же существует. Видно, что процесс сборки включает в сбя всякие доп. тулзы, которых в Линуксах может и не быть. Ах, какая досада. Ведь для того же сверхсуперпупуркроссплатформенного С++ всегда все тулзы доступны для всех платформ, агагагага.
Здравствуйте, Sheridan, Вы писали:
S>Здравствуйте, Mamut, Вы писали:
M>>Так как это было обсосано два-три года тому назад, ссылки (на удивление мало тебя): M>>http://rsdn.ru/forum/flame.comp/3899857.1.aspx
Здравствуйте, Иван Дубров, Вы писали:
Ф>>Я так думаю, что именно для этого она и задумывалась — типа компиляция для того проца, который сейчас установлен. Однако, практика показала, что решения без JIT быстрее, а там, где нужна оптимизация под проц, она делается руками.
ИД>Если брать ту же Java, проблема её производительности, я думаю, совсем не из-за байткода. Вон тот же LLVM с правильно выбранным языком генерирует вполне нормальный код (ну, пока отстаёт местами от GCC, но сколько лет LLVM, а сколько GCC?). Проблема в том, что JVM задаёт очень фиксированную модель выполнения, на которую прикладные задачи накладываются не оптимально. Добавь сюда ещё проверки в рантайме и жор памяти для поддержки всей этой системы и получишь тормоза.
А вы можете продемонстрировать тормоза Java, вызванные ограниченной моделью выполнения? В сравнение с С++ (поэтому несравнимое, вроде GC vs new/delete сранивать не надо).
Здравствуйте, Mamut, Вы писали:
S>>Ты сравниваешь зеленое с громким. Я говорю о том что моно != дотнет и в качестве примера привожу сырец на дотнет, предлагая его собрать под моно. S>>Ты отчегото, видимо устав за день головой, предлагаешь мне зачемто собрать под виндами приложения, заточенные под линух. Ибо ввиндах нет понятия "сменить dm", не нужен вайн.
M>Тогда почему же ты предлагаешь мне скомпилировать приложение, заточенное под винду?
Под дотнет.
M>Хотя, как оказалось, RavenDB вполне себе бегает на Mono, то есть никаких препятствий к тому, чтобы его можно бло собирать под Mono, нет. И какой-то скрипт все же существует.
Я взял первый попавшийся проект, наугад. Или ты будешь возражать что найдутся дотнет проекты не собирающиеся под моно и наоборот?
Здравствуйте, Mamut, Вы писали:
M>Здравствуйте, Sheridan, Вы писали:
S>>Здравствуйте, Mamut, Вы писали:
M>>>Так как это было обсосано два-три года тому назад, ссылки (на удивление мало тебя): M>>>http://rsdn.ru/forum/flame.comp/3899857.1.aspx
Там про двоичную совместимость вообще ни слова. Хотя, фантазии, заменяющие тебе процесс мышления, никогда не дадаут тебе возможность это увидеть.
Ты пытаешься свернуть дотнет практически до "это просто язык шарп и куча библиотек, шарп — язык и кроссплатформенность ему ортогональна, а библиотеки это библиотеки, они к языку отношения не имеют"
Нет уж, тут котят от котлет не отделишь. Есть дотнет. Есть моно. Это не одно и тоже.
Здравствуйте, Mamut, Вы писали:
S>>Ничего подобного. Я даже и не пытаюсь. Просто говорю то, что вижу в силу своей незашоренности окнами или там маковыми полями.
M>О да, по маковым полям ты у нас ксперт — ты ведь из них не вылезаешь
Эй, ты уверен что сам не подсел? Вообщето пока что еще зима.
Здравствуйте, vsb, Вы писали:
vsb>А вы можете продемонстрировать тормоза Java, вызванные ограниченной моделью выполнения? В сравнение с С++ (поэтому несравнимое, вроде GC vs new/delete сранивать не надо).
Например, можно представить разницу в представлении понятия "объект типа точка с двумя координатами" в ранайме, в C++ и в Java. А ещё лучше -- массив точек.
В C++ это будет, грубо говоря, память для массива + немного памяти для хранения кода методов класса "точка". Вызов метода "точки" из массива -- простейшая арифметика указателей и вызов функции.
В Java ты получишь расходы памяти и дополнительные инструкции для поддержания семантики JVM (GC, исключения, безопасность, рефлекшн, и.т.д).
При этом у тебя нет никакой возможности реализовать "легковесную" "точку", которой всё это не нужно. То есть JVM, конечно, попытается сделать какие-то оптимизации, но она всё равно достаточно ограничена в возможностях. Как-то так.
Здравствуйте, Иван Дубров, Вы писали:
ИД>Здравствуйте, vsb, Вы писали:
vsb>>А вы можете продемонстрировать тормоза Java, вызванные ограниченной моделью выполнения? В сравнение с С++ (поэтому несравнимое, вроде GC vs new/delete сранивать не надо).
ИД>Например, можно представить разницу в представлении понятия "объект типа точка с двумя координатами" в ранайме, в C++ и в Java. А ещё лучше -- массив точек.
ИД>В C++ это будет, грубо говоря, память для массива + немного памяти для хранения кода методов класса "точка". Вызов метода "точки" из массива -- простейшая арифметика указателей и вызов функции.
ИД>В Java ты получишь расходы памяти и дополнительные инструкции для поддержания семантики JVM (GC, исключения, безопасность, рефлекшн, и.т.д).
По расходу памяти — согласен. По дополнительным инструкциям — опять же интересно посмотреть, насколько они влияют на производительность реальных алгоритмов. По-моему не очень сильно влияют. Безопасность проверяется при загрузке класса, во время выполнения никаких проверок не должно быть. Рефлекшн это просто метаинформация.
ИД>При этом у тебя нет никакой возможности реализовать "легковесную" "точку", которой всё это не нужно. То есть JVM, конечно, попытается сделать какие-то оптимизации, но она всё равно достаточно ограничена в возможностях. Как-то так.
Если необходимо оптимизировать по памяти этот случай — можно использовать конструкцию вроде
int[] x;
int[] y;
или
long[] xy;
В итоге дополнительных расходов порядка O(N) не будет. Семантика, конечно, другая.
Вообще принято считать, что память нынче дешёвая и для многих приложений так и есть. Памяти всегда можно добавить до каких-то разумных пределов, конечно, вот процессор "добавить" уже сложно, если тормозит, то тормозит. Поэтому интереснее именно тормоза процессора.
Здравствуйте, FR, Вы писали:
G>>Ты хочешь сказать что можно раз скомпилировать код на C\C++ и запускать везде? Что-то я сомневаюсь что у тебя так выйдет.
FR>Ну с LLVM вполне реально, пока скорее в теории, на практике только недостаток библиотек не дает.
Никто этим заниматься никогда не планировал, ибо в общем то никому не надо. "Virtual Machine" в название случайно как-то вкралось )
Здравствуйте, esil, Вы писали:
ИД>>Чем позже делается компиляция -- тем больше возможностей для оптимизации. Не зря в GCC LTO придумали.
E>LTO не имеет никакого отношения к "Чем позже делается компиляция -- тем больше возможностей для оптимизации".
А к чему это имеет отношение? Это способ делать некоторые оптимизации в момент, когда становится доступна некоторая информаци. Вот, прям с их wiki:
>Link Time Optimization (LTO) gives GCC the capability of dumping its internal representation (GIMPLE) to disk, so that all the different compilation units that make up a single executable can be optimized as a single module. This expands the scope of inter-procedural optimizations to encompass the whole program (or, rather, everything that is visible at link time).
Это способ отложить часть компиляции (некоторые оптимизации) до момента, когда у тебя будет необходимая информация. Например, совсершенно никак нельзя заинлайнить некую тривиальную функцию из libfoo-1.0.0.so во время сборки проекта, потому что при запуске у клиента может оказаться libfoo-1.0.1.so. Делая оптимизацию во время линковки ты уже совершенно точно знаешь, какой именно код стоит за libfoo и можешь проводить такие оптимизации.
Здравствуйте, esil, Вы писали:
E>LTO — это способ выполнять межпроцедурные оптимизации на всей программе (а не по-модульно). Именно это и сказано у них в wiki. Фраза "делать компиляцию как можно позже" — это спекуляция, потому что на самом деле компиляция делается не раньше и не позже, она просто делается на всей программе, а не на каждом модуле отдельно.
ИД>>Это способ отложить часть компиляции (некоторые оптимизации) до момента, когда у тебя будет необходимая информация. Например, совсершенно никак нельзя заинлайнить некую тривиальную функцию из libfoo-1.0.0.so во время сборки проекта, потому что при запуске у клиента может оказаться libfoo-1.0.1.so. Делая оптимизацию во время линковки ты уже совершенно точно знаешь, какой именно код стоит за libfoo и можешь проводить такие оптимизации.
E>кто-то уже научился инлайнить функции из скомпилированных разделяемых библиотек?
Да, это у меня фантазия, похоже, разыгралась.
Но вообще Java умеет Там, правда, нет разделения "статических" библиотек и "динамических", но заинлайнить метод идущий из класса, который был загружен уже в процессе работы (например, какой-то плагин) -- она может.
Здравствуйте, Иван Дубров, Вы писали:
E>>кто-то уже научился инлайнить функции из скомпилированных разделяемых библиотек?
ИД>Да, это у меня фантазия, похоже, разыгралась.
ИД>Но вообще Java умеет Там, правда, нет разделения "статических" библиотек и "динамических", но заинлайнить метод идущий из класса, который был загружен уже в процессе работы (например, какой-то плагин) -- она может.
Да, при динамической компиляции такое возможно. А также возможны всякие другие крутые вещи, например инлайн кода виртуальной машины, если эта виртуальная машина написана на Java (вроде есть/была такая JVM, не помню название).
Но реально на практике возможностей для межпроцедурной оптимизации в JIT меньше, потому что это занимает очень много времени. Например, мне не известен ни один JIT, который строит глобальный граф вызовов на всей программе, просто потому, что это слишком дорого (ну не может же приложение стартовать десятки минут). Что характерно, есть статический компилятор Java (не JIT), который таки занимается этим
Здравствуйте, IT, Вы писали:
IT>Почему MS не желает заниматься другими платформами для меня совершенно непонятно.
А как оно будет зарабатывать на .Net на других платформах? За счет средств разаработки?
Здравствуйте, IT, Вы писали:
IT>Кросплатформенность .NET — это не иллюзия, а тупое нежелание MS переносить код на другие платформы. Mono прекрасно работает и на линуксе и на андроиде. Никаких проблем с этим нет.
Работает, но например наш сервак на моно начнает отжирать оч.много памяти вплоть до полного исчерпания или почти полного, под виндой на .Net работает корректно...
Здравствуйте, Sheridan, Вы писали:
S>То что моно сделан "по мотивам" дотнета не делает его дотнетом. S>Хотя с другой стороны оба — мертворождены, поэтому разговор пустой.
S>Нет уж, тут котят от котлет не отделишь. Есть дотнет. Есть моно. Это не одно и тоже.
Было пройдено еще два года тому назад. То, что ты в одну кучу мешаешь CLR и набор библиотек от МСа не делает то, что ты говоришь, хоть сколько-то правдивым.
Здравствуйте, Философ, Вы писали:
Ф>Здравствуйте, kochetkov.vladimir, Вы писали:
KV>>4 ASP.NET сайта, аудитами которых я занимался, крутились под линуксом.
Ф>насколько мне известно, для ASP.NET нужен IIS. Ф>под чем они там крутились?
Для ASP.NET даже на винде IIS не обязателен, если что. Что касается моно, то http://www.mono-project.com/ASP.NET Конкретно те сайты, о которых говорил я, закручивались fastcgi-mono-server'ом и обслуживались nginx'ом. По субъективным ощущениям, работало достаточно шустро.
Здравствуйте, Mamut, Вы писали:
M>Ты будешь возражать, что найдутся проекты, которые не собираются под gcc, но собирающиеся под Microsoft C++ compiler и наоборот?
Нет
M>>Ты будешь возражать, что найдутся проекты, которые не собираются под gcc, но собирающиеся под Microsoft C++ compiler и наоборот? S>Нет
Так в чем вопрос? Mono и MS .net Framework реализуют один и тот же стандарт. В MS .net Framework просто дополнительные windows-зависимые библиотеки. Так же, как есть платформо-зависимые библиотеки для С++
Но я повторяюсь. Это все было пройдено два-три года тому назад.
Здравствуйте, Pzz, Вы писали:
Pzz>Настоящему хирургу все равно, каким ножом резать, на каком органе и при какой болезни — ибо принципы медицины идентичны для всех болезней и отличаются только диагнозом, а базовые технологии есть в любой операционной, а отличия в архитектуре нивелируются хорошей анестезией
Да ладно. Копните поглубже и вам откроется нейрохирургия, кардиохирургия и т.д. и т.п.
Здравствуйте, IT, Вы писали:
IT>В результате на сегодняшний день наблюдается стойкая тенденция не только написания сервернго кода на Java, но и переписывания существующего .NET кода на Java.
Надо же, а вроде ты где-то год тому назад говорил, что в банках .NET везде, нет?
Здравствуйте, IT, Вы писали:
IT>А народ жалуется, что в некоторых местах пробить тупизну админов, уцепившихся за линукс просто не возможно.
Не знаю как там админы, а вот от руководителей финансовых компаний вполне ожидаю, что они предпочитаю не зависеть от одного отдельно взятого Микрософта.
Здравствуйте, igna, Вы писали:
IT>>А народ жалуется, что в некоторых местах пробить тупизну админов, уцепившихся за линукс просто не возможно. I>Не знаю как там админы, а вот от руководителей финансовых компаний вполне ожидаю, что они предпочитаю не зависеть от одного отдельно взятого Микрософта.
Но ведь зависят же. Все рабочие станции в банках — Windows, а основной рабочий софт — MS Office. Сервера в сравнении с этим — это капля в море.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
IT>Но ведь зависят же. Все рабочие станции в банках — Windows, а основной рабочий софт — MS Office. Сервера в сравнении с этим — это капля в море.
Эээ, стоп. MS Office-то не финансовые компании пишут.
Здравствуйте, igna, Вы писали:
IT>>Но ведь зависят же. Все рабочие станции в банках — Windows, а основной рабочий софт — MS Office. Сервера в сравнении с этим — это капля в море. I>Эээ, стоп. MS Office-то не финансовые компании пишут.
Нет, не пишут. Но используют и зависят.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, igna, Вы писали:
IT>>Нет, не пишут. Но используют и зависят. I>И все-таки это совсем другая зависимость. Главная проблема при переходе на OpenOffice будет пользователей переучить, а не программу переписать.
И?
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, igna, Вы писали:
I>И все-таки это совсем другая зависимость. Главная проблема при переходе на OpenOffice будет пользователей переучить, а не программу переписать.
Когда я дома детям OpenOffice поставил, им даже переучиваться не пришлось. А что происходит на предприятиях, рядом
А фиг его знает. Тот же руководитель вполне может считать, что если он Office освоил, то и подчиненные смогут, а программирование для него возможно гадский темный лес.
Здравствуйте, igna, Вы писали:
I>А фиг его знает. Тот же руководитель вполне может считать, что если он Office освоил, то и подчиненные смогут, а программирование для него возможно гадский темный лес.
На самом деле руководителям банков до лампочки на чём у них софт написан. Они и слов таких как .NET и Java не знают. Эта политика определяется ниже и не всегда людьми разбирающимися во всех деталях, и очень часто на основании личных предпочтений.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
LP>>Разработчику банковских систем должно быть известно, что логика на клиенте — это дыра в безопасности системы. IT>Не вижу здесь логики.
Не видишь возможности фальсификации клиента?
LP>>Далее, совершенно очевидно, что чем толще клиент, тем меньше диапазон устройств, на которых он может работать (это перпендикулярно кросплафторменности — речь идет о ресурсах). Вот буквально недавно забраковали таких вот любителей толстенького — клиент выжирал до полугига оперативы и работал, мягко говоря, не быстро, причем это было обусловлено объективными причинами (то есть не было следствием кривой реализации), в результате из мобильных девайсов пользоваться им было невозможно. Заменили реализацию на 100% сервер сайд, теперь крутится везде, где есть браузер.
IT>У вас трейдеры прямо с собственных телефонов торгуют? Впервые слышу. Что касается браузеров, то тут java точно не нужна. Это ошибка, переходите срочно на ASP.NET MVC.
Какие еще трейдеры? Я такой ересью не занимаюсь. Электроэнергетика, алюминиевая промышленность и дорожное строительство — в этих областях (особенно в первой и третьей) использование мобильных устройств стремительно растет.
IT>>>You wish! Пока вы там фреймворки разрабатываете энтерпрайз аккуратненько ASP.NET MVC и Silverlight осваивает. LP>>Фреймворки уже давно готовы, цветут и пахнут, в отличие от вашего Сильверлайта. Его как, похоронили уже, или до сих пор выдерживают в гробу? IT>Жив дурилка. И все ваши пахнущие фреймворки переживёт.
А говорили, что уже умер. Кто же из вас двоих врет, ты или Интернет?
Социализм — это власть трудящихся и централизованная плановая экономика.
vsb>>>>А вы можете продемонстрировать тормоза Java
S>Let's combat begin!
S>Выбирайте компилятор жабы, сударь. В качестве C++ компилятора я беру ICC. Далее пишем тестовый код на С++ и идентичный ему на жабе.
Надееюсь, идентичный по функциональности, а не по конструкциям?
Здравствуйте, Mamut, Вы писали:
vsb>>>>>А вы можете продемонстрировать тормоза Java
S>>Let's combat begin!
S>>Выбирайте компилятор жабы, сударь. В качестве C++ компилятора я беру ICC. Далее пишем тестовый код на С++ и идентичный ему на жабе.
M>Надееюсь, идентичный по функциональности, а не по конструкциям?
Как будет угодно. Жабе это всё равно не поможет Только условимся что объект "точка" это таки объект, а не размазывание соплей полей по раздельности. Ну и к данным точки стучимся через сеттеры-геттеры. Всё по-взрослому. Чтобы итоговый код походил на реальный, идущий в production.
Предлагаю следующий приблизительный функционал:
1) создаём несколько десятков миллионов точек
2) делаем несколько функторов, обрабатывающих точки. Прореживаем массив точек, возвращая результат в новом контейнере.
например:
определяем, какие точки попадают в BoundingBox, заданный двумя диагональными вершинами
определяем, какие точки лежат выше/ниже оси абцисс/ординат
определяем, у каких точек модуль разности координат меньше/больше переданной константы.
3) поворачиваем все точки вокруг Pivot на угол Alpha
4) зеркально отражаем все точки вокруг произвольной оси, заданной двумя точками
6) сортируем точки по X/Y координате
Повторяем это несколько сотен или тысяч раз. Смотрим результат. Чешем репу.
> Что характерно, JGit выполняет операцию rev-list --objects –all примерно вдвое дольше, чем это делает Git, на проекте вроде ядра Linux, а index-pack для файла размером около 270 МБ тоже длится примерно вдвое дольше.
Хех. Уже этой фразы достаточно, чтобы не бояться и брать в руки Java
Здравствуйте, Mamut, Вы писали:
S>>Повторяем это несколько сотен или тысяч раз. Смотрим результат. Чешем репу.
M>Про это могу сказать только вот: http://habrahabr.ru/blogs/programming/136210/
M>Мой комментарий оттуда: M>
>> Что характерно, JGit выполняет операцию rev-list --objects –all примерно вдвое дольше, чем это делает Git, на проекте вроде ядра Linux, а index-pack для файла размером около 270 МБ тоже длится примерно вдвое дольше.
M>Хех. Уже этой фразы достаточно, чтобы не бояться и брать в руки Java
Непонятно только, это согласие на писькометрию или попытка слиться ?
Здравствуйте, LaPerouse, Вы писали:
LP>>>Разработчику банковских систем должно быть известно, что логика на клиенте — это дыра в безопасности системы. IT>>Не вижу здесь логики. LP>Не видишь возможности фальсификации клиента?
Удачность фальсификации клиента зависит от кривизны рук разработчика, а не от наличия в клиенте бизнес логики.
IT>>У вас трейдеры прямо с собственных телефонов торгуют? Впервые слышу. Что касается браузеров, то тут java точно не нужна. Это ошибка, переходите срочно на ASP.NET MVC. LP>Какие еще трейдеры? Я такой ересью не занимаюсь. Электроэнергетика, алюминиевая промышленность и дорожное строительство — в этих областях (особенно в первой и третьей) использование мобильных устройств стремительно растет.
Так ты про энергенику. А мы тут всё больше про банки.
LP>А говорили, что уже умер. Кто же из вас двоих врет, ты или Интернет?
Скорее всего ты. Видимо, раз начались переходы на личности, то аргументы закончились?
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, LaPerouse, Вы писали:
LP>А говорили, что уже умер. Кто же из вас двоих врет, ты или Интернет?
Ничего не умерло. В Windows 8 оно еще с WinRT подружится. Меньше паникерства!
Здравствуйте, stasgoo, Вы писали:
S>Здравствуйте, vsb, Вы писали:
vsb>>>>А вы можете продемонстрировать тормоза Java
S>Let's combat begin!
S>Выбирайте компилятор жабы, сударь. В качестве C++ компилятора я беру ICC. Далее пишем тестовый код на С++ и идентичный ему на жабе. Собираем, выкладывая опции командной строки. Выкладываем бинарники сочуствующим, но ленящимся. И меряемся письками скоростью. Прогнозирую слив жабы по скорости минимум в 5(!) раз.
Стандартный Oracle JVM последней версии. Давайте попробуем.
IT>>>А народ жалуется, что в некоторых местах пробить тупизну админов, уцепившихся за линукс просто не возможно. I>>Не знаю как там админы, а вот от руководителей финансовых компаний вполне ожидаю, что они предпочитаю не зависеть от одного отдельно взятого Микрософта.
IT>Но ведь зависят же. Все рабочие станции в банках — Windows, а основной рабочий софт — MS Office. Сервера в сравнении с этим — это капля в море.
Ну вот, кстати, у того же Приватбанка(самый крупный коммерческий банк Украины) все рабочие станции в отделениях на линухе...
Новости очень смешные. Зря вы не смотрите. Как будто за наркоманами подсматриваешь. Только тетка с погодой в завязке.
There is no such thing as a winnable war.
Здравствуйте, stasgoo, Вы писали:
S>Здравствуйте, vsb, Вы писали:
vsb>>>>А вы можете продемонстрировать тормоза Java
S>Let's combat begin!
S>Выбирайте компилятор жабы, сударь. В качестве C++ компилятора я беру ICC. Далее пишем тестовый код на С++ и идентичный ему на жабе. Собираем, выкладывая опции командной строки. Выкладываем бинарники сочуствующим, но ленящимся. И меряемся письками скоростью. Прогнозирую слив жабы по скорости минимум в 5(!) раз.
Давайте только сразу выкладывайте скомпиленные бинари для Win7 c процом AMD, и для линуха с ним же(ну, эт для плюсов, жабовское запустится везде одинаково). Бо у меня интелов отродясь не было, а на Убунте просто потестить охота.
Новости очень смешные. Зря вы не смотрите. Как будто за наркоманами подсматриваешь. Только тетка с погодой в завязке.
There is no such thing as a winnable war.
Здравствуйте, stasgoo, Вы писали:
S>Let's combat begin!
S>Выбирайте компилятор жабы, сударь. В качестве C++ компилятора я беру ICC. Далее пишем тестовый код на С++ и идентичный ему на жабе. Собираем, выкладывая опции командной строки. Выкладываем бинарники сочуствующим, но ленящимся. И меряемся письками скоростью. Прогнозирую слив жабы по скорости минимум в 5(!) раз.
Самое интересное было бы сравнить на развесистой тяжёлой ынтырпрайз системе. Например, какая-нибудь система для банков или страховых. Там всё самое интересное начинается.
Но это нереально, так как две идентичные системы ты не найдёшь
А на микротестах сложно правильно протестировать. Я как-то смотрел нативный код, который JVM генерирует для простенького цикла + виртуальный вызов, так JVM попыток 5 делала компиляции этого кода до тех пор пока весь код не редуцировался в несколько строк ассемблерного кода (после агресивного инлайна). Какой вариант считать правильным, первый или последний? Или что-то промежуточное? И вообще, насколько это влияет в реально больших и развесистых системах?
P.S. Задача (нечестная) :D
Есть библиотека вычисляющая функцию от целого (compute). Посчитать сумму compute(i) от 0 до заданного в командной строке числа (без верхней границы). Например, при cnt := 3 и compute(i) := i ответ будет 3.
Требование: возможность подменять compute без перекомпиляции программы (т.е в случае с C++ это должна быть динамическая библиотека).
Здравствуйте, gandjustas, Вы писали:
G>Ага, запусти на мобилке то что написано для десктопа.
И что будет? )
G>>>Второй вариант — "программа под любую платформу собирается из одного набора исходников". Такое похоже на правду, НО есть платформенно-зависимый код, есть UI, который чаще всего надо проектировать под каждую платформу отдельно. _>>Не надо, если выбрать правильные библиотеки. У нас вот кроссплатформенный продукт и "платформенных ifdef'ов" там на весь проект пара штук. G>Это будет третий вариант
Это не третий вариант, во всяком случае в озвученном виде. Мы пишем программы (а не библиотеки) на C++ с GUI и они работают на множестве платформ простой перекомпиляцией.
G>А потому что кроссплатформенность нафиг никому не упала. G>Это тупо флаг, которым размахивают вендоры. Реальная польза от кроссплатформенности для конечного пользователя нулевая, если не отрицательная.
Пользователю конечно пофиг написана программа с помощью кроссплатформенных инструментов или же нет. А вот производителю это очень важно — меньше расходов.
Здравствуйте, Uzumaki Naruto, Вы писали:
UN>Здравствуйте, Kingofastellarwar, Вы писали:
UN>Рассмотрим правильное кроссплатформеное программирование под С/C++ — все прекрасно компилируется под любые платформы — от PC до мобильных...
а вы код правильного кросс-платформенного приложения видели? это же ужос просто. совместимость компиляторов сильно хромает и хз какое подмножество стандарта на каком компиляторе реализовано. а кросс-платформенных библиотек кот накакал.
UN>Каждый язык имеет свою нишу и применение... настоящему программисту все равно на каком языке писать, UN>под какую платформу и архитектуру — ибо принципы программирования идентичные для всех языков UN>и отличаются только синтаксисом, а базовые технологии есть во всех платформах, а отличия
Сегодня собеседовали доктора из института. спросили за языки и в частности за плюсы. доктор ответил, что может и на плюсах, но мыслит все равно на си. и мы сразу нашли друг друга, т.к. он поймет мой код, а я его. хотя ни он, ни я ни разу не программисты и тем более не "настоящие". мы стоящие специалисты, во!
вы еще скажите настоящему переводчику все равно с какого языка на какой переводить, ибо все равно переводит гугл, а переводчик только правит совсем нелепые ошибки. точно так и у программистов есть своя специализация. есть особенности мышления. есть скилзы. даже в такой профессии как фотография отчетливо выделяются те, кто умеет хорошо снимать и те, кто умеет хорошо обрабатывать отснятый материал.
> в архитекторах нивелируются едиными типами данных...
так не типами едины.
americans fought a war for a freedom. another one to end slavery. so, what do some of them choose to do with their freedom? become slaves.
UN>Рассмотрим на примере java... все работает прекрасно на всех платформах...
Оно даже в пределах одной платформы не всегда работает — совершенно легальные SSLSocket'ы резко изменили свое поведение при переходе от Sun-машины 1.6 к 1.7, причем обнаружить и найти проблему у не самых глупых людей заняло два дня.
Здравствуйте, Eugeny__, Вы писали:
E__>Давайте только сразу выкладывайте скомпиленные бинари для Win7 c процом AMD, и для линуха с ним же(ну, эт для плюсов,
В чем, по твоему мнению, проявится отличие между линухом и виндой ? I/O в тестах нету, только голый код.
E__>жабовское запустится везде одинаково).
Запустится может и одинаково. А заработает одинаково хорошо ? Или сегодня все JVM по качеству идентичны ?
E__>Бо у меня интелов отродясь не было, а на Убунте просто потестить охота.
Интеловское небязательно. Но если будем компилить с максимальной оптимизацией надо чтобы все расширения типа SSE3 присутствовали.
Здравствуйте, Иван Дубров, Вы писали:
ИД>Требование: возможность подменять compute без перекомпиляции программы (т.е в случае с C++ это должна быть динамическая библиотека).
Необязательно библиотека. Благодаря, как ни странно, Apple, сейчас С++ может компилиться в байткод и JITится по требванию. Гуглить LLVM, CLang.
Здравствуйте, IT, Вы писали:
IT>На самом деле руководителям банков до лампочки на чём у них софт написан. Они и слов таких как .NET и Java не знают. Эта политика определяется ниже и не всегда людьми разбирающимися во всех деталях, и очень часто на основании личных предпочтений.
А эти "люди ниже" не являются руководителями? Ну и ладно, в любом случае Office они на уровне среднего пользователя знают, а программирование на уровне среднего программиста — далеко не всегда.
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, LaPerouse, Вы писали:
LP>>>>Разработчику банковских систем должно быть известно, что логика на клиенте — это дыра в безопасности системы. IT>>>Не вижу здесь логики. LP>>Не видишь возможности фальсификации клиента?
IT>Удачность фальсификации клиента зависит от кривизны рук разработчика, а не от наличия в клиенте бизнес логики.
Признай наконец, что ляпнул чушь. Если логика вынесена на клиент, существует возможность замены это логики путем изменения клиента. Если логика на сервере, то на нее можно влиять только подбором входных данных; верификация эти данных на стороне сервера способно устранить большинство проблем.
IT>>>У вас трейдеры прямо с собственных телефонов торгуют? Впервые слышу. Что касается браузеров, то тут java точно не нужна. Это ошибка, переходите срочно на ASP.NET MVC. LP>>Какие еще трейдеры? Я такой ересью не занимаюсь. Электроэнергетика, алюминиевая промышленность и дорожное строительство — в этих областях (особенно в первой и третьей) использование мобильных устройств стремительно растет. IT>Так ты про энергенику. А мы тут всё больше про банки.
Не знаю про что вы говорите, я говорю о .net и java.
LP>>А говорили, что уже умер. Кто же из вас двоих врет, ты или Интернет? IT>Скорее всего ты. Видимо, раз начались переходы на личности, то аргументы закончились?
На RSDN была новость о том, что команду разработчиков разогнали, оставив лишь двоих для выпуска последней версии. Вот я и спрашиваю, кто же прав, о каком переходе на личности ты говоришь?
Социализм — это власть трудящихся и централизованная плановая экономика.
Здравствуйте, IT, Вы писали:
IT>У вас трейдеры прямо с собственных телефонов торгуют? Впервые слышу. Что касается браузеров, то тут java точно не нужна. Это ошибка, переходите срочно на ASP.NET MVC.
Вообще-то трейдинговых приложений под iPhone/iPad вагон и маленькая тележка.
Здравствуйте, stasgoo, Вы писали:
S>Интеловское небязательно. Но если будем компилить с максимальной оптимизацией надо чтобы все расширения типа SSE3 присутствовали.
На AMD я сталкивался с забавным: по флагам проца поддержка SSE3 есть, а по факту падает с illegal instruction.
Здравствуйте, igna, Вы писали:
I>А эти "люди ниже" не являются руководителями?
Я вляются и что? Boss of my boss of my boss является руководителем, но уже такого уровня, что понятиями java и .net не заморачивается. У него своих проблем выше крыши.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, genre, Вы писали:
IT>>У вас трейдеры прямо с собственных телефонов торгуют? Впервые слышу. Что касается браузеров, то тут java точно не нужна. Это ошибка, переходите срочно на ASP.NET MVC. G>Вообще-то трейдинговых приложений под iPhone/iPad вагон и маленькая тележка.
Например, amazon.com.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
IT>Я вляются и что? Boss of my boss of my boss является руководителем, но уже такого уровня, что понятиями java и .net не заморачивается. У него своих проблем выше крыши.
Ты зубы-то не заговаривай. Суть в том, что тот, кто выбирает между Java и .NET или между MS Ofiice и, скажем, OpenOffice, знает Office по крайней мере на уровне среднего пользователя, а программирование на уровне среднего программиста — далеко не всегда.
Здравствуйте, IT, Вы писали:
IT>А без хамства уже никак не обойтись?
Это не хамство, а фразеологический оборот.
IT>Этот человек не занимается решением подобных вопросов. Для этого у него есть специалисты, которые предоставят ему всю информацию и все за и против.
Представление о том, что .NET продвигается только Microsoft-ом, а Java — не только Oracle-ом, есть почти у каждого управленца. Некоторые даже знают про IBM и Google.
Здравствуйте, stasgoo, Вы писали:
S>Здравствуйте, Иван Дубров, Вы писали:
ИД>>Требование: возможность подменять compute без перекомпиляции программы (т.е в случае с C++ это должна быть динамическая библиотека).
S>Необязательно библиотека. Благодаря, как ни странно, Apple, сейчас С++ может компилиться в байткод и JITится по требванию. Гуглить LLVM, CLang.
Воооот! Началось всё с того, что дескать, байт-код -- он только вредит (ну т.е явно об этом автор топика не говорил, но у меня сложилось именно такое понимание). А получается, что как раз-таки с байткодом даже ещё и больше возможностей для оптимизации. Время старта -- да, с ним всё относительно грустно.
ИД>>>Требование: возможность подменять compute без перекомпиляции программы (т.е в случае с C++ это должна быть динамическая библиотека).
S>>Необязательно библиотека. Благодаря, как ни странно, Apple, сейчас С++ может компилиться в байткод и JITится по требванию. Гуглить LLVM, CLang.
ИД>Воооот! Началось всё с того, что дескать, байт-код -- он только вредит (ну т.е явно об этом автор топика не говорил, но у меня сложилось именно такое понимание). А получается, что как раз-таки с байткодом даже ещё и больше возможностей для оптимизации. Время старта -- да, с ним всё относительно грустно.
При установке прогонять аналог ngen'а, и все пучком, по идее
Здравствуйте, Mamut, Вы писали:
M>При установке прогонять аналог ngen'а, и все пучком, по идее
Не получится пучков У JIT-а есть фатальный недостаток: безблагодатность жёсткие ограничения на время работы. Как бы не хотелось, но от многих оптимизаций придётся отказаться, чтобы пользователь не фалломорфировал, полдня ожидая JIT при запуске офиса.
Здравствуйте, stasgoo, Вы писали:
S>Здравствуйте, Mamut, Вы писали:
M>>При установке прогонять аналог ngen'а, и все пучком, по идее
S>Не получится пучков У JIT-а есть фатальный недостаток: безблагодатность жёсткие ограничения на время работы. Как бы не хотелось, но от многих оптимизаций придётся отказаться, чтобы пользователь не фалломорфировал, полдня ожидая JIT при запуске офиса.
Так при установке же можно прогонять. Ставишь новый пакет -- система его прожёвывает на фоне и выкатывает на диск уже супер-оптимизированные бинарники. Проблема только в том, что всё-таки хочется чтобы часть динамических библиотек (нетривиальный код, который нет смысла инлайнить, например) всё-таки бы разделялся, чтобы не генерировать гигабайтные бинарники для каждого приложения.
М>>>сильно. а какое отношение это имеет к JIT и прочим умным словам? Ф>>это имеет отношение к .Net. М>создание 400х чекбоксов в гриде? помилуйте. давайте использовать инструменты по назначению. какие проблемы реализовать _один_ элемент управления самостоятельно? совсем уже обленились. тут же тривиально все. будет летать на любой платформе. давайте я вам не буду объяснять сколько ресурсов кушает один элемент управления?
Не понимаю. Почему вот этот тупейший код:
var table = $(document.body).append('<table>');
for(var i=0; i < 20; i++){
var tr = $('<tr>');
for(var j=0; j < 20; j++){
var td = $('<td>');
var chk = $('<input type="checkbox">');
chk.bind('click', function(){$(this).parent().css('background-color', $(this).is(':checked') ? 'red' : 'white')});
td.append(chk);
tr.append(td);
}
table.append(tr);
}
Который jQuery, тупое создание 400 чекбоксов с максимально тупым назначением событий каждому чекбоксу... И не тормозит. Более того, создание аналогичного в каком-нить ExtJS тоже не будет тормозить.
Но нет, в WPF это низзя ни в коем случае, вы шо. Нужно в обязательном порядке делать собственный контрол на каждый чих? Где эти чихи начинаются? На 20 чекбоксах? На 30?
Здравствуйте, мыщъх, Вы писали:
м>давайте я вам не буду объяснять сколько ресурсов кушает один элемент управления?
Не-не, расскажи, сколько ресурсов требует чекбокс в WPF. Если вспомнить, что в дотнетах память не ресурс, получится что ресурсов ему не требуется
м> вы бы еще создали 400 потоков и сказали, что система -- фуфло
У меня прямо сейчас в системе 903 потока, в серверном процессе пул периодически разрастается до полутора тысяч, иничо
M>Но нет, в WPF это низзя ни в коем случае, вы шо. Нужно в обязательном порядке делать собственный контрол на каждый чих?
мы говорим за WPF или дотнет? за WPF не знаю, в код дотнета смотрел дизасмом. ничего ужасного в нем не нашел. нормальный такой код. взаимодействие с нативным кодом, конечно, через задницу, но в рамках управляемого кода особых тормозов быть не должно.
americans fought a war for a freedom. another one to end slavery. so, what do some of them choose to do with their freedom? become slaves.
Здравствуйте, мыщъх, Вы писали:
М>а вы код правильного кросс-платформенного приложения видели? это же ужос просто.
Ну вот я сейчас смотрю на такой код (наш) и ничего страшного там не вижу.
М>совместимость компиляторов сильно хромает и хз какое подмножество стандарта на каком компиляторе реализовано.
Это вы про код использующий спец. фичи конкретного компилятора или про что? Даже Буст (уж на что полная извращений библиотека) без проблем компилируется везде. А у вас какие-то более хитрые коды? )))
М>а кросс-платформенных библиотек кот накакал.
ЭЭэ, это в сравнение с чем? Все библиотеки что мы используем кроссплатформенные...
Здравствуйте, gandjustas, Вы писали:
G>Ничего, даже если запустится, то работать будет невозможно.
Почему невозможно? А если это какой-нибудь конвертер файлов просто?
Кстати, я вообще то сам Java не люблю, но совсем по другим причинам. А тут не могу согласиться с такими наездами на неё — кроссплатоформенность там всё же реальная.
G>Какие платформы входят в это множество?
Потенциально (наши инструменты это поддерживают) можно под: windows, osx, все unix'ы, OpenVMS, OS/2, iOS, WinCE, PalmOS и т.п. На практике для бизнеса полезны только: Windows (с большим приоритетом), OS X, Linux.
G>Кроссплатформенность нужна исчезающе малому проценту вендоров ПО.
Типа гораздо выгоднее разработать отдельное приложение под каждую платформу, да?
Здравствуйте, alex_public, Вы писали:
_>Здравствуйте, мыщъх, Вы писали:
М>>а вы код правильного кросс-платформенного приложения видели? это же ужос просто. _>Ну вот я сейчас смотрю на такой код (наш) и ничего страшного там не вижу.
мой код тоже компилируется везде. но мне везет. у меня даже стандартного в/в нету. у меня даже malloc'а нету. есть входной буфер. есть преаллоцированный буфер. но если посмотреть в код FireFox, то становится дурно.
М>>совместимость компиляторов сильно хромает и хз какое подмножество стандарта на каком компиляторе реализовано. _>Это вы про код использующий спец. фичи конкретного компилятора или про что?
берем FireFox. пытаемся компилировать ранние версии. у меня получилось собрать только 2.0, а более ранние — MS VC 6 выдает внутреннюю ошибку компиляции и падает, а MS VC 2008 выдает кучу ошибок и ничего не собирает.
последние версии лиса в этом смысле сильно продвинулись вперед, но проблем все равно куча. и для сборки приходится деражть определенную среду. вот тут наконец дали мне полную версию студии (не экспресс), на ней уже не собирается.
> Даже Буст (уж на что полная извращений библиотека) без проблем > компилируется везде. А у вас какие-то более хитрые коды? )))
лис, хром -- у всех них довольно жесткие требования к компиляторам. сборка новых версий это как бы не проблема (раз смогли собрать они -- смогу и я). а вот если хочешь собрать какую-то древность -- то нужной версии компилятора не найти, особенно если это не gcc, а коммерческий компилятор.
americans fought a war for a freedom. another one to end slavery. so, what do some of them choose to do with their freedom? become slaves.
Здравствуйте, Иван Дубров, Вы писали:
ИД>Так при установке же можно прогонять. Ставишь новый пакет -- система его прожёвывает на фоне и выкатывает на диск уже супер-оптимизированные бинарники.
Меня выбешивает даже то, как на i5 ngen жуёт сопли при установке какого нить .NET FW, а тут для всех прог так? Да ну нафиг!
Здравствуйте, alex_public, Вы писали:
_>Здравствуйте, gandjustas, Вы писали:
G>>Ничего, даже если запустится, то работать будет невозможно.
_>Почему невозможно? А если это какой-нибудь конвертер файлов просто?
На мобилке? Где по-умолчанию и доступа к ФС нету?
_>Кстати, я вообще то сам Java не люблю, но совсем по другим причинам. А тут не могу согласиться с такими наездами на неё — кроссплатоформенность там всё же реальная.
Ни разу. j2ME сильно отличается j2EE как ни крути. Как в библиотеках, так и в подходе к разработке.
G>>Какие платформы входят в это множество?
_>Потенциально (наши инструменты это поддерживают) можно под: windows, osx, все unix'ы, OpenVMS, OS/2, iOS, WinCE, PalmOS и т.п. На практике для бизнеса полезны только: Windows (с большим приоритетом), OS X, Linux.
Ага, то есть ни одной мобилки, а сейчас всякие планшеты набирают оборот.
G>>Кроссплатформенность нужна исчезающе малому проценту вендоров ПО. _>Типа гораздо выгоднее разработать отдельное приложение под каждую платформу, да?
Ну вот производители фотошопа считают так. У них разные билды под разные оси.
М>>>сильно. а какое отношение это имеет к JIT и прочим умным словам? Ф>>это имеет отношение к .Net. М>создание 400х чекбоксов в гриде? помилуйте. давайте использовать инструменты по назначению. какие проблемы реализовать _один_ элемент управления самостоятельно? совсем уже обленились. тут же тривиально все. будет летать на любой платформе. давайте я вам не буду объяснять сколько ресурсов кушает один элемент управления?
Там получается каждый чекбокс в одно окно GUI? Тогда действительно маразм, но даже не WPF или дотнета, а виндового GUI — что нет отдельного понятия widget, хотя надо было сделать ещё лет 10 назад.
Ф>> именно библиотеки хорошо характеризуют платформу, на которой они написаны М>создание 400х чек-боксов показывает, что программисты совсем разучились думать и хотят готовых _стандартных_ компонентов под нестандартную задачу, хотя она на чем угодно реализуется элементарно и без тормозов и без ограничения на кол-во элементов в гриде. хоть миллион на миллион. ловим событие "щелчок", смотрим где мыша, вычисляем позицию верхнего левого угла элемента, из битового массива берем его состояние, меняем на противоположное и рисуем либо галку либо пустое место.
А так ещё лучше — хотя надо откуда-то изображения галочек взять. Это ж целого дизайнера привлекать.
Здравствуйте, stasgoo, Вы писали:
S>Здравствуйте, Mamut, Вы писали:
M>>При установке прогонять аналог ngen'а, и все пучком, по идее
S>Не получится пучков У JIT-а есть фатальный недостаток: безблагодатность жёсткие ограничения на время работы. Как бы не хотелось, но от многих оптимизаций придётся отказаться, чтобы пользователь не фалломорфировал, полдня ожидая JIT при запуске офиса.
Зато их вполне можно делать инкрементально. Выделить один тред и пол-ядра (или сколько сказано в настройках) на работу statclock profiler (такой, что меряет место работы по таймерным сигналам) и напускать JIT на занятые места, контролируя, чтобы он не превысил разрешённую долю процессорного ресурса системы. Технологически это тривиально.
Здравствуйте, Трололоша, Вы писали:
Т>Здравствуйте, stasgoo, Вы писали:
S>>Интеловское небязательно. Но если будем компилить с максимальной оптимизацией надо чтобы все расширения типа SSE3 присутствовали. Т>На AMD я сталкивался с забавным: по флагам проца поддержка SSE3 есть, а по факту падает с illegal instruction.
Какая модель процессора? Какая ОС?
(вообще-то очень слабо верится, слишком очевидный ляп.)
Здравствуйте, netch80, Вы писали:
N>Здравствуйте, stasgoo, Вы писали:
S>>Здравствуйте, Mamut, Вы писали:
M>>>При установке прогонять аналог ngen'а, и все пучком, по идее
S>>Не получится пучков У JIT-а есть фатальный недостаток: безблагодатность жёсткие ограничения на время работы. Как бы не хотелось, но от многих оптимизаций придётся отказаться, чтобы пользователь не фалломорфировал, полдня ожидая JIT при запуске офиса.
N>Зато их вполне можно делать инкрементально. Выделить один тред и пол-ядра (или сколько сказано в настройках) на работу statclock profiler (такой, что меряет место работы по таймерным сигналам) и напускать JIT на занятые места, контролируя, чтобы он не превысил разрешённую долю процессорного ресурса системы. Технологически это тривиально.
.net 4.5 так и делает, собирает статистику, а потом в бекграунде ngen-ит, то что часто используется
Здравствуйте, IT, Вы писали:
IT>>>У вас трейдеры прямо с собственных телефонов торгуют? Впервые слышу. Что касается браузеров, то тут java точно не нужна. Это ошибка, переходите срочно на ASP.NET MVC. G>>Вообще-то трейдинговых приложений под iPhone/iPad вагон и маленькая тележка.
IT>Например, amazon.com.
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, LaPerouse, Вы писали:
LP>>Признай наконец, что ляпнул чушь. IT>Давай так. Ты выключишь свою демагогию, а я свою включать не буду. Договорились? Вот и славненько.
Стандарты демагогии в этой ветке устанавливаешь именно ты.
LP>>Если логика вынесена на клиент, существует возможность замены это логики путем изменения клиента. Если логика на сервере, то на нее можно влиять только подбором входных данных; верификация эти данных на стороне сервера способно устранить большинство проблем. IT>Я не знаю в каком окружении вы работаете и какой у вас уровень доверия к пользователям, но у нас описываемые тобой проблемы отсутствуют как класс.
У нас заказчики незапароленный дамп бд в пубичные фалообменники заливают, поэтому затраты на безопасность финансово неоправданны. Но ты-то пишешь для банков, поэтому уровень безопасности должен быть не просто другой, а качественно другой.
IT>>>Так ты про энергенику. А мы тут всё больше про банки. LP>>Не знаю про что вы говорите, я говорю о .net и java.
IT>Юлишь. То ты про то, что должно быть известно разработчику банковских систем. Потом вдруг сразу "Какие еще трейдеры?". А теперь оказывается ты не знаешь про что вы говорите
Я тебе назвал конкретный факт, который должен быть известен разработчику банковских систем, но сам факт имеет отношение не только к финансовой среде. Демагогию разводишь.
LP>>На RSDN была новость о том, что команду разработчиков разогнали, оставив лишь двоих для выпуска последней версии. Вот я и спрашиваю, кто же прав, о каком переходе на личности ты говоришь? IT>Мало ли кто где кого разогнал и по каким причинам? Ты прямо такой доверчивый, что веришь любой новости на RSDN.
Нет бы дать ссылку, хоть как-то подтверждающую свои слова. Я сослался на новость, а ты на что?
Социализм — это власть трудящихся и централизованная плановая экономика.
M>>Стопстопстоп. Отрисовка грида с 20x20 чекбоксов — это настолько сложня задача, что вся выделенная хрень не может с этим справится? MM>Не понял. А причем здесь влияние "выделенной хрени"? Биндинги к рендерингу вообще никак не относятся... Ладно, давай по другому напишу. Когда ты создаешь чекбоксы средствами HTML, то по сути ты говоришь браузеру отрендерить чекбоксы. Причем набор вариантов ограничен допустимыми значениями тега type и слабыми возможностями влияния на внешний вид чекбокса. В результате браузеру не нужно особо напрягаться. Он видит всю картину — столько-то чекбоксов на такой-то площади экрана. Он заранее знает, как это оптимизировать, ведь внешний вид вполне себе фиксирован... Теперь берем WPF. Каждый чекбокс оказывается отдельным контролом. Контрол поддерживает шаблоны, предугадать его внешний вид нереально. Я могу туда хоть таб-контрол запихнуть! Целостной картины тоже нет. Всё это впихнуто в грид, который тоже контрол со своими заморочками. Свободы для оптимизации значительно меньше. Зато фич по кастомизации больше. За них и платим.
Это все — демагогия, пытающаяся прикрыть отмазки, пытающиеся прикрыть кривизну реализации. Ничего из описанного даже близко не объясняет, почему грид с 20x20 чекбоксами тормозит.
Здравствуйте, MxMsk, Вы писали: M>>Стопстопстоп. Отрисовка грида с 20x20 чекбоксов — это настолько сложня задача, что вся выделенная хрень не может с этим справится? MM>Не понял. А причем здесь влияние "выделенной хрени"? Биндинги к рендерингу вообще никак не относятся... Ладно, давай по другому напишу. Когда ты создаешь чекбоксы средствами HTML, то по сути ты говоришь браузеру отрендерить чекбоксы. Причем набор вариантов ограничен допустимыми значениями тега type и слабыми возможностями влияния на внешний вид чекбокса. В результате браузеру не нужно особо напрягаться. Он видит всю картину — столько-то чекбоксов на такой-то площади экрана. Он заранее знает, как это оптимизировать, ведь внешний вид вполне себе фиксирован... Теперь берем WPF. Каждый чекбокс оказывается отдельным контролом. Контрол поддерживает шаблоны, предугадать его внешний вид нереально. Я могу туда хоть таб-контрол запихнуть! Целостной картины тоже нет. Всё это впихнуто в грид, который тоже контрол со своими заморочками. Свободы для оптимизации значительно меньше. Зато фич по кастомизации больше. За них и платим.
HTML тут практически такие же возможности предоставляет что и WPF в плане кастомизации внешнего вида чекбокса.
M>Который jQuery, тупое создание 400 чекбоксов с максимально тупым назначением событий каждому чекбоксу... И не тормозит. Более того, создание аналогичного в каком-нить ExtJS тоже не будет тормозить.
M>Но нет, в WPF это низзя ни в коем случае, вы шо. Нужно в обязательном порядке делать собственный контрол на каждый чих? Где эти чихи начинаются? На 20 чекбоксах? На 30?
Давайте мух от котлет...
В приведенной ссылке автор написал 400 про чекбоксов в гриде и тормоза. И все. Как эти тормоза проявляются и прочая — неизвестно.
Пока единственное, что удалось возпроизвести это то, что при создании 400 чекбоксов форма при ресайзе жрет процессор и не всегда поспевает за мышкой. (тупо хватаем мышкой правый нижний угол и начинаем судоржно таскать)
В остальном — кликанье, изменение состояния чекбокса — тормозов нет.
В этом плане приведенный вами выше пример ведет себя практически так же как и в WPF (браузер — Chrome).
Кстати, в той же теме чуть ниже отписались, что в VCL поведение идентичное.
Здравствуйте, syrompe, Вы писали:
S>HTML тут практически такие же возможности предоставляет что и WPF в плане кастомизации внешнего вида чекбокса.
Какие, например? Я с HTML почти не сталкиваюсь, так что могу и не знать.
Здравствуйте, MxMsk, Вы писали:
MM>Здравствуйте, syrompe, Вы писали:
S>>HTML тут практически такие же возможности предоставляет что и WPF в плане кастомизации внешнего вида чекбокса. MM>Какие, например? Я с HTML почти не сталкиваюсь, так что могу и не знать.
Здравствуйте, syrompe, Вы писали:
S>>>HTML тут практически такие же возможности предоставляет что и WPF в плане кастомизации внешнего вида чекбокса. MM>>Какие, например? Я с HTML почти не сталкиваюсь, так что могу и не знать. S>скыдыщь
Если я правильно понял, там кастомный вид создают картинками.
Как это будет работать на мониторах с разной настройкой DPI?
Как это учитывает цветовую схему ОС?
Здравствуйте, Mamut, Вы писали:
M>А ты сам этого не видишь? Понимаешь, 20x20 чекбоксов, как их ни рисуй — это настолько мизер, что даже удивительно, что торможение грида пытаются объхяснить чем угодно, лишь бы не кривизной фреймворка.
Вот здесь
очень правильный камент. Не фига непонятно из примера, что там тормозит. Я пробовал прикинуть, что может создавать нагрузку с учетом архитектуры WPF, а сейчас накидал грид 20 x 20 и не тормозит чего-то. Что делать, теперь не знаю.
Здравствуйте, MxMsk, Вы писали:
MM>Здравствуйте, syrompe, Вы писали:
S>>>>HTML тут практически такие же возможности предоставляет что и WPF в плане кастомизации внешнего вида чекбокса. MM>>>Какие, например? Я с HTML почти не сталкиваюсь, так что могу и не знать. S>>скыдыщь MM>Если я правильно понял, там кастомный вид создают картинками. MM>Как это будет работать на мониторах с разной настройкой DPI? MM>Как это учитывает цветовую схему ОС?
В WPF в 90% случаев иконки тоже делают картинками (PNG).
В HTML есть Canvas — так что тоже можно нарисовать в векторе.
В HTML тоже можно размеры задавать в Pixel independent единицах.
А как WPF учитывает цветовую схему ОС?
M>>А ты сам этого не видишь? Понимаешь, 20x20 чекбоксов, как их ни рисуй — это настолько мизер, что даже удивительно, что торможение грида пытаются объхяснить чем угодно, лишь бы не кривизной фреймворка. MM>Вот здесь
очень правильный камент. Не фига непонятно из примера, что там тормозит. Я пробовал прикинуть, что может создавать нагрузку с учетом архитектуры WPF, а сейчас накидал грид 20 x 20 и не тормозит чего-то. Что делать, теперь не знаю.
Здравствуйте, syrompe, Вы писали:
S>В WPF в 90% случаев иконки тоже делают картинками (PNG).
Так речь же не об иконках. Речь о ControlTemplate, возможности которого создают нехилый оверхэд. К слову, у нас в проекте все картинки — векторные Drawing и Geometry.
S>В HTML есть Canvas — так что тоже можно нарисовать в векторе.
Вот пускай мне предоставят пример, где все чекбоксы нарисованы Canvas-ом в векторе
S>В HTML тоже можно размеры задавать в Pixel independent единицах.
Да, но в готовых PNG не задашь.
S>А как WPF учитывает цветовую схему ОС?
Шаблоны контролов используют DynamicResource на ключи из SystemColors.
Здравствуйте, netch80, Вы писали:
N>Какая модель процессора? Какая ОС?
модель уже не вспомню. А от OС cpuid не зависит.
N>(вообще-то очень слабо верится, слишком очевидный ляп.)
Здравствуйте, neFormal, Вы писали:
F>легко собирается, если нет привязок к винде или не-дотнет штукам.. F>даже я писал на шарпах под линухом, а потом запускался под виндами..
А наоборот?
Здравствуйте, Mamut, Вы писали:
M>>>Ты будешь возражать, что найдутся проекты, которые не собираются под gcc, но собирающиеся под Microsoft C++ compiler и наоборот? S>>Нет
M>Так в чем вопрос? Mono и MS .net Framework реализуют один и тот же стандарт. В MS .net Framework просто дополнительные windows-зависимые библиотеки. Так же, как есть платформо-зависимые библиотеки для С++
M>Но я повторяюсь. Это все было пройдено два-три года тому назад.
И тогда же мы выяснили что моно — кроссплатформенен, а дотнет — нет.
Ф>>> именно библиотеки хорошо характеризуют платформу, на которой они написаны М>>создание 400х чек-боксов показывает, что программисты совсем разучились думать и хотят готовых _стандартных_ компонентов под нестандартную задачу, хотя она на чем угодно реализуется элементарно и без тормозов и без ограничения на кол-во элементов в гриде. хоть миллион на миллион. ловим событие "щелчок", смотрим где мыша, вычисляем позицию верхнего левого угла элемента, из битового массива берем его состояние, меняем на противоположное и рисуем либо галку либо пустое место.
N>А так ещё лучше — хотя надо откуда-то изображения галочек взять. Это ж целого дизайнера привлекать.
Оу. Делаем одну галочку на чем вам нравится. Принтскрин. Паинт, или что там еще. Вырезаем квадратик. Делаем то же со всем стадиями галочки, которые нам нужны. Вставляем в ресурсы приложения, рисуем картинку. Профит!
Новости очень смешные. Зря вы не смотрите. Как будто за наркоманами подсматриваешь. Только тетка с погодой в завязке.
There is no such thing as a winnable war.
S>>Не получится пучков У JIT-а есть фатальный недостаток: безблагодатность жёсткие ограничения на время работы. Как бы не хотелось, но от многих оптимизаций придётся отказаться, чтобы пользователь не фалломорфировал, полдня ожидая JIT при запуске офиса.
N>Зато их вполне можно делать инкрементально. Выделить один тред и пол-ядра (или сколько сказано в настройках) на работу statclock profiler (такой, что меряет место работы по таймерным сигналам) и напускать JIT на занятые места, контролируя, чтобы он не превысил разрешённую долю процессорного ресурса системы. Технологически это тривиально.
Да и, вобще-то, на кой черт компилить все подряд? Большинство кода занимает от силы сотые доли процентов проца при выполнении, но этого кода в приложении большинство. Его компиль-не компиль, ничего в производительности не выиграешь.
Кстати, отчасти потому на серверах и распространились платформы с байткодом и джитом. Времени у последнего на выявление узких мест предостаточно, а все остальное просто нет смысла компилить в нативу. А десктопные приложения на той же жабе запускаются всегда в "клиентском" режиме, т.е. без джита вообще, ибо бессмысленно. Кому надо — ключик укажет явно, если есть узкие места(т.е. серьезные рассчеты).
Новости очень смешные. Зря вы не смотрите. Как будто за наркоманами подсматриваешь. Только тетка с погодой в завязке.
There is no such thing as a winnable war.
M>А ты сам этого не видишь? Понимаешь, 20x20 чекбоксов, как их ни рисуй — это настолько мизер, что даже удивительно, что торможение грида пытаются объхяснить чем угодно, лишь бы не кривизной фреймворка.
Даже не в в плохой час упомянутая джава, у которой это и контролы с каждым окошком для каждого(прада, внутренним жабовским, а не нативными, но плюс ли это?), и сложная модель для отрисовки запрашивается каждый раз, и еще и рисуется это на канвасе интерпритатором, без всякого ускорения, на этом если и притормаживает, то только из-за пресловутой отрисовки на канвасе без нативы, точечка-по-точечке в интерпритируемом коде. А то и вовсе не тормозит, смотря какой комп. Чего там напихали в тот ВПФ, у которого отрисовка вообще видеокартой идет, я не знаю.
Новости очень смешные. Зря вы не смотрите. Как будто за наркоманами подсматриваешь. Только тетка с погодой в завязке.
There is no such thing as a winnable war.
Здравствуйте, Евгений Акиньшин, Вы писали:
ЕА>.net 4.5 так и делает, собирает статистику, а потом в бекграунде ngen-ит, то что часто используется
Это ты про их сервисы типа clr_optimization_vXXXXX ?
Здравствуйте, MxMsk, Вы писали:
MM>Теперь берем WPF. Каждый чекбокс оказывается отдельным контролом. Контрол поддерживает шаблоны, предугадать его внешний вид нереально. Я могу туда хоть таб-контрол запихнуть! Целостной картины тоже нет. Всё это впихнуто в грид, который тоже контрол со своими заморочками. Свободы для оптимизации значительно меньше. Зато фич по кастомизации больше. За них и платим.
O. M. F. G.!
Робяты, вам не кажется что вас где то жестоко нае....?
Вы по сути выкладываете дофига сил на борьбу с "фичами по кастомизации".
Здравствуйте, Eugeny__, Вы писали:
E__>Даже не в в плохой час упомянутая джава, у которой это и контролы с каждым окошком для каждого(прада, внутренним жабовским, а не нативными, но плюс ли это?), и сложная модель для отрисовки запрашивается каждый раз, и еще и рисуется это на канвасе интерпритатором, без всякого ускорения, на этом если и притормаживает, то только из-за пресловутой отрисовки на канвасе без нативы, точечка-по-точечке в интерпритируемом коде. А то и вовсе не тормозит, смотря какой комп. Чего там напихали в тот ВПФ, у которого отрисовка вообще видеокартой идет, я не знаю.
Мы уже выяснили, что это я пытался бороться с ветрянными мельницами, а их оказывается и нет. В том плане, что когда не фантазируешь, а бацаешь пример, то ничего не тормозит. Поэтому, нужно узнать, что такого специфического сделал автор. Видимо там есть какое-то условие, приводящее к тормозам. Может он эффекты битмэповые накатил — они переводят отрисовку в программную и сейчас уже obsolete. О! Я тут подумал. А может быть у него Binding-и слетели и Студия постоянно пишет об этом сообщения в Trace? Это может вызывать тормоза при отладке, которых в Release, естественно, нет.
Здравствуйте, alex_public, Вы писали:
_>Кстати, я вот не однократно замечаю, что многие люди в спорах типа Java или .Net против Native зацикливаются на байткоде. Т.е. одни говорят что это самое классное, а другие на оборот ругают его... В то время как на мой взгляд это вообще ерунда. И кстати появление llvm это только подтверждает. Принципиальное отличие Java и .Net от нативных языков в том, что они по сути испольняются в своей виртуальной машине, которая накладывает огромные ограничения. А вот в каком виде у нас код не имеет особого значения. В отдельных случаях удобнее байткод просто, в каких-то байткод с jit, а в каких-то и машинные коды. И это по идее одинаково должно быть для всех языков и платформ. Просто в зависимости от специализации языка какие-то направления у него могут быть слабее развиты.
_>Кстати, я вот не однократно замечаю, что многие люди в спорах типа Java или .Net против Native зацикливаются виртуальной машине. Так вот никакой виртуальной машины нет. Байткод компилируется непосредственно в машинный код. Также существует расхожее заблуждение что "виртуальная машина" что-то ограничивает. Но по сути она дает даже больше возможностей. Например генерация типобезопасного кода во время работы программы. Оптимизация динамически типизированного кода. И даже банальную возможность возвращать из функции лямбду с честным замыканием.
Здравствуйте, Kingofastellarwar, Вы писали:
K>Здравствуйте, Uzumaki Naruto, Вы писали:
UN>>Рассмотрим на примере java... все работает прекрасно на всех платформах...
K>прекрасно это как? я лично не видел ни одного приложения на жаве, которое прекрасно работало хотя б под линухом, вендой и макосью.
UN>>Рассмотрим правильное кроссплатформеное программирование под С/C++ — все прекрасно компилируется под любые платформы — от PC до мобильных...
K>ясное дело что оно комплируется, заставить скомпилирвоать можно всё, тока вот писать на таком не тянет совсем.
Я в эклипсе и под виндой и под линуксом работаю. Что не так с ним?
UNIX way — это когда тебе вместо туалетной бумаги дают топор, рубанок и карту близлежащего леса
Server Error in '/' Application.
Runtime Error
Description: An application error occurred on the server. The current custom error settings for this application prevent the details of the application error from being viewed remotely (for security reasons). It could, however, be viewed by browsers running on the local server machine.
Здравствуйте, esil, Вы писали:
E>Здравствуйте, _d_m_, Вы писали:
___>>Не порите чушь, ей больно! ___>>Вот лучше почитай, что умные люди пишут: ___>>http://blogs.msdn.com/b/ruericlippert/archive/2011/12/01/why-il.aspx
E>Умный человек так и не ответил на поставленный самому себе вопрос: "Зачем распространять скомпилированные программы в виде IL?"
Вот эта фраза тебе ни о чем не говорит? :
Предположим, у вас есть несколько языков программирования: C#, VB, F#, JScript .NET и т.д. И, предположим, у вас есть m сред времени выполнения: компьютеры с ОС Windows, работающие на процессорах x86 или x64, XBOX 360, телефоны, Silverlight, работающий на Мак-е… и предположим, что мы используем подход с одним компилятором. Какое количество генераторов кода вам придется написать внутри вашего компилятора? Для каждого языка программирования вам придется написать кодогенератор для каждого окружения, в результате, придется написать n x m генераторов.
Здравствуйте, gandjustas, Вы писали:
G>Здравствуйте, alex_public, Вы писали:
_>Кстати, я вот не однократно замечаю, что многие люди в спорах типа Java или .Net против Native зацикливаются виртуальной машине. Так вот никакой виртуальной машины нет. Байткод компилируется непосредственно в машинный код. Также существует расхожее заблуждение что "виртуальная машина" что-то ограничивает. Но по сути она дает даже больше возможностей. Например генерация типобезопасного кода во время работы программы. Оптимизация динамически типизированного кода. И даже банальную возможность возвращать из функции лямбду с честным замыканием.
Это был бы хороший, годный троллинг, если бы не очевидные ляпы как по форме, так и по содержанию. По форме — ты не снял квотинг (кстати, тут за него начали штрафовать). По содержанию — это грубо неверно. Байткод может не компилироваться в машинный код, а исполняться интерпретатором с выбором ветки на каждый байт. Виртуальная машина действительно ограничивает, даже если даёт больше возможностей на что-то другое. А перечисленные тобой возможности относятся к функциональным дополнениям, которые можно сделать и самому, если машина в принципе это позволяет; это не увеличение набора возможностей, а помощь в реализации существующих.
Здравствуйте, _d_m_, Вы писали:
___>Вот эта фраза тебе ни о чем не говорит? :
___>
___>Предположим, у вас есть несколько языков программирования: C#, VB, F#, JScript .NET и т.д. И, предположим, у вас есть m сред времени выполнения: компьютеры с ОС Windows, работающие на процессорах x86 или x64, XBOX 360, телефоны, Silverlight, работающий на Мак-е… и предположим, что мы используем подход с одним компилятором. Какое количество генераторов кода вам придется написать внутри вашего компилятора? Для каждого языка программирования вам придется написать кодогенератор для каждого окружения, в результате, придется написать n x m генераторов.
Не очень понятно всё же причём тут рассуждения про байткод и вопрос кроссплатформенности. Или вы считаете что наличие возможности компиляции в байткод, единый для разных архитектур, является главным фактором кроссплатформенности? При таком подходе ооооооооооооочень много языков и технологий можно посчитать за кроссплатформенные. Только на практике почему то не так это.
Там про двоичную совместимость вообще ни слова. Хотя, фантазии, заменяющие тебе процесс мышления, никогда не дадаут тебе возможность это увидеть. S>Ты пытаешься свернуть дотнет практически до "это просто язык шарп и куча библиотек, шарп — язык и кроссплатформенность ему ортогональна, а библиотеки это библиотеки, они к языку отношения не имеют"
А что, не так?
Почему-то, когда речь заходит о С++ все так, а тут ВНЕЗАПНО не так.
S>Нет уж, тут котят от котлет не отделишь. Есть дотнет. Есть моно. Это не одно и тоже.
Есть intel c++ compiler, есть gcc, есть microsoft c++ compiler. Это не одно и то же
Есть кроссплатформенный Qt, есть чисто виндовый MFC и чисто линуксовые, скажем, KDE'шные библиотеки. Это тоже не одно и то же.
Но при этом С++, по твоим же уверждениям, кроссплатформенный. Для тебя это нормально.
Как только примняешь ту же логику к .net'у, у тебя моментально включаются двойные стандарты.
Там про двоичную совместимость вообще ни слова. Хотя, фантазии, заменяющие тебе процесс мышления, никогда не дадаут тебе возможность это увидеть.
M> S>Ты пытаешься свернуть дотнет практически до "это просто язык шарп и куча библиотек, шарп — язык и кроссплатформенность ему ортогональна, а библиотеки это библиотеки, они к языку отношения не имеют"
M> А что, не так?
M> Почему-то, когда речь заходит о С++ все так, а тут ВНЕЗАПНО не так.
Мамут, а тебе слово Framework ни о чем не говорит? Я думал, ты это понял, два года назад.
Здравствуйте, gandjustas, Вы писали:
g>Кстати, я вот не однократно замечаю, что многие люди в спорах типа Java или .Net против Native зацикливаются виртуальной машине. Так вот никакой виртуальной машины нет. Байткод компилируется непосредственно в машинный код. Также существует расхожее заблуждение что "виртуальная машина" что-то ограничивает. Но по сути она дает даже больше возможностей. Например генерация типобезопасного кода во время работы программы. Оптимизация динамически типизированного кода. И даже банальную возможность возвращать из функции лямбду с честным замыканием.
Да, кое-какие небольшие плюсы от неё есть. Помню как меня порадовала возможность динамической загрузки классов в программу, когда я впервые стал смотреть на Java. Но все они являются как бы не уникальными — в нейтиве всё тоже самое возможно, просто с помощью отдельных технологий (типа COM например).
А вот ограничения "виртуальной машины" у Java и .Net огромные и главное принципиально не устранимые никакими дополнениями...
Здравствуйте, alex_public, Вы писали:
_>А вот ограничения "виртуальной машины" у Java и .Net огромные и главное принципиально не устранимые никакими дополнениями...
Можно перечислить основные ограничения "виртуальной машины" дотнета?
M>> Почему-то, когда речь заходит о С++ все так, а тут ВНЕЗАПНО не так.
H>Мамут, а тебе слово Framework ни о чем не говорит? Я думал, ты это понял, два года назад.
Здравствуйте, Mamut, Вы писали:
M> M>> Почему-то, когда речь заходит о С++ все так, а тут ВНЕЗАПНО не так.
M> H>Мамут, а тебе слово Framework ни о чем не говорит? Я думал, ты это понял, два года назад.
M> http://rsdn.ru/forum/flame.comp/3893346.1.aspx
Ты пойми, совершенно фиолетово, что там стандартизировано, а чего нет. Когда речь идет о переносимости фреймвока так и нужно говорить о фреймвоке, а не той его части на которую распространяется стандарт. Иначе ваши слова есть ни что иное как лукавство.
Ты пойми, совершенно фиолетово, что там стандартизировано, а чего нет. Когда речь идет о переносимости фреймвока так и нужно говорить о фреймвоке, а не той его части на которую распространяется стандарт. Иначе ваши слова есть ни что иное как лукавство.
Осталось понять, что имеет в виду Шеридан, когда говорит «дотнет». Дальше — по ссылке
Здравствуйте, NikeByNike, Вы писали:
NBN> НС>Можно перечислить основные ограничения "виртуальной машины" дотнета?
NBN> Отсутствие кроссплатформенности.
Виртуальная машина, как раз таки, вполне себе переносима
.
H>Ой, да перестань. Не нужно делать вид, будто ты не понимаешь, что когда говорят .NET имеется ввиду платформа Microsoft .NET, с её полным названием Microsoft .NET Framework.
Нет, не понимаю. Учитывая, что здесь люди уже приводили примеры нормальной кроссплатформенной разработки с использованием как моно, так и ms.net'а.
MM>Мы уже выяснили, что это я пытался бороться с ветрянными мельницами, а их оказывается и нет. В том плане, что когда не фантазируешь, а бацаешь пример, то ничего не тормозит. Поэтому, нужно узнать, что такого специфического сделал автор. Видимо там есть какое-то условие, приводящее к тормозам. Может он эффекты битмэповые накатил — они переводят отрисовку в программную и сейчас уже obsolete. О! Я тут подумал. А может быть у него Binding-и слетели и Студия постоянно пишет об этом сообщения в Trace? Это может вызывать тормоза при отладке, которых в Release, естественно, нет.
Да скорее всего. Часто проблема не там, где ее ищешь, это да. Я сталкивался с тормозами из-за излишнего логгирования. Банально потому, что оно выполняется в том же потоке.
Новости очень смешные. Зря вы не смотрите. Как будто за наркоманами подсматриваешь. Только тетка с погодой в завязке.
There is no such thing as a winnable war.
_>Кстати, я вот не однократно замечаю, что многие люди в спорах типа Java или .Net против Native зацикливаются на байткоде. Т.е. одни говорят что это самое классное, а другие на оборот ругают его... В то время как на мой взгляд это вообще ерунда. И кстати появление llvm это только подтверждает. Принципиальное отличие Java и .Net от нативных языков в том, что они по сути испольняются в своей виртуальной машине, которая накладывает огромные ограничения.
Но при этом и дает местами шикарные возможности(та же рефлексия позволяет за счет пары утилитарных классов снижать размер кода в десятки раз, причем если это не берется из конфигов, то тормозит оно ровно до первого прохода jit(ибо реально для каждого случая ровно 1 нить исполнения получается) — я напишу развернутый пост об этом, ибо как раз сейчас занимаюсь переводом сишного проекта в жабу(100 строк с++ превращаются в 10 жабовских), только как закончу, хоть это и не скоро).
Которые, к слову, будут только расширяться.
Новости очень смешные. Зря вы не смотрите. Как будто за наркоманами подсматриваешь. Только тетка с погодой в завязке.
There is no such thing as a winnable war.
Здравствуйте, NikeByNike, Вы писали:
NBN> NBN>> Отсутствие кроссплатформенности.
NBN> H>Виртуальная машина, как раз таки, вполне себе переносима
NBN> С++ в теории тоже хорош.
.
M> H>Ой, да перестань. Не нужно делать вид, будто ты не понимаешь, что когда говорят .NET имеется ввиду платформа Microsoft .NET, с её полным названием Microsoft .NET Framework.
M> Нет, не понимаю.
.
M>> H>Ой, да перестань. Не нужно делать вид, будто ты не понимаешь, что когда говорят .NET имеется ввиду платформа Microsoft .NET, с её полным названием Microsoft .NET Framework.
M>> Нет, не понимаю.
H>Тяжело тебе...
Тяжело вам, что вы не можете внятно объяснить, что вы хотите, и что вам нужно.
Здравствуйте, NikeByNike, Вы писали:
NBN> NBN>> С++ в теории тоже хорош.
NBN> H>Практика показывает, что он даже лучше
NBN> Для мобильной области и геймдева — однозначно
NBN> Хз на счёт серверной
Не помнишь, куда там транслировался фейсбучный похапэ?
Здравствуйте, Ночной Смотрящий, Вы писали:
E>>кто-то уже научился инлайнить функции из скомпилированных разделяемых библиотек?
НС>Да, дотнет.
Что стырено из джавы, но тем не менее, очень даже работает.
Я вам хуже скажу. В джаве можно получить вообще неизвестный класс черти откуда(тупым потоком байт из сети загрузить кастомным класслоадером как Object, но можно придумать и более изощренный сценарий), создать экземпляр(или же вызывать статику — неважно), проверить его на наличие нужного нам метода, и часто вызывать его через рефлексию, даже не кастуя ни к какому известному интерфейсу. И... Внезапно по нему пройдется джит, увидит, что вызываемый метод у класса есть, и его имя в программе статическая строка(т.е. оно выполняется, и будет всегда выполняться именно так). И он его заинлайнит, убрав рефлексию, плюс скомпилит в нативу. Очень прошу примера, как такое возможно в нативе. Это немного похоже на ком(тоже слепой вызов), вот только ком объект не инлайнится никогда. Ваш выход, господа.
Новости очень смешные. Зря вы не смотрите. Как будто за наркоманами подсматриваешь. Только тетка с погодой в завязке.
There is no such thing as a winnable war.
Здравствуйте, Eugeny__, Вы писали:
E__>Что стырено из джавы, но тем не менее, очень даже работает.
Это не может быть стырено из джавы, потому что в джаве вообще нет сущности, соответствующей библиотеке. У них класс заодно и единица деплоймента, и умение инлайнить методы чужих классов жизненно необходимо.
E__> И... Внезапно по нему пройдется джит, увидит, что вызываемый метод у класса есть, и его имя в программе статическая строка(т.е. оно выполняется, и будет всегда выполняться именно так). И он его заинлайнит, убрав рефлексию
Здравствуйте, NikeByNike, Вы писали:
NBN> NBN>> Хз на счёт серверной
NBN> H>Не помнишь, куда там транслировался фейсбучный похапэ?
NBN> Ты задаёшь далёкие от меня вопросы
Здравствуйте, Eugeny__, Вы писали:
E__>ибо как раз сейчас занимаюсь переводом сишного проекта в жабу(100 строк с++ превращаются в 10 жабовских)
У тебя похоже весь С++ код сплошь и рядом самописный, за исключением вызовов стандартных либ.
Здравствуйте, Ночной Смотрящий, Вы писали:
_>>А вот ограничения "виртуальной машины" у Java и .Net огромные и главное принципиально не устранимые никакими дополнениями...
НС>Можно перечислить основные ограничения "виртуальной машины" дотнета?
Ну, как минимум с нативными вещами нужно работать через интероп. Вызвать напрямую инструкцию процессора, или получить байты с usb не выйдет.
Новости очень смешные. Зря вы не смотрите. Как будто за наркоманами подсматриваешь. Только тетка с погодой в завязке.
There is no such thing as a winnable war.
Здравствуйте, NikeByNike, Вы писали:
NBN> НС>Это именно отсутствие, а не ограничение. Ну и, если говорить о CLR, то Моно пока никто не отменял.
NBN> Это очень куцее всё с точки зрения CP. С++ + Qt сейчас наверное самое-самое, в общем случае.
Есть еще FreePascal + Lazarus. Там, кажется, даже BeOS поддерживается
Здравствуйте, Eugeny__, Вы писали:
E> _>Да, кое-какие небольшие плюсы от неё есть. Помню как меня порадовала возможность динамической загрузки классов в программу, когда я впервые стал смотреть на Java. Но все они являются как бы не уникальными — в нейтиве всё тоже самое возможно, просто с помощью отдельных технологий (типа COM например).
E> Ну, ставить com и динамическую подгрузку классов в жабе(а там еще и класслоадер можно заменить — иногда это такие возможности дает) — это глупость. Ком — это действие вслепую, и вообще дикий костыль.
Ладно, не нравится тебе COM... У дельфей есть пакеты (bpl), тоже можно загрузку динамическую организовать (и подозреваю, что как и в жабе, можно обеспечить прозрачную загрузку из сети)
Здравствуйте, Eugeny__, Вы писали:
E> Но при этом и дает местами шикарные возможности(та же рефлексия позволяет за счет пары утилитарных классов снижать размер кода в десятки раз, причем если это не берется из конфигов, то тормозит оно ровно до первого прохода jit(ибо реально для каждого случая ровно 1 нить исполнения получается) — я напишу развернутый пост об этом, ибо как раз сейчас занимаюсь переводом сишного проекта в жабу(100 строк с++ превращаются в 10 жабовских), только как закончу, хоть это и не скоро). E> Которые, к слову, будут только расширяться.
Рефлексия это не прерогатива менеджед платформ У нынешних дельфей (и видимо C++ Builder'а) RTTI такой, что мама не горюй.
Здравствуйте, Eugeny__, Вы писали:
E__>Ну, как минимум с нативными вещами нужно работать через интероп.
Не обязательно. Это только у джавы такое ограничение. Интероп нужен для относительно безопасной работы с нейтивом.
E__> Вызвать напрямую инструкцию процессора,
Здравствуйте, hattab, Вы писали:
H>У дельфей есть пакеты (bpl), тоже можно загрузку динамическую организовать (и подозреваю, что как и в жабе, можно обеспечить прозрачную загрузку из сети)
H>Да я более чем внятно все объяснял, даже ссылку на вики давал (поверь, там описано все очень внятно). Я думаю тут есть явное нежелание сторонников дотнета признать тот простой факт, что он не кроссплатформенен
дотнет — это три разные сущности, какую из них ты имеешь в виду (и да, то, что МС называет эти три сущности одним именем, делу не помогает)
Здравствуйте, NikeByNike, Вы писали:
НС>>Можно перечислить основные ограничения "виртуальной машины" дотнета?
NBN>Отсутствие кроссплатформенности.
Ну так она особо и не планировалась. Моно — это продукт совсем другой конторы. А у той же джавы Сан, а потом Оракл, как вендор, гарантирует именно переносимость между разными _платформами_, а не разными версиями ОС.
Новости очень смешные. Зря вы не смотрите. Как будто за наркоманами подсматриваешь. Только тетка с погодой в завязке.
There is no such thing as a winnable war.
Здравствуйте, Eugeny__, Вы писали:
E__>Ну так она особо и не планировалась. Моно — это продукт совсем другой конторы. А у той же джавы Сан, а потом Оракл, как вендор, гарантирует именно переносимость между разными _платформами_, а не разными версиями ОС.
Вот и получается, что такая хорошая штука, а неприменима.
Здравствуйте, Mamut, Вы писали:
M> H>Да я более чем внятно все объяснял, даже ссылку на вики давал (поверь, там описано все очень внятно). Я думаю тут есть явное нежелание сторонников дотнета признать тот простой факт, что он не кроссплатформенен
M> дотнет — это три разные сущности, какую из них ты имеешь в виду (и да, то, что МС называет эти три сущности одним именем, делу не помогает)
Здравствуйте, Ночной Смотрящий, Вы писали:
НС> H>У дельфей есть пакеты (bpl), тоже можно загрузку динамическую организовать (и подозреваю, что как и в жабе, можно обеспечить прозрачную загрузку из сети)
НС> А инлайнинг будет работать?
Здравствуйте, Ночной Смотрящий, Вы писали: E__>>Что стырено из джавы, но тем не менее, очень даже работает. НС>Это не может быть стырено из джавы, потому что в джаве вообще нет сущности, соответствующей библиотеке. У них класс заодно и единица деплоймента, и умение инлайнить методы чужих классов жизненно необходимо. E__>> И... Внезапно по нему пройдется джит, увидит, что вызываемый метод у класса есть, и его имя в программе статическая строка(т.е. оно выполняется, и будет всегда выполняться именно так). И он его заинлайнит, убрав рефлексию НС>Пруфлинк можно?
Ну, для начала тестик:
Скрытый текст
import java.lang.reflect.Method;
import java.net.URL;
import java.net.URLClassLoader;
public class Main {
public static void main(String[] args) throws Throwable {
// Вставляйте смело свой URL, откуда хотите.
// но результат будет одинаков - какая нахрен разница, откуда получнеы байты класса?
URLClassLoader loader = new URLClassLoader(new URL[]{new URL("http://files.rsdn.ru/21658/")});
// грузим класс
Class<?> coolClassClass = loader.loadClass("CoolClass");
// инстанс
Object coolClassInst = coolClassClass.newInstance();
//получаем метод через рефлексию
Method method = coolClassClass.getDeclaredMethod("foo", long.class, long.class);
// чисто утилитарноеint result = 0;
long time = System.nanoTime();
//первый проход, без JITfor(long i = 0; i < 1000; i ++) {
result += (Long)method.invoke(coolClassInst, i, i++);
}
System.err.println(System.nanoTime() - time);
time = System.nanoTime();
// Ждем джитfor(long i = 0; i < 100000000; i ++) {
result += (Long)method.invoke(coolClassInst, i, i++);
}
// это время ради прикола
System.err.println(System.nanoTime() - time);
time = System.nanoTime();
//второй проход, после JITfor(long i = 0; i < 1000; i ++) {
result += (Long)method.invoke(coolClassInst, i, i++);
}
System.err.println(System.nanoTime() - time);
// чисто для того, чтобы не перемешался вывод
Thread.sleep(500);
// чтобы компилытор вообще все не убрал
System.out.println(result);
}
}
Исходник класса(минимализируем вычисления, делая акцент на вызове):
Скрытый текст
public class CoolClass {
public long foo(long a, long b){
return a + b;
}
}
Результаты(в наносекундах):
11759187 // это тормоза от рефлексии, 1000 вызовов
3098936672 // разугрев, 100000000 вызовов, где-то посередке прошелся компилятор
343025 // опа, на 2 порядка выше скорость! И те же 1000 вызовов, как в первом случае!
838457712 // это просто вывод результата - без него компилер расслабится и ваще все выкинет
Асм код не предоставлю, по крайней мере пока(увы, нет времени, если кто подскажет, как посмотреть результать компиляции джавовского джита — буду рад). Но результаты джита в этом случае говорят сами за себя. Он делает код на два порядка быстрее. И джиту еще есть куда развиваться.
И да, говорящему "рефлексия — тормоз" я всегда рад выдать ссылку на этот пост. Да, тормоз. До первого прохода джита. А если этот тормоз что-то решает, то компилятор по нему пройдется, и ускорит. Сильно ускорит.
Новости очень смешные. Зря вы не смотрите. Как будто за наркоманами подсматриваешь. Только тетка с погодой в завязке.
There is no such thing as a winnable war.
Здравствуйте, Трололоша, Вы писали:
E__>>ибо как раз сейчас занимаюсь переводом сишного проекта в жабу(100 строк с++ превращаются в 10 жабовских) Т>У тебя похоже весь С++ код сплошь и рядом самописный, за исключением вызовов стандартных либ.
Не, там адский винегрет многолетней давности. Где-то хорошо, где-то плачешь кровавыми слезами. Переписываю на джаве, пишу обвязки с использованием рефлексии и аннотаций, зачастую не самых понятных(бля, ну как можно понять поля, называющиеся в оригинале и в базе как void1, void2 и так далее?) — но приходится(местами из говнокода, но это чисто утилитарный код для поддержки легаси — мне нельзя что-то сломать, притом никто не знает, как оно должно работать, хотя работает, а хочется сильно сократить эти тонны кода — ну куда эти классы по 10000 строк?), делаю пусть и чутка медленнее(магические цифры — в enum, кучу параметров сущности — в объект, кучу похожих методов — в один, добавляя параметр, которым эти похожие отличаются, ну там много интересного, код сокращается, я хотя-бы все методы в один экран вмещаю, хотя в оригинале там адовые простыни экранов на 5).
Новости очень смешные. Зря вы не смотрите. Как будто за наркоманами подсматриваешь. Только тетка с погодой в завязке.
There is no such thing as a winnable war.
Здравствуйте, hattab, Вы писали:
H>Рефлексия это не прерогатива менеджед платформ У нынешних дельфей (и видимо C++ Builder'а) RTTI такой, что мама не горюй.
Вот не в курсе. Я там ниже примерчик написал. Напиши, пожалуйста, свой аналог, только как и я — выложи, загружаемый модуль на файлы рсдн, ссылку на основной запускаемый модуль для винды и линуха(который загружаемый модуль берет прямо с рсдн, и сразу юзает), и код. Ну и тайм-мерки тоже не забудь. Мы тут холиварим, но нужно и объективные данные иметь.
Новости очень смешные. Зря вы не смотрите. Как будто за наркоманами подсматриваешь. Только тетка с погодой в завязке.
There is no such thing as a winnable war.
Здравствуйте, hattab, Вы писали:
H>Ладно, не нравится тебе COM... У дельфей есть пакеты (bpl), тоже можно загрузку динамическую организовать (и подозреваю, что как и в жабе, можно обеспечить прозрачную загрузку из сети)
Пример в студию! Аналог моего кода в джаве — он прост как столб, а копаться в мегабайтах мы не станем.
ЗЫ это не сарказм. Я не знаю нихрена про делфи, отчего бы и не узнать. На примере кода, конечно.
Новости очень смешные. Зря вы не смотрите. Как будто за наркоманами подсматриваешь. Только тетка с погодой в завязке.
There is no such thing as a winnable war.
Здравствуйте, Ночной Смотрящий, Вы писали:
E__>>Ну, как минимум с нативными вещами нужно работать через интероп.
НС>Не обязательно. Это только у джавы такое ограничение. Интероп нужен для относительно безопасной работы с нейтивом.
Согласен, ни разу не приходилось. Но это не значит, что никому это не нужно.
E__>> или получить байты с usb не выйдет.
НС>Получить байты с USB — выйдет.
Просто для знаний(я пока далеко от дотнета ушел) — как?
Новости очень смешные. Зря вы не смотрите. Как будто за наркоманами подсматриваешь. Только тетка с погодой в завязке.
There is no such thing as a winnable war.
Здравствуйте, Ночной Смотрящий, Вы писали:
H>>У дельфей есть пакеты (bpl), тоже можно загрузку динамическую организовать (и подозреваю, что как и в жабе, можно обеспечить прозрачную загрузку из сети)
НС>А инлайнинг будет работать?
Он только подозревает загрузку из сети, а ты его инлайнами
Как ты себе предсталяешь инлайн в рантайме без виртуальной машины?
Новости очень смешные. Зря вы не смотрите. Как будто за наркоманами подсматриваешь. Только тетка с погодой в завязке.
There is no such thing as a winnable war.
Здравствуйте, мыщъх, Вы писали:
М>создание 400х чек-боксов показывает, что программисты совсем разучились думать и хотят готовых _стандартных_ компонентов под нестандартную задачу, хотя она на чем угодно реализуется элементарно и без тормозов и без ограничения на кол-во элементов в гриде. хоть миллион на миллион. ловим событие "щелчок", смотрим где мыша, вычисляем позицию верхнего левого угла элемента, из битового массива берем его состояние, меняем на противоположное и рисуем либо галку либо пустое место.
Здравствуйте, Иван Дубров, Вы писали:
ИД>Попробуй сделать целевой метод приватным, по идее тогда эта оптимизация не должна сработать и вызов будет всегда идти через внутренние методы JVM.
P.S. Ммм, походу, всё равно быстро получается Видимо, всё-таки основной прирост от ускорения внутренней механика sun.reflect/java.lang.reflect.
Здравствуйте, Eugeny__, Вы писали:
E__>Не, там адский винегрет многолетней давности. Где-то хорошо, где-то плачешь кровавыми слезами. Переписываю на джаве, пишу обвязки с использованием рефлексии и аннотаций, зачастую не самых понятных(бля, ну как можно понять поля, называющиеся в оригинале и в базе как void1, void2 и так далее?)
Здравствуйте, Eugeny__, Вы писали: E> H>Рефлексия это не прерогатива менеджед платформ У нынешних дельфей (и видимо C++ Builder'а) RTTI такой, что мама не горюй. E> Вот не в курсе. Я там ниже примерчик написал. Напиши, пожалуйста, свой аналог, только как и я — выложи, загружаемый модуль на файлы рсдн, ссылку на основной запускаемый модуль для винды и линуха(который загружаемый модуль берет прямо с рсдн, и сразу юзает), и код. Ну и тайм-мерки тоже не забудь. Мы тут холиварим, но нужно и объективные данные иметь.
С загрузкой делать лень (если честно, лень выносить юнит в пакет , сама загрузка ровно одна строчка ). Но работу с RTTI покажу (Delphi XE2):
Основной код
Program rtti_method_call;
{$APPTYPE CONSOLE}Uses
System.RTTI, System.Diagnostics, CoolUnit;
Var
inst : TObject;
mtd : TRttiMethod;
sw : TStopwatch;
Index : Integer;
Result : Integer;
Proc : Function(Self : Pointer; A, B : Integer) : Integer;
Begin
With TRttiContext.Create.FindType('CoolUnit.TCoolClass').AsInstance Do
Begin
inst := GetMethod('Create').Invoke(MetaclassType, []).AsObject;
mtd := GetMethod('Foo');
End;
sw := TStopwatch.StartNew;
// Вызов средствами RTTIFor Index := 1 To 1000000 Do
Result := Result + mtd.Invoke(Inst, [Index, Index + 1]).AsInteger;
WriteLn(sw.ElapsedMilliseconds); // 4358 msec
// Но мы же знаем сигнатуру метода! И мы в нативе :cool: :) Читерим!!!!!!!
Proc := mtd.CodeAddress;
sw := TStopwatch.StartNew;
// Метод полученный средствами RTTI вызывается напрямую, без малейших проблемFor Index := 1 To 1000000 Do
Result := Result + Proc(inst, Index, Index + 1);
WriteLn(sw.ElapsedMilliseconds); // 1 msecEnd.
Код юнита
Unit CoolUnit;
Interface
Type
TCoolClass = Class(TObject)
Function Foo(A, B : Integer) : Integer;
End;
Implementation
Function TCoolClass.Foo(A, B : Integer) : Integer;
Begin
Result := A + B;
End;
Initialization// Чтоб линкер не выкинул классIf TCoolClass.ClassInfo = NIL Then
Halt;
End.
Исполняемый модуль выкладывать?
Кстати, твой тест я запустить не смог:
java version "1.6.0_14"
Java(TM) SE Runtime Environment (build 1.6.0_14-b08)
Java HotSpot(TM) 64-Bit Server VM (build 14.0-b16, mixed mode)
Exception in thread "main" java.lang.NoClassDefFoundError: Main/class
Caused by: java.lang.ClassNotFoundException: Main.class
at java.net.URLClassLoader$1.run(Unknown Source)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(Unknown Source)
at java.lang.ClassLoader.loadClass(Unknown Source)
at sun.misc.Launcher$AppClassLoader.loadClass(Unknown Source)
at java.lang.ClassLoader.loadClass(Unknown Source)
at java.lang.ClassLoader.loadClassInternal(Unknown Source)
Could not find the main class: Main.class. Program will exit.
Здравствуйте, Eugeny__, Вы писали:
НС>>Не обязательно. Это только у джавы такое ограничение. Интероп нужен для относительно безопасной работы с нейтивом.
E__>+/-
Можно значки расшифровать?
НС>>Зачем? E__>Согласен, ни разу не приходилось. Но это не значит, что никому это не нужно.
Нет, ну есть кое какие ситуации. Но что то мне подсказывает, что автор утверждения совсем не их имел в виду.
НС>>Получить байты с USB — выйдет.
E__>Просто для знаний(я пока далеко от дотнета ушел) — как?
Точно так же, как на С++. CLR это не JVM, unsafe код там никто не отменял.
Здравствуйте, netch80, Вы писали:
N>Зато их вполне можно делать инкрементально. Выделить один тред и пол-ядра (или сколько сказано в настройках) на работу statclock profiler (такой, что меряет место работы по таймерным сигналам) и напускать JIT на занятые места, контролируя, чтобы он не превысил разрешённую долю процессорного ресурса системы. Технологически это тривиально.
In addition to this tracking and updating mechanism, NGen now also supports deferred commands. This means that if you want to use NGen with a large application (which may take a significant amount of time to complete), you can queue this command to be completed by the new NGen service. The NGen service is a true Windows® service process that runs in the background and waits for idle time on the machine, at which point it will complete any outstanding compilation jobs that have been waiting in the queue.
Здравствуйте, Eugeny__, Вы писали:
E__>Оу. Делаем одну галочку на чем вам нравится. Принтскрин. Паинт, или что там еще. Вырезаем квадратик. Делаем то же со всем стадиями галочки, которые нам нужны. Вставляем в ресурсы приложения, рисуем картинку. Профит!
А потом пользователь меняет схему аэро и весь твой профит пропадает. Для рисования элементов стандартных контролов есть специальное API, его и надо использовать.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Здравствуйте, Eugeny__, Вы писали:
E__>>Оу. Делаем одну галочку на чем вам нравится. Принтскрин. Паинт, или что там еще. Вырезаем квадратик. Делаем то же со всем стадиями галочки, которые нам нужны. Вставляем в ресурсы приложения, рисуем картинку. Профит!
НС>А потом пользователь меняет схему аэро и весь твой профит пропадает. Для рисования элементов стандартных контролов есть специальное API, его и надо использовать.
transparent спасет
Социализм — это власть трудящихся и централизованная плановая экономика.
Здравствуйте, gandjustas, Вы писали:
G>Здравствуйте, alex_public, Вы писали:
_>>Здравствуйте, gandjustas, Вы писали:
G>>>Ничего, даже если запустится, то работать будет невозможно.
_>>Почему невозможно? А если это какой-нибудь конвертер файлов просто?
G>На мобилке? Где по-умолчанию и доступа к ФС нету?
_>>Кстати, я вообще то сам Java не люблю, но совсем по другим причинам. А тут не могу согласиться с такими наездами на неё — кроссплатоформенность там всё же реальная. G>Ни разу. j2ME сильно отличается j2EE как ни крути. Как в библиотеках, так и в подходе к разработке.
Скоро это различие исчезнет. Oracle сразу после прихода к власти обещал двигаться в этом направлении. И таки двигается. В восмерку уже войдет javafx.
Социализм — это власть трудящихся и централизованная плановая экономика.
Здравствуйте, Иван Дубров, Вы писали:
E__>>Я вам хуже скажу. В джаве можно получить вообще неизвестный класс черти откуда(тупым потоком байт из сети загрузить кастомным класслоадером как Object, но можно придумать и более изощренный сценарий), создать экземпляр(или же вызывать статику — неважно), проверить его на наличие нужного нам метода, и часто вызывать его через рефлексию, даже не кастуя ни к какому известному интерфейсу. И... Внезапно по нему пройдется джит, увидит, что вызываемый метод у класса есть, и его имя в программе статическая строка(т.е. оно выполняется, и будет всегда выполняться именно так). И он его заинлайнит, убрав рефлексию, плюс скомпилит в нативу. Очень прошу примера, как такое возможно в нативе. Это немного похоже на ком(тоже слепой вызов), вот только ком объект не инлайнится никогда. Ваш выход, господа.
ИД>Нет, JIT такую магию не умеет.
ИД>Там всё проще, java.lang.reflect.Method#invoke(obj, args) делегирует вызов через интерфейс MethodAccessor. Насколько я помню, первые сколько-то вызовов испоьзуется стандартная реализация интерфейса, которая делает вызов используя внутренние методы JVM. После какого-то количества вызовов, генерируется специальная реализация MethodAccessor.invoke(obj, args) { return (TargetObject) obj.targetMethod((Type0) arg0, ...) }, которая впоследствии и используется. Т.е рефлексивный вызов становится обычным вызовом через интерфейс + пара кастов. Вот после этого-то как раз и вступает в работу JIT, и уже тогда он может что-то куда-то заинлайнить.
ИД>Попробуй сделать целевой метод приватным, по идее тогда эта оптимизация не должна сработать и вызов будет всегда идти через внутренние методы JVM.
Запусти мой пример. Посмотри на циферки. JIT не такой тупой, как его рисуют.
Новости очень смешные. Зря вы не смотрите. Как будто за наркоманами подсматриваешь. Только тетка с погодой в завязке.
There is no such thing as a winnable war.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Можно перечислить основные ограничения "виртуальной машины" дотнета?
Наверняка это всё тут пережёвывалось уже сотни раз. Ну если есть желание ещё разок...
— кривой вызов системных функций и невозможность прямого вызова функций из известных C++ библиотек
— невозможность написания низкоуровнего кода
— невозможность написания быстрого (в сравнение с C++ скажем) кода для ряда задач
— сложности с реализацией автоматического RAII.
Это общие с Java проблемы. А у .Net добавляется ещё отсутствие кроссплатформенности.
В целом в своей нише (написания массы "корпоративного" кода малоквалифицированными программистами) эти недостатки не особо важны и компенсируются преимуществами, так что оба инструмента наверняка будут процветать там и дальше.
Жаль только что фанаты иногда пытаются вытащить технологию из своей нищи и распространить куда не надо.
Здравствуйте, Eugeny__, Вы писали:
E__>Но при этом и дает местами шикарные возможности(та же рефлексия позволяет за счет пары утилитарных классов снижать размер кода в десятки раз, причем если это не берется из конфигов, то тормозит оно ровно до первого прохода jit(ибо реально для каждого случая ровно 1 нить исполнения получается)
Про скорость верю (правда опять же после прогона, т.е. для серверного софта скорее). А вот на счёт полезности вообще... Мне на самом деле не часто приходилось видеть красивые и нужные применения рефлексии. Т.е. специально придумать пример под неё — это не проблема естественно. А вот именно что бы из практики пришёл "запрос" и именно только рефлексия давала бы красивое решение...
E__>я напишу развернутый пост об этом, ибо как раз сейчас занимаюсь переводом сишного проекта в жабу(100 строк с++ превращаются в 10 жабовских), только как закончу, хоть это и не скоро).
Что-то как-то сомнительно. Вообще то как раз Java всегда отличалась многословностью — цена упрощённого синтаксиса. Разве что там какой-то дикий код раньше был. )))
Здравствуйте, Eugeny__, Вы писали:
E__>Ну, ставить com и динамическую подгрузку классов в жабе(а там еще и класслоадер можно заменить — иногда это такие возможности дает) — это глупость. Ком — это действие вслепую, и вообще дикий костыль.
Ммм, ну оно конечно не такое симпатичное как в Java, но нужные задачи решает на самом деле. Хотя мне кажется что как раз это и есть область где Java может победить.
Как пример в последнее время вижу больше онлайн-банкингов через Java, а не через ActiveX. Хотя лично мне больше нравится вообще на html.
Здравствуйте, alex_public, Вы писали:
_>- кривой вызов системных функций
Что значит кривой?
_> и невозможность прямого вызова функций из известных C++ библиотек
Это не соответствует действительности. Слинкованные в dll функции вызываются без проблем. Для статической линковки есть МС++.
_>- невозможность написания низкоуровнего кода
Какого именно?
_>- невозможность написания быстрого (в сравнение с C++ скажем) кода для ряда задач
Ты CLR с конкретными языками не перепутал? Если что, С++ в IL прекрасно компилируется.
_>- сложности с реализацией автоматического RAII.
При чем тут CLR? Это особенности конкретных языков, не более того.
_>Жаль только что фанаты иногда пытаются вытащить технологию из своей нищи и распространить куда не надо.
Здравствуйте, Иван Дубров, Вы писали:
ИД>Здравствуйте, Eugeny__, Вы писали:
E__>>Я вам хуже скажу. В джаве можно получить вообще неизвестный класс черти откуда(тупым потоком байт из сети загрузить кастомным класслоадером как Object, но можно придумать и более изощренный сценарий), создать экземпляр(или же вызывать статику — неважно), проверить его на наличие нужного нам метода, и часто вызывать его через рефлексию, даже не кастуя ни к какому известному интерфейсу. И... Внезапно по нему пройдется джит, увидит, что вызываемый метод у класса есть, и его имя в программе статическая строка(т.е. оно выполняется, и будет всегда выполняться именно так). И он его заинлайнит, убрав рефлексию, плюс скомпилит в нативу. Очень прошу примера, как такое возможно в нативе. Это немного похоже на ком(тоже слепой вызов), вот только ком объект не инлайнится никогда. Ваш выход, господа.
ИД>Нет, JIT такую магию не умеет.
Угу. А скорение в 100 раз — это миф, да?
Там же нет особой магии. Просмотреть нить исполения, выяснить, что она одна, да напрямую сделать.
Новости очень смешные. Зря вы не смотрите. Как будто за наркоманами подсматриваешь. Только тетка с погодой в завязке.
There is no such thing as a winnable war.
Да, обязательно. Бо сравнивать на разных машинах глупо.
H>Кстати, твой тест я запустить не смог: H>
H>java version "1.6.0_14"
H>Java(TM) SE Runtime Environment (build 1.6.0_14-b08)
H>Java HotSpot(TM) 64-Bit Server VM (build 14.0-b16, mixed mode)
H>
H>Exception in thread "main" java.lang.NoClassDefFoundError: Main/class
H>Caused by: java.lang.ClassNotFoundException: Main.class
H> at java.net.URLClassLoader$1.run(Unknown Source)
H> at java.security.AccessController.doPrivileged(Native Method)
H> at java.net.URLClassLoader.findClass(Unknown Source)
H> at java.lang.ClassLoader.loadClass(Unknown Source)
H> at sun.misc.Launcher$AppClassLoader.loadClass(Unknown Source)
H> at java.lang.ClassLoader.loadClass(Unknown Source)
H> at java.lang.ClassLoader.loadClassInternal(Unknown Source)
H>Could not find the main class: Main.class. Program will exit.
H>
java -server Main
В папке с классом. Не забываем о больших и наленьких буквах — main и Main — это два разных ксласса!
Новости очень смешные. Зря вы не смотрите. Как будто за наркоманами подсматриваешь. Только тетка с погодой в завязке.
There is no such thing as a winnable war.
Здравствуйте, Ночной Смотрящий, Вы писали:
_>> и невозможность прямого вызова функций из известных C++ библиотек НС>Это не соответствует действительности. Слинкованные в dll функции вызываются без проблем. Для статической линковки есть МС++.
С моно не работает.
_>>- невозможность написания быстрого (в сравнение с C++ скажем) кода для ряда задач НС>Ты CLR с конкретными языками не перепутал? Если что, С++ в IL прекрасно компилируется.
Процессор IL выполнять не умеет. А JIT по качеству оптимизаций до промышленных C++ компиляторов не дотягивает.
Здравствуйте, MxMsk, Вы писали:
MM> Может он эффекты битмэповые накатил — они переводят отрисовку в программную и сейчас уже obsolete. О! Я тут подумал. А может быть у него Binding-и слетели и Студия постоянно пишет об этом сообщения в Trace? Это может вызывать тормоза при отладке, которых в Release, естественно, нет.
Здесь будем воевать, а не выяснять по делу, поэтому:
1) биндинги не слетели и никаких эффектов нет (куда к черту)
2) компьютеры... не самые слабые, но не фонтан: (P4 или младшие C2Duo, 1-2ГБ памяти, видео не знаю какое)
3) сначала я использовал реализацию здесь от известного гуру Джоша Смита. Она тоже тормозит и имеет другие еще недостатки.
Вопросы: кто виноват? Достаточно ли быстр WPF? Оптимально ли сделал Смит? Не дурак ли я, что сделал чекбоксами вместо кастомных значков?
Конечно, можно, как и написал мыщъх, сделать все ручками: обрабатывать клики, отказаться от биндингов... и т.д.
Будет быстро (наверно).
Но у меня тут пресловутый "энтерпрайз". То есть — делайте быстрее, требования допридумываются по ходу.
Новости очень смешные. Зря вы не смотрите. Как будто за наркоманами подсматриваешь. Только тетка с погодой в завязке.
There is no such thing as a winnable war.
Здравствуйте, Eugeny__, Вы писали:
ИД>>Нет, JIT такую магию не умеет.
E__>Угу. А скорение в 100 раз — это миф, да? E__>Там же нет особой магии. Просмотреть нить исполения, выяснить, что она одна, да напрямую сделать.
Нет, перечитай внимательнее, что я написал. Это не JIT такой умный, а реализация reflection-а.
Здравствуйте, 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 для теста мне писать ну совсем неохота. Поэтому в ближайшем приближении.
1000 вызовов точно померять очень сложно, даже используя RDTSC. Поэтому мерять буду 1М вызовов. JIT тут нету, поэтому вмешаться некому.
1000000 вызовов, 0.001950118 секунд. Это по 1.9 нс на вызов. В ~32 раза быстрее чем смог заинлайнить JIT.
Давай теперь заинлайним и там и там: теперь вызываемая функция static и в том же классе.
...\jdk1.7.0_03\bin>java.exe -server -cp test Main
61890
245393108
2799
1876919424
Что даёт нам 61.9 нс для первого прохода, и 2.8 нс после JIT.
Результаты С++: 1000000 вызовов, 0.000082465 секунд. Получаем 0.082 нс на вызов. Опять быстрее, в ~34 раза.
Здравствуйте, Eugeny__, Вы писали:
E> Аааа, начерта так много кода???? Для простейшей операции!
Ты про TCoolClass?
E> Я думал, джава по оверхеду на высоте, но паскаль — явно выше.
Так паскаль всегда был языком с довольно громоздким синтаксисом и строгим требованием к описанию всего и вся. Важно ведь, чтоб читать было легко, а написать руки не отвалятся.
Здравствуйте, 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 пыталась протолкнуть его как универсальную технологию для всего
Пример?
_>И соответственно были толпы народа поддерживающие эту странную идею.
Пример?
_> Кстати, до некоторых из них похоже и сейчас ещё не дошло... )))
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Так не используй его, если он тебе кривым кажется.
Я то вообще .net не использую ни в каком виде. Но что вы можете предложить взамен тем, кто использует? )
НС>Ну кто ж вам мешал МС++ использовать?
Это не нам, а тем кто делал биндинги. Да, и MC++ — это насмешка над настоящим C++. И кстати, а оно есть на моно? )
НС>Ты хвостом не верти. Ты утверждал про ограничения виртуальной машины.
Про неё и говорю. Ограничения именно виртуальной машины. Т.е. берём любой язык из неё и он будет заметно медленее чем нативный C++ или Фортран и т.п на значительном классе задач..
_>> ) Т.е. на clr есть язык с поддержкой RAII в стиле C++? ) НС>Да. Называется С++.
Т.е. в MC++ временем жизни объектов управлет совсем не GC? )
_>>Собственно MS с появлением .Net пыталась протолкнуть его как универсальную технологию для всего НС>Пример?
Помнится в начале 2000-ых говорил с Доном Боксом на эту тему — он прямо пылал энтузиазмом. Ну как же, dll hell побеждено — впереди только светлое будщее со сплошным дотнетом.
_>> Кстати, до некоторых из них похоже и сейчас ещё не дошло... ))) НС>Пример?
Ну например часть .Net раздела форума rsdn похоже ещё не может смириться с реальностью...
НС>И на исходный вопрос ответа так и нет.
Ага, ага. Был вопрос про недостатки виртуальный машины .Net. Я привёл список. В итоге часть его скипнута, на часть комментарии типа "ну и не используй это возможность", и на ещё часть демагогия про точность формулировки (хотя все всё поняли прекрасно) с целью замять вопрос.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>А если еще чуть чуть выше посмотреть, то можно увидеть, что речь вообще то с самого начала была о том, зачем нужен JIT.
Вообще то изначально в теме речь шла о кроссплатформенности, к которой вопросы jit и т.п. имеют весьма косвенное отношение. На что автору темы уже неоднократно намекнули.
Здравствуйте, alex_public, Вы писали:
_>Здравствуйте, Ночной Смотрящий, Вы писали:
НС>>А если еще чуть чуть выше посмотреть, то можно увидеть, что речь вообще то с самого начала была о том, зачем нужен JIT.
_>Вообще то изначально в теме речь шла о кроссплатформенности, к которой вопросы jit и т.п. имеют весьма косвенное отношение. На что автору темы уже неоднократно намекнули.
косвенное оно сейчас, а тогда на заре это была первая из причин для создания управляемых языков и сред исполнения
всё остальное можно было легко реализовать на нативных языках и синтаксис, и библиотеки, и рефлекшон, и объекты по сети.
Я изъездил эту страну вдоль и поперек, общался с умнейшими людьми и я могу вам ручаться в том, что обработка данных является лишь причудой, мода на которую продержится не более года. (с) Эксперт, авторитет и профессионал из 1957 г.
Здравствуйте, Kingofastellarwar, Вы писали:
_>>Вообще то изначально в теме речь шла о кроссплатформенности, к которой вопросы jit и т.п. имеют весьма косвенное отношение. На что автору темы уже неоднократно намекнули. K>косвенное оно сейчас, а тогда на заре это была первая из причин для создания управляемых языков и сред исполнения K>всё остальное можно было легко реализовать на нативных языках и синтаксис, и библиотеки, и рефлекшон, и объекты по сети.
Вы сейчас видимо имели в виду саму идею байткода, а не jit, т.к. допустим в Java jit появился только со временем...
Да, я согласен что для бинарной кроссплатформенности необходим байткод (хотя вообще то не забываем ещё и про интерпретаторы!). Но именно такая кроссплатформенность в большинстве случаев не требуется. И соответственно вопрос байткода (а с ним jit и всего остального) уходят далеко в сторону по сравнению с вопросами поддержки функций платформы и наличия нужных библиотек.
Здравствуйте, alex_public, Вы писали:
_>Вы сейчас видимо имели в виду саму идею байткода, а не jit, т.к. допустим в Java jit появился только со временем...
_>Да, я согласен что для бинарной кроссплатформенности необходим байткод (хотя вообще то не забываем ещё и про интерпретаторы!). Но именно такая кроссплатформенность в большинстве случаев не требуется. И соответственно вопрос байткода (а с ним jit и всего остального) уходят далеко в сторону по сравнению с вопросами поддержки функций платформы и наличия нужных библиотек.
точно, об этом и тема, о том, что ни байткод, ни жит не нужны для решения "вопросов поддержки функций платформы и наличия нужных библиотек."
Я изъездил эту страну вдоль и поперек, общался с умнейшими людьми и я могу вам ручаться в том, что обработка данных является лишь причудой, мода на которую продержится не более года. (с) Эксперт, авторитет и профессионал из 1957 г.
Здравствуйте, alex_public, Вы писали:
_>Помнится в начале 2000-ых говорил с Доном Боксом на эту тему — он прямо пылал энтузиазмом. Ну как же, dll hell побеждено — впереди только светлое будщее со сплошным дотнетом.
Так вот кто повинен в появлении SxS Hell!!! Сжечь еретика!!!!!
Здравствуйте, 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++ компиляторов не дотягивает.
Только разговор немного не об этом. Не о качестве оптимизаций, а о принципиальных ограничениях мифической "виртуальной машины" дотнета.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Это был намек на твое незнание базовых вещей платформы, а именно на то, что код совершенно не обязан быть 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, Вы писали:
_>>Типа гораздо выгоднее разработать отдельное приложение под каждую платформу, да? G>Ну вот производители фотошопа считают так. У них разные билды под разные оси.
Ну и? Сколько платформ, столько раз "build" нажать... Где ты разглядел "отдельные приложения под каждую платформу"?
Здравствуйте, Eugeny__, Вы писали:
E__>Не, давай уж ком замутим. Загружаемый из сети. Заодно глянем на красоту кода этого кома. Ну а там уже и доборемся до того, как это дело без напряга запустить под Линуксом и Маком. В джавовском варианте ничего менять не придется.
Ну замути если есть желание. Потестим.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>А смешанные сборки — это ж Win32 бинарник, никакой кроссплатформенности без всяких вайнов.
Моно смешанные сборки даже на Windows не поддерживает.
Здравствуйте, Eugeny__, Вы писали:
E> Сначала давай вариант с ком. Потом — мультиплатформенный. А вот после этого — посмотрим. А то мы меряем очень разные вещи.
Изначально же речь шла о джитовой оптимизации, причем тут твое желание увидеть мультиплатформу?
Здравствуйте, 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% пользователей... )))
Здравствуйте, alex_public, Вы писали:
_>Если для того что бы добраться до 10% пользователей надо переписывать приложение целиком, то такое редко может быть оправдано по деньгам. А вот если для этого надо всего лишь перенести исходники на соседний комп (или вообще в виртуальную машину) и нажать там build, то это имеет смысл даже ради 1% пользователей... )))
Для мака важен родной гуй. На винде следование windows UI style бывает менее важно, но тем не менее со счетов скидывать нельзя.
"Родной гуй" это гуй, который выглядит и ведёт себя как все остальные программы. Т.е. такой же стиль, такое же оформление, такие же шорткаты и т.п.
Здравствуйте, MxMsk, Вы писали:
M>>Который jQuery, тупое создание 400 чекбоксов с максимально тупым назначением событий каждому чекбоксу... И не тормозит. Более того, создание аналогичного в каком-нить ExtJS тоже не будет тормозить. M>>Но нет, в WPF это низзя ни в коем случае, вы шо. Нужно в обязательном порядке делать собственный контрол на каждый чих? Где эти чихи начинаются? На 20 чекбоксах? На 30? MM>Надо понимать, нужны ли тебе бенефиты WPF (шаблоны, масштабируемость, биндинги, эффекты).
Что имеется ввиду под масштабируемостью в WPF?
MM>Если нужны, то придется учиться пользоваться технологией, что включает и умение выкручиваться в тормозных ситуациях.
Есть ситуации, где не выкрутишься никак. WPF хорошо умеет лишь однажды загрузить ресурсы, приписать им трансформацию/анимацию и сказать всей кухне "старт", чтобы нейтивная часть всё это проигрывала... А если я хочу свой "проигрыватель"... то вот и получили WinRT. ^)
MM>Вот у нас на проекте первоначальный вариант рисования сложного графика тратил на рендеринг около 10 секунд.
Гм... т.е. не вычисление результатов, только лишь рисование графика в 2012-м году занимает 10 сек?
Надо бы вам дать тем же PCAD по голове, который умел десятки ты элементов рисовать сс номральной скоростью еще на 286-х машинах... А совсем охренели уже со своими дотнетами...
MM>Сейчас уходит меньше секунды притом, что количество данных только возросло. Потому что научились. Потому что нужны были другие фичи WPF, такие, например, как подстройка DPI.
Потому что кривая либа. Потому что "изкаробки" работает плохо. Не умеет, не предусмотрено, не учли и т.д.
На самом деле для WPF достаточно лишь представлять себе внутренний поток событий, в первую очередь событий лейаута, сериализацию его для проигрывания на нейтивной стороне, чтобы заведомо знать, что стоит на WPF делать, а чему лучше поискать альтернативу. Там же можно захостить обычное WinForms-окошко а на нем DirectX. А рисовать графики в DirectX всяко не сложнее, чем в WPF, скорее наоборот. Т.е. это уже какая-то косность мышления, похоже...
Здравствуйте, MxMsk, Вы писали:
S>>А как WPF учитывает цветовую схему ОС? MM>Шаблоны контролов используют DynamicResource на ключи из SystemColors.
Справедливости ради, популярные темы WPF, в т.ч. от MS, практически никакие системные цвета, кроме цвета Windows (напр. заний фон EditBox), не используют.
Здравствуйте, Ночной Смотрящий, Вы писали:
E__>>Оу. Делаем одну галочку на чем вам нравится. Принтскрин. Паинт, или что там еще. Вырезаем квадратик. Делаем то же со всем стадиями галочки, которые нам нужны. Вставляем в ресурсы приложения, рисуем картинку. Профит!
НС>А потом пользователь меняет схему аэро и весь твой профит пропадает. Для рисования элементов стандартных контролов есть специальное API, его и надо использовать.
Ну... оно разное для разных версий Windows или текущих режимов. Может быть до 3-х вариаций рисования, что малость перебор. Да еще надо делать ручную или отложенную загрузку библиотек тем.
Здравствуйте, vdimas, Вы писали:
V>Потому что кривая либа. Потому что "изкаробки" работает плохо. Не умеет, не предусмотрено, не учли и т.д. V>На самом деле для WPF достаточно лишь представлять себе внутренний поток событий, в первую очередь событий лейаута, сериализацию его для проигрывания на нейтивной стороне, чтобы заведомо знать, что стоит на WPF делать, а чему лучше поискать альтернативу. Там же можно захостить обычное WinForms-окошко а на нем DirectX. А рисовать графики в DirectX всяко не сложнее, чем в WPF, скорее наоборот. Т.е. это уже какая-то косность мышления, похоже...
В последнем нашем споре о WPF оказалось, что, хотя ты и весь из себя такой инженер, но легко забиваешь на факты, делая выводы, основанные на незнании
. Также и сейчас ты пытаешься сыграть аналогично, сказав "бла-бла-бла, всё проще делать на DirectX". При этом тебя, вроде бы инженера, почему-то не волнуют ни требования, которые я привел выше, ни проблемы интеграции WinForms и DirectX с WPF, ни поддержка этих решений, как с точки зрения наличия программистов со знанием DirectX, так и наличия соответствующего DirectX на ОС заказчика. Так что, я думаю, поставь-ка ты мне снова минус-рожицу, и разговор можно считать закрытым.
Здравствуйте, Трололоша, Вы писали:
Т>Для мака важен родной гуй. На винде следование windows UI style бывает менее важно, но тем не менее со счетов скидывать нельзя. Т>"Родной гуй" это гуй, который выглядит и ведёт себя как все остальные программы. Т.е. такой же стиль, такое же оформление, такие же шорткаты и т.п.
Ага, важен.
Ну так у меня и есть родной GUI, когда компилирую под Мак. И под Windows тоже самое... Я же говорю, это не Java, a нативная кроссплатформенность. )))
Здравствуйте, Трололоша, Вы писали:
Т> Для мака важен родной гуй.
Т> "Родной гуй" это гуй, который выглядит и ведёт себя как все остальные программы. Т.е. такой же стиль, такое же оформление, такие же шорткаты и т.п.
Похоже, что уже нет. Политика партии меняется на глазах
Здравствуйте, alex_public, Вы писали:
_>Здравствуйте, gandjustas, Вы писали:
V>>>Очередной отжиг. Вне дотнета жизни нет? G>>Если учесть что 90% компов — windows, то можно считать что нету. G>>Из оставшихся 10% большая часть маки, там тоже кроссплатформенный софт не жалуют.
_>Ха, а это кстати ещё один аргумент в пользу разработки с помощью кроссплатформенных инструментов.
_>Если для того что бы добраться до 10% пользователей надо переписывать приложение целиком, то такое редко может быть оправдано по деньгам. А вот если для этого надо всего лишь перенести исходники на соседний комп (или вообще в виртуальную машину) и нажать там build, то это имеет смысл даже ради 1% пользователей... )))
Здравствуйте, gandjustas, Вы писали:
V>>Да че ты так к UI привязался? Платформенно-независимого UI хоть попой ешь. G>Только от него тянет блевать. Он везде одинаково плохо выглядит.
Критерии плохости в студию, пожалуйста.
V>>Проблемы только у конкретно дотнета с их непереносимыми WinForms и WPF, бо в той же Java с кроссплатформенным GUI с рождения никаких проблем не было. G>Кроме убогости и ненужности — да, не было.
И критерии ненужности — сюда же.
G>Да, детка, покажи мне api для WP7
А она кому-то реально нужна?
100% кроссплатформенность вообще на всё, что есть в природе, очевидно, недостижима. Обсуждать имеет смысл только сходные по концепциям и достаточно распространённые.
Я бы ещё понял запрос на что-то с поддержкой одновременно Android, Windows 8 и iPad'овскую ось (не помню, как зовётся), но WP7 — это за гранью разумного со всех сторон...
Здравствуйте, netch80, Вы писали:
N>Здравствуйте, gandjustas, Вы писали:
V>>>Да че ты так к UI привязался? Платформенно-независимого UI хоть попой ешь. G>>Только от него тянет блевать. Он везде одинаково плохо выглядит.
N>Критерии плохости в студию, пожалуйста.
Несоответствие гайдлайнам интерфейсов системы.
V>>>Проблемы только у конкретно дотнета с их непереносимыми WinForms и WPF, бо в той же Java с кроссплатформенным GUI с рождения никаких проблем не было. G>>Кроме убогости и ненужности — да, не было. N>И критерии ненужности — сюда же.
Несоответствие гайдлайнам интерфейсов системы.
Неиспользование возможностей системы (таскбар в Win7 напрмиер)
G>>Да, детка, покажи мне api для WP7 N>А она кому-то реально нужна?
Нужна. Люди то покупают. Процент WP7 на рынке телефонов больше чем процент никсов на рынке десктопов
N>100% кроссплатформенность вообще на всё, что есть в природе, очевидно, недостижима. Обсуждать имеет смысл только сходные по концепциям и достаточно распространённые.
Я говорил тоже самое и начал как раз с уточнения определений.
N>Я бы ещё понял запрос на что-то с поддержкой одновременно Android, Windows 8 и iPad'овскую ось (не помню, как зовётся), но WP7 — это за гранью разумного со всех сторон...
Тем не менее на .NET можно написать код, который после компиляции одинаково заработает на всех указанных платформах. На других языках это невозможно.
Полезность этого кода под вопросом конечно, но самой возможности это не отменяет.
Предлагаю поговорить о кроссплатформенности на примере футбола.Вроде бы в каждой его разновидности есть поле, мяч, ворота и две команды. Вратарь и полевые игроки в каждой. Но дьявол, как обычно, кроется в деталях...
V>>Понимаешь... Нет такой либы, где бы нельзя было кастомизировать внешний вид любого контрола. И никакими тормозами, как в WPF, за это платить не надо. Поэтому пытаться обсуждать внешний вид GUI вместо архитектуры/возможностей — это надо быть максимально далеким от предмета обсуждения. G>Слушай, ты уже обосрался с тормозами WPF. В одной из тем кто-то просто прогнал профайлером и посмотрел где там тормоза. Отнюдь не в отрисовке G>Заканчивай.
Про WPF? Ссылку.
И ты проигнорировал суть, однако.
А тормоза обсуждаются здесь же в ветке, если что.
G>>>Кроме того не везде работает, покажешь такую либу чтобы работала в Android, iOS и WP7? Или хотябы в любой паре из них?
V>>Т.е. гугле таки забанили? V>>Везде, где доступен компилятор C++, доступны библиотеки на нем. Например, для iOS вовсю уже активно юзают GCC, бо Objective-C тот еще уродец. QT работает на Mac OS X без проблем, так же как в iOS. Для android наконец вышел Android NDK, на котором уже собрали QT. G>Не размазывай сопли, просто дай ссылку на GUI либу, которая работает на Android, iOS и WP7.
При чем тут WP7? Под него еще ничего нет и толком не будет пока платформу до ума не доведут. Прблема-то не столько техническая, сколько административная: невозможно будет нейтивное приложение выставить на Marketplace или как там оно называется. А так-то его уже давно хакнули. Т.е. твои требования насчет WP7- это от непонимания устройства вещей. Слив.
V>>Обосновать сможешь? Или ругань вместо технических деталей — это твой любимый способ сливания? G>Это правда жизни, скриншоты прислать?
Скриншоты чего? Например, скриншоты студии 2010 на WPF ничем не лучше скриншотов Eclipse, который на Java. Если же ты просто где-то увидел безвкусицу и на основании этого делаешь выводы, то в твоей консерватории что-то не так.
Обоснуй, что на Java невозможно делать нормальное UI. Нормальных скриншотов подкинуть не проблема: http://docs.oracle.com/javase/tutorial/uiswing/lookandfeel/nimbus.html
С первых строчек гугля, лентяй.
Ну и этого не обязательно. Для всех поулярных ГУИ-либ на джава есть возможность отображения в системной теме, а не в кастомной. Поэтому, обсуждать нечего, а ты опять показал себя борцом в сетрянными мельницами.
V>>Сосредоточься плиз на приводимых фактах: Моно является кроссплатформенным. И даже в системных вещах. И даже в GUI. Бо есть бинды QT, GTK и многих других либ. G>Это смотря что считать кроссплатформенностью. Еще раз напомню про Android, iOS и WP7. Их пересечение существует в маленьком подмножестве .NET, не Java и не C++.
Не существует этого пересечения по дотнету как таковому, не изобретай. Существует пересечение только по сильверлайт и то, через одно место. т.е. через Marketplace.
V>>Ох и нубство дремучее... В MSDN тебя тоже забанили? Дай мне любой бинарник для WP7, я тебе список импортируемых символов оттуда распечатаю, если сам не умеешь, детка. И по каждому символу дам ссылку на MSDN. Там такое же обычное WinAPI, за исключением user32... если тебе это что-то говорит. И DirectX тоже есть, напомню и под DirectX/OpenGL есть кроссплатформенные GUI-библиотеки, так же напомню. G>Не умничай, просто покажи api QT для WP7.
АПИ для QT неизменно для любой платформы.
И вообще, твоё воинствующее невежество начинает раздражать. Покажи мне лучше сервелат для Bada? Доля этих устройств на рынке намного больше доли WP7. Я вижу, что ты пытаешься хвалить свой дотнет, но делаешь это неумело, т.к. со своими попытками в кач-ве примера приводить платформы, которые невостребованы на рынке — это жалкое зрелище. Рассматривать стоит то, что де-факто популярно у народа. Для случая это многие десятки платформ. Для сервелата — ровно 3. Смешно.
Здравствуйте, мыщъх, Вы писали:
М>лис, хром -- у всех них довольно жесткие требования к компиляторам. сборка новых версий это как бы не проблема (раз смогли собрать они -- смогу и я). а вот если хочешь собрать какую-то древность -- то нужной версии компилятора не найти, особенно если это не gcc, а коммерческий компилятор.
Эээ.. пролема обычно ровно наоборот, более новую версию невозможно собрать на более старом компиляторе. Но это, ИХМО, нормально: новые версии разрабатываются на новых инструментах, т.е. хочешь всё новое — переходи на новое.
А насчет давности: все старые ходовые версии gcc вроде как доступны.
Здравствуйте, vdimas, Вы писали:
V>Да че ты так к UI привязался? Платформенно-независимого UI хоть попой ешь. Проблемы только у конкретно дотнета с их непереносимыми WinForms и WPF
Т.е. в случае плюсов платформонезависимую либу взять можно, а дотнета уже нельзя?
V>Брехня опять. Моно сильно отличается от версии MS.
Чем конкретно?
V> Для примера, QT для разных платформ имеет одно и то же АПИ. А у меня сходу ни одно приложение для дотнета на Моно не идет.
А у меня кое что идет.
V> Т.е. это надо забыть про дотнет и разрабатывать под Моно даже на виндах, чтобы получилось кроссплатформенно.
Не обязательно. Можно просто периодически проверять на Моно, различия там не такие уж и большие.
Здравствуйте, Трололоша, Вы писали:
НС>>А смешанные сборки — это ж Win32 бинарник, никакой кроссплатформенности без всяких вайнов. Т>Моно смешанные сборки даже на Windows не поддерживает.
Здравствуйте, alex_public, Вы писали:
_>Это действительно так. Но всё дело в том, что если писать ТАКОЙ код, то возникает вопрос: "а зачем нам тут вообще .Net тогда?".
Затем, что там, где нам unsafe не нужен, можно все делать в safe. Ваш КО.
_> Т.е. у нас тут по сути возникает бледная копия нативного C++
Логическую ошибку в своих рассуждениях сам найдешь?
Обожаю WPF — ненавистников. Просто-таки квинтэссенция чистой ненависти. По поводу кроссплатформенного UI — все это сказки.
Кроссплатформенный сервис — еще могу поверить. Кроссплатформенные библиотеки(в основном реализации алгоритмов, не привязанные к конкретной задаче) — верю безоговорочно.
У многих плюсовиков наблюдается какая-то непонятная фобия на managed среды вообще и на дотнет в частности. Да, не труъ кроссплатформенная среда.
Знаете, я бы с удовольствием посмотрел бы на реальные кроссплатформенные проекты с человеческим интерфейсом(на десктопе, естественно, а не в вебе, там как раз понятно все).
Мне такие проекты как-то не попадались. И вообще, я не понимаю, почему любители Юникс плачут о том, что дотнет не поддерживается в *nix среде? Дотнетчики же об этом не плачут. Странно это все, короче.
Впрочем, если MS вдруг решит выпустить версию CLR под *nix, то будет очень интересно посмотреть, сколько проживет Qt и прочие Gtk.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Затем, что там, где нам unsafe не нужен, можно все делать в safe. Ваш КО.
Так RAII то нужен везде, а не в одном узком месте. В том смысле что должна формироваться (автоматических, без работы программиста) цепочка деструкторов сквозь всё приложение, а не один маленький unsafe класс. Да и другие вещи типа работы с памятью и вызова системных функций тоже обычно не в одном месте требуются.
Конечно если заниматься только рисованием формочек (хотя как выяснилось в этой теме, тут тоже не всё так просто — 20х20 чекбоксов уже не тянем ), то совсем другое дело — тут можно обойтись только safe кодом.
Т.е. всё как я и говорил с самого начала: для написания всякого внутрикорпоративного софта Java и .Net подходят отлично. А вот для более качественного и требовательного софта берём уже другие инструменты.
Но фанатикам не понять — они будут везде совать своё любимое. )))
_>> Т.е. у нас тут по сути возникает бледная копия нативного C++ НС>Логическую ошибку в своих рассуждениях сам найдешь?
Бледная копия потому, что проблемы быстродействия и работы на низком уровне не решает даже unsafe код.
Здравствуйте, Codechanger, Вы писали:
C>Знаете, я бы с удовольствием посмотрел бы на реальные кроссплатформенные проекты с человеческим интерфейсом(на десктопе, естественно, а не в вебе, там как раз понятно все). C>Мне такие проекты как-то не попадались.
Эээ, вы это серьёзно? Тут же ссылки можно даже не десятками, а сотнями кидать.
V>Да и вообще, упоминание системных вещей смешнее всего. Например, ACE/boost/libevent/ptlib и еще куче других либ пофиг тонкости отличий АПИ операционнок, а вот "кроссплатформенному" дотнету (С) — не пофиг. Цирк как он есть.
И это ACE, которая еще вполне себе простая штука. В тот же буст я даже не полезу.
Новости очень смешные. Зря вы не смотрите. Как будто за наркоманами подсматриваешь. Только тетка с погодой в завязке.
There is no such thing as a winnable war.
Здравствуйте, Sinclair, Вы писали:
S>Серъёзно что ли? А мне вот как раз кажется, что детерминистическая финализация мало где нужна.
Не в том дело. Допустим нам надо контролировать всего один ресурс. Но что бы всё сработало правильно нам мало просто добавить соответствующий деструктор в класс работающий с ресурсом. Нам надо что бы ещё и все владельцы убивали экземпляры нашего класса в нужное время — получается иерархическая цепочка на всю программу. Ну естественно это если мы хотим что бы всё автоматом работало. Можно и без этого — ручными вызовами и тогда действительно можно локализовать в одном месте с соответствующим ручным кодом там.
S>И как раз для его упрощения в MC++ сделано вполне всё по уму.
Кстати, а MC++ вообще кто-то использует? ) Я именно честно спрашиваю, потому что просто не знаю. Сам таких не видел. ))) Ну и как бы на мой взгляд странно использовать C++ в .Net. Т.е. как бы если уж мы принимаем все недостатки clr, то тогда уж не бесплатно — как минимум синтаксического сахара можно и добавить. Это я в смысле C# или ещё чего поприятнее. )))
S>Впрочем, как сразу же выяснилось в этой же теме, 20x20 чекбоксов вполне себе тянем — тормоза воспроизвести в студии не удалось.
Хы, ну в принципе так и должно быть. А то я уже прямо шокирован был. )))
Здравствуйте, Codechanger, Вы писали:
C>По поводу кроссплатформенного UI — все это сказки.
Ну почему. Если тебе не нужно что то красочное и цветастое, при этом быстро работающее, кросплатформенный UI вполне реален.
C>У многих плюсовиков наблюдается какая-то непонятная фобия на managed среды вообще и на дотнет в частности.
Нет в ней ничего непонятного. Обычный консерватизм (который, в свою очередь, вызван нежеланием ломать моск). В штыки будет восприниматься все альтернативное, имеющее ненулевую популярность.
И не у многих, кстати, а только у небольшого количества. Просто их очень заметно.
C>Знаете, я бы с удовольствием посмотрел бы на реальные кроссплатформенные проекты с человеческим интерфейсом(на десктопе, естественно, а не в вебе, там как раз понятно все).
Здравствуйте, alex_public, Вы писали:
_>Так RAII то нужен везде, а не в одном узком месте.
А для RAII unsafe и не нужен. C++/CLI вполне его обеспечивает в чисто managed контексте. А в шарпе есть using, который не полностью автоматичен (но у него есть свои достоинства), а так же всякие intrinsic вещи типа SafeHandle.
_>Конечно если заниматься только рисованием формочек (
"Рисование формочек", а точнее качественный UI — одна из самых сложных задач в программировании.
_>хотя как выяснилось в этой теме, тут тоже не всё так просто — 20х20 чекбоксов уже не тянем )
Тут даже ехе'шник выложили, демонстрирующий что ничего не тормозит и косяки в чем то другом. И ты явно это видел. Но решил занятся откровенными и грубыми подтасовками.
_>, то совсем другое дело — тут можно обойтись только safe кодом.
А еще safe кодом можно обойтись в 99.99% серверного кода, к примеру. Это, по твоей внутренней шкале, круче формочек? Или нужно непременно драйвера писать, чтобы круто?
_>Но фанатикам не понять — они будут везде совать своё любимое. )))
Пока что на фанатика больше похож ты, когда предмет не знаешь, но огульно обвиняешь.
_>>> Т.е. у нас тут по сути возникает бледная копия нативного C++ НС>>Логическую ошибку в своих рассуждениях сам найдешь? _>Бледная копия потому, что проблемы быстродействия
Расскажи, что за проблемы быстродействия на работе ты решаешь?
_> и работы на низком уровне не решает даже unsafe код.
Здравствуйте, Ночной Смотрящий, Вы писали:
_>>Так RAII то нужен везде, а не в одном узком месте.
НС>А для RAII unsafe и не нужен. C++/CLI вполне его обеспечивает в чисто managed контексте. А в шарпе есть using, который не полностью автоматичен (но у него есть свои достоинства), а так же всякие intrinsic вещи типа SafeHandle.
Вот чего я не понимаю, так это то, какого хрена в жабу никак не добавят using. Простая же штука, по сути — это банальный синтаксический сахар над try-finally.
_>>, то совсем другое дело — тут можно обойтись только safe кодом.
НС>А еще safe кодом можно обойтись в 99.99% серверного кода, к примеру. Это, по твоей внутренней шкале, круче формочек? Или нужно непременно драйвера писать, чтобы круто?
Мухаха, я на прошлой работе писал драйвера на яве .
Новости очень смешные. Зря вы не смотрите. Как будто за наркоманами подсматриваешь. Только тетка с погодой в завязке.
There is no such thing as a winnable war.
Здравствуйте, Eugeny__, Вы писали:
E__>Вот чего я не понимаю, так это то, какого хрена в жабу никак не добавят using. Простая же штука, по сути — это банальный синтаксический сахар над try-finally.
В жабу много чего надо добавить. Да и в шарп тоже. Но если у последнего компилятор на плюсах и необходимость сорелизов со студией палки в колеса вставляют, то в случае жабы просто неповоротливость и консервативность сам ого процесса изменения языка мешает.
E__>Мухаха, я на прошлой работе писал драйвера на яве .
Внутри МС был проект в том числе с написанием kernel-mode драйверов на шарпе, с учетом некоторой доработки unsafe конструкций и специального ядерного рантайма (codename Redhawk, если тебе это о чем то говорит, часть Раддеровского Midori). Но потом пришел Синовский и проект задвинули в маргинальную нишу.
Впрочем, если верить Mary-Jo Foley (а ей стоит верить) — кое что в Win8 оттуда просочилось.
Здравствуйте, alex_public, Вы писали:
_>Но фанатикам не понять — они будут везде совать своё любимое. )))
Тут еще как посмотреть, кто фанатик, а кто нет.
E__>>Вот чего я не понимаю, так это то, какого хрена в жабу никак не добавят using. Простая же штука, по сути — это банальный синтаксический сахар над try-finally.
НС>В жабу много чего надо добавить. Да и в шарп тоже. Но если у последнего компилятор на плюсах и необходимость сорелизов со студией палки в колеса вставляют, то в случае жабы просто неповоротливость и консервативность сам ого процесса изменения языка мешает.
Ну, отчасти эта консервативность — плюс(джава до сих пор бинарно совместима с древними махровыми версиями). Отчасти — минус. Но вот некоторые вещи именно на уровень языка(а не байткода) я бы добавил.
E__>>Мухаха, я на прошлой работе писал драйвера на яве .
НС>Внутри МС был проект в том числе с написанием kernel-mode драйверов на шарпе, с учетом некоторой доработки unsafe конструкций и специального ядерного рантайма (codename Redhawk, если тебе это о чем то говорит, часть Раддеровского Midori). Но потом пришел Синовский и проект задвинули в маргинальную нишу. НС>Впрочем, если верить Mary-Jo Foley (а ей стоит верить) — кое что в Win8 оттуда просочилось.
Ну, у меня были в client-mode, и кто-то скажет, что это и не драйвера вовсе. Но как тогда назвать код, который общается с устройством по его специфическому протоколу, а наверх дает высокоуровневое API для управления устройством(точнее, классом устройств, а там уже для каждого свой драйвер)?
Новости очень смешные. Зря вы не смотрите. Как будто за наркоманами подсматриваешь. Только тетка с погодой в завязке.
There is no such thing as a winnable war.
Здравствуйте, Eugeny__, Вы писали:
E__>Ну, отчасти эта консервативность — плюс(джава до сих пор бинарно совместима с древними махровыми версиями).
Шарп тоже, до сих пор бинарно совместим с 2.0 (а небинарно с 1.0). Только бинарная совместимость никак развитию языка мешать не должна. В частности, для using точно рантайм менять не нужно.
E__>Ну, у меня были в client-mode, и кто-то скажет, что это и не драйвера вовсе
Здравствуйте, Codechanger, Вы писали:
C> Обожаю WPF — ненавистников. Просто-таки квинтэссенция чистой ненависти. По поводу кроссплатформенного UI — все это сказки.
...
C> Знаете, я бы с удовольствием посмотрел бы на реальные кроссплатформенные проекты с человеческим интерфейсом(на десктопе, естественно, а не в вебе, там как раз понятно все).
В моей сказке живут GoldenDict (Qt. Win + Lin), Lazarus (LCL. Win + Lin + Mac), Avalon (Qt. Win + Lin). VirtualBox (Qt. Win + Lin) + еще немного мелочи. У меня хорошая сказка
C> Мне такие проекты как-то не попадались. И вообще, я не понимаю, почему любители Юникс плачут о том, что дотнет не поддерживается в *nix среде? Дотнетчики же об этом не плачут. Странно это все, короче.
С чего ты взял что плачут? Из последней убунты вообще моно решили выкинуть, так что там все без истерик
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>А для RAII unsafe и не нужен. C++/CLI вполне его обеспечивает в чисто managed контексте. А в шарпе есть using, который не полностью автоматичен (но у него есть свои достоинства), а так же всякие intrinsic вещи типа SafeHandle.
Я же спрашивал уже в этой теме, в MC++ временем жизни объекта управлет GC или нет? И какой был ответ? )
_>>Конечно если заниматься только рисованием формочек ( НС>"Рисование формочек", а точнее качественный UI — одна из самых сложных задач в программировании.
Скорее задач дизайна и эргономики. ) А запрограммировать уже нарисованный интерфейс сейчас может и обезьяна. ))) Собственно говоря в современных инструментах его обычно и рисуют в спец. визуальных редакторах.
НС>А еще safe кодом можно обойтись в 99.99% серверного кода, к примеру. Это, по твоей внутренней шкале, круче формочек? Или нужно непременно драйвера писать, чтобы круто?
Серверы — это понятие растяжимое... Допустим аpache, nginx, mysql, oracle известно на чём написаны. Собственно и MS продукты тоже не на .Net или Java, как ни странно. )))
А вот для определённых неторопливых внутрикорпоративных дел... Ну да я уже писал про это. )))
НС>Пока что на фанатика больше похож ты, когда предмет не знаешь, но огульно обвиняешь.
Эщэ, вообще то я как раз отвожу каждому инструменту свою нишу. У .Net и Java она своя и я несколько раз тут подчёркивал, что в своей нише они безусловно лучшие. У C++ тоже своя ниша. А сейчас у нас наблюдается вообще появления нового игрока — html5+javascript.
А вот как раз фанатики не могут признать что их инструмент не является нужным за пределами их ниши.
НС>Расскажи, что за проблемы быстродействия на работе ты решаешь?
Например работа с видео. Хотя мы в любом случае используем C++ не только для проектов требующих высокое быстродействие.
НС>Работа на низком уровне это драйвера что ли?
Вроде уже обсуждалось) Ну например реализация защиты ПО. Хотя драйверы — это тоже хороший пример.
Здравствуйте, Ночной Смотрящий, Вы писали:
E__>>Ну, отчасти эта консервативность — плюс(джава до сих пор бинарно совместима с древними махровыми версиями).
НС>Шарп тоже, до сих пор бинарно совместим с 2.0 (а небинарно с 1.0). Только бинарная совместимость никак развитию языка мешать не должна. В частности, для using точно рантайм менять не нужно.
Дык, я о том же. Добавить небольшую конструкцию в компилятор(благо, в жабе он простой как столб), да пронаследовать от какого-нибудь Disposable все внутренние классы, использующие внешние ресурсы. А то, глядя на эти дикие конструкции, хочется плакать кровавыми слезами.
E__>>Ну, у меня были в client-mode, и кто-то скажет, что это и не драйвера вовсе
НС>alex_public, несомненно, скажет
Ну да, драйвера должны быть суровыми, сишными, и крутиться в ядре. Я бы посмотрел, как выглядела бы реализация драйвера пин-клавиатуры в ядре(там очень много криптографии в логике, если что). Вместо моего относительно красивого кода, так как мне не пришлось перертягивать в код всю реализацию шифрования — для этого либы есть.
Новости очень смешные. Зря вы не смотрите. Как будто за наркоманами подсматриваешь. Только тетка с погодой в завязке.
There is no such thing as a winnable war.
H>С чего ты взял что плачут? Из последней убунты вообще моно решили выкинуть, так что там все без истерик
Но при этом он ставится одной командой. Ну, или при установке того же gnome-do(ибо оно на дотнете писано; кстати, хороший пример красивой и нужной десктопной проги мало того, что на дотнете, так еще и под линух).
Новости очень смешные. Зря вы не смотрите. Как будто за наркоманами подсматриваешь. Только тетка с погодой в завязке.
There is no such thing as a winnable war.
_>Вроде уже обсуждалось) Ну например реализация защиты ПО. Хотя драйверы — это тоже хороший пример.
Ну попробуй мне рассказать, что же я такое писал на джаве. Для взаимодействия с устройствами.
Новости очень смешные. Зря вы не смотрите. Как будто за наркоманами подсматриваешь. Только тетка с погодой в завязке.
There is no such thing as a winnable war.
V>>Да и вообще, упоминание системных вещей смешнее всего. Например, ACE/boost/libevent/ptlib и еще куче других либ пофиг тонкости отличий АПИ операционнок, а вот "кроссплатформенному" дотнету (С) — не пофиг. Цирк как он есть.
E__>Но какой ценой...
E__>
E__>И это ACE, которая еще вполне себе простая штука. В тот же буст я даже не полезу.
Полезь в STL, какие проблемы? От библиотеки требуется АПИ, а не тонкости реализации. Например STL обычно свой для каждой платформы свой, без всяких ifdef.
В общем, ACE затем и нужен, чтобы эти ifdef перенести из кода клиента в код библиотеки. Не хочешь сравнить отличия в реализации, скажем, джавы для разных платформ?
Это наверно "такой ценой"... (С)
E__>>И это ACE, которая еще вполне себе простая штука. В тот же буст я даже не полезу.
V>Полезь в STL, какие проблемы? От библиотеки требуется АПИ, а не тонкости реализации. Например STL обычно свой для каждой платформы свой, без всяких ifdef.
Этот подход мне больше нравится. Но получается, что сам код STL далек от кроссплатформенности, что и требовалось довазать.
V>В общем, ACE затем и нужен, чтобы эти ifdef перенести из кода клиента в код библиотеки.
Ага. Только хочешь глянуть на то, как код внутри реализован(абсолютно нормальная практика в жабе), открываешь, и закрываешь нафиг. Ибо читабельно очень с трудом.
V>Не хочешь сравнить отличия в реализации, скажем, джавы для разных платформ? .Это наверно "такой ценой"... (С)
Мне реализация JVM еще ни разу не пригождалась. А вот в ACE пришлось покопаться.
Новости очень смешные. Зря вы не смотрите. Как будто за наркоманами подсматриваешь. Только тетка с погодой в завязке.
There is no such thing as a winnable war.
Здравствуйте, Eugeny__, Вы писали:
E> H>С чего ты взял что плачут? Из последней убунты вообще моно решили выкинуть, так что там все без истерик
E> Но при этом он ставится одной командой. Ну, или при установке того же gnome-do(ибо оно на дотнете писано; кстати, хороший пример красивой и нужной десктопной проги мало того, что на дотнете, так еще и под линух).
Так там все одной командой ставится, вопрос то ведь не в этом А с линзами юнити никакой гном-до не нужен
Здравствуйте, Eugeny__, Вы писали:
E__>Ну попробуй мне рассказать, что же я такое писал на джаве. Для взаимодействия с устройствами.
Откуда мне знать? ) Хотя в любом случае если там главное работа с устройствами, то на C++ это было бы проще, т.к. без всяких костылей типа JNI. Правда если эти костыли уже написаны кем-то раньше, то тогда вполне может быть выгоднее просто дописать немного.
Здравствуйте, alex_public, Вы писали:
E__>>Ну попробуй мне рассказать, что же я такое писал на джаве. Для взаимодействия с устройствами.
_>Откуда мне знать? ) Хотя в любом случае если там главное работа с устройствами, то на C++ это было бы проще, т.к. без всяких костылей типа JNI. Правда если эти костыли уже написаны кем-то раньше, то тогда вполне может быть выгоднее просто дописать немного.
JNI там и в помине не было. Устройства подключаются к ком порту, и открываешь его просто как файл. Причем единообразно в винде и линухе(кроссплатформенные дрова получились, хехе). Ну или usb, но с эмуляцией ком порта(отличается только тем, что нужно открыть не /dev/ttySх, а /dev/ttyUSBx, в винде просто номер кома 10+). Ком-порт, если что, до сих пор стандарт в области всяких финансовых девайсов(и слава яйцам).
Новости очень смешные. Зря вы не смотрите. Как будто за наркоманами подсматриваешь. Только тетка с погодой в завязке.
There is no such thing as a winnable war.
Здравствуйте, alex_public, Вы писали:
E__>>JNI там и в помине не было. Устройства подключаются к ком порту, и открываешь его просто как файл. Причем единообразно в винде и линухе(кроссплатформенные дрова получились, хехе). Ну или usb, но с эмуляцией ком порта(отличается только тем, что нужно открыть не /dev/ttySх, а /dev/ttyUSBx, в винде просто номер кома 10+). Ком-порт, если что, до сих пор стандарт в области всяких финансовых девайсов(и слава яйцам).
_>Ну так значит драйвер тут у нас в самой ОС есть — ничего писать не надо. А пишем обычную прикладную программу. Если там нет больших потоков данных (ну собственно т.к. ком-порт, то уже понятно что нет), то без разницы на чём писать. Что на C++, что на Java, что на Питоне. Точнее всё зависит от квалификации сотрудников. )))
Ну, программу, которая общается с устройством на уровне специфического бинарного протокола, я бы не назвал прикладной.
А так да, данных там немного, и я даже не парился особо с ресурсами, ибо по сравнению с тем количеством мусора(в памяти), который генерит юзеринтерфейс, сотня байт в секунду от драйвера — это сущие мелочи, по профайлингу там выходили какие-то дикие доли процентов процессора(за гранью 6 нулей с правой части от десятичной запятой).
Новости очень смешные. Зря вы не смотрите. Как будто за наркоманами подсматриваешь. Только тетка с погодой в завязке.
There is no such thing as a winnable war.
Здравствуйте, Eugeny__, Вы писали:
V>>Полезь в STL, какие проблемы? От библиотеки требуется АПИ, а не тонкости реализации. Например STL обычно свой для каждой платформы свой, без всяких ifdef.
E__>Этот подход мне больше нравится. Но получается, что сам код STL далек от кроссплатформенности, что и требовалось довазать.
Разве? А мне показалось, что С++ и STL составляют платформу, не? А то масло-маслянное выходит если утверждать, что "платформа не кроссплатформенна".
V>>В общем, ACE затем и нужен, чтобы эти ifdef перенести из кода клиента в код библиотеки. E__>Ага. Только хочешь глянуть на то, как код внутри реализован(абсолютно нормальная практика в жабе), открываешь, и закрываешь нафиг. Ибо читабельно очень с трудом.
А где ты видел в ACE какую-либо реализацию, коль речь о кроссплатформенной ее части, а не о прикладной? Более 80% ее кроссплатформенного кода — это просто адаптеры сигнатур и типов различных АПИ. А остальное — это эмуляция отсутствующих ср-в низлежащего АПИ другими его ср-вами. Там смотреть толком не на что. Ес-но куча ifdef, бо под каждое АПИ идёт своя ветка адаптации. А то, что уже идет уровнем повыше — там уже никаких ifdef, ACE использует собственный низлещащий АПИ. Т.е. библиотеку ACE можно поделить на две фундаментальные вещи: это адаптеры АПИ ОС и кое-какой прикладной функционал, сидящий поверх этих адаптеров.
V>>Не хочешь сравнить отличия в реализации, скажем, джавы для разных платформ? .Это наверно "такой ценой"... (С) E__>Мне реализация JVM еще ни разу не пригождалась. А вот в ACE пришлось покопаться.
Ну, да, баги там бывают порой... Но для единственного разработчика да еще и бесплатности — это весьма и весьма недурное поделие. Согласись, даже нелепо сравнивать трудозатраты на джаву и ACE. Могу лишь риторически пожалеть, что boost так поздно стал доходить до ума и даже до сих пор кое-где сырее, чем ACE.
Просто коль речь о кроссплатформенности, то пример ACE — это был пример, что кроссплатформенность дается относительно дешево в плане трудозатрат, если на эту кроссплатформенность изначально нацелиться. Я сам на дотнете активно разрабатываю с 2002-го года, еще с его бет, и там ни разу кроссплатформенностью и не пахло. Постоянно натыкаюсь на торчащие уши WinAPI (бо и на нем поработал прилично до этого, еще хорошо его помню). Очевидно же, что они не ставили задачу написать кроссплатформенный фреймворк. Да и вообще, можно сравнить весь фреймворк, необходимый для работы современных приложений vs то его подмножество, что удалось включить в стандарт. Вот тебе кроссплатформенная часть vs вся остальная.
Здравствуйте, Ночной Смотрящий, Вы писали:
V>>Да че ты так к UI привязался? Платформенно-независимого UI хоть попой ешь. Проблемы только у конкретно дотнета с их непереносимыми WinForms и WPF НС>Т.е. в случае плюсов платформонезависимую либу взять можно, а дотнета уже нельзя?
Можно, но ведь не берут, бо как-то не сложилась дотнетная культура вне VisualStudio. А без культуры не будет обратной связи и развития, т.е. не будет заметной доли кроссплатформенных аппликух.
ИМХО, что-то странное в сообществе дотнетных разработчиков происходит: тут рядом на полном серьезе на совет использовать DirectX для напрашивающейся для этого задачи отвечают в том духе, что это совсем уже за рамками привычного... И отвечает довольно сильный дотнетчик.
Это приговор, однако.
V>>Брехня опять. Моно сильно отличается от версии MS. НС>Чем конкретно?
АПИ библиотек, иногда поведением/спецификациями при том же самом внешнем АПИ (сигнатурах). В общем, отличается от спецификаций дотнета. Список отличий трекается и постоянно обновляется.
V>> Для примера, QT для разных платформ имеет одно и то же АПИ. А у меня сходу ни одно приложение для дотнета на Моно не идет. НС>А у меня кое что идет.
Замечательно.
V>> Т.е. это надо забыть про дотнет и разрабатывать под Моно даже на виндах, чтобы получилось кроссплатформенно. НС>Не обязательно. Можно просто периодически проверять на Моно, различия там не такие уж и большие.
Это одно и то же. Если ориентируемся на меньшее подмножество АПИ, то значит именно под него ведем разработку. Т.е. Visual Studio выступает уже не как целевой tool-chain, а как удобный редактор кода.
Здравствуйте, MxMsk, Вы писали:
MM>>>с точки зрения наличия программистов со знанием DirectX Т>>Пардон, освоить сабсет функций DX, нужный для рисования графиков, можно за день. MM>Прикинул, в принципе я тоже могу выучить наизусть 10 функций из любого API за один день. Жаль, что этого недостаточно для качественный разработки.
Мы всё ещё о рисовании графиков?
Нафига учить API наизусть? Сколько тебе надо времени чтоб понять какие функции тебе нужны чтобы нарисовать график?
MM>Если эта оценка, как и предыдущая, сделана "за 1 день", то наверняка по факту траблов хватит. Но можешь вычеркнуть.
Камрад, я вплотную занимался графикой на DirectX начиная с DirectX 7. И как бы знаю что там и как.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>>>А смешанные сборки — это ж Win32 бинарник, никакой кроссплатформенности без всяких вайнов. Т>>Моно смешанные сборки даже на Windows не поддерживает. НС>Естественно. Ибо незачем.
Вот поэтому когда стала задача кровь из носу дописать в проект, который заточен под mono поддержку работы с такой вот сборкой пришлось городить подпорки из говна высочайшей очистки.
Здравствуйте, Codechanger, Вы писали:
C>Знаете, я бы с удовольствием посмотрел бы на реальные кроссплатформенные проекты с человеческим интерфейсом(на десктопе, естественно, а не в вебе, там как раз понятно все).
Здравствуйте, MxMsk, Вы писали:
MM>>>с точки зрения наличия программистов со знанием DirectX Т>>Пардон, освоить сабсет функций DX, нужный для рисования графиков, можно за день. MM>Прикинул, в принципе я тоже могу выучить наизусть 10 функций из любого API за один день. Жаль, что этого недостаточно для качественный разработки.
Для тех дебрей, куда вы уже залезли в WPF, и пары лет мало. Даже если мало одного дня (согласен, надо два минимум)... ну выдели в команде самого сообразительного и любознательного и дай ему неделю на эксперименты. Он продвинется за эту неделю дальше, чем вы всей остальной командой за пару месяцев, если уж тяжеловесные графики или схемы рисовать надо (из дестяков/сотен тыщ элементов). Technology evaluation — это нормальный и обязательный процесс в современных конторах... чтобы однажды не встрять надолго всей командой из-за какой-нить ерунды.
Здравствуйте, alex_public, Вы писали:
_>Кстати, а MC++ вообще кто-то использует?
Я видел как использовали для заворачивания сторонней .lib чтоб заюзать как .net сборку.
Больше ничего не попадалось.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Впрочем, если верить Mary-Jo Foley (а ей стоит верить) — кое что в Win8 оттуда просочилось.
Ещё один повод не притрагиваться к W8 покуда не выйдет W9
Здравствуйте, Eugeny__, Вы писали:
E__>Ну да, драйвера должны быть суровыми, сишными, и крутиться в ядре.
"Правильный байкер должен быть небрит, с перегаром и волосат" (С) да!!!
E__>Я бы посмотрел, как выглядела бы реализация драйвера пин-клавиатуры в ядре(там очень много криптографии в логике, если что).
Пфффф. ЛЕХКО! RSA и ECC из kernel driver уже делали, а всякая мелочёвка типа хэшей, блочных и потоковые шифров, OEAP и прочие паддинги это как шонить обоссать.
Это как раз всё просто.
Вот например network connection из ядра поднять до недавнего времени в винде было геморно.
E__> Вместо моего относительно красивого кода, так как мне не пришлось перертягивать в код всю реализацию шифрования — для этого либы есть.
А шо, либы разве в кернеле не собираются? У меня почему то собрались, причём С++ либы, не plain C.
Здравствуйте, Eugeny__, Вы писали:
E__>JNI там и в помине не было. Устройства подключаются к ком порту, и открываешь его просто как файл.
Нууу. Это сложно назвать драйвером. По сути это как стареньким terminal подрубиццо к модему и слать ему AT команды.
Настоящий дравер там сидит ниже, и предоставляет тебе высокоуровневый API эмулируя файловое устройство, через которое ты и лезешь.
Здравствуйте, Трололоша, Вы писали:
MM>>Если эта оценка, как и предыдущая, сделана "за 1 день", то наверняка по факту траблов хватит. Но можешь вычеркнуть. Т>Камрад, я вплотную занимался графикой на DirectX начиная с DirectX 7. И как бы знаю что там и как.
Угу. Вот поэтому тебе и кажется, что всё просто. Потому, что ты уже потратил черте сколько времени "вплотную".
Здравствуйте, Eugeny__, Вы писали:
E> Ну, программу, которая общается с устройством на уровне специфического бинарного протокола, я бы не назвал прикладной.
Эт почему? У меня с 3G-модемом общается вполне себе прикладная софтина, уж точно не драйвер нихрена
Здравствуйте, hattab, Вы писали:
H>Здравствуйте, Eugeny__, Вы писали:
E>> Ну, программу, которая общается с устройством на уровне специфического бинарного протокола, я бы не назвал прикладной.
H>Эт почему? У меня с 3G-модемом общается вполне себе прикладная софтина, уж точно не драйвер нихрена
Драйвер — её компонент.
Драйвер не обязан быть ядерным. Во многих случаях (как USB) в разы проще делать драйвер в userland.
Здравствуйте, MxMsk, Вы писали:
MM>>>Если эта оценка, как и предыдущая, сделана "за 1 день", то наверняка по факту траблов хватит. Но можешь вычеркнуть. Т>>Камрад, я вплотную занимался графикой на DirectX начиная с DirectX 7. И как бы знаю что там и как. MM>Угу. Вот поэтому тебе и кажется, что всё просто. Потому, что ты уже потратил черте сколько времени "вплотную".
Да не укусит, не боись ты так.
Потрать одни выходные на эксперименты.
Здравствуйте, gandjustas, Вы писали:
_>Кстати, я вот не однократно замечаю, что многие люди в спорах типа Java или .Net против Native зацикливаются виртуальной машине. Так вот никакой виртуальной машины нет. Байткод компилируется непосредственно в машинный код. Также существует расхожее заблуждение что "виртуальная машина" что-то ограничивает. Но по сути она дает даже больше возможностей. Например генерация типобезопасного кода во время работы программы. Оптимизация динамически типизированного кода. И даже банальную возможность возвращать из функции лямбду с честным замыканием.
Здравствуйте, MxMsk, Вы писали:
MM>>>Если эта оценка, как и предыдущая, сделана "за 1 день", то наверняка по факту траблов хватит. Но можешь вычеркнуть. Т>>Камрад, я вплотную занимался графикой на DirectX начиная с DirectX 7. И как бы знаю что там и как. MM>Угу. Вот поэтому тебе и кажется, что всё просто. Потому, что ты уже потратил черте сколько времени "вплотную".
То, что нужно для рисования графиков заняло крохи времени. DX умеет сильно больше, вот на всё остальное надо много времени.
Здравствуйте, vdimas, Вы писали:
V>Можно, но ведь не берут, бо как-то не сложилась дотнетная культура
Или потому что не особо нужно. Там где таки нужно — берут.
V> вне VisualStudio
А при чем тут VS? VS кроссплатформенные библиотеки использовать не мешает.
V>>>Брехня опять. Моно сильно отличается от версии MS. НС>>Чем конкретно?
V>АПИ библиотек
Все общие библиотеки по АПИ идентичны. Если есть расхождение — это бага.
V>Список отличий трекается и постоянно обновляется.
Все действительно серьезные и частые проблемы уже вычистили.
V>>> Т.е. это надо забыть про дотнет и разрабатывать под Моно даже на виндах, чтобы получилось кроссплатформенно. НС>>Не обязательно. Можно просто периодически проверять на Моно, различия там не такие уж и большие.
V>Это одно и то же.
Нет, не одно.
V> Если ориентируемся на меньшее подмножество АПИ, то значит именно под него ведем разработку.
У меня есть весьма большие проекты, где никто ни на какое подмножество никогда не ориентировался. Тем не менее на Моно спортировалось без урезания функционала и переписывания больших кусков.
V> Т.е. Visual Studio выступает уже не как целевой tool-chain, а как удобный редактор кода.
Все там нормально со студией. Для Моно студия по прежнему остается основной IDE. Потому что, во-первых, никто не обязывает использовать моновские компиляторы, а во-вторых и для моновского компилятора есть интеграция в студию (см. Mono tools for VS).
Здравствуйте, Трололоша, Вы писали:
Т>Вот поэтому когда стала задача кровь из носу дописать в проект, который заточен под mono поддержку работы с такой вот сборкой
Не распарсил. И не понял, нафига на моно понадобилась смешанная сборка. Расцепляй на managed сборку и нативную либу, делов то. И никаких говноподпорок.
Здравствуйте, alex_public, Вы писали:
_>Я же спрашивал уже в этой теме, в MC++ временем жизни объекта управлет GC или нет? И какой был ответ? )
Нормальный был ответ. В зависимости от того, как объект был создан. Если в управляемой куче — управляет. Если в неуправляемой — не управляет. Что тут непонятно?
НС>>"Рисование формочек", а точнее качественный UI — одна из самых сложных задач в программировании.
_>Скорее задач дизайна и эргономики.
И программирования тоже.
_> ) А запрограммировать уже нарисованный интерфейс сейчас может и обезьяна.
Тебе кажется.
_>Серверы — это понятие растяжимое... Допустим аpache, nginx, mysql, oracle известно на чём написаны.
tomcat, resin, trac, hg и т.п. тоже известно.
_> Собственно и MS продукты тоже не на .Net или Java, как ни странно. )))
У МС много продуктов.
_>Эщэ, вообще то я как раз отвожу каждому инструменту свою нишу
Только вот очень специфично ты ее отводишь.
_>А вот как раз фанатики не могут признать что их инструмент не является нужным за пределами их ниши.
Кто именно?
_>Хотя мы в любом случае используем C++ не только для проектов требующих высокое быстродействие.
Вот вот.
_>Ну например реализация защиты ПО. Хотя драйверы — это тоже хороший пример.
Здравствуйте, Трололоша, Вы писали:
E__>>JNI там и в помине не было. Устройства подключаются к ком порту, и открываешь его просто как файл. Т>Нууу. Это сложно назвать драйвером.
Точно. Крутые перцы, они из кернелмоды не вылазят. А обезьянки драйверов не могут, да.
Т>Настоящий дравер там сидит ниже
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Здравствуйте, RomikT, Вы писали:
RT>>Добавили уже RT>>try-with-resources
НС>А это в какой версии? И этот Closeable, его в стандартной библиотеке везде реализовали?
В седьмой, последней. Реализовали много где (здесь есть список), хотя может что-то и забыли.
Здравствуйте, Uzumaki Naruto, Вы писали:
K>>рассмотрим на примере только дотнета, я его лучше всего знаю, а проблемы у его собратьев такие же.
UN>Рассмотрим на примере java... все работает прекрасно на всех платформах...
Ага расскажите-ка пожалуста про Java под Андроидом и ее производительность... Назвать это нормальной работой у меня язык не поворачивается.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Не распарсил. И не понял, нафига на моно понадобилась смешанная сборка.
Она уже есть. И её надо заюзать.
НС> Расцепляй на managed сборку и нативную либу, делов то.
Готовую закрытую сборку стороннего производителя?
НС> И никаких говноподпорок.
Если бы всё всегда было просто.
Здравствуйте, Ночной Смотрящий, Вы писали:
V>>GTK V>>— GoogleChrome
НС>Мой хром на chrome://credits/ никакого гтк не упоминает
На виндах WTL, на Linux пишет GIMP Toolkit.
Собственно, там всё GUI — это меню, тулбары и адресная строка. Все остальные диалоги выполнены как веб-страницы, которые, в свою очередь, на кроссплатформенном WebToolkit.
Здравствуйте, hattab, Вы писали:
n>> H>Эт почему? У меня с 3G-модемом общается вполне себе прикладная софтина, уж точно не драйвер нихрена n>> Драйвер — её компонент. n>> Драйвер не обязан быть ядерным. Во многих случаях (как USB) в разы проще делать драйвер в userland. H>Драйвер обеспечивает функционирование устройства (и никакого отношения к софтине не имеет вообще),
Он вообще-то тоже софт.
H> а прикладуха общается с девайсом для своих чисто утилитарных нужд.
И может тоже обеспечивать его функционирование.
H> Какой же она драйвер...
Позиция понятна, но меня такая терминология не устраивает из-за её непрактичности. В приведённом мной примере в ядре драйвер USB стека и хоста, а далее что-то в userland. Но если оно управляет устройством, то оно — драйвер. Так, может быть, не соответствует постановлениям какого-то очередного ВЦСПС или MS, но вещи называются, imho, своими именами.
Здравствуйте, netch80, Вы писали:
n> H>Драйвер обеспечивает функционирование устройства (и никакого отношения к софтине не имеет вообще),
n> Он вообще-то тоже софт.
А никто и не спорит
n> H> а прикладуха общается с девайсом для своих чисто утилитарных нужд.
n> И может тоже обеспечивать его функционирование.
В рамках прикладной области, но не в рамках взаимодействия с ОС.
n> Позиция понятна, но меня такая терминология не устраивает из-за её непрактичности. В приведённом мной примере в ядре драйвер USB стека и хоста, а далее что-то в userland. Но если оно управляет устройством, то оно — драйвер. Так, может быть, не соответствует постановлениям какого-то очередного ВЦСПС или MS, но вещи называются, imho, своими именами.
Я не знаю о постановлениях партии и МС, руководствуюсь исключительно здравым смыслом. Сейчас вот решил свериться с вики:
Дра́йвер (англ. driver, мн. ч. дра́йверы[1]) — это компьютерная программа, с помощью которой другая программа (обычно операционная система) получает доступ к аппаратному обеспечению некоторого устройства.
А кернел или юзермод значения не имеет, это частности.
Здравствуйте, hattab, Вы писали:
H>Я не знаю о постановлениях партии и МС, руководствуюсь исключительно здравым смыслом. Сейчас вот решил свериться с вики:
Уже смешно: "исключительно здравый смысл" для тебя стал некритичным цитированием википедии.
H>
Дра́йвер (англ. driver, мн. ч. дра́йверы[1]) — это компьютерная программа, с помощью которой другая программа (обычно операционная система) получает доступ к аппаратному обеспечению некоторого устройства.
А если это будет не программа, а компонент программы, то твоему здравому смыслу начинает казаться, что принципиальное условие нарушено?
Хорошо, встречный вопрос: а если работа с устройством выделена в отдельную SO, она же DLL?
И тут же попутный вопрос — является ли драйвер в ядре отдельной *программой*?
H>А кернел или юзермод значения не имеет, это частности.
Здравствуйте, Kingofastellarwar, Вы писали:
E__>>Мухи — отдельно, котлеты — отдельно. Дотнет писан МС-ом, и реальная мультиплатформенность им не нужна. Жаба очень даже мультиплатформенна, и проектов на ней, где это пригождается очень и очень много. В основном это энтерпрайз, но все-таки.
K>а зачем энтерпрайзу мультиплатформенность?
О топ менеджеры такие выдумщики И спокойно могут отдать команду на замену железа причем с другой архитектурой И ключевые слова здесь "халява", "откат" и "по дружбе". Если кто-то скажет, что в России и не такое может быть, то спешу разочаровать — данный опыт связан в основном с зарубежными компаниями...
Здравствуйте, netch80, Вы писали:
n> H>Я не знаю о постановлениях партии и МС, руководствуюсь исключительно здравым смыслом. Сейчас вот решил свериться с вики:
n> Уже смешно: "исключительно здравый смысл" для тебя стал некритичным цитированием википедии.
Узнаю рафинированного интеллектуала закатывающего глазки от цитирований вики На что считаю возможным задать вопрос: а ты, собственно, сам-то, чьих будешь?
n> H>
Дра́йвер (англ. driver, мн. ч. дра́йверы[1]) — это компьютерная программа, с помощью которой другая программа (обычно операционная система) получает доступ к аппаратному обеспечению некоторого устройства.
n> А если это будет не программа, а компонент программы, то твоему здравому смыслу начинает казаться, что принципиальное условие нарушено?
Давай я тебе на пальцах объясню, как для первоклашки, коли ты решил затеять терминологический спор. Есть утилька, ну скажем, PhenomMsrTweaker для управления AMD'шной Cool&Quiet. В ее состав входят собственно драйвер и гуй. И драйвер и гуй являются отдельными программами (я это юниксоиду объясняю, офигеть). Так понятнее?
Здравствуйте, hattab, Вы писали:
n>> H>Я не знаю о постановлениях партии и МС, руководствуюсь исключительно здравым смыслом. Сейчас вот решил свериться с вики:
n>> Уже смешно: "исключительно здравый смысл" для тебя стал некритичным цитированием википедии.
H>Узнаю рафинированного интеллектуала закатывающего глазки от цитирований вики На что считаю возможным задать вопрос: а ты, собственно, сам-то, чьих будешь?
Я не знаю, что такое "чьих" в твоём варианте (мне эти российские закидоны с определением групповой принадлежности как-то в принципе непонятны), но дело не в википедии (я её сам рихтую помаленьку, BTW), а в *некритичном* отношении. Ты отказался от одного источника, но вдруг принял другой без всякого анализа. Что, собственно, и смущает.
n>> А если это будет не программа, а компонент программы, то твоему здравому смыслу начинает казаться, что принципиальное условие нарушено?
H>Давай я тебе на пальцах объясню, как для первоклашки, коли ты решил затеять терминологический спор.
Спор начал ты. Твоя фраза "У меня с 3G-модемом общается вполне себе прикладная софтина, уж точно не драйвер нихрена" в ответ на реплику собеседника.
H> Есть утилька, ну скажем, PhenomMsrTweaker для управления AMD'шной Cool&Quiet. В ее состав входят собственно драйвер и гуй. И драйвер и гуй являются отдельными программами (я это юниксоиду объясняю, офигеть). Так понятнее?
Оно-то понятно, но как само по себе, а не ответ на вопрос. Ты от него ушёл.
Здравствуйте, netch80, Вы писали:
n> H>Узнаю рафинированного интеллектуала закатывающего глазки от цитирований вики На что считаю возможным задать вопрос: а ты, собственно, сам-то, чьих будешь?
n> Я не знаю, что такое "чьих" в твоём варианте (мне эти российские закидоны с определением групповой принадлежности как-то в принципе непонятны)
Пацик-нацик?
n>но дело не в википедии (я её сам рихтую помаленьку, BTW), а в *некритичном* отношении. Ты отказался от одного источника, но вдруг принял другой без всякого анализа. Что, собственно, и смущает.
Ты из факта цитирования делаешь слишком глубокие выводы, это называется высасыванием из пальца
n> H>Давай я тебе на пальцах объясню, как для первоклашки, коли ты решил затеять терминологический спор.
n> Спор начал ты. Твоя фраза "У меня с 3G-модемом общается вполне себе прикладная софтина, уж точно не драйвер нихрена" в ответ на реплику собеседника.
Это был не спор о терминах, это был намек на то, что ни всякая софтина общающаяся с девайсом является драйвером.
n> H> Есть утилька, ну скажем, PhenomMsrTweaker для управления AMD'шной Cool&Quiet. В ее состав входят собственно драйвер и гуй. И драйвер и гуй являются отдельными программами (я это юниксоиду объясняю, офигеть). Так понятнее?
n> Оно-то понятно, но как само по себе, а не ответ на вопрос. Ты от него ушёл.
Здравствуйте, hattab, Вы писали:
n>> H>Узнаю рафинированного интеллектуала закатывающего глазки от цитирований вики На что считаю возможным задать вопрос: а ты, собственно, сам-то, чьих будешь? n>> Я не знаю, что такое "чьих" в твоём варианте (мне эти российские закидоны с определением групповой принадлежности как-то в принципе непонятны) H>Пацик-нацик?
Да нет, просто перестаю понимать, что там творится. Вроде и язык тот же, и говорят вроде так же, но смысл оказывается совсем другим. Это в политике, но фраза про "чьих будешь?" в техническом контексте сразу завернула туда.
n>>но дело не в википедии (я её сам рихтую помаленьку, BTW), а в *некритичном* отношении. Ты отказался от одного источника, но вдруг принял другой без всякого анализа. Что, собственно, и смущает. H>Ты из факта цитирования делаешь слишком глубокие выводы, это называется высасыванием из пальца
С моей точки зрения, понимание того сообщения как "а вот смотри, где истинное мнение" однозначно.
n>> H> Есть утилька, ну скажем, PhenomMsrTweaker для управления AMD'шной Cool&Quiet. В ее состав входят собственно драйвер и гуй. И драйвер и гуй являются отдельными программами (я это юниксоиду объясняю, офигеть). Так понятнее? n>> Оно-то понятно, но как само по себе, а не ответ на вопрос. Ты от него ушёл. H>Акцентировал болдом. Так лучше?
В плане объяснения своей позиции — да. В плане адекватности её видимым вокруг реалиям — нет.
Здравствуйте, Ночной Смотрящий, Вы писали:
_>>Я же спрашивал уже в этой теме, в MC++ временем жизни объекта управлет GC или нет? И какой был ответ? ) НС>Нормальный был ответ. В зависимости от того, как объект был создан. Если в управляемой куче — управляет. Если в неуправляемой — не управляет. Что тут непонятно?
Тогда как это соотносится с фразой "А для RAII unsafe и не нужен. C++/CLI вполне его обеспечивает в чисто managed контексте.(c) Ночной Смотрящий" ?
_>>Серверы — это понятие растяжимое... Допустим аpache, nginx, mysql, oracle известно на чём написаны. НС>tomcat, resin, trac, hg и т.п. тоже известно.
Особенно порадовал hg — просто мегасевер. Классный аргумент!
_>>Ну например реализация защиты ПО. Хотя драйверы — это тоже хороший пример. НС>Ага, маргинальный. Как и защита ПО.
Ага, ага, только благодаря этим маргиналам вы вообще можете пользоваться компьютером.
Здравствуйте, hattab, Вы писали:
H>Да я более чем внятно все объяснял, даже ссылку на вики давал (поверь, там описано все очень внятно). Я думаю тут есть явное нежелание сторонников дотнета признать тот простой факт, что он не кроссплатформенен
Так все же, давай выясним какая часть некросплатформенна-то? А то вот я сейчас напишу на шарпе программу, и под линухом и под виндами ее скомпилю и запущу. Что мы имеем в виду под кроссплатформенностью? Кроссплатформенность на уровне сырцов, бинарей или еще чего-то? Плюсовый вот на уровне сырцов кроссплатформенный, частично правда, так же как и шарповый код. Тока тут под платформой следует понимать скорее не windows/linux, в .net/mono. При соблюденнии определенных правил и использовании определенных либ шарповый код переносим между .net и моно платформами, следовательно будет работать везде, где будет одна из этих платформ. Найдите отличия от джавы или плюсов.
Здравствуйте, Трололоша, Вы писали:
НС>>Точно. Крутые перцы, они из кернелмоды не вылазят. А обезьянки драйверов не могут, да. Т>Дело не в кернелмоде.
Ну как же — драйвера в юзермоде это и не драйвера вовсе, не та степень крутизны.
Т>Еслиб он вешался сверху на порт и наружу выставлял бы в паблик какой либо более высокоуровневый API
А там именно все так и есть, насколько я понял автора.
Здравствуйте, alex_public, Вы писали:
НС>>Нормальный был ответ. В зависимости от того, как объект был создан. Если в управляемой куче — управляет. Если в неуправляемой — не управляет. Что тут непонятно?
_>Тогда как это соотносится с фразой "А для RAII unsafe и не нужен. C++/CLI вполне его обеспечивает в чисто managed контексте.(c) Ночной Смотрящий" ?
Прекрасно соотносится. Не понимаю, что тебя смущает.
_> Особенно порадовал hg — просто мегасевер.
А что с ним не так? Вполне себе неплохой сервер.
_>>>Ну например реализация защиты ПО. Хотя драйверы — это тоже хороший пример. НС>>Ага, маргинальный. Как и защита ПО.
_>Ага, ага, только благодаря этим маргиналам вы вообще можете пользоваться компьютером.
Здравствуйте, Ночной Смотрящий, Вы писали:
V>>На виндах WTL, на Linux пишет GIMP Toolkit. НС>И это демонстрация кроссплатформенности?
Во-первых, основа UI там — это WebToolkit.
НС>Это как раз демонстрация обратного: хочешь качественный UI — делай для каждой платформы свой собственный.
WebToolkit один на всех.
Во-вторых, из всего GUI системное там только меню и окошки-хосты для WebToolkit. Поэтому даже WTL — это было перебор.
Во-третьих, даже MS не использует свои собственные системные меню Windows в своих собственных флагманских продуктах типа Office или VisualStudio. В общем, именно из-за "для каждой платформы свой собственный", выпадающее меню в Google Chrome под Windows выглядит как убого, а на остальных платформах — как привычное качественное (С) меню с иконками.
Я уверен, что это временно, бо продукт активно разрабатывается. Например, в MenuStrip под дотнетными WinForms этот нелепый баг с потерей фокуса главным окном при выпадении их нового кастомного меню продержался дольше, чем прошло с первого релиза GoogleChrome. Хотя, казалось бы, аналогичное меню уже было в Офисе и самой Студии, можно было просто портировать код...
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>>>Точно. Крутые перцы, они из кернелмоды не вылазят. А обезьянки драйверов не могут, да. Т>>Дело не в кернелмоде. НС>Ну как же — драйвера в юзермоде это и не драйвера вовсе, не та степень крутизны.
Не болтайте ерундой.
Т>>Еслиб он вешался сверху на порт и наружу выставлял бы в паблик какой либо более высокоуровневый API НС>А там именно все так и есть, насколько я понял автора.
Давай может лучше напрямую спросим у автора.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Можно и готовую, если очень захотеть.
Через задницу — можно.
НС> А можно попросить этого самого производителя изготовить раздельно.
В данном случае — нельзя.
Здравствуйте, netch80, Вы писали:
n> H>Ты из факта цитирования делаешь слишком глубокие выводы, это называется высасыванием из пальца
n> С моей точки зрения, понимание того сообщения как "а вот смотри, где истинное мнение" однозначно.
Неправильное понимание Это была ссылка на публичный, общедоступный и модерируемый источник информации с некоторыми претензиями на энциклопедичность (с чем-то не согласен? можешь отрихтовать ). Более того, это была ссылка подтверждающая мое собственно мнение (а не мнение составленное по изучению сего ресурса).
n> n>> H> Есть утилька, ну скажем, PhenomMsrTweaker для управления AMD'шной Cool&Quiet. В ее состав входят собственно драйвер и гуй. И драйвер и гуй являются отдельными программами (я это юниксоиду объясняю, офигеть). Так понятнее?
n> n>> Оно-то понятно, но как само по себе, а не ответ на вопрос. Ты от него ушёл.
n> H>Акцентировал болдом. Так лучше?
n> В плане объяснения своей позиции — да. В плане адекватности её видимым вокруг реалиям — нет.
Здравствуйте, мыщъх, Вы писали:
М>создание 400х чек-боксов показывает, что программисты совсем разучились думать и хотят готовых _стандартных_ компонентов под нестандартную задачу, хотя она на чем угодно реализуется элементарно и без тормозов и без ограничения на кол-во элементов в гриде. хоть миллион на миллион. ловим событие "щелчок", смотрим где мыша, вычисляем позицию верхнего левого угла элемента, из битового массива берем его состояние, меняем на противоположное и рисуем либо галку либо пустое место.
Сейчас откопал свою старую софтину, с примерно такой же задачей и таким же решением, и вспомнил про эту ветку. У меня тоже пара сотен контролов притормаживала, пришлось писать всю обработку вручную.
Но дьявол — в деталях, это пришлось делать примерно в 95 году, под 3.11 винду для 386/486 машин без всякого ускорения видео.
Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.
Здравствуйте, Ops, Вы писали:
Ops>Здравствуйте, мыщъх, Вы писали:
Ops>Сейчас откопал свою старую софтину, с примерно такой же задачей и таким же решением, и вспомнил про эту ветку. Ops>У меня тоже пара сотен контролов притормаживала, пришлось писать всю обработку вручную.
когда-то по глупости попытался на MFC загнать в объект list (или как он называется? уже не помню) несколько сотен тысяч элементов (может быть больше -- забыл за давностью). винда попросила веревку и кусочек мыла. мыла я ей не дал, а стал динамически добавлять элементы только в ту часть списка, которая отображается на экране, но оно все равно тормозило и потому плюнл и написал свой список с нуля на основе окна. взлетело. до сих пор удивляюсь как люди словари пишут. типа лингво. там же вроде стандартный список (ну в ранних версиях точно стандартный). вероятно, добавляют динамически, хотя я не спец по гуи, так что могу ошибаться.
Ops>Но дьявол — в деталях, это пришлось делать примерно в 95 году, под 3.11 винду для 386/486 машин без всякого ускорения видео.
я писал чуть позже для 95 винды. так же писал тетрис примерно в то же время для изучения основ GDI32. НТ мои выходки терпела (я там создавал слишком много кистей и прочих GDI-объектов), а 98 винда вела себя странно и в какой-то момент тетрис из цветного превращался в черно-белый, т.к. было создано слишком много GDI-объектов. плюнул и спустился на уровень ниже, рисуя в памяти и потом копируя на экран как битмап. заработала. с тех пор у меня аллергия на все виндовые контролы и потому предпочитаю писать руками.
но 400 чекбоксов это все же перебор. ведь чек-бокс это довольно сложный элемент управления вообще-то. и ресурсоемкий. тут в соседней ветке обсуждают "память больше не ресурс". а чек-бокс это не только память. если вам нужно 400 пепельниц вы же не будете покупать 400 мерседесов
americans fought a war for a freedom. another one to end slavery. so, what do some of them choose to do with their freedom? become slaves.
Здравствуйте, мыщъх, Вы писали:
М>Здравствуйте, Kingofastellarwar, Вы писали:
K>>рассмотрим на примере только дотнета, я его лучше всего знаю, а проблемы у его собратьев такие же. М>дотнет это ни разу не мультиплатформа, ибо официально поддерживается только венда, да и то не всех версий. так что даже в рамках венды это не мультиплатформа.
Слушай, видимо у меня карма такая, что я говорю в принципе те-же слова, а в меня начинают mono тыкать и переводить разговор на "так ведь шарп же кроссплатформа!!"
Здравствуйте, мыщъх, Вы писали:
М>но 400 чекбоксов это все же перебор. ведь чек-бокс это довольно сложный элемент управления вообще-то. и ресурсоемкий. тут в соседней ветке обсуждают "память больше не ресурс". а чек-бокс это не только память. если вам нужно 400 пепельниц вы же не будете покупать 400 мерседесов
Так 40 чекбоксов вполне могдли работать и тогда без явных тормозов, сейчас 400 должны выплевываться на ура просто грубой силой — одни частоты выросли в 20+ раз, не говоря уже про общую производительность железа. Про непосредственно рисование вообще не говорю — можно рендерить их помногу за раз на любой, не самой древней видюхе, это вам не S3 Trio64.
В MMO играх бывают сцены с несколькими сотнями персонажей, и они как-то ведь отрисовываются, причем в динамике, а персонаж — это далеко не чек-бокс по сложности и ресурсам.
Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.
М>но 400 чекбоксов это все же перебор. ведь чек-бокс это довольно сложный элемент управления вообще-то. и ресурсоемкий. тут в соседней ветке обсуждают "память больше не ресурс". а чек-бокс это не только память. если вам нужно 400 пепельниц вы же не будете покупать 400 мерседесов
Почему, блин, в столь гонимой всеми тут жабе 400 чекбоксов рисуются и работают на ура? Не, ну я понимаю, что они там рисуются ручками, а не виндовыми контролами(в жабе весь интерфейс тупо рисуется на канвасе жабовским кодом), но все-таки... Там тоже иерархия контролов с лайоутами, куда похлеще и посложнее виндовой, плюс все менеджед до самых костей, но тормозов-то нет(точнее, на старых машинах есть, но тормоза ровно одинаковые для прорисовки текста и кучи контролов, обусловленные все той же интерпритируемой отрисовкой по пикселю).
Новости очень смешные. Зря вы не смотрите. Как будто за наркоманами подсматриваешь. Только тетка с погодой в завязке.
There is no such thing as a winnable war.
Здравствуйте, Eugeny__, Вы писали:
E__>Здравствуйте, мыщъх, Вы писали:
E__>Почему, блин, в столь гонимой всеми тут жабе 400 чекбоксов рисуются и работают на ура?
потому что в винде тяжелое наследие грехов молодости. не скажу на семерку, но в NT линейке контролы реально монстроузны. но тут пишут, что win api не тормозит, а тормозят всякие фрейморки поверх него.
но тут вопрос в другом. в чем проблема нарисовать все это самому? оно же совсем просто рисуется. даже если писать на win api, но реализовать этот функционал можно за один день (сейчас мне скажут за любовь к велосипедам).
americans fought a war for a freedom. another one to end slavery. so, what do some of them choose to do with their freedom? become slaves.
Здравствуйте, мыщъх, Вы писали:
М>но тут вопрос в другом. в чем проблема нарисовать все это самому? оно же совсем просто рисуется. даже если писать на win api, но реализовать этот функционал можно за один день (сейчас мне скажут за любовь к велосипедам).
Если не тормозит (а на виндовых контролах это так, не знаю как в .Net), то и незачем рисовать самому. )
Здравствуйте, Eugeny__, Вы писали:
E__> в жабе весь интерфейс тупо рисуется на канвасе жабовским кодом ... обусловленные все той же интерпритируемой отрисовкой по пикселю
С чего вы взяли, что в Java2D все рисуется "жабовским кодом" и "по пикселю"? Как раз наоборот, растеризация векторной графики выполняется в нативном коде, а отрисовка готовых bitmaps и закрашивание прямоугольников уже давно ускоряется через direct3d/opengl.
Здравствуйте, Ночной Смотрящий, Вы писали:
_>>Кстати, возможно не всё так плохо НС>Учитывая запрет P\Invoke для обычных приложений и грядущий переезд на новое ядро — забудь.
Здравствуйте, Ночной Смотрящий, Вы писали:
_>>Так вот. Если говорить о наличие библиотек и поддержке платформ, то очевидно что C++ тут безусловный лидер.
НС>С. Без всяких ++.
А смысл платить больше за то же самое?
В чистом С замахаешься ресурсами управлять и без эксепшенов тоже просеивать коды ошибок не весело.
НС>Ну как же — драйвера в юзермоде это и не драйвера вовсе, не та степень крутизны.
Это зависит от "многошаговости" внутри одной операции драйвера. Если из юзермодовского надо многократно обращаться к OS API, то да, степень получается существенно не та. По крайней мере на x86/x64-архитектурах.
Здравствуйте, vdimas, Вы писали:
_>>>Так вот. Если говорить о наличие библиотек и поддержке платформ, то очевидно что C++ тут безусловный лидер. НС>>С. Без всяких ++. V>А смысл платить больше за то же самое? V>В чистом С замахаешься ресурсами управлять и без эксепшенов тоже просеивать коды ошибок не весело.
Здравствуйте, vdimas, Вы писали:
V>Ему уже очень много лет
Не так уж и много. Если не считать всяких экспериментальных релизов, то чуть больше 4 лет.
V>, но до сих пор никто не видел на нем игр, сравнимых с нейтивными на той же железке.
Если нам не помогут, то мы тоже никого не пощадим.
А без хамства уже никак не обойтись?
Тут же ссылки можно даже не десятками, а сотнями кидать.
