Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>·>Тут надо отличать. Логические утечки: утечки ресурсов (незакрытые файлы, невозвращённые коннекты в пул, етс), утечки данных (вечнорастущий контейнер или забитый диск) возможны вообще в любом ЯП. А я имею в виду утечки памяти на уровне самого ЯП. EP>На C++ тот же механизм что и для памяти, применим и для ресурсов. На управляемых языках же начинаются всякие полумеры типа using/with/try-with-resources — которые не спасают от транзитивности "быть ресурсом" и т.п. — и потерять ресурс там намного легче, что намного хуже ибо приводит к логическим ошибкам, а не просто OOM.
Я об этом и говорю. С ресурсами сложно обращаться, соответственно, — чем их меньше в коде — тем лучше. А в С++ худший крайний случай: каждый объект — ресурс.
EP>·>утечки данных (вечнорастущий контейнер или забитый диск) возможны вообще в любом ЯП EP>На C++ подобные утечки (видимо которые ты называешь "языковыми") могут быть только в случае цикла в ref-counted графе. EP>Да и то вопрос — если там ресурсы, это уже "языковая" утечка, или как? Ибо если ресурсы c prompt finalization то и на Java будет тот же ref-counting, только кривой
Угу. Если нет ресурсов — нет проблем. Но в реальном мире без них не обойтись, но можно хотя бы стараться минимизировать.
EP>Отсутствие же утечек других родов легко гарантировать (в том смысле который ты называешь "языковым") — не используй голый new, используй RAII — и проблема решена (именно в плане "языковых" утечек). Легко верифицируется простым grep'ом (либо Clang'ом, но чуть сложнее). EP>Они могут лишь появится в коде с сильно кастомными структурами данных, да и то далеко не в каждой структуре данных требуется именно голый new/delete.
Ещё не используй голые указатели и ссылки. И аккуратно продумывай свои структуры данных, чтобы они вдруг ВНЕЗАПНО не оказались "сильно кастомными" (cyclic ref имеешь в виду?).
EP>·>А я имею в виду утечки памяти на уровне самого ЯП. EP>Тут грань очень тонкая, ибо никогда не используемые данные на которые есть ссылка — это тоже утечка, и могла бы например разруливаться на уровне ЯП/компилятора (особенно если язык не полный по Тьюрингу).
Ну это пока только в соседней Вселенной, к сожалению.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, ·, Вы писали:
EP>>·>Тут надо отличать. Логические утечки: утечки ресурсов (незакрытые файлы, невозвращённые коннекты в пул, етс), утечки данных (вечнорастущий контейнер или забитый диск) возможны вообще в любом ЯП. А я имею в виду утечки памяти на уровне самого ЯП. EP>>На C++ тот же механизм что и для памяти, применим и для ресурсов. На управляемых языках же начинаются всякие полумеры типа using/with/try-with-resources — которые не спасают от транзитивности "быть ресурсом" и т.п. — и потерять ресурс там намного легче, что намного хуже ибо приводит к логическим ошибкам, а не просто OOM. ·>Я об этом и говорю. С ресурсами сложно обращаться, соответственно, — чем их меньше в коде — тем лучше. А в С++ худший крайний случай: каждый объект — ресурс.
При этом добавление нового ресурса где-нибудь в глубине композиции это тривиальная операция в отличии от C#/Java, так как свойство "быть ресурсом" — транзитивно, и эта транзитивность встроена в C++.
EP>>Отсутствие же утечек других родов легко гарантировать (в том смысле который ты называешь "языковым") — не используй голый new, используй RAII — и проблема решена (именно в плане "языковых" утечек). Легко верифицируется простым grep'ом (либо Clang'ом, но чуть сложнее). EP>>Они могут лишь появится в коде с сильно кастомными структурами данных, да и то далеко не в каждой структуре данных требуется именно голый new/delete. ·>Ещё не используй голые указатели и ссылки.
Нет, голые указатели и ссылки вполне можно использовать — на УТЕЧКИ они никоим образом не влияют. Например часто итератор вектора это всего лишь указатель
(когда говорят о запретах обычно имеют в виду голые владеющие указатели (которая сопряжены с голым new), а не обычные non-owning)
·> И аккуратно продумывай свои структуры данных, чтобы они вдруг ВНЕЗАПНО не оказались "сильно кастомными" (cyclic ref имеешь в виду?).
Нет, здесь не cyclic ref (сразу же оговорку сделал — "Отсутствие же утечек других родов"), а те случаи где у тебя будет new в явном виде — вот они крайне редки, ибо даже внутри собственных структур данных обычно используются готовые vector, unique_ptr, etc, etc, а не new и голые владеющие указатели.
EP>>·>А я имею в виду утечки памяти на уровне самого ЯП. EP>>Тут грань очень тонкая, ибо никогда не используемые данные на которые есть ссылка — это тоже утечка, и могла бы например разруливаться на уровне ЯП/компилятора (особенно если язык не полный по Тьюрингу). ·>Ну это пока только в соседней Вселенной, к сожалению.
Я-то понимаю что ты хотел сказать — что-то такое что помогло провести границу между C++ и другими языками в этом плане.
Но термин "утечки на уровне самого ЯП" — не точен, ибо любую утечку можно подогнать под это определение.
Здравствуйте, alex_public, Вы писали:
_>·>Это же числодробилка чистейшая. Я говорю о среднем случае, для типичных задач. _>Согласен что числодробилка. И согласен что в среднем по приложению будет совсем не такое громадное отставание, а как ты и говорил в пару раз. Но как на счёт упомянутых тобой небольших усилий, с помощью которых можно свести отставание к десятку процентов? ) Какая у нас будет оптимизация в случае данного кода? )))
Сам же понимаешь, что это нетипичный случай.
_>·>Да и кстати C++ no-simd как раз в 2 раза быстрее таки. JIT похоже не умеет simd. _>Насколько я слышал умеет, но не для таких целей (автовекторизацию циклов действительно не умеет). Но как бы это не оправдание для отставания, как ты понимаешь. )))
За цену managed можно и потерпеть. В сишный компилер вложено ещё больше человеколет, ибо чрезвычайно важно.
_>·>ИЧСХ — c# оказался ещё медленнее. _>Да, причём совершенно неожиданно для меня. Потому что по идее никаких предпосылок для этого нет. Ведь как язык то C# всё же получше. И никакого escape-анализа и т.п. тут по идее не возникает. Но практика вот показывает такое...
Как язык (набор фич) может и лучше (дело вкуса), а вот внутре... Да банально потому, что в JVM оптимизацию вложено больше человеколет именно в оттачивание производительности, ибо важно. А Майкрософт привлекает фичами, соответственно и вкладывается в них.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>·>Ты первый начал чушь пороть. Но я хоть что-то похожее на аргументы привёл. А вот ещё: DYNAMIC_DOWNCAST EP>·>Доказать-то сможшешь, что java — динамический? EP>Язык со статической типизацией. Но даже на статическом языке можно переходить в динамику, из чего вытекает меньшее количество статических проверок.
Язык становится динамическим ,когда тип языковых конструкций не проверяется компилятором. Вот например в c#
dynamic dynamic_ec = new ExampleClass();
// The following line is not identified as an error by the
// compiler, but it causes a run-time exception.
dynamic_ec.exampleMethod1(10, 4);
т.е. синтаксически вызов метода exampleMethod1 выглядит как и вызов любого другого метода, те же лексемы. Но компилятор опускает проверку, т.к. знает о специальном исключительном случае "dynamic" типа.
в java таких "фич" нет, и не надо. Хочешь так извращаться, бери какой-нибуь groovy.
EP>Утрированный пример: something.call("function_name"); — ошибка в имени функции вылезет только в runtime даже в языке со статической типизацией.
Утрированный пример: std::map<std::string, std::function<void> >something; something.at("function_name")();. Ну как? Запишем таки С++ в динамические языки?
EP>Вещей типа вылета pure virtual call в рантайме при статическом полиморфизме нет. Они появляются при переходе на динамические конструкции.
В java даже "pure virtual call" нет. Получается C++ ещё более динамический!
Ты похоже путаешь "статический|динамический полиморфизм" и "статический|динамический язык".
EP>Чем больше типов стирается, тем меньше ошибок может поймать компилятор. Например если использовать везде штуки типа boost::any — то и ошибки будут рантаймовые.
Ну точно С++ — динамический!
EP>Твой оппонент говорит о том (и с чем я согласен), что в коде на управляемых языках программисты как раз склонны
Потому что ничем не грозит. В Java неправильное приведение типа — исключение, в Плюсах — UB.
EP>к излишнему динамизму по сравнению с C++ — в котором например статический полиморфизм используется повсеместно.
Потому что обычный полиморфизм тормозит.
EP>·>А так кодогенерацию можно в run-time делать (в Плюсах — невозможно). EP>Возможно
А есть что-то реальное, а не заброшенный 10 лет назад студенческий курсовик?
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, ·, Вы писали:
EP>>·>Ты первый начал чушь пороть. Но я хоть что-то похожее на аргументы привёл. А вот ещё: DYNAMIC_DOWNCAST EP>>·>Доказать-то сможшешь, что java — динамический? EP>>Язык со статической типизацией. Но даже на статическом языке можно переходить в динамику, из чего вытекает меньшее количество статических проверок. ·>Язык становится динамическим ,когда тип языковых конструкций не проверяется компилятором.
Ещё раз, не язык становится динамическим, а в коде используется больше динамических подходов. Простейшее для понимания утверждение жеж
·> Вот например в c# ·>
·>dynamic_ec.exampleMethod1(10, 4);
·>
·>т.е. синтаксически вызов метода exampleMethod1 выглядит как и вызов любого другого метода, те же лексемы. Но компилятор опускает проверку, т.к. знает о специальном исключительном случае "dynamic" типа.
Замени на dynamic_ec.call("exampleMethod1", 10, 4); — типизация статическая, а код такой же динамический как и с dynamic в C#, со всеми вытекающими недостатками (типа меньшего количества статических проверок).
·>в java таких "фич" нет, и не надо.
Нормальная фича.
EP>>Утрированный пример: something.call("function_name"); — ошибка в имени функции вылезет только в runtime даже в языке со статической типизацией. ·>Утрированный пример: std::map<std::string, std::function<void> >something; something.at("function_name")();. Ну как? Запишем таки С++ в динамические языки?
Ты не понимаешь о чём речь. И на C++ можно писать с кучей динамики, более того можно вообще дёргать eval какого-нибудь динамического языка.
Речь же о том что обычно на Java больше динамики чем на C++, а не о том что у него типизация динамическая.
·>Ты похоже путаешь "статический|динамический полиморфизм" и "статический|динамический язык".
Прикольно, вообще-то это ты тут запутался. Я не говорил что у Java динамическая типизация — перечитай сообщение ещё раз.
EP>>Твой оппонент говорит о том (и с чем я согласен), что в коде на управляемых языках программисты как раз склонны ·>Потому что ничем не грозит. В Java неправильное приведение типа — исключение, в Плюсах — UB.
Ты опять не понимаешь о чём речь. Дело не в UB или ещё в чём-то (в одной из форм dynamic_cast как раз исключение) — ещё раз посмотри на dynamic_ec.call — там никакого UB.
EP>>к излишнему динамизму по сравнению с C++ — в котором например статический полиморфизм используется повсеместно. ·>Потому что обычный полиморфизм тормозит.
В этой под-теме не важно почему — факт того что в C++ больше статики налицо. Больше статики — больше проверок времени компиляции.
EP>>·>А так кодогенерацию можно в run-time делать (в Плюсах — невозможно). EP>>Возможно ·>А есть что-то реальное, а не заброшенный 10 лет назад студенческий курсовик?
Твоё утверждение о невозможности — не верно. Банально с собой можно тасккать компилятор — и получаешь runtime кодогенерацию.
А какой-там пример — заброшенная библиотека или например OpenCL — рояли не играет — если проявить чуточку фантазии то будет и runtime-кодогенерация
Здравствуйте, ·, Вы писали:
EP>>·>А то внезапно у тебя не получится сделать std::vector<MyType> и придётся лепить std::vectior<some_smart_pointer<MyType>> и прочее. EP>>Может придётся, а может и нет, и по-умолчанию скорее нет чем да. В Java же эта индерекция будет всегда, не считая варианты с байт-буферами и прочим ручным нарезанием. ·>Но далеко не всегда эта индирекция будет создавать хоть какие-то заметные проблемы.
Естественно — и на Python'е пишут полезные программы, и на 1С. Речи о том что "всё пропало" — нет. Просто факт важный для производительного кода, только и всего
"The going word at Facebook is that 'reasonably written C++ code just runs fast,' which underscores the enormous effort spent at optimizing PHP and Java code. Paradoxically, C++ code is more difficult to write than in other languages, but efficient code is a lot easier [to write in C++ than in other languages]." – Herb Sutter at //build/, quoting Andrei Alexandrescu
EP>>>>О, в Java наконец появятся структуры? EP>>·>О java 9 он вроде поторопился, фичефриз уже прошел, релизят через пол года (но пробовать можно уже сейчас), но есть планы в 10ке https://en.wikipedia.org/wiki/Project_Valhalla_(Java_language) через года полтора-два. EP>>Во-во, а ты спрашивал что за косвености(индерекции), вот же они: ·>Я вроде и не спрашивал, ты меня с кем-то путаешь. Я знаю что эти индирекции создают перф проблемы.
Тогда в чём был вопрос здесь?
·>Я не понял твоё высказывание. косвенность чего? Почему на единицу, а не на 0.99 или 42?
Причём тут рациональная косвенность 0.99? И что не понятно про меньшую на единицу косвенность?
·> Однако, не всегда эти проблемы заметны. Там где эти проблемы заметны — можно пофиксить, да, не так красиво как со структурами или подобным, но можно.
С тем что "можно" я не спорю, а наоборот утверждаю.
Здравствуйте, ·, Вы писали:
·>Здравствуйте, Serginio1, Вы писали:
S>>>> Еще раз это аналог .NGEN. Он мало, что дает. И оптимизации для андроид версии там скорее всего нет, ибо батарея будет садиться быстро. S>>·>.net native делается с целью убрать зависимость от fw (который изначально был непереносимым и неотъемлимым компонентом системы, засунутый по самые гланды), а производительность за счёт чего? (ну кроме как за счёт исправления косяков ngen). S>> За счет того, что JIT не сильно оптимизирующий компилятор. Кстати в UUnity там пошли в IL2CPP ·>Это потому что в dotnet плохая реализация JIT, ну не смогли. В java такой проблемы в общем случае нет. ·>ART кстати тоже через С компилирует. Т.к. AOT оказалась более подходящей в условиях мобильных девайсов, т.к. там пользователям важно, чтобы приложения стартовали как можно быстрее, а не раскочегаривались. В серверных же применениях явы — JIT рулит и бибикает.
Ну вот видишь уже подвижка. Согласился что нужен натив для андроида. S>>·>Цели убрать такую зависимость в ART нет, поэтому сделали именно так. S>>·>Компиляторы java->native были, есть и будут если понадобится. Каких-то принципиальных проблем их использовать — нет. S>>·>Я, кстати, много лет назад использовал GCJ, чтобы собрать из java-кода standalone (в смысле без каких либо зависимостей) dll. S>> Еще раз есть кроссплатформенный .Net Core, который кстати позволяет работать только с используемыми библиотеками. S>>https://habrahabr.ru/post/311520/ и не зависить от Фреймворка. Так что твои умозаключения об зависимости от фреймвока нет. ·>Я запутался. Зачем и core, и native?
А, то что в для .Net Native нужны библиотеки по .NetStandard S>> Главное скорость, расход батареи, обфускация. ·>Скорость чего? Инстолляции? Кого это парит? Расход батареи тут не причём, т.к. ART компилирует только в install time (времени расходутеся как правило меньше, чем на скачку). Сколько раз в день ты ставишь новый софт на свой мобильник?
Специально для тебя выделил твои же слова.
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>>>Нет, не даст — на уровне массива интов отличия как раз непринципиальные. I>>Вообще то разница уже видна
EP>Вот кстати пример в тему — взяли сортировку массива int64, с прибитыми гвоздями типами и компаратором — на C++ и Java сделали практически идентичный код (с поправкой на отсутствие указателей), и произвели замер: EP>36:16 EP>В итоге получили как раз разницу в те самые десятки процентов
Вот здесь фраза "most advantageous for Java as possible", это уже интересно. Но я чтото не вижу результатов замера ?
Здравствуйте, ·, Вы писали:
V>>Да, я охотно верю, что в пути кода, обрабатывающего FIX-сообщение, нет приведений типов. Но это один процент от всего приложения, пусть и самый критичный к эффективности. В остальном его будет дофига. А еще если брать совсем остальное что ты предложил: базы, отчеты, платежи и т.д., то там в джаве динамика динамикой погоняет. ·>Какой динамикой? Ты о чём? Почитай учебники что-ли, хоть ту же вики:
Почитай лучше реальный код или АПИ всевозможных джавовских фреймворков (системных и прикладных), поверх которых вы всё там рисуете.
V>>Возьми огромные проекты на С++ (мильоны открытых) и поищи грепом этот dynamic_cast. В подавляющем большинстве их не встретишь ни одного. V>>Сейчас вообще модно компилить с отключением RTTI. В коммерческом коде так и вовсе dynamic_cast — нонсенс. ·>Ты первый начал чушь пороть.
Не кипишуй, это не чушь, это реальный расклад.
·>Но я хоть что-то похожее на аргументы привёл.
Я тебе предлагал исходниками обменяться. Ты отказался. Потому единственно, что ты можешь защищать — это собственный код. А если брать любой открытый джавовский — так я и вовсе сразу победил, потому что тысячу раз прав. Единственный тут тонкий момент — ты можешь продолжать утверждать, что у вас не так.
Как в песне Слепакова — "они все такие, а я не такой!" ))
Это макрос для убожества MFC от 90-го года разработки.
Покажешь мне проекты новее 2000-го года на MFC?
·>Доказать-то сможшешь, что java — динамический?
Да любым фреймворком, тем же Spring. Неужели ты никогда не пользовался Spring?
Или взять абсолютно любые провайдеры зависимостей (их часто зовут IoC-контейнерами, что само по себе неграмотно, кста).
Или взять абсолютно любые провайдера JPA и т.д.
Везде в основе лежат даункасты и динамика.
V>>·>Что такое "уровень типизации"? V>>Имелась ввиду статическая типизация. ·>предложение "Потому что статической типизации исходника несопоставим от слова совсем." тоже смысла не имеет. Что сказать-то хочешь?
С этой поправкой имеет. Хотя, я уверен, из контекста был понятен и первоначальный вариант.
Представь на минуту, что в Джава вообще запретили динамическое приведение типов. Ну вот включи воображение. Всё, с этого момента такой операции тупо нет в JVM. Вот как ты будешь писать код?
V>>·>Не понял, можно пример? Что мешает в java сделать так же? V>>Даункасты мешают. Это просто такой принцип построения архитектуры и привычки девелоперов, что без даункаста никуда. ·>Так увольте вы, наконец, этих девелоперов, наймите нормальных.
Да-да, и перестань пользоваться джавовскими библиотекам.
V>>·>Это я к тому, что наличие плохих тестов на Джава, не означает невозможность писать хорошие тесты. И наоборот. V>>Я не придирался к кач-ву отдельных тестов, я же однозначно выразился — речь идёт о покрытии 100% веток кода. Т.е. речь о полноте набора тестов, принятых в мире Джавы. Сколько видел — позитивных тестов больше негативных. А их должно быть намного-намного больше. Но в Джава малость другая философия, а именно — выплюнул исключение наверх и дело с концом. ·>Ну покрывай сколько хочешь, хоть 101%. Причём тут исключения? Я перестал понимать о чём ты говоришь, какой-то поток ворчания.
Да какое уж тут ворчание.
Просто ты в упор проблемы не видишь в привычном для Джавы подходе слабого покрытия кода тестами и вот тебе кажется, что я тупо придираюсь. Ы-Ы-Ы, как грится.
Понимаешь, в Джаве принято покрывать тестами только целевые юз-кейзы, а не всю потенциальную комбинаторику вызовов, которая может произойти (по различным причинам) в реальном сложном приложении. Именно поэтому считается, что в среднем коде Джава намного больше ошибок, чем в С++. Тут как бэ условная "безопасность" среды немного расслабляет и вот эта "безопасность" с лихвой компенсируется россыпью логических ошибок. В итоге шило на мыло, как по мне. Если бы в С++ творилась подобная небрежность, программы на С++ вообще бы не работали. Се ля ви.
И да, порой покрыть всю комбинаторику возможных вызовов сложно даже для некоего одиночного объекта, имеющего более 3-х зависимостей. Такая суровая необходимость борьбы со взрывным комбинаторным ростом потенциально-возможных сочетаний прогона одного и того же кода диктует экосистеме С++ специфические правила хорошего тона, а именно — необходимо резко ограничивать исходную размерность пространства "разрешённого".
Ограничивают это пространство через, да-да, ту самую суровейшую статическую типизацию. Дешевый шаблонный механизм С++, отсутствие пенальти за абстракции (средний мелкий объект/структура шириной всего в один int может являть из себя агрегат из кучи шаблонных типов, 3-5 уровней агрегации — запросто, хоть 10), меньше имерархий и диспетчеризации по конкретным типам.
Например, есть такой оксюморон в плюсах — "статический визитор". Понятно, что визитор НЕ может быть статическим. Тут речь о том, что тот класс задач, который во многих языках решается или через патерн-матчинг или через паттерн Посетитель или даже через тупой прямой опрос типа объекта и даункаст в стиле if(obj is Type1) {...} else if(obj is Type2){} и т.д., в 99% случаев в С++ такая задача решается через статическую диспетчеризацию. К каждому прикладному объекту С++ можно цеплять кучу признаков времени компиляции. Причем, такие признаки могут быть как простыми интегральными флажками (булевскими, целыми, некие типизированные enum), так и целыми глубочайшими иерархиями типов, в свою очередь снабженными подобными флагами. И всё это живёт только в compile-time. В случае джава подобные флаги надо либо вносить явно как часть данных (поля/св-ва) и поверять их в рантайм, либо как часть типа, вводя иерархии наследования и плодя на ровном месте виртуальные ф-ии в protected-интерфейсе классов, которые (виртуальные ф-ии) собсно и являют собой ту самую рантайм-диспетчеризацию (либо по поведению, либо по возвращаемому значению некоего виртуального св-ва-признака).
В итоге, если сравнить программы на С++ и Джава, писанные для решения той же самой задачи, в исполнении С++ может обнаружиться в несколько раз больше конечных (инстанциированных) типов, но при этом намного меньше кода. Угу, шаблоны С++ и Джавы не сравнимы, ес-но и базовая инфраструктура для такого метапрограммирования на сейчас развита не то, чтобы хорошо, а уже даже черезчур. Было бы желание понять ЗАЧЕМ это всё нужно языку С++.
В итоге, тестов для С++ понадобится тоже меньше, т.к. всевозможные неверные вызовы, которые можно осуществить в Джава и на потенциальную возможность которых стоит написать тесты, в хорошей С++-программе даже в исходнике выразить невозможно — компилятор же не даст!
Вот такая тут связь типизированности, тестового покрытия и надежности конечных программ.
V>>·>Количество информации доступной JIT — больше, так что не всё так однозначно. V>>Откуда больше? ·>Потому что он видит реальные данные, с которыми работает программа, наиболее частые потоки выполнения, реально используемые в данный момент классы, и т.п.
Ясно. ))
Мне поискать для тебя обсуждения по суперкомпиляции, которые тут происходили в разные годы?
Кароч, за последние лет 10 мало что изменилось, т.е. положа руку на, у тебя есть возможность НЕСПЕШНО ознакомиться с этим вопросом.
Простого "ты не прав" ты не примешь, ес-но, опять будет лишь ругань, выражения из разряда "мелешь чушь, газируешь лужи" и прочая непотребщина.
V>>Ну вот как раз Сессия — объект самого верхнего уровня и создаётся в куче. Но таких объектов во всём приложении — просто мизерный мизер. ·>Текущие данные в сессии — тоже могут быть сложными объектами со сложным lifecycle.
У сессии есть только её состояние, — в смысле состояния эквивалентного конечного автомата. А вот как кодируется и реализуется конечный автомат — дело сильно разное для С++ и Джавы, ес-но. В Джаве окромя паттерна State и подходов-то вменяемых нет.
Тут как в классике. Есть функция вычисления следующего состояния от типа и системных полей входящего сообщения + состояния сессии + внешних сигналов, и так же ф-ия выхода (колбэков) как ф-ия текущего состояния + типа и системных входящего сообщения.
V>>Например, все справочные данные можно хранить в коллекциях по-значению. ·>Всяко бывает, не только справочники.
Это был просто очевидный пример из области реализации HFT.
Там 90% всех данных в этой области — это справочники: диалекты протоколов, типы полей, пришедшие с биржи описания рынков, разделов, фидов, типов инструментов, типов ордеров, типов валют, размерностей тиков, контрагентов, настроек и т.д. до бесконечности.
V>>За время работы такие данные только добавляются, но никогда физически не удаляются (лишь помечаются как неактивные). ·>А почему нельзя удалить-то?
А зачем это делать для операций, происходящих раз в месяц примерно (удаление некоего инструмента?), если достоверно биржевая система перезапускается раз в сутки?
Тут банальная инженерная формулировка задачи и соотв.решение с учётом всех компроммисов по каждому из решений.
V>>Справочники хранятся как сбалансированное дерево или мультииндекс, итераторы остаются валидными после добавления нового элемента. ·>И ради чего?
Ради локальности в памяти + дешевой операции join.
V>>·>В HFT-системе (бирже, например) вполне можно обращаться к БД (но не из всех частей этой системы). V>>Если часть системы — отдельный от, собственно, HFT-матчинга процесс, то и стоит рассматривать именно его — что это за процесс, какие требования и т.д. Тем более, что такие вспомогательные процессы обычно на других физических узлах исполняются. ·>Пусть отдельный, пусть на других узлах. И что? Почему это должно как-то серьёзно отличаться в ЯП?
У другой задачи будет другая экосистема.
Такие вещи вообще приложение веб-сервера решать может, а веб-сервера сейчас на чём только не пишут. ))
Всё чаще на node.js, кста.
V>>>>В реальном HFT. V>>·>Наличие реального HFT не означает отсутствие нереального HFT. V>>И снова в Киеве дядька. ·>Моя телепатия меня всегда подводит, а ты как всегда сам слабо понимаешь о чём пишешь.
Да-да. И вообще опять лужу загазировал и прочее "несешь бред".
V>>>>·>Вести бд счетов, движение средств, и контактные и прочие данные клиентов. Архивы трейдов. Описание инструментов. V>>>>30-40 таблиц, я же давал тебе цифры уже. V>>·>И что? V>>Что Джава не сэкономит ни йоту времени на разработку на задачах такой размерности. ·>Спекуляция.
Борьба с мифами.
Спекуляцией является процесс наоборот — натягивать опыт из разработки и обслуживания больших информационных систем на маленькие.
Просто надо быть честными с самим собой.
Сама организация информационной структуры сложной системы — отдельная задача. Вот именно под эту задачу хорошо ложатся управляемые среды и куча их абстрактных интерфейсов, протоколов, фреймворков и прочего до бесконечности, куда ведут описательные ссылки из артефактов описаний архитектуры таких систем.
Если же всю информационную сложность можно описать скромной "плоской" брошюркой, то освободившиеся от поддержки "информационной целостности" (назовём так) усилия можно потратить на шлифовку неких критических путей прохождения кода за гораздо меньшую, чем в управляемых средах, трудоёмкость. Вот ты там описывал ручную плоскую разметку памяти FIX-сообщения. За ту же трудоёмкость можно написать половину FIX-движка.
V>>·>Джава работает прекрасно и даёт кучу бенефитов, уменьшает стоимость разработки. V>>Для задач уровня a+b никаких бенефитов нет. ·>Заблуждение.
Так убеди меня в обратном! ))
V>>·>Разве не прекрасно просто вызвать метод интерфейса в LL-Core сервисе, а имплементация интерфейса будет в другом DB-сервисе, который выполнит тормозной SQL? Не надо выдумывать совместимых сериализаций и протокола взаимодействия между разными языками. V>>RMI жрет ресурсы сам по себе, чтобы пользоваться им из узла основного сервиса. )) ·>Ну не используй RMI. У нас UDP-multicast в качестве транспорта.
Вот, пока что ты лишь подтверждаешь, а не убеждаешь в обратном.
V>>Ну реально, не смешно уже. Сегодня все задачи сетевые и C++ отлично себя в этих задачах чувствует. ·>Я рад за его здоровье. Но в Java это таки проще.
Смелее! Что такого я пропустил в Джава, что этого нет в С++ в плане сетевого обмена?
V>>От совсем уж лени можно взять точно такую же CORBA, я ей пользовался в некритичных к быстродействию приложениях. ·>CORBA вроде сдохла давно. И даже уже закопали.
Живет как раз там, где джависты хотят вызов методов удалённого объекта, а тот не на джаве или наоборот.
Т.е. там, где так и не освоили REST-модели.
V>>И то она гораздо легковеснее, чем RMI. ·>
Сие факт. RMI работает по рефлексии, а CORBA — через харкорный генерённый код. Разница в скорости сериализации-десериализации более чем на порядок.
V>>Да и вообще. В С++ другая философия. В этом языке вообще не принято создавать всякие иерархии, абстрактные базы/интерфейсы и т.д. V>>Это большая редкость — некий абстрактный интерфейс. ·>А что делать?
Ну я выше описал, что делать.
Другие языковые ср-ва.
V>>>>Такую "сложность" сейчас делают студенты на коленке на чем угодно. V>>·>Не надо ждать изменений от C++-икзпертов, когда java-"студентам" понадобилось внести изменение в "свою" часть. V>>С++-студентов тоже хватает. ·>Студенты в C++ такое понапишут... segfault это самое удачное будет.
Код студентов проходит ревью обязательно.
За попытки лезть в коллекции ручками можно пожурить и показать как правильно. Схватывают на лету обычно.
Надёжный код складывается из использования надёжных библиотек и надёжных языковых приёмов. Вот и весь "секрет".
V>>>>Потому что вес клиента и вес биржи несопоставимы. Клиентами бывают совсем маленькие брокерские конторы. Ну и ОК. V>>·>Так почему не Плюсы-то? Они экономят 0.00001% всех затрат что-ли? V>>Ну это к тебе вопрос, почему совсем небольшие конторы предпочитают Java. ·>Потому что дешевле обходится с теми же результатами. Мелким конторам приходится работать эффективнее, чтобы выживать.
Ну это же законы бизнеса чистой воды. Меньше вложишь, меньше получишь. Кто-то собирает сливки с биржи, а кто-то остатки.
V>>·>А сколько там Студия стоит? V>>Нисколько. V>>Что-то стоит только профессиональная версия и выше, но это уже для суровой командной работы ср-вами самой студии (что тоже редкость). ·>Ну IDEA Community тоже бесплатна, или Эклипс. А сурово работать иногда таки приходится.
Сурово — это разрозненный набор инструментария, отдельно для PM, отдельно для разработки архитектуры, отдельно issue tracking, отдельно git + куча плагинов разной степени курьёзности для объединения всего этого вместе? ))
Просто мало кто пользует инфраструктуру MS для командной разработки. Под "ср-вами самой студии" подразумевалось именно это.
V>>>>И не надо мне про Джаву в блокноте. На ней в блокноте писать невозможно от слова совсем, это будет идиотизм, а не разработка. V>>·>C++ в блокноте тоже не фонтан. V>>Проще намного, в отсутствии иерархий. ·>Опять занос какой-то... Каких ещё иерархий?
Наследования и переопределения виртуальных ф-ий. Потому что тут для понимания кода надо часто сказать вверх-вниз по иерархии.
V>>Достаточно какой-нить Kate. V>>Кода всегда меньше, локальные типы можно объявить и заюзать по месту, а не искать их в других папках/файлах и т.д. и т.п. V>>Разнообразие функторов, декларативный биндинг и т.д. и т.п. V>>Кароч, надобности в навигации резко меньше. ·>И получаются файлики на 10000 строк. Спасибо.
Не за что. В С++ порой отдельные методы в отдельные файлы выносятся.
Ну это так, для общего развития.
"Локальный код" и "один класс" — порой сильно разные понятия.
·>А если ты не знал, в одном файле можно делать множество java-классов (заметь, и .h-файлы не нужны!).
Открытый в соседнем окне h-файл, — это как открытый справочник. Есть такое. ))
В джаве для аналогичного надо специфическое представление кода.
V>>Там, где есть выход на скрипты, там уже совсем-совсем ни джава, ни дотнет не нужны. )) ·>Я не знаю зачем ты скрипты хочешь... Но если надо — они есть и в огромном количестве. Как легко прикрутить, скажем JS к С++? Ну, чтобы можно было C++ классы использовать и всё такое?
Я давал тебе ссылку.
V>>·>Жуть. Макросы макросами погоняют. Как и в старом добром MFC, даже CObject есть. Нового-то что? V>>Ну, маппинг XML для DB, как часто бывает в Джава, — это еще хуже, ИМХО. V>>Поэтому, указал и другой способ. ·>А что там хуже-то?
В разрыва второго рода. Неверный макрос хоть компилятор проверит, а тут в рантайме всё тазиком накроется.
·>С рефлексией-то из коробки? В худшем случае аннотацию воткнуть на класс придётся.
Твоя "аннотация" плохо вяжется с такими комментами:
Как в старом добром QT...
))
Да, я считаю, что на сегодня безопасней аннотаций ничего нет и быть не может, потому как рефакторинг и прочие глобальные поиски-замены ничего не ломают. Это моё ИМХО, но пока лучших подходов чем это я не видел.
·>Тут кодогенерация нужна на уровне исходников, чтобы в IDE работало всякое автодополнение и прочее. А так кодогенерацию можно в run-time делать (в Плюсах — невозможно).
А зачем в рантайм кодогенерация? Чтобы каждый раз выполнять ту самую однократную работу? ))
Мы как-то давным давно юзали предыдущее поколени BL Toolkit, там тоже есть рантайм-генерация акцессоров, так специально допилили код, чтобы эта генерация была как часть compile-time.
·>Но ведь можно не использовать Hibernate или JPA. Так и быть, разрешу тебе и это.
Остальное в чем-то хуже всегда.
V>>>>Интересно, на какую букву заменить первую в "jdbc", чтобы получить нечто, что на 20 лет старше самой джавы? )) V>>>>И да, вот еще интересно. Я вот видел некие провайдеры jdbc, писанные как JNI-обертки не напомнишь над чем? (рука-лицо снова) V>>·>Они оборачивают closed source пропиетарные native only коннекторы к субд, тут тупо других нет вариантов. V>>Ох, наивный. )) ·>А что тогда?
А структура этих ф-ий очень близка к АПИ ODBC (разве что одна операция ODBC описывается 2-3-мя из списка по ссылке, т.е. стандарт ODBC чуть более высокоуровневый).
По первой ссылке есть и для C++ обертки, написано, что АПИ совместимо с JDBC. Т.е. это является прямым ответом на твой вопрос.
Единственно что, это АПИ почти никогда в С++ проектах не используют.
Дело в том, что к БД лезут через какой-нить ORM-фреймворк, а у него свои типы-абстракции и их проще (и намного эффективнее) закодить через более низкоуровневый слой.
V>>·>Scala slick? V>>Да ну. В таком виде и на С++ писать можно: ·>Не понял я тогда что тебе надо.
ЧТД. Ничего. Всё есть.
V>>·>К Скале претезнии обычно в том, что язык слишком перегружен фичами и они не всегда друг с другом хорошо согласуются. V>>Ну да. Идущие для джава-машинки фичи плохо согласуются с основной философией Скалы. )) ·>А конкретно?
Тут тоже были развернутые обсуждения. ))
Лень начинать заново, можно попробовать поискать.
Для затравки, "всё является объектом" с т.з. Скалы и сущность "объект" с т.з. JVM — это сильно разные вещи.
Здравствуйте, Serginio1, Вы писали:
S>>> За счет того, что JIT не сильно оптимизирующий компилятор. Кстати в UUnity там пошли в IL2CPP S>·>Это потому что в dotnet плохая реализация JIT, ну не смогли. В java такой проблемы в общем случае нет. S>·>ART кстати тоже через С компилирует. Т.к. AOT оказалась более подходящей в условиях мобильных девайсов, т.к. там пользователям важно, чтобы приложения стартовали как можно быстрее, а не раскочегаривались. В серверных же применениях явы — JIT рулит и бибикает. S> Ну вот видишь уже подвижка. Согласился что нужен натив для андроида.
Нужен не натив как таковой, а АОТ. А вот у тебя подвижек нет, с терминами полный швах — AOT != натив. Подумай на досуге, что является результатом работы JIT?
S>>> Еще раз есть кроссплатформенный .Net Core, который кстати позволяет работать только с используемыми библиотеками. S>>>https://habrahabr.ru/post/311520/ и не зависить от Фреймворка. Так что твои умозаключения об зависимости от фреймвока нет. S>·>Я запутался. Зачем и core, и native? S> А, то что в для .Net Native нужны библиотеки по .NetStandard
Понятнее не стало. Зачем две технологии? Зачем два названия?
S>>> Главное скорость, расход батареи, обфускация. S>·>Скорость чего? Инстолляции? Кого это парит? Расход батареи тут не причём, т.к. ART компилирует только в install time (времени расходутеся как правило меньше, чем на скачку). Сколько раз в день ты ставишь новый софт на свой мобильник? S> Специально для тебя выделил твои же слова.
У тебя путаница с ЖЦ приложения.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, Ikemefula, Вы писали:
EP>>Вот кстати пример в тему — взяли сортировку массива int64, с прибитыми гвоздями типами и компаратором — на C++ и Java сделали практически идентичный код (с поправкой на отсутствие указателей), и произвели замер: EP>>36:16 EP>>В итоге получили как раз разницу в те самые десятки процентов I>Вот здесь фраза "most advantageous for Java as possible", это уже интересно.
Они говорят что не стали использовать обобщённую сортировку на C++ (с шаблонами), а прибили гвоздями тип элемента int64 и т.п. — чтобы сделать тест благоприятствующим для Java насколько возможно.
I>Но я чтото не вижу результатов замера ?
Здравствуйте, ·, Вы писали:
·>Здравствуйте, Serginio1, Вы писали:
S>>>> За счет того, что JIT не сильно оптимизирующий компилятор. Кстати в UUnity там пошли в IL2CPP S>>·>Это потому что в dotnet плохая реализация JIT, ну не смогли. В java такой проблемы в общем случае нет. S>>·>ART кстати тоже через С компилирует. Т.к. AOT оказалась более подходящей в условиях мобильных девайсов, т.к. там пользователям важно, чтобы приложения стартовали как можно быстрее, а не раскочегаривались. В серверных же применениях явы — JIT рулит и бибикает. S>> Ну вот видишь уже подвижка. Согласился что нужен натив для андроида. ·>Нужен не натив как таковой, а АОТ. А вот у тебя подвижек нет, с терминами полный швах — AOT != натив. Подумай на досуге, что является результатом работы JIT? https://ru.wikipedia.org/wiki/JIT-%D0%BA%D0%BE%D0%BC%D0%BF%D0%B8%D0%BB%D1%8F%D1%86%D0%B8%D1%8F
JIT-компиляция (англ. Just-in-time compilation, компиляция «на лету»), динамическая компиляция (англ. dynamic translation) — технология увеличения производительности программных систем, использующих байт-код, путём компиляции байт-кода в машинный код или в другой формат непосредственно во время работы программы.
Ahead-of-Time (AOT) компилятор — это вид транслятора, который использует метод компиляции перед исполнением (англ. ahead-of-time compilation). Применяется как для компиляции высокоуровневых языков (например, Си, С++ или Паскаль), так и для компиляции «промежуточных» языков, таких как байт-код Java, .NET Common Intermediate Language (CIL), IBM System/38, IBM System i.
Во многих реализациях языков программирования используется JIT-компиляция, которая позволяет компилировать промежуточный код напрямую в бинарный во время его выполнения, что позволяет существенно увеличить скорость выполнения. JIT требует выделения дополнительной памяти.
Метод АОТ не требует выделения дополнительной памяти и АОТ-компиляция проходит с минимальной нагрузкой на систему. Процесс компиляции полностью выполняется перед выполнением программы.
In some operating system configurations (mostly embedded systems) the operating system services for generating code dynamically are not available, this prevents Mono’s JIT from working. In those systems, you can use –aot=full to ensure that Mono precompiles everything, and then use the option –full-aot to ensure that Mono never uses the JIT engine.
# Do a full AOT:
$ mono --aot=full mscorlib.dll
$ mono --aot=full sample.exe
# Run, but request that Mono never tries to JIT:
$ mono --full-aot sample.exe
Full AOT is a fairly straightforward process except in the case of generic instantiations. In those cases Mono must perform a static analysis of the code and determine all of the possible instantiations of a type and generate the code required. For example if a program uses a List<int> and a List<double> mono will detect this and generate all of the referenced methods for both data types.
S>>>> Еще раз есть кроссплатформенный .Net Core, который кстати позволяет работать только с используемыми библиотеками. S>>>>https://habrahabr.ru/post/311520/ и не зависить от Фреймворка. Так что твои умозаключения об зависимости от фреймвока нет. S>>·>Я запутался. Зачем и core, и native? S>> А, то что в для .Net Native нужны библиотеки по .NetStandard ·>Понятнее не стало. Зачем две технологии? Зачем два названия?
.Net Native это технология компиляции, но для компиляции он использует библиотеки созданные по определенным стандартам https://docs.microsoft.com/en-us/dotnet/articles/standard/library
S>>>> Главное скорость, расход батареи, обфускация. S>>·>Скорость чего? Инстолляции? Кого это парит? Расход батареи тут не причём, т.к. ART компилирует только в install time (времени расходутеся как правило меньше, чем на скачку). Сколько раз в день ты ставишь новый софт на свой мобильник? S>> Специально для тебя выделил твои же слова. ·>У тебя путаница с ЖЦ приложения.
Значит я тебя понять не могу. NGEN ускоряет загрузку приложения. Будешь с эти спорить?
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Ikemefula, Вы писали:
I>·>Это же числодробилка чистейшая. Я говорю о среднем случае, для типичных задач. I>Это числодробилка и она еще проще алгоритмически, нежели сортировки.
Проблема не в алгоритмической сложности, а то что конкретно этот алгоритм хорошо ложится на специализированные команды процессора.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>Да и то вопрос — если там ресурсы, это уже "языковая" утечка, или как? Ибо если ресурсы c prompt finalization то и на Java будет тот же ref-counting, только кривой
Именно так. Построить надёжный ref-counting ср-вами управляемых языков невозможно.
У них операция копирования не подлежит переопределению, поэтому любой ref-counting получается только с "ручным" слежением за ним.
EP>Отсутствие же утечек других родов легко гарантировать (в том смысле который ты называешь "языковым") — не используй голый new, используй RAII — и проблема решена (именно в плане "языковых" утечек). Легко верифицируется простым grep'ом (либо Clang'ом, но чуть сложнее).
EP>·>А я имею в виду утечки памяти на уровне самого ЯП. EP>Тут грань очень тонкая, ибо никогда не используемые данные на которые есть ссылка — это тоже утечка, и могла бы например разруливаться на уровне ЯП/компилятора (особенно если язык не полный по Тьюрингу).
+100500
Когда-то лет 20 назад вокруг VB/VBA были аналогичные здравые рассуждения.
С тех пор память компов выросла многократно и народ малость подзабил на сей очевидный момент.
Здравствуйте, ·, Вы писали:
I>>·>Это же числодробилка чистейшая. Я говорю о среднем случае, для типичных задач. I>>Это числодробилка и она еще проще алгоритмически, нежели сортировки. ·>Проблема не в алгоритмической сложности, а то что конкретно этот алгоритм хорошо ложится на специализированные команды процессора.
Не смеши людей. Тривиальные циклы по массивам уже дадут тебе отставание в десятки процентов.
можно увидеть упрощённую сводную табличку результатов. Там же есть ссылка на Java код данного теста (меньше 20 строчек) — покажешь как этот простенький примерчик довести до уровня быстродействия C++? ))) _>·>Это же числодробилка чистейшая. Я говорю о среднем случае, для типичных задач. _>Согласен что числодробилка. И согласен что в среднем по приложению будет совсем не такое громадное отставание, а как ты и говорил в пару раз. Но как на счёт упомянутых тобой небольших усилий, с помощью которых можно свести отставание к десятку процентов? ) Какая у нас будет оптимизация в случае данного кода? )))
Ок, согласен, что с simd у jvm дело плохо. Может когда-нибудь научится.
В общем-то я не утверждал, что всегда. Ты заявил, что "в разы медленнее". Я воспринял это как "обычно в разы медленнее", а ты, видимо, имел в виду "встречаются задачи, когда в разы медленнее".
_>·>Да и кстати C++ no-simd как раз в 2 раза быстрее таки. JIT похоже не умеет simd. _>Насколько я слышал умеет, но не для таких целей (автовекторизацию циклов действительно не умеет). Но как бы это не оправдание для отставания, как ты понимаешь. )))
А если ещё GPU вспомнить...
_>·>ИЧСХ — c# оказался ещё медленнее. _>Да, причём совершенно неожиданно для меня. Потому что по идее никаких предпосылок для этого нет. Ведь как язык то C# всё же получше. И никакого escape-анализа и т.п. тут по идее не возникает. Но практика вот показывает такое...
Практика показывает реальное положение вещей, а не обещания MS и веру адептов.
Тут вот ещё: https://benchmarksgame.alioth.debian.org/u64q/compare.php?lang=java&lang2=csharpcore
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>·>Язык становится динамическим ,когда тип языковых конструкций не проверяется компилятором. EP>Ещё раз, не язык становится динамическим, а в коде используется больше динамических подходов. Простейшее для понимания утверждение жеж
Динамические подходы зависят от задач, а не от языка. Использование std::map — динамический подход?
Ок, могу согласится, что использование динамических подходов в Java проще, чем в Плюсах. Это что, плохо?
EP>·> Вот например в c# EP>·>
EP>·>dynamic_ec.exampleMethod1(10, 4);
EP>·>
EP>·>т.е. синтаксически вызов метода exampleMethod1 выглядит как и вызов любого другого метода, те же лексемы. Но компилятор опускает проверку, т.к. знает о специальном исключительном случае "dynamic" типа. EP>Замени на dynamic_ec.call("exampleMethod1", 10, 4); — типизация статическая,
Ровно такая же конструкция может быть и в С++. Почему возможность такой конструкции ставится в упрёк именно Яве, хотя ровно то же можно сделать и в С++?
EP>а код такой же динамический как и с dynamic в C#, со всеми вытекающими недостатками (типа меньшего количества статических проверок).
Нет, не такой же. "exampleMethod1" это просто строковой литерал, а exampleMethod1 — символ языка.
EP>·>в java таких "фич" нет, и не надо. EP>Нормальная фича.
А смысл? Ни автодополнения, ни рефакторингов, ни goto definition, нифига.
EP>>>Утрированный пример: something.call("function_name"); — ошибка в имени функции вылезет только в runtime даже в языке со статической типизацией. EP>·>Утрированный пример: std::map<std::string, std::function<void> >something; something.at("function_name")();. Ну как? Запишем таки С++ в динамические языки? EP>Ты не понимаешь о чём речь. И на C++ можно писать с кучей динамики, более того можно вообще дёргать eval какого-нибудь динамического языка. EP>Речь же о том что обычно на Java больше динамики чем на C++, а не о том что у него типизация динамическая.
Так какой такой особенной динамики?
Может ты имеешь в виду рефлексию? Да, простота, которая даёт рефлексия делает возможным строить системы для связи с языковыми конструкциями (т.е. символ языка становится рантайм-значением) — вчерашний студент может наворотить что-то с рефлексией и оно даже будет работать. Но это преимущество Java, сделать что-то работающее на Плюсах — гораздо сложнее, поэтому и применяется реже. Обычно делают хрень с макросами или какой-нибудь генерацией исходников каким-нибудь жутким m4.
EP>·>Ты похоже путаешь "статический|динамический полиморфизм" и "статический|динамический язык". EP>Прикольно, вообще-то это ты тут запутался. Я не говорил что у Java динамическая типизация — перечитай сообщение ещё раз.
Я не понимаю что ты имеешь в виду "больше динамики". Скажем, весь такой жутко динамический PHP и Пайтон написаны на C++ — это означает, что в C++ больше динамики?
Java тоже написана на С++, значит по определению "динамичнось" С++ не может быть меньше "динамичности" Явы. Шах и мат
EP>>>Твой оппонент говорит о том (и с чем я согласен), что в коде на управляемых языках программисты как раз склонны EP>·>Потому что ничем не грозит. В Java неправильное приведение типа — исключение, в Плюсах — UB. EP>Ты опять не понимаешь о чём речь.
Тут мне vdimas говорил, что в Java программе чаще используются касты (похоже, там у них специальный человек с плёткой стоит и заставляет всех касты в java код вставлять).
EP>Дело не в UB или ещё в чём-то (в одной из форм dynamic_cast как раз исключение) — ещё раз посмотри на dynamic_ec.call — там никакого UB.
Ок. В чём тогда разница между Явой и плюсами в этом смысле?
Ксати, dynamic_cast вообще в Яве не существует. Опять получается, что С++ более динамичный!
EP>>>к излишнему динамизму по сравнению с C++ — в котором например статический полиморфизм используется повсеместно. EP>·>Потому что обычный полиморфизм тормозит. EP>В этой под-теме не важно почему — факт того что в C++ больше статики налицо. Больше статики — больше проверок времени компиляции.
Может и налицо, но это мнение, зависящее от твоей интерпретации понятий, а не факт.
EP>>>Возможно EP>·>А есть что-то реальное, а не заброшенный 10 лет назад студенческий курсовик? EP>Твоё утверждение о невозможности — не верно.
На текущий момент — верно. Ты вообще читал-то сам что это, прежде чем предлагать это как возможность кодогенерации в Плюсах? "a simplified, C-like sub-language with first-class arrays and no pointer arithmetic" — так ещё никто Плюсы не оскорблял.
EP>Банально с собой можно тасккать компилятор — и получаешь runtime кодогенерацию.
Компилятор не является частью языка или платформы. javax.tools.JavaCompiler — является. Вот когда появится std::cpp_compiler или ладно, я даже согласен на boost::cpp_compiler — поговорим.
Плюс ещё java.lang.instrument есть.
EP>А какой-там пример — заброшенная библиотека или например OpenCL — рояли не играет — если проявить чуточку фантазии то будет и runtime-кодогенерация
С чуточкой фантазии и единороги радугу едят.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, ·, Вы писали:
_>>·>ИЧСХ — c# оказался ещё медленнее. _>>Да, причём совершенно неожиданно для меня. Потому что по идее никаких предпосылок для этого нет. Ведь как язык то C# всё же получше. И никакого escape-анализа и т.п. тут по идее не возникает. Но практика вот показывает такое... ·>Практика показывает реальное положение вещей, а не обещания MS и веру адептов. ·>Тут вот ещё: https://benchmarksgame.alioth.debian.org/u64q/compare.php?lang=java&lang2=csharpcore
С этими бенчмарками чтото непонятное, PHP и Node.js не просто лидируют, а рвут в говно плюсовый вариант
